Ok, so the curiosity got the better of me, and I decided to take a look at the x0rfbserver program.
I grabbed the source tarball and looked at the code, to see if I could understand how it works, and what it would take to eliminate the pop-up dialog and to setup the properties via commandline args. What totally surprised me was the COMPLETE lack of comments and documentation. If you guys EVER catch me distributing code like this, then get a gun and shoot me! Maybe they figured that the comments would all be in German and, and most people wouldn't understand anyway, but jeez. at least give us a clue of how the thing works. I come from a Cobol world, where the idea was that the code would be self-documenting, and even my cobol code contains tons of comments. Ok, enough ranting :) 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 ? 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
