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.
Performance
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.
Create a password-less login environment for ssh. This is an
optional convenience.
You will need to include your user in the audio group for
reasonable behaviour of pulseaudio.
Create a file .xinitrc in your home directory as follows
(using kde session):
start-pulseaudio-x11
#
replace startkde by gnome-session for gnome desktop
ssh -X
anil@server ". .bash_profile; startkde"
In the .bash_profile on the server, add
if [ "${SSH_CONNECTION}"
]; then
PULSE_SERVER="${SSH_CONNECTION%% *}"
export PULSE_SERVER
fi
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
:)
