[K12OSN] Improve loading time for OOo

Samps samps at redjocks.com
Wed Oct 13 00:55:38 UTC 2004


David Trask wrote:
> "Support list for opensource software in schools." <k12osn at redhat.com> on
> Monday, October 11, 2004 at 10:21 PM +0000 wrote:
> 
>>Hardware is dual AMD Athlon XP1700 w. 1Gb SDRAM, user homes exported 
> 
>>from an E-smith SME server using NFS
> 
> I'm very curious as to how you're doing this.  I'm a big E-Smith user, but
> I'm using Samba/LDAP for my current setup.  I'm able to get NFS and all
> working on E-Smith as I have an E-Smith server being used for backups and
> so forth with variuous NFS directories being mounted or exported.  How are
> you authenticating?  Samba?
> 
> David N. Trask
> Technology Teacher/Coordinator
> Vassalboro Community School
> dtrask at vcs.u52.k12.me.us
> (207)923-3100
> 
> 
> 
> 

David,
Sorry for the late reply...  Sleeping took a bit longer than expected.

I've replied to the list, as I thought there would be a general 
interest, please forgive me...


Yes, Samba for authentication.

The E-Smith is set up as a Domain Controller and we're using roaming 
profiles for the Windows clients.
The LTSP servers have one NIC each and are all on the same switched 
subnet, along with 240 clients and some 10-11 other servers, mostly 
E-smiths.


On the E-smith DC:

Installed PORTMAP
Installed NFS (older version, newer one refused to install)

Created a folder, /home/e-smith/users/LTSPhomes
exported /home/e-smith/files/users/LTSPhomes over NFS to our LTSP servers

(having trouble making PORTMAP and NFS start up at start-up, still 
starting them manually)

I have given up on getting LDAP to work for authentication, at least for 
now, I've spent too much time on it, compared to the expected outcome. 
Samba will have to do for now.



On LTSPs (4.1.0):

Set authentication to SMB, entered IP-addy of DC (just in case DNS ain't 
working), used the GUI 'Authentication Tool' for this.

Added an entry /etc/fstab like:
server-ip://home/e-smith/files/users/LTSPhomes  /home   nfs  rw,udp  0 0
this ensures that /home is in one spot (the e-smith DC), regardless of 
which LTSP the user is currently using.

Our internal IP-range has been split between our four LTSP servers, with 
about 500 addresses each, no overlap. The idea being that whichever 
server is fastest to answer a DHCP request is also the one best suited 
to serve the client asking. Not 'real' load balancing but it seems to 
work okay with the few clients that I have tried it with.

Added a folder in /etc/skel, called H-Drive (our users are in the habit 
of saving their stuff to a drive representation...  it's a Windows 
thing, don't ask ;-) and a hidden file called .creds.txt which is, 
initially, empty.

Users data, residing on the e-smith DC, is mounted to their 
/home/H-Drive folder by a line added to GDM:
/usr/bin/connect.sh
the contents of which is:

#!/bin/bash
smbmount //DC-name/$USER /home/$USER/H-Drive -o 
uid=$USER,gid=$USER,credentials=./.creds.txt

a launcher is added to /etc/skel/Desktop which points to connect.sh. 
When the launcher is called, smbmount will ask for the password for the 
users home-directory on the Samba e-smith DC and mount it on the 
/home/H-Drive folder.
If the user adds a line like: password=users-samba-password in the 
.creds.txt file, the home directory will be added by GDM during logon, 
no questions asked. Tip from Mike Rambo, thanks Mike.



The reason we are mounting stuff from other servers, using descriptors 
like 'H-Drive', is, that all our client computers are running Windows 
2000 at the moment and we want to make it as transparent as possible for 
the users to switch between Windows and Linux, as all our PCs (bar a 
handful specialised Windows ones) will PXE-boot into K12LTSP unless the 
users interrupt this process, in which case they get a Windows 2000 
loaded from the local disk.

The beauty of this setup is:
a)That we don't have to rush out and re-image a Windows installation, 
they can do most work on the K12LTSP
b) Even as hardware fails (disks) the PC is still usable
c) The K12LTSP is always 'fresh' (or can be made 'fresh' by the users 
themselves
d) As the size and complexity of applications increase, the locally 
installed Windows suffers from hardware restrictions and the K12LTSP 
scales to suit
e) In some areas, where the most unruly kids hang out, there won't be a 
possibility of booting to anything BUT K12LTSP
f) We are able to use quite old hardware, which we actually buy as 'good 
second hand', so we get twice as many 'bums on seats' as we would if we 
had to constantly cater for the latest and greatest in locally installed 
Windows programmes.

cheers
Samps




More information about the K12OSN mailing list