Multiple server setup

A multiple server setup is useful for larger thin client networks. Instead of using one big server, it makes it possible to use smaller servers, and dispatch users on them. You can adjust computing resources as the demand grows simply by adding a new server. To make sure that every server behaves the same from the users point of view, new services and configurations that are required will be discussed. In addition, some configurations specific to thin clients will be presented.

Infrastructure setup

Network topology

The network topology is the same as a standalone server setup, except that there are more than one server on the thin client lan.

You will need to select one server to behave as the primary server. This server will be used to run additional services, hold users files, and network boot thin clients.

Secondary servers will be used only to run desktop sessions. They are simpler, and will be configured to use the central services from the primary server. Installing the package ltsp-server will install required software.

Common authentication

A user should be able to start a session with the same login and password, no matter which server it connects to. For this purpose, a central authentication mechanism must be used. There are many possibilities offered. Here are the major technologies:

  • LDAP authentication: On the master server, setup an OpenLDAP server. Configure each servers to use this LDAP server as the authentication base, with the pam_ldap plugin.

  • NIS authentication: On the master server, setup a NIS server. Configure each server to use this NIS server for the authentication.

  • Winbind authentication: Useful if you already have an Active Directory server.

  • The smbldap-installer offers system administrators an easy way to set up a Samba/LDAP server which can authenticate both Windows and non-Windows (Linux, Mac OS X, and others) clients. Home directories can be centrally located on one server and shared with other servers. For more information: http://www.majen.net/smbldap

For detailed instructions, see their respective manuals.

Shared home directories

Shared home directories are easy to setup using an NFS server on the primary server. To configure the share, install the package nfs-kernel-server. Then, edit the file /etc/exports and add the following line, by replacing secondary_server_ip by the real IP address of the server.

/home   secondary_server_ip(rw,no_root_squash)
                    

After this modification, the service needs to be restarted.

sudo invoke-rc.d nfs-kernel-server restart
                    

You can define the mount point on each secondary servers, by editing the file /etc/fstab and adding the following line:

192.168.0.1:/home /home nfs hard,intr,rsize=8192,wsize=8192,bg 0 0
                    

With the default setup, the home directory of the user must exist before the first login. To create the home directory on the fly on the first login, you can use the pam_mkhomedir plugin. The NFS export option no_root_squash allows any secondary server to create directories on the primary server.

Shared printers

For printers to be accessible on each server, the cups server must be configured to share printers. Refer to the CUPS manual for detailed instructions.

Synchronization of packages

Once you install one desktop application on one server, then you must install it on all the other servers, as well. Otherwise, users may not be able to use the same set of applications. First, make sure that /etc/apt/sources.list file is the same on each server. Then, list packages of the reference server. Using the primary server for this purpose is not recommended, since it may install other server packages that are not necessary on secondary servers. To build the package list:

dpkg --get-selections > deblist 

Then, copy this file on the target server you want to sync applications, and perform the following steps:

sudo dpkg --set-selections < deblist
sudo apt-get dselect-upgrade
                    

Apt will install additional packages that are not already installed on the target machine.

Managing the SSH known hosts file

For security reasons, a thin client won't connect to an untrusted server. You must add the keys of secondary servers inside the client root on the primary server. To do this, first export the key file of the secondary server to add:

sudo ltsp-update-sshkeys --export ssh_known_hosts.myhostname
                    

Then, copy the file on the primary server, in the directory /etc/ltsp/, and run ltsp-update-sshkeys on the primary server. Then, thin clients will trust the freshly added server, and will be able to connect to it.

If a secondary server changes it's IP address, then this procedure must be repeated.

Setting network forwarding

Primary server will act as an network gateway for other servers. With this configuration, other workstations will be able to access the network behind the primary server. Here is an example of script that setup the network forwarding. We put it in /etc/network/if-up.d/forward.sh, and make it executable. The script will run at each network start. In this example, the primary server private IP is 192.168.0.1. It must be adapted for the IP address used.

#!/bin/bash

echo 1 > /proc/sys/net/ipv4/ip_forward

echo Setting up the forwarding

LAN_IP_NET="192.168.0.1/24"
LAN_NIC="eth1"
OUT_NIC="eth0"

iptables -t nat -A POSTROUTING -s $LAN_IP_NET -o $OUT_NIC -j MASQUERADE
iptables -A FORWARD -j ACCEPT -i $LAN_NIC -s $LAN_IP_NET
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
                

Replication of desktop profiles

If you customize user's desktop, then custom desktop profiles should be copied to every server. Gnome desktop profiles created with Sabayon are located in /etc/desktop-profiles

Session dispatching

Define the server list

LDM is a login manager for thin clients. Users can select a server from the available ones in the host selection dialog box.

The displayed server list is defined by the LDM_SERVER parameter. This parameter accepts a list of server IP address or host names, separated by space. If you use host names, then your DNS resolution must work on the thin client. If defined in the lts.conf file, the list order will be static, and the first server in the list will be selected by default.

You can also compute a new order for the server list, by creating the script /opt/ltsp/i386/usr/lib/ltsp/get_hosts. The parameter LDM_SERVER overrides the 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 names, in the chosen order.

Dispatching method

You can change this behavior by using a script to rearrange the list. The simplest way to do it is by randomizing the list. First, define a custom variable in the file lts.conf, for example MY_SERVER_LIST, that will contain the list of servers, the same way as LDM_SERVER Then, put the following script in /opt/ltsp/i386/usr/lib/ltsp/get_hosts.

#!/bin/bash
# Randomize the server list contained in MY_SERVER_LIST parameter

TMP_LIST=""
SHUFFLED_LIST=""

for i in $MY_SERVER_LIST; do
rank=$RANDOM
let "rank %= 100"
TMP_LIST="$TMP_LIST\n${rank}_$i"
done

TMP_LIST=$(echo -e $TMP_LIST | sort)
for i in $TMP_LIST; do
SHUFFLED_LIST="$SHUFFLED_LIST $(echo $i | cut -d_ -f2)"
done

echo $SHUFFLED_LIST
                    

More advanced load balancing algorithms can be written. For example, load balancing can be done by querying ldminfod for the server rating. By querying ldminfod, you can get the current rating state of the server. This rating goes from 0 to 100, higher is better. Here is an example of such a query:

nc localhost 9571 | grep rating | cut -d: -f2