LTSP: Thin clients made easy


In depth: One of the main advantages of using LTSP is its cost-effectiveness. Instead of 30 mid-range computers for a classroom or office, you buy one high-end machine and 30 cheap terminals. The terminals don't even need to be new computers, as the hardware requirements are so low that old hardware can be reused instead of thrown away. When the time comes for a hardware upgrade - to cope with more resource-intensive programs, for example - only the server needs to be upgraded, with the terminals carrying on doing the same job as before.

In this tutorial we're going to show you how to install LTSP on your distro of choice, then configure thin clients to connect up to the server with the minimum of fuss.

There are also environmental advantages - 30 PCs use a lot of power and convert much of this into heat, requiring several fans per machine. Thin clients do much less work, and so use less power and generate less heat and noise. Older PCs may not have such an advantage here if they're running at the top end of their capability, but diskless thin client computers can be virtually silent, having no fans or disk drives.

System maintenance is also easier when everything is on one computer, and upgrades are simpler, as is backing up. In fact, the only major disadvantage of such a system is that the server provides a single point of failure. If this breaks, the whole system goes down, so some sort of redundancy is needed here if downtime isn't acceptable.

How does it work?

Most network adaptors, particularly those built into motherboards, have a network boot facility. The BIOS sends a specific DHCP request over the network, and the server runs a particular network bootloader (either Pxelinux or a version of Grub).

This sends an optional boot menu to the client, followed by a kernel for the computer to boot. The server also exports a directory over NFS for the client to use as its root directory. After this, the boot process proceeds as normal, as does all other use of the computer. The only difference is that the hard disk is at the end of several metres of Ethernet cable instead of a few inches of ribbon cable.

LTSP starts off in the same way, but instead of loading a full system from the network-mounted drive, it sets up a very minimal system, with just the basics needed to boot the kernel, start the X display, and handle mouse and keyboard input (and usually the sound).

Then it opens a desktop session using XDMCP, which opens a desktop from the server on the thin client. There are no user programs running on the thin client - all other apps run on the server, using the client as its input and output devices. This also means that startup can be faster than on a normal desktop computer, despite running on slower hardware and loading everything over the network, because most of the programs started in a typical boot are already running on the server.

System requirements

The requirements for the server depend on the number of clients connected and whether they'll all be in use at the same time. A computer room in a school will have most of its computers in use simultaneously, placing far more load on the server than an office where people come and go, log in and log out, and maybe 30-40% of the systems are in use at any one time (apart from first thing in the morning when everyone arrives at work and checks essential sites such as YouTube and Facebook).

The general recommendation has always been 256MB of RAM for the server itself, plus another 60MB for each client connected, although some now recommend 100MB per client. As all programs are running on the server, it's also good to have plenty of processing power, particularly a dual-core or dual-processor system.

It's a particularly good idea to use a 64-bit processor when you're working with plenty of client machines, not only because of the extra processor performance, but also because it can work with more memory, which is often the most significant factor limiting performance.

The clients need very little in the way of system resources, as the server is doing all of the work - 128MB of memory is ample, as is a Pentium II processor. The main requirement is that the computer is able to boot from the network, though there are ways round this (see the Alternative Booting Methods box, below). The essential is a fast network - at least a 1Gb connection from the server to the switch, and at least 100Mbps to the clients.

Alternative booting method

The easiest way to boot an LTSP client is to use a PXE-enabled network card (as found in most modern onboard adaptors), but this isn't the only method. Some PCI Ethernet cards come with a boot ROM, and the Etherboot project provides open source boot ROM code for a couple of hundred different cards. Creating your own boot ROM is a little ambitious, but it is possible to put the Etherboot code on to a bootable floppy disk.

No, don't stop reading - this really is very simple, thanks to some clever stuff at The site generates boot images for many cards in several formats. Simply select your card (run lspci -n to see its PCI ID numbers), choose the type of image you want and click on the Get ROM button. Then just copy the file you've downloaded to the disk with

cat cat eb-5.4.3-yournic.zdsk >/dev/fd0
Visit ROM-o-matic for a customised boot floppy image for your network card.

Visit ROM-o-matic for a customised boot floppy image for your network card.

Installing an LTSP server

You have a choice to make before you embark on setting up an LTSP server: you can use a specialist distro with everything built in and (mostly) preconfigured, or you can install the LTSP packages on an existing distro.

Each way has its own advantages - getting LTSP pre-installed is obviously more convenient from a setup perspective, but it would be better to use an existing distro if you're used to it, particularly if other machines on your network use that distro as well. Of course, if there's an LTSP-enabled version of your current favourite, you can have your cake and eat it - for example, Ubuntu users will feel right at home with Edubuntu.

As the thin clients are running on the same computer, the distro you choose will be what your users use too, which can also influence your choice. If you're setting up a dedicated LTSP server for an office or school environment, a distro designed for LTSP makes sense.

On the other hand, if you simply want to experiment with it and are installing the server package on a general-purpose computer, an add-on package saves you the hassle of installing a new distro. An alternative way to experiment is to use a dedicated distro and install it in a virtual machine with VirtualBox or VMware.

There are several distros with LTSP support built in - see the box below for a list of some of the more popular choices. They're all aimed at the educational market, which gives an idea of the main use for LTSP. We'll use Edubuntu here, mainly because so many of you will already be familiar with its parent, Ubuntu.

LTSP distros

There are several distros that have LTSP built in, and they're mainly aimed at the educational market. This doesn't stop you using them for non-educational projects, mind. They include...

Edubuntu uses the familiar Ubuntu text installer. Select the first option, "Install to the hard disk", from the boot menu and the distro will be installed with LTSP included. You'll see a message about no free interfaces for LTSP during installation, but don't worry.

The Ubuntu installer sets up the network to use DHCP, but this isn't possible with LTSP, which provides DHCP services itself and needs a static address. We'll fix this shortly. There's also an occasional problem with the installer hanging during creation of the client image, although this only seems to happen when it's installing in a virtual machine.

The solution to this is to take the workstation install option, which doesn't include LTSP, then run Synaptic to install ltsp-server and ltsp-server-standalone after rebooting, and run sudo ltsp-build-client. The resultant system is the same.

Now run System > Administration > Network, click the Properties button and turn off roaming mode for your wired interface. Set the configuration to Static and pick a suitable IP address, subnet mask and gateway address. If you're unsure, use whatever you've been given by your current DHCP server, which you can find with the commands

sudo ifconfig eth0
sudo route -n

Now you can edit /etc/ltsp/dhcpd.conf and set suitable values. If you're on a 192.168.1.* network, something like this would work:

subnet netmask {
  option domain-name "";
  option domain-name-servers;
  option broadcast-address;
  option routers;

This assumes that your internet router is at and that it also provides DNS for your network. If your network is different, change the values accordingly.

You now need to disable any other DHCP server running on your network. When you boot the client, it will send out a DHCP request, which must be answered by the LTSP server. Some DHCP servers have an option to ignore certain network MAC addresses, in which case you can leave your normal DHCP server running and tell it to ignore your client computers.

This is only useful if you're testing LTSP on a temporary or virtual system. With a full-time working system, the LTSP server should provide DHCP services for the network.

Edubuntu sets up a dynamic IP address during installation, but you must change this to a static address.

Edubuntu sets up a dynamic IP address during installation, but you must change this to a static address.

Installing on your preferred distro

To install on your current distribution, you need a package called ltsp-utils, which should be in your distro's repositories. We're going to use Fedora here, but the procedure is about the same with any distro. Fedora has the ltsp-utils package in its main repository, so you can install it with Yum.

To get LTSP on an already-installed distro, start with the ltsp-utils package, which will install the rest for you.

To get LTSP on an already-installed distro, start with the ltsp-utils package, which will install the rest for you.

If your distro doesn't have it, download it from, where you'll find Debian, RPM and Slackware packages, which you install in the usual way for your distro. There's also a general ltsp-utils tarball, which you can install on any distro with this:

tar xf ltsp-utils-0.25-0.tgz
cd ltsp_utils
su -c ./

However you install it, the next step is to run ltspadmin as root. If you need to use a proxy for HTTP or FTP, go to 'Configure The Installer Options' and set them, otherwise you can use the defaults and go straight to 'Install/Update LTSP Packages'.

The first step is to select the packages you want - the easiest option here is to press A for all of them. To get information on what each option installs, highlight it and press S. Press Q to begin the installation. This may take a while, depending on the speed of your internet connection.

Now you have all the software you need to run a remote session from a thin client, but none of it is set up yet. This is done via the Configure LTSP option, which runs ltspcfg. Press S to see the status of all the required services and files.

Everything should have 'yes' in the configured column, and services should be running. Press C from the configuration menu to set up each item in turn. The runlevel should be five on a Red Hat- or SUSE-based system, two on a Debian derivative.

ltspcfg shows whether all the required services are configured and running. Ignore the portmapper message with Fedora.

ltspcfg shows whether all the required services are configured and running. Ignore the portmapper message with Fedora.

The DHCP section only sets up a sample configuration in /etc/dhcpd.conf.sample, which you should edit as with Edubuntu above and rename to /etc/dhcpd.conf. One important point to check here is that the filename directives in dhcpd.conf point to existing files.

First, check the server_args setting in /etc/xinetd.d/tftp - this will probably be something like -s /tftpboot, which means that the filenames in dhcpd.conf are relative to this directory. So if dhcpd is set to look for /lts/2.6.20-9-ltsp-1/pxelinux.0, the actual file should be /tftpboot/lts/2.6.20-9-ltsp-1/pxelinux.0. This one catches a few people out.

There are two filenames to set - one used for PXE booting and one for other boot methods. The reason for this is that PXE is limited to loading a 32K boot file, so it transfers a bootloader that then takes care of loading the kernel. Etherboot loads the kernel directly.

Work your way through the various options - the accompanying text helps, and the defaults are generally sane. In most cases it's just a matter of ensuring that the required software is installed (which you do though the distro's package manager) and set to run at boot time. Fedora 8 doesn't use Portmap, which ltspcfg expects to see, but uses the alternative rpcbind instead. This means that ltspcfg reports a problem here where none exists, so you can ignore it.

The final step creates an lts.conf file in /opt/ltsp/i386/etc. This is the directory exported as root for the clients, so this file will appear in their /etc directories - it's the client configuration. The defaults are fine if you want the client to open a single desktop screen.

For more advanced use, the docs at cover the options available here. Now reboot the computer. This step is not strictly necessary, but it does enable you to run ltspcfg again to make sure all the services are configured and running.

Booting the first client

Now you've installed the server, it's time to test it by booting another computer on the same network. While this would normally be a thin client machine, any i386-based computer will do for basic testing, even a virtual one. For the purposes of testing, it's even possible to run the server in one virtual machine and the client in another.

There should be no special configuration needed on the client beyond setting the BIOS to boot from the network, or using a boot floppy if your network card doesn't support direct booting. You should see the DHCP negotiation followed by the TFTP transfer to load the bootloader and kernel.

After that, the normal boot sequence appears. Most of this flashes past too quickly for you to see, but don't worry about that - it means that everything is working correctly. If it stops at any point, the last text displayed will give an indication of what went wrong and we'll look at some solutions in a moment.

Otherwise, you should see a typical X login screen. Type in the usual login details and you'll be presented with a desktop running on the server, but largely indistinguishable from a local desktop. What can you run here? The answer to that is just about anything that could be run from a desktop on the server, because that's what you're doing.

However, remember that all display updates go over the network, so don't expect to play FPS games at a decent frame rate. But being able to use resource-hungry apps such as on a low-powered machine is a real advantage.

Gnome, and Firefox running at the same time, on a 700MHz computer with 128MB of RAM - and no swapping!

Gnome, and Firefox running at the same time, on a 700MHz computer with 128MB of RAM - and no swapping!


Once the server is set up, booting a client should just work - but practice often differs from theory. There are a few points during the client boot process where things can go wrong, and seeing where it stopped is often a good way to identify the problem.

If the computer doesn't even try to boot from the network, you probably need to enable network booting in the BIOS. If you're using a ROM-o-matic boot floppy and it doesn't work, try a different disk image - there can be differences between apparently identical cards.

If the network boot starts but fails to load anything, resulting in a timeout, make sure any firewall you have on the server allows DHCP and TFTP connections. DHCP is generally enabled, but TFTP tends to be blocked by default. If you see the results of the DHCP negotiation on the client's screen, DHCP is working - you can double-check this by watching the system log file on the server - usually /var/log/messages - while booting the client with

tail -f /var/log/messages

You should see several DHCP messages fly past, ending with a DHCPACK. If the client then fails on the TFTP transfer, the error message with PXE booting is "PXE-E32: TFTP open timeout". There are three likely explanations: either your TFTP server is not running and ltspcfg will have confirmed that it is; the path to the kernel image is wrong in /etc/dhcpd.conf; or your firewall is blocking the request.

The last is easiest to test - just turn off your firewall for a few seconds while you boot the client. If it works, open up UDP port 69 to local addresses in the firewall.

Ensure your firewall allows TFTP, RPC and NFS traffic or your clients won't boot.

Ensure your firewall allows TFTP, RPC and NFS traffic or your clients won't boot.

The next stage at which things can go wrong is mounting the root filesystem over NFS, in which case you'll see "Failed to mount the root directory via NFS!" followed by a kernel panic. Check that the directory given in the root-path option in /etc/dhcpd.conf is listed in /etc/exports. If not, correct /etc/exports and apply the changes with

exportfs -r

If these are correct, it's probably our friend the firewall blocking access again, in which case you need to open up the NFS and RPC ports to the local network. These are ports 111 and 2049 for TCP and UDP. Now go forth, and feel the power of using less power!

First published in Linux Format

First published in Linux Format magazine

You should follow us on or Twitter

Your comments


Thank you for writing this article. I've always wanted to try this, but hadn't seen anything in writing walking me through a setup. It does help me understand the overall installation process.

One question?

What do you use to allow anonymous messages? Or I guess how are you allowing this? I'm a newbie and just want to learn. I hate having to log in just to post a reply so something. Thanks.

2 DHCP servers - MAC or IP port filter it.

Hi, what I was so Thankful about your site is how you "suggested" to filter your clients in the router.

I know it won't work if you don't have access to the router so I guess you have to figure it out on your own.

Have been studying LTSP for 1 whole day without success because I had 2 dhcp servers, thankfully you "suggested" to filter my clients. I'm using a Belkin router.

I tweaked a lot aboout my dhcpd.conf files, but your article was the last one I need to read, again, thanks for making my project a success.

One more supplement

I had issue with boot LTSP client, because my firewall blockade TFTP server (port 69), and NFS or rather NBD, wich work on port 2000 (not 2049 like NFS). So You have to be careful what You use, NFS or NBD! Look at /etc/inetd.conf (ubuntu 8.04 LTS) first, You will see what You use, this is ease way ;-)
Sorry for my bad english,

Kernel panic

in class, we are trying to boot a dinosaur of a computer, and it boots fine until a certain part. then it iss followed by about 300 periods, and then "Kernel panic. not enough memory" or something like that. any ideas what it is?

Typo in /etc/ltsp/dhcpd.conf


Great write-up - very much appreciated.

I did notice a small typo in your /etc/ltsp/dhcpd.conf example:

On the second line, it says:

I think it should say:

Otherwise the range of IPs assigned to the DHCP will not work.

Thank you again.

Thin Client Hardware?

At minimum is this what you only need from a thin client?

1. Mobo (w/ boot from network feature)
2. 128mb RAM
3. LAN Card

You don't need a HDD right?

Is there a low-watt PSU available on the market so that you don't spend so much electricity as if you're running a "fat" client?

thin client

perdon que no hablo ingle pero decime funcionda con thin client?

found whith thin client?????


sorry but I have a problem and I am looking for help

How can i use nis authentication from an external server
(nis server A <> ltsp Server B, users home in server A),
for an ltsp fat client?
There is a book were i can read a configuration for this
problem, but only for Ltsp version 4.1 (I have to
configure NIS_DOMAIN and NIS_SERVER variables in
lts.conf Book Author: McQuillan).

My Ltsp server is version 5.2 and i have a "fat client",
is it correct to configure only in lts.conf ?

The Ltsp server is it only a client for nis ?

Adding Unity Bar to LTSP thin clients

I am new to the LTSP world but I am interested in adding either Unity Bar or some sort of NAV Bar to LTSP on Ubuntu 11.10. What is the best method of performing this? What other recommendations does anyone have for a bar i.e. Cairo etc..?

Any help would be appreciated.


print from printer connected to thin client

Hello Everyone

I am using k12linux ltsp. I just need to know that how to print from the printer connected to thin client directly.

if anyone knows please help me my mail id:

many many thanks

Manual static IP kills server X

I've read a lot about LTSP and in every place I read, everyone says I have to modify /etc/network/interfaces and set the static IP address of the LTSP interface ... I tried this several times and it never worked, all I got was server's Gnome3 killed after restarting the networking service ...

Don't know why this happens. And anyway I ended up just changing the network settings for that interface with the network administrator ... Changed to manual, change the IP, NetMask, GW, DNS ... DONE ! ... no restarting network service and now I got all my clients running ...

Any ideas why this happened to me ? ... I'm using Ubuntu 12.04 as the server ... also tried with Linux Mint 13 and XFCE (as server) with almost the same behavior ...

Thanks !!!

Thank you for the good writeup.

Appreciating the dedication you put into your website and in depth information you offer. It’s great to come across a blog every once in a while that isn’t the same old rehashed information. Great read! I’ve saved your site and I’m adding your RSS feeds to my Google account.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Username:   Password: