HowTos for networked clients

Introduction to thin clients and diskless workstations

(!) Default for new Debian Edu Buster installations: LTSP clients are using the same architecture as the LTSP server, i.e. 64-bit-PC (aka amd64) or 32-bit-PC (aka i386).

/!\ Please keep in mind to use the correct architecture for all commands referred to below.

One generic term for both thin clients and diskless workstations is LTSP client. LTSP is the Linux Terminal Server Project.

Thin client

A thin client setup enables an ordinary PC to function as an (X-)terminal, where all software runs on the LTSP server. This means that this machine boots via PXE without using a local client hard drive.

Diskless workstation

A diskless workstation runs all software locally. The client machines boot directly from the LTSP server without a local hard drive. Software is administered and maintained on the LTSP server (inside of the LTSP chroot), but it runs on the diskless workstation. Home directories and system settings are stored on the server too. Diskless workstations are an excellent way of reusing older (but powerful) hardware with the same low maintenance cost as with thin clients.

LTSP defines 320MB as the default minimum amount of RAM for diskless workstations. If the amount of RAM is less, the machine will boot as thin client. The related LTSP parameter is FAT_RAM_THRESHOLD with the default value 300. So if (for example) the clients should only boot as diskless workstations if they have 1 GB RAM, add FAT_RAM_THRESHOLD=1000 to lts.conf (or set this in LDAP). Unlike workstations diskless workstations run without any need to add them with GOsa², because LDM is used to login and connect to the LTSP server.

LTSP client firmware

LTSP client boot will fail if the client's network interface requires a non-free firmware. A PXE installation can be used for troubleshooting problems with netbooting a machine; if the Debian Installer complains about a missing XXX.bin file then non-free firmware has to be added to the initrd used by LTSP clients.

In this case execute the following commands on an LTSP server.

# First get information about firmware packages
apt-get update && apt-cache search ^firmware-
# Decide which package has to be installed for the network interface(s). 
# Most probably this will be firmware-linux-nonfree.
# Things have to take effect in the LTSP chroot for architecture amd64.
ltsp-chroot -a amd64 apt-get update
ltsp-chroot -d -a amd64 apt-get -y -q install <package name>
# copy the new initrd to the server's tftpboot directory and update the NBD image.

As a shorter alternative -- installing all available firmware and updating the tftpboot directory -- you could execute:


LTSP client type selection

Each LTSP server has two ethernet interfaces: one configured in the main subnet (which is shared with the main server), and another forming a local subnet (a separate subnet for each LTSP server).

On the main subnet the complete PXE menu is provided; the separate subnet for each LTSP server allows only diskless and thin LTSP client selection.

Using the default PXE menu on the main subnet, a machine could be started as diskless workstation or thin client. By default clients in the separate subnet will run as diskless workstations if the amount of RAM is sufficient. If all clients in this LTSP client subnet should run as thin clients, the following has to be done.

(1)Open the file /opt/ltsp/amd64/etc/ltsp/update-kernels.conf with an editor
and replace the line
CMDLINE_LINUX_DEFAULT="init=/sbin/init-ltsp quiet"
CMDLINE_LINUX_DEFAULT="init=/sbin/init-ltsp LTSP_FATCLIENT=False quiet"
(2)Execute 'ltsp-chroot -a amd64 /usr/share/ltsp/update-kernels'
(3)Execute 'ltsp-update-kernels'
(4)Execute 'ltsp-update-image'

Configuring the PXE menu

The PXE configuration is generated using the script debian-edu-pxeinstall. It allows some settings to be overridden using the file /etc/debian-edu/pxeinstall.conf with replacement values.

Configuring the PXE installation

The PXE installation option is by default available to anyone able to PXE boot a machine. To password protect the PXE installation options, a file /var/lib/tftpboot/menupassword.cfg can be created with content similar to this:


The password hash should be replaced with an MD5 hash for the desired password.

The PXE installation will inherit the language, keyboard layout and mirror settings from the settings used when installing the main-server, and the other questions will be asked during installation (profile, popcon participation, partitioning and root password). To avoid these questions, the file /etc/debian-edu/www/debian-edu-install.dat can be modified to provide preselected answers to debconf values. Some examples of available debconf values are already commented in /etc/debian-edu/www/debian-edu-install.dat. Your changes will be lost as soon as debian-edu-pxeinstall is used to recreate the PXE-installation environment. To append debconf values to /etc/debian-edu/www/debian-edu-install.dat during recreation with debian-edu-pxeinstall, add the file /etc/debian-edu/www/debian-edu-install.dat.local with your additional debconf values.

More information about modifying PXE installations can be found in the Installation chapter.

Adding a custom repository for PXE installations

For adding a custom repository add something like this to /etc/debian-edu/www/debian-edu-install.dat.local:

#add the skole projects local repository
d-i     apt-setup/local1/repository string stable main contrib non-free
d-i     apt-setup/local1/comment string         Example Software Repository
d-i     apt-setup/local1/source boolean         true
d-i     apt-setup/local1/key    string

and then run /usr/sbin/debian-edu-pxeinstall once.

Changing the PXE menu on a combined (main and LTSP) server

The PXE menu allows network booting of LTSP clients, the installer and other alternatives. The file /var/lib/tftpboot/pxelinux.cfg/default is used by default if no other file in that directory matches the client, and out of the box it is set to link to /var/lib/tftpboot/debian-edu/default-menu.cfg.

If all clients should boot as diskless workstations instead of getting the full PXE menu, this can be implemented by changing the symlink:

ln -s /var/lib/tftpboot/debian-edu/default-diskless.cfg /var/lib/tftpboot/pxelinux.cfg/default

If all clients should boot as thin clients instead, change the symlink like this:

ln -s /var/lib/tftpboot/debian-edu/default-thin.cfg /var/lib/tftpboot/pxelinux.cfg/default

See also the PXELINUX documentation at .

Separate main and LTSP server

For performance and security considerations it might be desired to set up a separate main server which doesn't act as LTSP server.

To have ltspserver00 serve diskless workstations on the main ( network, when the main server is not a combined server, follow these steps:

 DEFAULT ltsp/amd64/vmlinuz initrd=ltsp/amd64/initrd.img nfsroot= init=/sbin/init-ltsp boot=nfs ro quiet ipappend 2

As an alternative, you could use ldapvi, search for 'next server tjener' and replace tjener with ltspserver00.

Use a different LTSP client network is the default LTSP client network if a machine is installed using the LTSP profile. If lots of LTSP clients are used or if different LTSP servers should serve both i386 and amd64 chroot environments the second preconfigured network could be used as well. Edit the file /etc/network/interfaces and adjust the eth1 settings accordingly. Use ldapvi or any other LDAP editor to inspect DNS and DHCP configuration.

Add LTSP chroot to support 32-bit-PC clients

In case LTSP server and chroot are 64-bit-PC, it is still possible to support older 32-bit systems. At least 20 GiB additional disk space on /opt would be required.

Changing network settings

The debian-edu-config package comes with a tool which helps in changing the network from to something else. Have a look at /usr/share/debian-edu-config/tools/subnet-change. It is intended for use just after installation on the main server, to update LDAP and other files that need to be edited to change the subnet.

/!\ Note that changing to one of the subnets already used elsewhere in Debian Edu will not work. and are already set up as LTSP client networks. Changing to these subnets will require manual editing of configuration files to remove duplicate entries.

There is no easy way to change the DNS domain name. Changing it would require changes to both the LDAP structure and several files in the main server file system. There is also no easy way to change the host and DNS name of the main server (tjener.intern). To do so would also require changes to LDAP and files in the main-server and client file system. In both cases the Kerberos setup would have to be changed, too.

LTSP in detail

LTSP client configuration in LDAP (and lts.conf)

To configure specific LTSP clients with particular features, you can add settings in LDAP or edit the file /opt/ltsp/amd64/etc/lts.conf. Please note that ltsp-update-image has to be run after each change to lts.conf. The image update isn't needed if lts.conf is copied to the /var/lib/tftpboot/ltsp/amd64/ directory.

/!\ We recommend to configure clients in LDAP (and not edit lts.conf directly, however, configuration webforms for LTSP are currently not available in GOsa², you have to use a plain LDAP browser/explorer or ldapvi), as this makes it possible to add and/or replace LTSP servers without loosing (or having to redo) configuration.

The default values in LDAP are defined in the cn=ltspConfigDefault,ou=ltsp,dc=skole,dc=skolelinux,dc=no LDAP object using the ltspConfig attribute. One can also add host specific entries in LDAP.

Run man lts.conf to have a look at available configuration options.

The default values are defined under [default]; to configure one client, specify it in terms of its MAC address or IP address like this: [].

Example: To make the thin client ltsp010 use 1280x1024 resolution, add something like this:

X_MODE_0 = 1280x1024
X_HORZSYNC = "60-70"

somewhere below the default settings.

To force the use of a specific xserver on an LTSP client, set the XSERVER variable. For example:

XSERVER = nvidia

If a thin client comes up with a black screen the use of a specific color depth might help. For example:


Depending on what changes you make, it may be necessary to restart the client.

To use IP addresses in lts.conf you need to add the client MAC address to your DHCP server. Otherwise you should use the client MAC address directly in your lts.conf file.

Force all LTSP clients to use LXDE as default desktop environment

Make sure that LXDE is installed on the LTSP server; then add these lines below [default] in "lts.conf":


Desktop autoloader

This tool preloads the default Desktop environment (and programs of your choice). It is only useful for diskless clients. The setup is site specific, also some technical skills are required.

At least two files need to be edited. Available <editor> choices are: vi, nano, mcedit.

If the setup is complete, update the NBD image running ltsp-update-image and test it.

Load-balancing LTSP servers

Part 1

It is possible to set up the clients to connect to one of several LTSP servers for load-balancing. This is done by providing /opt/ltsp/amd64/usr/share/ltsp/get_hosts as a script printing one or more servers for LDM to connect to. In addition to this, each LTSP chroot needs to include the SSH host key for each of the servers.

First of all, you must choose one LTSP server to be the load-balancing server. All the clients will PXE-boot from this server and load the Skolelinux image. After the image is loaded, LDM chooses which server to connect to by using the "get_hosts" script. You will decide later how this is done.

The load-balancing server must be announced to the clients as the "next-server" via DHCP. As DHCP configuration is in LDAP, modifications have to be done there. Use ldapvi --ldap-conf -ZD '(cn=admin)' to edit the appropriate entry in LDAP. (Enter the main server's root password at the prompt; if VISUAL isn't set, the default editor will be nano.) Search for a line reading dhcpStatements: next-server tjener Next-server should be the IP address or hostname of the server you chose to be the load-balancing server. If you use hostname you must have a working DNS. Remember to restart the DHCP service.

Now you have to move your clients from the network to the network; attach them to the backbone network instead of the network attached to the LTSP server's second network card. This is because when you use load-balancing, the clients need direct access to the server chosen by LDM. If you leave your clients on the network, all of the clients' traffic will go through that server before it reaches the chosen LDM server.

Part 2

Now you have to make a "get_hosts" script which generates a list of server names for LDM to connect to. The parameter LDM_SERVER overrides this script. In consequence, this parameter must not be defined if the get_hosts is going to be used. The get_hosts script writes on the standard output each server IP address or host name, in random order.

Edit "/opt/ltsp/amd64/etc/lts.conf" and add something like this:

MY_SERVER_LIST = "xxxx xxxx xxxx"

Replace xxxx with either the IP addresses or hostnames of the servers as a space-separated list. Then, put the following script in /opt/ltsp/amd64/usr/lib/ltsp/get_hosts on the server you chose to be the load-balancing server.

 # Randomise the server list contained in MY_SERVER_LIST parameter
 for i in $MY_SERVER_LIST; do
     let "rank %= 100"
 TMP_LIST=$(echo -e $TMP_LIST | sort)
 for i in $TMP_LIST; do
     SHUFFLED_LIST="$SHUFFLED_LIST $(echo $i | cut -d_ -f2)"

Part 3

Now that you've made the "get_hosts" script, it's time to make the SSH host key for the LTSP chroots. This can be done by making a file containing the content of /opt/ltsp/amd64/etc/ssh/ssh_known_hosts from all the LTSP servers that will be load-balanced. Save this file as /etc/ltsp/ssh_known_hosts.extra on all load-balanced servers. The last step is very important because ltsp-update-sshkeys runs every time a server is booted, and /etc/ltsp/ssh_known_hosts.extra is included if it exists.

/!\ If you save your new host file as /opt/ltsp/amd64/etc/ssh/ssh_known_hosts, it will be erased when you reboot the server.

There are some obvious weaknesses with this setup. All clients get their image from the same server, which causes high loads on the server if many clients are booted at the same time. Also, the clients require that server to be always available; without it they cannot boot or get an LDM server. Therefore this setup is very dependent on one server, which isn't very good.

Your clients should now be load-balanced!

Sound with LTSP clients

LTSP thin clients use networked audio to pass audio from the server to the clients.

LTSP diskless workstations handle audio locally.

Use printers attached to LTSP clients

Use NFS instead of NBD

To speed up customizing and testing an LTSP chroot NFS could be used.

# Switch from NBD --> NFS:
sed -i 's/default ltsp-NBD/default ltsp-NFS' /opt/ltsp/$(dpkg --print-architecture)/boot/pxelinux.cfg/ltsp
sed -i 's/ontimeout ltsp-NBD/ontimeout ltsp-NFS/' /opt/ltsp/$(dpkg --print-architecture)/boot/pxelinux.cfg/ltsp

# Switch from NFS --> NBD:
sed -i 's/default ltsp-NFS/default ltsp-NBD' /opt/ltsp/$(dpkg --print-architecture)/boot/pxelinux.cfg/ltsp
sed -i 's/ontimeout ltsp-NFS/ontimeout ltsp-NBD/' /opt/ltsp/$(dpkg --print-architecture)/boot/pxelinux.cfg/ltsp

Upgrading the LTSP environment

It is useful to upgrade the LTSP environment with new packages fairly often, to make sure security fixes and improvements are made available. To upgrade, run these commands as user root on each LTSP server:

ltsp-chroot -a amd64  # this does "chroot /opt/ltsp/amd64" and more, ie it also prevents daemons from being started
apt update
apt upgrade
apt full-upgrade

Installing additional software in the LTSP environment

To install additional software for an LTSP client you must perform the installation inside the chroot of the LTSP server.

ltsp-chroot -a amd64
## optionally, edit the sources.list:
#editor /etc/apt/sources.list
apt update
apt install $new_package

Slow login and security

Skolelinux has added several security features on the client network preventing unauthorised superuser access, password sniffing, and other tricks which may be used on a local network. One such security measure is secure login using SSH, which is the default with LDM. This can slow down some client machines which are more than about fifteen years old, with as little as a 160 MHz processor and 32 MB RAM. Although it's not recommended, you can add a line to /opt/ltsp/amd64/etc/lts.conf containing:


/!\ Warning: The above protects initial login, but all activities after that use unencrypted networked X. Passwords (except the initial one) will travel in cleartext over the network, as well as anything else.

Note: Since such fifteen-year-old thin clients may also have trouble running newer versions of LibreOffice and Firefox due to pixmap caching issues, you may consider running thin clients with at least 128 MB RAM, or upgrade the hardware, which will also give you the benefit of being able to use them as diskless workstations.

Connecting Windows machines to the network / Windows integration

Joining a domain

For Windows clients the Windows domain "SKOLELINUX" is available to be joined. A special service called Samba, installed on the main server, enables Windows clients to store profiles and user data, and also authenticates the users during the login.

/!\ Joining a domain with a Windows client requires the steps described in the Debian Edu Buster Samba Howto.

Windows will sync the profiles of domain users on every Windows login and logout. Depending on how much data is stored in the profile, this could take some time. To minimise the time needed, deactivate things like local cache in browsers (you can use the Squid proxy cache installed on the main server instead) and save files into the H: volume rather than under "My Documents".

Remote Desktop

Choosing the LTSP server profile or the combined server profile also installs the xrdp and x2goserver packages.


Xrdp uses the Remote Desktop Protocol to present a graphical login to a remote client. Microsoft Windows users can connect to the LTSP server running xrdp without installing additional software - they simply start a Remote Desktop Connection on their Windows machine and connect.

Additionally, xrdp can connect to a VNC server or another RDP server.

Xrdp comes without sound support; to compile the required modules this script could be used.

 # Script to compile / recompile xrdp PulseAudio modules.
 # The caller needs to be root or a member of the sudo group.
 # Also, /etc/apt/sources.list must contain a valid deb-src line.
 set -e
  if [[ $UID -ne 0 ]] ; then  
     if ! groups | egrep -q sudo ; then
         echo "ERROR: You need to be root or a sudo group member."
         exit 1
 if ! egrep -q  ^deb-src /etc/apt/sources.list ; then
     echo "ERROR: Make sure /etc/apt/sources.list contains a deb-src line."
     exit 1
 TMP=$(mktemp -d)
 PULSE_UPSTREAM_VERSION="$(dpkg-query -W -f='${source:Upstream-Version}' pulseaudio)"
 XRDP_UPSTREAM_VERSION="$(dpkg-query -W -f='${source:Upstream-Version}' xrdp)"
 sudo apt -q update
 # Get sources and build dependencies:
 sudo apt -q install dpkg-dev
 cd $TMP
 apt -q source pulseaudio xrdp
 sudo apt -q build-dep pulseaudio xrdp
 # For pulseaudio 'configure' is all what is needed:
 # Adjust pulseaudio modules Makefile (needs absolute path)
 # and build the pulseaudio modules.
 cd $TMP/xrdp-$XRDP_UPSTREAM_VERSION/sesman/chansrv/pulse/
 sed -i 's/^PULSE/#PULSE/' Makefile
 sed -i "/#PULSE_DIR/a \
 # Copy modules to Pulseaudio modules directory, adjust rights.
 sudo cp *.so /usr/lib/pulse-$PULSE_UPSTREAM_VERSION/modules/
 sudo chmod 644 /usr/lib/pulse-$PULSE_UPSTREAM_VERSION/modules/module-xrdp*
 # Restart xrdp, now with sound enabled.
 sudo service xrdp restart


X2Go enables you to access a graphical desktop on the LTSP server over both low bandwidth and high bandwidth connections from a PC running Linux, Windows or macOS. Additional software is needed on the client side, see the X2Go wiki for more information.

Please note that the killer package should best be removed on the LTSP server if X2Go is used, see 890517.

Available Remote Desktop clients