[K12OSN] RE: OOserver

Nathan Shaffer nathan at grandvache.com
Fri Apr 16 16:39:39 UTC 2004

We do this for our 31 station lab. Rsh is utilized between the two 
boxes on a "closed" loop (crossover cable between the "desktop" server 
and the "application" server using gigabit).  By creating the separate 
class C network between the two boxes and only allowing rsh between the 
two servers on those specific ethernet slots we contain the openness of 
rsh.  We wrote a wrapper that looks like this:

# wrapper script to run ooffice remotely from appserver

xhost +appserver
rsh appserver "export DISPLAY=$DISPLAY; ooffice"

The wrapper is in /usr/local/bin. The users don't need to use the 
terminal.  If you look at the desktop tray, the command under 
"properties" may look something like "ooffice %u".  You may have to 
change the PATH that Gnome uses to get to the wrapper or where you 
locate the wrapper.  We're using 3.1.1 on the "desktop server" and 
didn't have to change the PATH.  We use this for OO, Evolution, 
Mozilla, and a host of other apps.   We mounted the NFS /home on the 
applications server so that when you open the application  and want to 
open a file that's been saved, it opens to the users "home".  There is 
a lot of bandwidth usage when you've got 30 users running slideshows 
with pictures/graphics, etc that we upgraded to the gigabit between the 
boxes due to bottlenecks.  This configuration makes it very easy to 1) 
update applications like OOffice because you don't have to worry about 
LTSP integration 2) install new applications for educators to try at 
their request. We've even installed WINE on the appserver to see what 
we can do with that (school mgmt uses Wintel apps).

One recommendation is to use the "purge process" so that if one 
terminal gets locked up using an rsh'ed application, when they log in 
on another terminal, it'll clear out the <defunct> rsh processes.

Nathan Shaffer
nathan at grandvache.com
St John the Apostle School
Oregon City, Or

> On Fri, 2004-04-16 at 01:18, Thomas Ryan Gordon Sr wrote:
>>  If k12ltsp was on box 1 and the system was being heavily taxed
>> | by open office use (just as an example) how can one attach a second
>> | box (box 2) so that all instances of openoffice run on box 2 but
>> | appear on clients served by box1, so that the resources used by
>> | openoffice primarily tax box 2?
>> you would use rsh or ssh to forward the X.  make sure there is plenty 
>> of
>> bandwidth between the two boxes.
> There is a big difference in what happens with rsh or ssh when
> your $DISPLAY is already on a different machine than where
> the command is issued.  Ssh makes a fake local $DISPLAY on
> the remote side that is transparently port-forwarded back
> to the machine where the command was issued over the encrypted
> connection, then sent on to the original $DISPLAY.  That means
> that the server running the window manager that you were
> trying to off-load is still involved.  With rsh, your
> original $DISPLAY is passed along or you would set it
> explicitly to point to the thin client.  Then when the
> program starts it will make it's own connection to $DISPLAY
> completely independent from the connection where the
> command was issued.  Rsh is less secure but off-loads more
> of the work.
	allow me to elaborate on your points: 1. rsh is not so much "less
secure", but "totally insecure" seems to describe it well. 1.a to run 
you need to open the access to the terminal display and keyboard.  this
may, or may not be a concern. 2. the additional load caused by ssh is
negligible compared with the load of running oo. 3. depending on the
balance between processing power and bandwidth you can adjust ssh
compression to taste.
	my $.02, julius

More information about the K12OSN mailing list