Oy! To much info. I read through that twice and its still blew me away.
Anyway. I think your on track for what I would love to see. These points No end user visibility or intervention required. (even the password supplied by the admin invoking the session) Not always running (I have lots of 486's with 16 meg O ram) Would local apps have to be enabled? I'd prefer it if not. I realize that it needs to run on the client machine but is there a way to work around this so that local apps don't have to be setup just for the use of Xorfb? That's not a big deal I just don't have local apps setup yet so it would be more work (not that I'm lazy) This sounds awesome. Matt > -----Original Message----- > From: Jason Bechtel [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 2:42 PM > To: [EMAIL PROTECTED] > Subject: [Ltsp-discuss] RE: X0rfbserver Citrix Server semi-sol'n > > > John, > > Sounds like lots of good news. Nice work! > > > Date: Thu, 6 Jun 2002 09:13:18 -0700 (PDT) > > From: John_Cuzzola <[EMAIL PROTECTED]> > > > > *** Hi All, > > I have been using x0rfbserver and it CAN work with > remote > > (non-local) sessions (with caveats). > <snip> > > > > First set your lts.conf to runlevel 3 (or whichever ltsp > 3 uses) so that > > it drops you into a shell prompt as root. > > Okay, this is obviously not going to be a part of the final > product. :-) As you mention later, this can all be put > into an rc file and run automatically each time. > > > ok now launch your X session like this (this is one long > line): > > > > /usr/X11R6/bin/xinit /usr/bin/X0rfbserver >& /dev/null -- > /ltsbin/XF86_S3 > > -ac -query <your ltsp server ip> > > So, *all* workstations would *always* be running a > x0rfbserver? This is an undesirable requirement. This > puts a load on many terminals that may never need shadowing > help. Even for those who might occasionally need help, > they shouldn't have to always be running the x0rfbserver, > even if it is hidden. Some workstations are lowly 486's > with minimal RAM... > > > This will launch x0rfbserver and give you a login screen. > You'll notice > > that x0rfbserver will ask you for the password. Just > leave it blank for > > now. To get rid of it simply run x0rfbserver as some > user. Enter the > > password then COPY the .x0rfbserver file from that users > home directory to > > the ltsp root. For me that would be: > /tftpboot/lts/ltsroot > > Cool trick! Good work! :-) > > > The x0rfbserver program can be shutdown by the user. > However, if they > > do their X session will terminate and send you back to > the login > > screen. (after changing your runlevel back to 5). I guess > they would learn > > very quickly not to shut the thing down. I tried some > simple stuff in > > order to hide it like issuing a -geometry directive and > moving the > > x0rfbserver box outside the viewing area but apparently > it doesn't honor > > it. I suppose it wouldn't be to big of a deal to edit the > source code and > > attempt to hide it (which I may look at when I get a free > moment - I'm > > sure the very capable programmers on this list can hack > something up > > quicker than I) > > This is what I was talking about in my last message. We > don't want any visible face on this program. And in order > to remove the X interface from it, we'll need to modify the > source code. > > I think our next step should be to contact the author(s) of > x0rfbserver and explain our requirements. Probably the > easiest way to get what we want is to ask for a feature and > get approval from the maintainer. We don't want to change > the code and then tell the maintainer that he should > incorporate our modifications or face a fork! If the > author has no time or interest in our mod, he or she could > at least recommend the best way to go about doing it, both > from a purely technical standpoint (which source files to > modify) and from a logistical standpoint (perhaps adding it > as a "plug-in" type feature instead of as a large > modification to the base code. I don't know, but let's > just contact the author first... > > I envision a simple command-line arg that disables the > interactive components (X interface). The invocation of > the app would then just be a script run by the > administrator like this: > > # the following line returns, leaving > # x0rfbserver running on the workstation (hopefully) > rsh ${WKSTN} /usr/X11R6/bin/x0rfbserver -stealth & > # the following line does not return until the admin quits > xrfbviewer ${WKSTN}:0 > # thus, the x0rfbserver gets terminated only after the > viewer exits > rsh ${WKSTN} killall -9 x0rfbserver > > Not sure about the details yet. Might not need the &. > Maybe better to just get the PID of the first rsh call and > kill it off from the server instead of starting another rsh > connection... > > Sound good? Is this what other people are also imagining? > > 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 > > _____________________________________________________________________ > 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
