*** Oh yes, sorry about that...I guess somewhat of the confusion is LTSP
Version 2 to 3. It is significantly different. I haven't had the
opportunity tpo try version 3 but since we're using version 2 and working
fine there are no plans to switch. Yes you'll need to be able to run the
xinit command. I'm not sure exactly how Version 3 does this I know that
the binaries are now supplied as opposed to copied over from the server. I
guess Jim would be best to answer (again sorry - I just don't know enough
about version 3). Based on my quick instructions I'm sure Jim understands
the concept and could tell us how it relates to LTSP 3. Basically our
setup is this. For every client we default to running locally which means
in the ltsp 2 days that /usr, /home, /opt ... are NFS mounted. For
programs the clients can't handle we 'log' into the server (via
rsh,ssh,whatever script) set the DISPLAY and shoot it back to the
client. This makes things like x0rfbserver easy to set-up. For running in
the default 'remote' mode, the instructions I sent work for LTSP 2 and I
would guess they would *almost* work with LTSP 3. The concept is not too
difficult but you would need someone much more familiar with LTSP 3 to
fill in the gaps (hint hint Jim *smile*). Anyways the basic concept is
both version 2 and version 3 of LTSP launch X with a file:
/tmp/start_ws
in that file it normally looks something like:
/ltsbin/XF86_SVGA -ac -query <ip of the server>
If that was changed to:
xinit /usr/bin/x0rfbserver >& /dev/null -- /ltsbin/XF86_SVGA -ac -query
<ip of the server>
and assuming all of the above components were available to the client
(xinit, x0rfbserver - probably will have to copy them down to the client's
tree) then RFB should launch and you should be able to connect to the
client (using the clients IP and xrfbviewer) With the caveats mentioned.
On Thu, 6 Jun 2002, CARRIE COY wrote:
> Sorry to be obtuse, but I'm confused by what you're doing here (and I'm
> dying to understand). How complicated is it to set up to run a "local
> window manager"? Why would someone want to run a local window manager
> (to be able to easily launch local apps?). Which WM are you running?
>
> Did you have to copy "xinit" and x0rfbserver into the /ltsroot directory
> to run them locally?
>
> If you care to expand on your post, I'd be very grateful.
> --
> Carrie Coy
>
>
> John_Cuzzola wrote:
>
> >
> >*** Hi All,
> > I have been using x0rfbserver and it CAN work with remote
> >(non-local) sessions (with caveats). I run my window manager locally and
> >if the user wants help he/she must launch x0rfbserver and tell me his/her
> >password (otherwise they don't get my help!)...Anyways it a simple thing
> >to copy a .x0rfbserver config file into their home directories and make it
> >immutable so they don't need to set a password. But I digress...Here's how
> >you can make x0rfbserver work remotely. I'm using an older LTSP version
> >2.xx but it should still apply to version 3. To experiment try this:
> >
> >First set your lts.conf to runlevel 3 (or whichever ltsp 3 uses) so that
> >it drops you into a shell prompt as root.
> >
> >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>
> >
> >
> >Substitute /ltsbin/XF86_S3 as appropriate for your Xserver (It's probably
> >just XFree86 for version 4)
> >
> >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
> >
> >After the user logs in try to connect to the box with
> >
> >xrfbviewer <ip of client>:0
> >
> >and it should work. To make the change permenant you'll have to edit the
> >rc.<whatever> script to have it recreate /tmp/start_ws file as above
> >(trivial).
> >
> >CAVEATS:
> >
> > 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)
> >
> >:)
> >
> >
> >On 6 Jun 2002, Derek Zoolander wrote:
> >
> >
> >
> >>On Wed, 2002-06-05 at 11:21, John_Cuzzola wrote:
> >>
> >>
> >>>
> >>>*** Oh yes,come to think of it , it was running as a local app
> >>>
> >>>
> >>>
> >>>
> >>Hi John,
> >>
> >>I am messing around with this at the moment. It works perfectly on stand
> >>alone computers but fails when used from the thin client.
> >>
> >>I am using x-class-0.6.2 as a static lib and rfb-0.6.1
> >>
> >>If I run the X0rfbserver on the server and try to connect from the thin
> >>client I get
> >>
> >>X Error of failed request: BadAccess (attemp to access private resource
> >>denied)
> >>
> >> Major opcode of failed request: 129 (MIT-SHM)
> >> Minor opcode of failed request: 1 (X_ShmAttach)
> >> Serial number of failed request: 1096
> >> Current serial number in output stream: 1097
> >>
> >>
> >>OR
> >>
> >>
> >>If I run the server on the thin client I get "Connect Error" on the
> >>server when running the viewer on the server and trying to connect to
> >>192.168.1.3 which is the thin client. The server is 192.168.1.7, if I
> >>try to connect to it it get a whole stack of info but the important bit
> >>at the end is almost the same as above, the last two lines are,
> >>
> >>Serial number of failed request: 252
> >>Current serial number in output stream: 263
> >>
> >>looks like some sort of security thing!
> >>
> >>How did you get it to run locally, I have copied the binaries to the lts
> >>directory also the static lib and I run netscape locally with no
> >>problems using rsh.
> >>
> >>
> >>
> >>
> >>
> >>_______________________________________________________________
> >>
> >>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
_____________________________________________________________________
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
