LTSP PXE Thin Clients

PDF version

One of the projects I've worked on at the University of Kansas, School of Engineering is the thin client PiXiE thin client project. This project started as brainstorm for creating high performance machines that provide limited but critical functions for engineering students. As a university we have constant budget problems and a difficult time coming up with enough money to maintain current computer hardware. This problem is compounded by the fact that engineers use a lot of high end memory, graphics and processor intensive software for modeling designs. Add to this that most of our students have better computers than we can offer due to budget constraints and typically only use our computer labs for free printing and Web access at school and we have the PiXiE projects.

I have always been fascinated by the power, affordability, and flexibility of thin clients. The ability to provide a high performance computer with client being any old piece of junk lying around--assuming the server is adequately specced--and single system configuration is absolutely perfect for the university environment. The cost of upgrading one machine every three years, even at 10 times the cost, is certainly cheaper than doing the same for fifty machines, not to mention the administration overhead of managing a single machine over sixty.

This solution would seem ideal for our public computer labs, but unfortunately the software that engineers require is typically 3D graphics intensive, and pretty much puts that idea on the bench as the end all solution. Luckily it still does provide an excellent solution for a subset of engineering computer labs by being exceedingly good at providing basic office productivity, printing and Internet functionality. Thanks to application usage statistics via Microsoft System Center Configuration Manager, we were able to figure out just what percentage of our computer labs were those functions, and the results aren't terribly surprising. Out top ten most utilized applications are office suite and Internet applications. With these numbers and a roughly run student server we decided to go ahead with piloting a thin client solution in our most highly utilized lab.

For the thin client solution to work we needed to address the primary problems of our regular thick client Windows workstations. Most notably this was logon times that exceeded three minutes for first logons and slow application startup times. I also had no budget to work with, a decommissioned Web server, and could primarily only do this in my spare time as management was not terribly supportive of the project. With all of these factors the best solution was to use a free and open source solution. The great performance of Linux and its fast login times, plus the highly stable LTSP Project made a great combination for providing fast logons and quick application load times with limited hardware.

One of my first swags at implementing LTSP was to first look at prebuilt LTSP distributions so that I could evaluate whether this was going meet the requirements of the project with the smallest amount of configuration to get it up and running. To that end I came across the Skole Linux project. After downloading the DVD and following the dead simple installation instructions available on the DebianEdu Wiki I had a working thin client in server in about an hour.

Messing around with the new thin client and server confirmed that the LTSP solution would more than adequately solve our logon and application load problems, but getting our Windows trained students to understand and use IceWeasel and other pure Debian quirks as well as the age of the distro didn't seem plausible. Not to mention that the Skole Linux distro is a little too feature complete for our distributed service environment. This lead to us pursuing an Ubuntu LTSP solution. The Ubuntu LTSP package and documentation seemed absolutely perfect. It provided a modern Debian distribution with SSH secured LTSP, Firefox, and strong user support community at the convenience of just a few "apt-get installs".

So following the guide on the Ubuntu LTSP Wiki I was able to again setup a working LTSP installation in about two hours. The installation happened in about an hour but there was problem getting the whole thing working with PXE boot as the TFTP server was not setup to start automatically. To fix this I had to modify the /etc/default/tftpd-hpa file to:

 

#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /var/lib/tftpboot"

The only change I made was RUN_DAEMON="no" to RUN_DAEMON="yes" and then starting the service.

After that I had a working client that had current software, fast logins, and surprisingly fast launch times for applications like OpenOffice.org. This seemed like the perfect fit for this solution and all that remained was customizing everything to better fit our environment and increase the performance of some silly things such as select boxes in Firefox from taking 10 seconds to drop down.

The customization started by joining the computers to the KU campus' domain for user authentication and access to network shares. This was done using Samba and Winbind. I did so by primarily following this Active Directory and Winbind Howto. The only modifications from that document were adding:

 

winbind enum users = no
winbind enum groups = no

I had to do this to the very large nature of the university active directory, and without those options set, the authentication simply did not work.

After getting that to work I needed to automatically mount network locations to the users home directories on logon. On the Windows lab machines we redirect user's Desktop and My Documents using group policy, and providing transparent access to the user's files is an important aspect of the project. In order to make this happen I needed to do two things. The first was mounting the common user's SMB share to their home directory. This was accomplished using the pam_mount library with a configuration similar to:

 

<volume fstype="cifs" server="fs" path="profiles/%(USER)"
        mountpoint="~/U Drive" options="workgroup=DOMAINNAME">
        <and>
                <not><user>root</user></not>
        </and>
</volume>

On the Windows side we mapped this network location to the U: drive, and thus the name seemed appropriate to helping the users adjust to the new environment. A key to making this work properly on first logon was adding the "U Drive" folder to /etc/skel/. With the network drive mounted and properly chowned, we still needed to redirect the user's Desktop and My Documents. This was easily done with the .xinitrc script by rming the Desktop and Documents folders that Gnome creates by default and symlinking them to the "U Drive" path where those folders existed. This effectively created an identical environment to the Windows machines.

Next on the hit list was improving performance of the most utilized applications. Most notably this included Firefox, Flash, and Java. In order to eek out some extra performance here, and reduce the load these applications caused on the server we chose to the LTSP local_apps feature. This allows you to install applications onto the RAM image that is run by the thin clients and run them on that hardware--as opposed to the server's iron. This was a simple process and simply involved doing:

 

sudo chroot /opt/ltsp/i386
apt-get install firefox
apt-get install adobe-flashplugin
apt-get install sun-java6-jre
apt-get install sun-java6-plugin
exit
sudo ltsp-update-image

After that, I just had to modify the default shortcut in /usr/share/applications/firefox.desktop to have the exec line be ltsp-localapps firefox %u

Next up was getting USB devices to mount properly on the thin clients so they were accessible to the user. This turned out to be a bit more tricky than expected. I followed the advice on the Enable Local Devices section of the Ubuntu LTSP Wiki, and was able to get local devices to mount for root, but nor for our regular users. The reason here is that we were not using local users and with around 3,000 of them, adding them all to the FUSE group was not really doable. To get around that I modified the FUSE udev rule in /etc/udev/rules.d/45-fuse.rules to:

 

KERNEL=="fuse", GROUP="fuse" MODE="0666"

to resolve that. There was also an issue with the USB drives being mounted to /media/USERNAME/DEVICENAME as caused the USB drive of one user to show up on every user's Desktop and Places section of gnome (even though they didn't have permission to access it). This caused a lot of confusing and was not easy to resolve. This was fixed by modifying a python script that does the mounting to move the mount point to the user's home directory. The script is /usr/sbin/ltspfsmounter. And the fix was to set the root and mediaroot variables in main to the user's home directory. Something like:

 

    root = "/home/%s" % get_var('USER')
    mediaroot = "/home/%s" % get_var('USER')

as well as commenting out the call to lbmount_command in the add_ltspfsmount function.

That pretty much take care of everything I wanted to do with the server and thin clients. The next step just involved booting the clients via PXE over the network. This ended with the result of well received, fast working, basic computers that if they were ever decided to be converted back to the Windows workstations they once were just required a reboot and a modification to the boot order (boot from disk first instead of the network). The other benefit of this all running in a RAM disk over the network is that if the thin client server is ever down, the clients will just boot from the hard drive instead of the network, leaving them as slow but fully featured WIndows workstations.

Overall the project has been quite positive on the few machines we have tried it out on. We are only running the thin clients on eight machines and we average 20-30 users a day and have had over 250 users logon to them over a one month period.