Network deployment and alternative OS's – 2.

Booting over the network is very useful whether you are using servers with network files storage or diskless client workstations. The idea is very simple. An operating system is installed in a directory on a network server. The client machine boots from the file server using pxe protocol and nfs root. The server uses dhcp and a nfs server to configure the client and point it to the appropriate root directory.

Linux Terminal Server Project

In the late 1990's, the LTSP project was created to enable low-end pc's to function as thin clients, especially for schools. The project created server scripts and a lightweight distribution for the client machines to make it easy for deployment by schools. An even greater benefit than being able to use obsolete pc's was the simplification of support. We found it far easier to manage over 60 clients with a server in various labs and offices than maintain even a single lab with networked pc's.

In order to be able to fine tune the distribution for each server environment, the LTSP project now creates scripts which would build a client os on the server. So, Ubuntu-based clients would be created on Ubuntu, Suse-based clients on Suse. A client machine boots and starts a custom display manager, LDM. LDM talks to the server, finds out the sessions available and starts an X session on the server.

By default, all applications run on the server and the display is shown on the client. The project has added capabilities for running local applications.

What makes it hard

The scripts can be non-trivial. The same root directory may be used by many clients. So, the root should be read-only; however, some files may need to be modified specifically for the client and some directories and files need be writeable for normal operations.

The common solution was to mount the needed files and directories on temps. However, the recent versions are now switching to a unionfs.

A second major change Ubuntu has done is to use a network block device by default. You create a squashfs image of the root directory. An nbd server makes it available on the server. The client connects to it using an nbd device. It is not clear if an nbd server offers an advantage over NFSv4.

The scripts have to keep evolving as distributions change the change the booting infrastructure, e.g replacement of mkinitrd by dracut. The generation of a custom initramfs is a critical need for the diskless boot environment. LTSP is not supported on recent versions of Fedora, probably because of the switch to systemd from init.


On a 1 gbps network, a diskless workstations was logged in and ready to use in in just under a minute. The additional time needed on a 100mbps network was less than 15 sec. The major difference of network speed is in the how snappy a user's environment is after signing in. This is because while the X server is running on the client, all applications, including the window manager, are running on the server. There is a lot of network traffic and resultant latency issues.

Modern desktop environments with desktop effects like Unity or Gnome3 shell can be painfully unresponsive on the diskless environment. The fallback mode of Gnome or KDE with desktop effects disabled run pretty well on diskless environments.

Media-rich applications may be impacted by the network delays. Hence, ltsp makes it easy to use local applications. You install local applications on the server in the change-root environment. You may, for example, install firefox and flashplayer for an excellent browsing experience.

The window manager and panel are running on the server. So, running a local application requires a special script – ltsp-localapps. It makes a very clever use of xprop command of X server to run the command on the local system.

In case you want to experience the feel of a diskless session without setting up the diskless environment, you may do what I do routinely. You will need two machines, the workstation you use and a machine you will use as a server.

  1. Create a password-less login environment for ssh. This is an optional convenience.

  2. You will need to include your user in the audio group for reasonable behaviour of pulseaudio.

  3. Create a file .xinitrc in your home directory as follows (using kde session):

    # replace startkde by gnome-session for gnome desktop
    ssh -X anil@server ". .bash_profile; startkde"

  4. In the .bash_profile on the server, add

    if [ "${SSH_CONNECTION}" ]; then
    export PULSE_SERVER

  5. From a terminal window, run

    $ xinit -- :1

So, what will be the future of LTSP?

LTSP is going to face the challenge of dealing with the current trend in desktops where the desktop effects are increasingly integrated into the window manager. In addition to the ability to run local applications, you can build a fat client with build-ltsp-client. That is, the desktop manager and applications will run on the local diskless machine.

Ltsp discussions continues to be very active and are an indication of the long term prospects for this project. As a recent discussion pointed out, the issue with desktop effects is really an issue with opengl over the network. There is an exciting project VirtualGL which may rescue the situation.

As software people, we should be thankful. Each advance which breaks stuff brings more opportunities of work and exploration for us :)