[K12OSN] Improve loading time for OOo

[Samps]

David Trask wrote:
> OK....several questions....see below

Answers attempted inline....

> 
> Samps <samps at redjocks.com> on Tuesday, October 12, 2004 at 9:21 PM +0000
> wrote:
> 
>>
>>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
> 
> 
> +++++++++++
> how do you....or is it possible...to simply export the home directory and
> have it show up as the "home" directory on the K12LTSP desktop.  My users
> are used to saving to their home folder on the K12LTSP desktop OR in
> Windows...to their home folder which is mapped to drive Z in "My
> Computer".  The only hurdle I see, and it may not be one as I've not tried
> it ...is the fact that the SME user directories contain both "maildir" and
> "home". 

You hit the nail on the head, the problem is that E-smith doesn't export 
  the same folder that gets mapped as 'home-dir' in Windows, at least I 
haven't found a way to achieve this.

  Did you create "LTSPhomes" prior to creating the users....

Yes, the LTSP-homes folder is created first, exported through NFS and 
when users are created on the LTSP server I tick the option "create 
/home/username" which gets created as a folder on the E-smiths 
LTSP-homes folder

did the
> permissions set right?  

Yes, I use the parameters RW, no_root_squash in the line in EXPORTS that 
defines the exporting of LTSP-homes. I think I can recall that NFS 
relies on UID and GID to allow access to folders and files and only the 
folder with the users name has the right UID/GID and gets shared read/write.

How about this scenario?  Could I create
> /home/e-smith/files/users/LTSPhomes  export and mount via NFS as the users
> home directory on K12LTSP (no desktop mapping or anything like that...I
> simply want the "home folder" to be the default simply mapped to the
> LTSPhome on SME server....I use SAMBA/LDAP now and I export and mount
> "home" from one server to another...on the desktop it's transparent)  
> Then in Windows..simply mount "LTSPhome" as a drive?
> ++++++++++++++
> 

I don't know if that's possible, haven't tried. My guess is that it is 
possible. The users will then see a list of all users folders and will 
have to find their own..? Better hope permissions are okay. I'll give it 
a go tomorrow, I still have a week 'till I have to get 'airborne'.




>>
>>(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
> 
> 
> ++++++++++++
> Assuming that I mount the export of LTSPhome as "home" on the K12LTSP
> server....since I'm authenticating to the SME server anyway...I shouldn't
> need or be bothered by a password at all right?  Especially when dealing
> with my "own" home directory.
> ++++++++++++
> 

That is a fair assumption. Since you're logged in, your credentials are 
known to the E-smith. Is there a variable in Linux like $PASSWORD or 
$SMBPASSWORD? If so, replace the crdentials=./.creds.txt with 
username=$USER,password=$PASSWORD and it should mount during login... 
Another thing I'll have to try tomorrow.

>>
>>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
> 
> 
> 
> David N. Trask