Setting up an LTSP Thin client system

There are many technologies tempting your wallet these days with promises of secure, easy, efficient, low-cost, scalable desktop computing. Many of these are based on virtualized Windows, with proprietary technology at each layer of the whole solution. (Tom Holub and crew evaluated this Windows-based onion/parfait at Berkeley in 2008-2009.)

I say … meh.

Linux and the Linux Terminal Server Project (LTSP) have provided this kind of technology for at least a decade for free. It is being used in large rollouts in the 3rd world where the technology cost issue is most important and in the 1st world where the human costs are the main issue. Before you sink $thousand$ trying to stack proprietary technology upon proprietary technology, why not see what some free software can provide? If you have the (minimal) hardware, you can have an LTSP system up and running in about 2 hours. No licenses, no signatures, no faxes, no crippleware, no POs, no RFPs, no bids, no lawyers. And surprisingly few tears.

The LTSP is an Open Source Software (OSS) project that provides the entire software stack to enable you to provision and host multiple clients (repurposed PCs, explicitly designed thin clients, laptops) on one server. The pros and cons of using this approach are discussed in detail elsewhere, but they boil down to 2: It’s easier to maintain and much cheaper to support. The Wikipedia description is arguably better than the home site’s introduction and also discusses large scale deployment using the LTSP-cluster project.

You can think of the server as a big PC and the clients are little PCs. Since the clients function mostly as display devices and most computation happens on the server, most of the hardware investment is in the server. Any PC that can PXE-boot can be used as a client. All PCs made in the last ~4 yrs have this capability and there are ways to use even older PCs if necessary.

Modern PCs, even those made for home use are enormously powerful and typically a single office user will use about 1-5% of it’s computing power averaged over time. LTSP takes advantage of this power and the sophisticated networked, multi-user, multitasking abilities of Linux to allow other users access to this unused power. At the same time, LTSP provides access to more applications (and different versions of applications), more secure storage, protection from malware, and more memory than they would have as a fat client and at the same time makes it easier to retain user settings. A downside is that there is sometimes detectably slower response than there would be on your own PC, but sometimes there is noticibly faster response as well (for example if someone else has recently launched a program on the server,it will start up ~5X faster when you launch it).

LTSP scales well; as noted, you can add clusters of terminal servers and load-balance among them. You can supplement these with specialized application servers, so if you really need 250 people typing up OpenOffice docs as fast as they can, it might be more efficient to roll out an app server that does nothing but run OpenOffice. When more storage is needed, you can add networked storage with trivial ease. And LTSP integrated well into a Kerberos/NIS system. All this for free, using OSS.

We have to assume that you know some basics about Linux, root access & responsibility, editing configuration files, file ownership & permissions, and network configuration. Some idea about how a PXE-boot and DHCP works and would be useful but not necessary. If you’re a Windows administrator without much Linux experience, this may be difficult. The technology is similar but the terminology is different. You might want to browse a book first.

If you already have a Linux system prepped to set up an LTSP system, skip down to the LTSP installation & configuration. If not, follow along.

One advantage of using the Ubuntu system for a LTSP base server is that Ubuntu provides the whole thing preconfigured via installation CD.

While the whole point of LTSP is to have a homogenous set of clients, we all know how picky humans can be. To support customization of client behavior and features, you can set a very large number of behaviors and features on a per-MAC basis using the lts.conf file.

Since this is (still) a fairly short introduction to LTSP, I won’t go into the fine points of tuning using this file, except to say that while it’s a text file that has to be edited manually, it’s fairly easy and direct.

Since you installed a 64bit server, the default was to install a 64bit client and for a variety of reasons and convenience, it’s a good idea to have the same architectures for both client and server. If you want to install a 32 bit client, it’s very easy to do, altho it will take several minutes to actually download and configure. Your part is only the 1st line:

You can now specify the 32 bit client by modifying the option root-path to point to the 32bit OS in the /etc/ltsp/dhcpd.conf:

While it makes it much easier to run applications on the server, you can install applications on the client side and run them there if the client has the resources to support them. For example, if you wanted to install and run Firefox on the client, you could chroot into the client OS tree, apt-get install firefox and the necessary files would then be installed inside the client OS image which would be transferred by PXE boot to the client. In order for client-side applications to be a viable option, the clients should have around 300MB RAM and a PIII, so this is actually moving from a thin client to a centrally managed fatter client.

This also makes the client image larger and in fact moves LTSP more towards the Perceus model, where the client actually does real work (not just provide a display). The boot image size will top out tho, as much of the OS and applications can reside on common NFS storage, and need not be transferred in the boot image.

Once you install utilities or applications in the client tree and/or change the client OS (X11 or other configuration files), you’ll have to re-create the boot image by running the command:

which will compress and install the client OS tree into a bootable image. Since the tree will be 100MB or greater, this will take several 10s of seconds to finish

This is very hardware-specific but typically it requires you to hit the Delete or F1 key early in the boot sequence to enter the BIOS settings, navigate to the Boot section and change the Boot Order to boot 1st from the network interface. On a machine that has 2 interfaces, it is difficult to know which is which, so there’s some guess-work involved. If an ethernet card has been added to a machine, the eth0 interface is often the new one, tho this depends on how the PCI addresses are numbered).

Power it on. After the BIOS splash screen, the PXE boot notification should pop up and after a few seconds, the PXE boot process should start. If all goes well, you’ll end up with the the Ubuntu login screen which will behave similar to a login to the main system, including the login chime if the client has an audio card and speakers. For a 5yr old, 900MHz PIII-based Thinkpad (100Mb ethernet), from power-on to the login screen takes 50s and another 15s from login to Desktop.

The same LTSP server that provides bytes to thin clients can also provide logins for other clients: direct ssh, X11 over ssh to Linux, Windows, and Mac fat clients, access to NX (compressed X11) logins that allow instant suspend/resume desktop sessions, as well as the usual breadth of services expected from a Linux server.

For example, the head node for our small cluster is a size that you might use as such a LTSP server - 4x64b cores, 16GB and it usually has >30 simultaneous logins and a variety of jobs running, including compiling and testing code, running analysis scripts and MATLAB, running a local DNS and DHCP server, as well as being the main file server for the cluster. The server is still responsive when the load exceeds 10 (10 CPUs worth of processes queued) and has gone as high as 65 (when it was NOT responsive, but it still recovered). It crashed for the 1st time last week after being up for more than 200 days.

This should not be an issue unless you change hardware (again, the client OS is only there to provide the X11 display) but if necessary, you chroot to the client dir tree, install the required packages (or make other necessary changes), exit the chroot, ltsp-update-image (as above), and reboot the clients.

Adding applications is as simple as using the package manager on the server to add the requested packages. The apt/dpkg commands are straight commandline utilities that once learned are very powerful and useful. aptitude is the curses-based utility. synaptic is the default Gnome graphical package manager and kpackagekit is the default for the KDE desktop. Obviously, since the clients are merely providing the display to the server, applications can be installed from the clients - you don’t need a direct login to the server. Note that depending on the application, you can get lockups if you try to simultaneously start multiple login sessions of some applications (Firefox, for example), due to file locking.

Extra storage can be added either by adding disks to the existing server, or more flexibly, adding network storage from additional network fileservers. Since Linux supports NFS, SMB/CIFS, SANs, as well as many other protocols and filesystems, it’s fairly trivial to add more storage, tho how transparent this will be depends on how you configure it. There are a few specialized Linux and BSD distributions designed specifically to act as file servers. Openfiler is an exceptionally good one and also has available commercial support. freeNAS is BSD-based file server distribution.

Video and audio over the network have been supported on LTPS for several years. Depending on the client load and the network speed, they will work better or worse, but in general they work slightly less well than on a dedicated fat client. If your clients require high quality audio/video, this is an argument for having these applications working locally. The local performance also depends on the local video card. A hardware accelerated card will give better performance than an basic video card. Audio is less affected, with decent audio available on even low-end clients.

Printers, faxes, and scanners are typically shared at the server level, altho it’s also possible to set up queues to devices physically attached to the clients via USB or other ports (for example if a manager needed to print confidential documents to his sole-use printer). This is configured in the server’s lts.conf file in the PRINTER_0_<etc> section.

A frequent reason for using the thin client model is the central storage pool for efficiency, ease of backup, and security. The last item relates to security of user data, large-scale leakage of data, and introduction of malware into the system. If the clients have no way of reading or writing local data, they cannot contribute to these kinds of security breaches. However, if data security is of less concern than convenience or there need to be mechanisms that allow the local reading or/or writing of data, it can be allowed on a per-client or general basis. USB drives are the usual devices that need to be supported, but regular hard disks, as well as CD/DVD drives can also be allowed. Also configured via the server’s lts.conf file in the LOCAL_APPS section.

If you need to support multiple versions of applications to support specific groups of users, there are a variety of ways to do this. You can:

Integrating your LTSP clients into a larger campus system is also fairly easy. The server needs a few more packages and files and some some minor configuration and it will be able to join an NIS/Kerberos domain so that the users can use any client to log into their accounts. This process is described in the Perceus report (the format_mount.pl is not applicable for LTSP).

Like the Perceus server, the LTSP server is a consumer of external Kerberos and NIS/NFS resources, so can be configured as a client and the LTSP clients are of course unaffected by this).

The LTSP server runs Linux. Period. However, if your users still need to run some Windows applications, there are sveral ways of allowing them to do this over a transition stage.

Note that none of the above mechanisms are free except via the WINE project. The Crossover/Codeweaver product (based on WINE) is better supported and more compatible with Windows apps, but is a commercial product. And use of Microsoft (and other vendors') applications requires software licensing on a per-user basis as it would if you were running on a pure MS platform. The idea tho, is that you would use this as a bridging technology that would end as soon as the users became familiar with a comparable Linux application.