John, My most heartfelt thanks... While I was strolling around LinuxTag 2002 in Karlsruhe you were working on this vital project. Thank you!
> Well after spending most of my Saturday playing with 0xrfbserver source code I believe I have added the > "-stealth" option. Here's how: > > step 1: > Compile xclass version 0.63. Get it at: > > http://sourceforge.net/projects/xclass > > (this step is probably optional as older xclasses will most likely work but just-in-case) Or, if you are using SuSE, xclass might not be installed (original 7.2 base distro). I'd keep this step in... :-) > step 2: > Grab & untar x0rfbserver version 0.6.1 get it at: > > http://download.hexonet.com/software/rfb > > step 3: > Grab my patched files for: > > x0rfbserver.cc > OXServiceApplet.cc > > which replaces those in the x0rfbserver sub-directory you untarred in step 2. (yes I know I should > have made them differential patches!). Get those files at: > > www.sd73.bc.ca/tux/rfb By not making them patches, you've essentially forked x0rfbserver. Now, I know the word "fork" carries a lot of negative connotation in the Free/Open Source world, so don't get excited, people! All he's done is alter two files in a project. We're still at a point where it would be utterly simple to make diff patches against the original files. The question is then the classic one. Do we go on maintaining a set of patches for this project as the main development progresses? Or do we submit our patches to the author with an explanatory email and get them accepted into the main source? Obviously, the latter option is preferable as it requires (almost?) no ongoing effort to maintain the desired functionality. Hopefully the author will accept these patches. Has anyone contacted him yet? > step 4: > Compile as per normal as stated in the INSTALL file: > make depend > make > > That'll do it. An "x0rfbserver -help" should reveal the stealth option. This patch also includes the feature of > a GLOBAL .x0rfbserver file. If .x0rfbserver exists in / that will be used over ~/.x0rfbserver. This is useful for those > of us who run local apps and/or want the client to activate the daemon themselves but not have them enter their own password > or options (like disable keyboard & mouse). This global file needs to be placed in the root of the client. So in my > case that would be /tftpboot/lts/ltsroot; for other's it would be /opt/... If you issue a: This didn't exist in the original version? Maybe I'm confusing two projects, but I thought it looked for a global config file in <prefix>/etc/ (default /usr/local/etc/). But whatever program I'm thinking of also allowed user-specific .x0rfbserver files to override the global config file, the opposite of what your patch accomplishes. Now, since it is running as root on the workstation and root's home directory is / (I think), the original policy would seem to suit your current choice of /.x0rfbserver just fine... Anyhow, my take on this is that the file does not belong in LTSP's root directory. It either belongs in <ltsproot>/etc/ or in <ltsproot>/usr/X11R6/etc/ (if this dir exists). I'm not familiar with the LSB, but I know that Jim is trying to comply with it as much as possible. Also, the main configuration file should not be a hidden file (i.e. should not start with a 'dot'). > x0rfbserver -stealth > > and do not have either a /.x0rfbserver file or a ~/.x0rfbserver file the user will be prompted with the options box so > I would recommend running the daemon first without stealth, entering the wanted password, then copying the .x0rfbserver > file from that users home directory and use it for your global config. Excellent. Yes, if x0rfbserver cannot run usefully due to a bad or missing configuration, then it should absolutely appear and ask for the necessary info. > I would launch the program as described in my previous email with xinit like: > > xinit /usr/bin/x0rfbserver -stealth >& /dev/null -- /ltsbin/XF86_SVGA -ac -query <ip of server> Or perhaps Jim's new system under 3.1 will provide a better way. I believe he specifically implied that it would. > There has been a very valid concern of running this daemon when not needed and the overhead. Looking at the > source it appears the client goes to sleep and does nothing until there is a connection. Tests with 'top' confirm > this. Even with a connection the daemon's cpu usage is typically less than 8%. Again in my tests running with > xinit showed no speed difference while the daemon was waiting and even with a connection it was > barely noticeable on the workstation. My test environment is still limited to a VMWare virtual workstation and I cannot switch to a console once in XWindows in the workstation because my *real* console intercepts the keystrokes! Doh! :-) So, can you please look into memory usage by x0rfbserver? This is great news about the light CPU-usage aspect, but that isn't my primary concern. If it likewise has a small memory footprint, however, then this thing is a godsend!! :-) We could actually let it run on all the stations (option in lts.conf, of course) without noticable penalty! The question then is about limiting the valid sources of the connections (probably in .x0rfbserver, which should be immutable) and implementing simple authentication, such as what you suggested about returning a random string and writing it into the LTSP root directory, proving root access on the LTSP server. Thanks for spending a Saturday on this! I hope you didn't miss too nice of a day outside... :-) Jason _______________________________________________________________ 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
