(thanks to Kaz Okayasu for the loan of the Gb switch)

1. Introduction

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.

2. Assumptions

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.

3. Pre-Requisites

3.1. Prep work

So you know what you might be getting yourself in for, I invite you to take a look at Dave Richard’s Blog. He works for the City of Largo, FL and has helped keep it running (and running well) on a Linux Thin Client infrastructure for at least a decade. He also wrote a book about it.

3.2. Hardware

If you’re just doing this to demo the project, you’ll need a PC with 2 ethernet interfaces (100Mb is OK, but 1Gb is much better), at least 2GB RAM and enough disk to hold the server OS, client OS, and any /home directories. You can easily get by with a 100GB disk.

One ethernet faces the public internet (or your local LAN); the other faces the private network on which your thin clients reside.

To allow the thin clients to connect to the server, you’ll need an ethernet switch; as noted, 1Gb is much better, but 100Mb is OK. More expensive switches will tend to support more throughput; but even the cheapest switch will allow your server to provision and test a few clients.

3.3. Software

This document will use the Ubuntu 10.04.1 distribution as it’s a Long Term Support (LTS) version. You can certainly use any Linux Distribution, but the commands to install and perhaps configure the services will be slightly different. If you can figure out what the CentOS process is from a Ubuntu command, by all means use what you’re comfortable with. This will also use a 64bit server and client OS. It actually does not make that much difference, but the 64bit server allows it to use much more RAM. I do show how to intall a 32bit client OS as well.

4. Installing the LTSP server

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

4.1. Installing a preconfigured LTSP system

Grab the Alternative CD ISO and burn it to a CD.

Pop it in the Server and reboot from the CD. The following process will take about an hour, but your interaction will be < 10 minutes.

This link is the official instructions for installing the combined Ubuntu/LTSP server. It references the 8.04 Hardy release but it’s essentially the same experience.

A slightly extended version follows:

  • once the CD boots, select your language.

  • press F4, select Install an LTSP Server, then <Enter>.

  • follow the directions to install Ubuntu as normal.

  • the installer will attempt to detect all the ethernet interfaces and then try to configure the primary one (eth0) via DHCP. If you don’t have a DHCP server running on that network or don’t want it to allocate an address for the server, hit Cancel and configure it as you want. This requires some very basic network config understanding and skills. You have to provide the following information (in parens are the configs for my local server as examples. You will have to change everything but the netmask.)

    • IP address (

    • netmask (

    • gateway (

    • nameserver (

    • hostname (flip) may be automatic if the server is already registered

    • domain name (nac.uci.edu) ditto

  • partitioning the disk. For a demonstration project, you can select the option Guided - use entire disk. It creates 2 partitions, a single ext4 filesystem that holds all the OS and user information, and the swap partition. Obviously on a production machine, you’d want separate partitions for the root, /home, and possibly /var, /boot, etc.

  • installer proceeds and installs the entire OS, then prompts for a user. This user (typically you) is a user not only for the server, but also for the thin client, just as ANY user on the server can be a thin client user and vice versa.

  • you also have the option to encrypt the users home directories, which will slow performance somewhat, but increase security. Typically this is used only for high-risk computers like laptops, but it’s your choice.

  • if you need to set an http proxy, you have the option to do so next.

  • at this point, the installer continues directly into the LTSP install, which requires a lot of downloading and installing for 10s of minutes. You can watch it or get coffee. (There is a fairly long stutter at 50% - don’t give up - just go and get another coffee.)

  • finally, install the boot loader to your boot disk (unless you have good reason not to), set the time format, and reboot.

You now have an integrated LTSP server ready to go. It has already configured the second ethernet interface to and prepped and compressed one client OS (you can add more if needed). Once the server has rebooted, you can plug in a PC (diskless, by all means) and boot it up as well. You’ll be able to log into the client using the login and password that you used when setting up the server. To add more clients , simply make sure that the BIOS is set to PXE-boot, plug them into the switch and turn it on. Of course you’ll also want to add more users, which is done by running the standard sudo adduser command on the server. the client should now have access to all the apps and utilities that a user would have on the server, because effectively you ARE on the server.

Note that you did not have to agree to a EULA or sign off on a single licensing agreement for the entire process.

Since this is an introduction, I won’t go into some of the glitches that can occur. Such hiccups can and do happen, but one good thing about using a technology that has its roots 10 years into the past is that a lot of them are well-understood and well documented (or at least Googleable).

4.2. Installing over an pre-installed system

If you already have a 10.04 installation (or another recent one if you feel confident about mixing releases), you can easily install the LTSP server on that one.

The few packages you need to specify are ltsp-server-standalone (which includes the dhcp server that is required) and the openssh-server:

sudo apt-get install ltsp-server-standalone openssh-server

This process will set up the LTSP server and try to start the DHCP server, but unless your secondary interface is already set up to pre-match the default (eth0 points to the internet; eth1 points to the Private net, set to, it will fail.

If it fails, you’ll need to manually edit the configuration file (Note: it’s not the /etc/dhcpd.conf file but the LTSP version, usually kept in /etc/ltsp/dhcpd.conf. The one shown below is the default, autoconfigured for the private network set to (The eth1 interface of the server was set to

The client only runs X

It may help to remind you that the LTSP client OS is not what you’ll be using to do your work - it exists (usually) to host a functioning X11 display (aka an Xterm) to allow you to log into the LTSP server. As far as clients are concerned, they’re running on the server. Therefore, there should be no real advantage to running in 64 bit mode - the client will not be allocating RAM beyond what it needs for X, and 4GB should be about 8 times more than what it should ever need.

# Default LTSP dhcpd.conf config file.
# [/etc/ltsp/dhcpd.conf]


subnet netmask {
    option domain-name "example.com";
    option domain-name-servers;
    option broadcast-address;
    option routers;
#    next-server;
#    get-lease-hostnames true;
    option subnet-mask;
#assumes that you want to load the 64bit client
    option root-path "/opt/ltsp/amd64";
    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
        filename "/ltsp/amd64/pxelinux.0";
    } else {
        filename "/ltsp/amd64/nbi.img";

If your private network interface (eth1) was set to, then the configuration file would look like this:

# NON-Default LTSP dhcpd.conf config file, configured for:
#  eth1 =
# [/etc/ltsp/dhcpd.conf]


subnet netmask {
# reserve only 9 address at the front of the range
    option domain-name "mynet";
# following assumes the LTSP server is also the name server
    option domain-name-servers;
    option broadcast-address;
# following assumes LTSP server is also the router
    option routers;
#    next-server;
#    get-lease-hostnames true;
    option subnet-mask;
# if want a 32bit client (see below for creating it), simply change all
# instances of 'amd64' to 'i386' below
# otherwise, the default client is the 64bit one.
    option root-path "/opt/ltsp/amd64";
    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
        filename "/ltsp/amd64/pxelinux.0";
    } else {
        filename "/ltsp/amd64/nbi.img";

5. Customizing Client Behavior

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.

6. Creating the client OS

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:

$ sudo ltsp-build-client  --arch i386
I: Retrieving Release
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://archive.ubuntu.com/ubuntu...
I: Retrieving adduser
I: Validating adduser
I: Extracting adduser...
I: Installing core packages...
I: Unpacking required packages...
I: Unpacking adduser...
I: Configuring the base system...
I: Base system installed successfully.

<lots of configuration info deleted>
info: LTSP client installation completed successfully

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:

option root-path "/opt/ltsp/i386";

7. Server vs Client Applications

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:

sudo ltsp-update-image -a [arch] -b [/base/of/ltsp/chroot]

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

8. Changing the client BIOS to PXE-boot

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).

9. Booting the client

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.

10. User and application loads

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.

11. Upgrading & Changing the client OS

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.

12. Adding / upgrading applications

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.

13. Adding storage

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.

14. Multimedia to LTSP clients

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.

15. Shared printers.

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.

16. Local storage devices

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.

17. Handling Application versions

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:

  • manually manipulate the PATH environment variable so that one group gets one path to the executables while another group gets another one.

  • use the Modules package to set or allow users to specify their own modules. Modules can be configured to automatically manipulate executable paths (PATH), library paths (LD_LIBRARY_PATH), include paths, environment variables, etc to customize users environments almost infinitely.

18. Adding LDAP, Kerberos, NIS/NFS

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).

19. LTSP coexistence with Windows apps

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.

  • If the applications are WINE compatible or Crossover compatible, then you can install an instance of that technology on the server and provide the apps via the emulation layer.

  • similarly, you can install a virtualized Windows installation on the server to be used as needed.

  • you can provide access to a Windows Terminal Server instance to provide network access to the Windows apps and provide rdesktop as an RDP client.

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.

20. Thin Client Promotion, Propaganda, Discussion