> > What i'm trying to figure out, is: Does this thing > work with any Xserver, or does it have to be an xserver > that uses vesa ?
*** I believe it will work with any Xserver and it does seem to be fairly lightweight. Although being able to launch it on demand would be a plus :) > > Assuming it works with any Xserver, it may be a very lightweight > program, in terms of its memory consumption, and it may > very well sit there on a workstation without causing much > trouble. > > Then, when someone wants to view the session, they'd just > connect up to it. > > I can see where I'd like to add a dialog box, giving the > user a chance to permit/deny the connection. > > Anyway, I won't be doing much with this until I get v3.1 > out the door. > > Jim. > > > > On Fri, 7 Jun 2002, John_Cuzzola wrote: > > > > > > > > Ooh! What about this... What about starting a program > > > with xinit as was recently suggested, but instead of > > > starting x0rfbserver it starts a monitoring app? > > > > *** I've written a similiar program (God it's a hacked up mess, but I get > > by) that listens on the client machine (tcp port) for an incoming > > connection. It is specifically written for local apps use (it > > assumes it has certain NFS mounts available but the idea could work > > the same for purely remote). There's two parts the daemon (runs on the > > server) and the > > client (issued by user root on the server). The client connects and tells > > the daemon the full path of the program to run then runs > > it. Authentication of course is a concern and I've implemented a very > > simple method. It may be flawed but simple and I think it does the job in > > terms of safety: > > > > 1. Client program connects to the workstation's daemon via tcp on a > > specified port. The daemon returns back a random 50 character filename to > > the client. > > > > 2. The client writes the file to a directory > > '/tftpboot/lts/ltsroot/remote-auth' (or > > whatever. ie: /opt/..) and sends back the full path of the program to run > > with arguments and optionally the uid/gid it would like to have the daemon > > launch it as. > > > > 3. The daemon server checks to see if the 50 character file in > > remote-auth directory exists, sends back a confirmation to the > > client, forks and drops it's permissions (if > > requested) and launches the program. > > > > 4. The client deletes the no longer needed remote-auth/filename. > > > > the remote-auth directory permissions would be 600 with user/group as > > root. So only root can read/write to that directory (daemon runs as root > > which it needs to anyway to change to an arbitrary uid/gid not to > > mention that the LTSP root is mounted read-only anyhows). > > > > Aaaannyways there's a simple method which doesn't require > > username/passwords. > > > > > > > > > > > > > > > > > > > > > > > > The problem with running an rsh daemon on the > > > > workstations is that it needs to know WHO is sending > > > > the request to run something, and whether they are > > > > allowed to or not. > > > > > > > > By turning on local apps, you enable NIS. That is how > > > > the rsh daemon will validate that the "WHO" is a correct > > > > user. > > > > > > > > An alternative to NIS might be LDAP, but we haven't > > > gotten > > > > that to work for local apps yet. > > > > > > > > In the past, some people have suggested just copying the > > > > servers /etc/passwd file to /opt/ltsp/i386/etc, but I can > > > > tell you very clearly that will NEVER be part of a > > > > standard LTSP package. > > > > > > > > Creating a special-purpose daemon to handle this, in my > > > > opinion, is just reinventing the wheel. Use what is > > > already > > > > there, and spend your time solving other more important > > > > problems. > > > > > > > > But, I also invite you to challenge me on this. Maybe > > > you've > > > > got a better way. > > > > > > _______________________________________________________________ > > > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > > > _____________________________________________________________________ > > > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > > > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > > > For additional LTSP help, try #ltsp channel on irc.openprojects.net > > > > > > > > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _____________________________________________________________________ > > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > > For additional LTSP help, try #ltsp channel on irc.openprojects.net > > > > _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.openprojects.net
