HowTos for networked clients
Contents
Introduction to thin clients and diskless workstations
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 from a diskette or directly from the server using network-PROM (or 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, 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 newer hardware with the same low maintenance cost as with thin clients.
LTSP client boot will fail if the client's network card 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 card(s). # Most probably this will be firmware-linux-nonfree # Things have to take effect in the LTSP chroot for architecture i386 ltsp-chroot -a i386 apt-get update ltsp-chroot -a i386 mkdir /tmp/user 2> /dev/null ltsp-chroot -a i386 mkdir /tmp/user/0 2> /dev/null ltsp-chroot -d -a i386 apt-get -y -q install <package name> # copy the new initrd to the server's tftpboot directory ltsp-update-kernels
LTSP client kernel
In order to support older hardware the package linux-image-486 is installed by default. If all LTSP client machines support the 686 processor architecture the linux-image-686 package could be installed in the chroot.
Make sure to execute ltsp-update-kernels after installation.
Machine type selection based on the network
Each LTSP server has two ethernet cards: one configured in the 10.0.0.0/8 subnet (which is shared with the main server), and another forming a local 192.168.0.0/24 subnet (a separate subnet for each LTSP server).
Diskless workstations get IP addresses assigned in the private subnet 10.0.0.0/8, while thin clients are connected in the separate subnet 192.168.0.0/24.
Configuring the PXE menu
The PXE configuration is generated using the script debian-edu-pxeinstall. It allows some settings to be overridden by adding a 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:
MENU PASSWD $4$NDk0OTUzNTQ1NTQ5$7d6KvAlVCJKRKcijtVSPfveuWPM$
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.
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 http://example.org/debian 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 http://example.org/key.asc
and then run /usr/sbin/debian-edu-pxeinstall once.
Changing the PXE menu on an 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 http://syslinux.zytor.com/wiki/index.php/PXELINUX .
If clients on the 192.168.x.x interface of a thin client server should boot as diskless workstations instead of thin clients, edit
/var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
and add a '3' (no quotes) to the end of the kernel argument line, to specify runlevel 3.
The file should then look like this:
default ltsp label ltsp kernel vmlinuz append ro initrd=initrd.img boot=nfs quiet 3
When adding such a workstation in GOsa², use an IP address matching the LTSP server interface IP address on the thin client net (by default 192.168.0.254, dynamic dhcp range starting at 192.168.0.20).
Separate main- and LTSP servers
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 (10.0.0.0/8) network, when tjener is not a combined server, follow these steps:
copy the ltsp directory from /var/lib/tftpboot on ltspserver00 to the same directory on tjener.
copy /var/lib/tftpboot/debian-edu/default-diskless.cfg to the same directory on tjener.
edit /var/lib/tftpboot/debian-edu/default-diskless.cfg to use the IP address of ltspserver00; the following example uses 10.0.2.10 for the IP address of ltspserver00 on the main network:
DEFAULT ltsp/i386/vmlinuz initrd=ltsp/i386/initrd.img nfsroot=10.0.2.10:/opt/ltsp/i386 boot=nfs ro quiet 3
set the symlink in /var/lib/tftpboot/pxelinux.cfg on tjener to point to /var/lib/tftpboot/debian-edu/default-diskless.cfg.
Changing network settings
The debian-edu-config package comes with a tool which helps in changing the network from 10.0.0.0/8 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. 192.168.1.0/24 is already set up as the thin client network. Changing to this subnet 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 thin clients with particular features, you can add settings in LDAP or edit the file /opt/ltsp/i386/etc/lts.conf.
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.
Install the package ltsp-docs and run "man lts.conf" to have a look at available configuration options (see /usr/share/doc/ltsp/LTSPManual.html for detailed information about LTSP).
The default values are defined under [default]; to configure one client, specify it in terms of its MAC address or IP address like this: [192.168.0.10].
Example: To make the thin client ltsp010 use 1280x1024 resolution, add something like this:
[192.168.0.10] X_MODE_0 = 1280x1024 X_HORZSYNC = "60-70" X_VERTREFRESH = "59-62"
somewhere below the default settings.
To force usage of a specific xserver on an LTSP client, set the XSERVER variable. For example:
[192.168.0.11] XSERVER = nvidia
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 thin clients to use LXDE as default desktop environment
Make sure that LXDE is installed on the thin client server; then add a line like this below [default] in "lts.conf":
LDM_SESSION=/usr/bin/startlxde
Note, that users will still be able to select other installed desktop environments using the "Settings" feature of LDM.
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/i386/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. How this is done you decide later on.
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 192.168.1.0 network to the 10.0.0.0 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 192.168.1.0 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 that prints a server 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/i386/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/i386/usr/lib/ltsp/get_hosts on the server you chose to be the load-balancing server.
#!/bin/bash # Randomise 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
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/i386/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/i386/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 support three different audio systems for applications: ESD, PulseAudio and ALSA. ESD and PulseAudio support networked audio and are used to pass audio from the server to the clients. ALSA is configured to redirect its sound via PulseAudio. For selected applications only supporting the OSS audio system, a wrapper is created by /usr/sbin/debian-edu-ltsp-audiodivert to redirect their sound to PulseAudio. Run this script without arguments to get a list of applications with such redirection enabled.
LTSP diskless workstations handle audio locally and have none of the special setup needed for networked audio.
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 i386 # this does "chroot /opt/ltsp/i386" and more, ie it also prevents daemons from being started aptitude update aptitude upgrade aptitude dist-upgrade exit
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 i386 ## optionally, edit the sources.list: #editor /etc/apt/sources.list aptitude update aptitude install $new_package exit
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 ten years old, with as little as a 160 MHz processor and 32 MB RAM. Although it's not recommended, you can add the value "True" in the /opt/ltsp/i386/etc/lts.conf file on the server:
LDM_DIRECTX=True
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 ten-year-old thin clients may also have trouble running never versions of OpenOffice.org and Firefox/Iceweasel 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.
Replacing LDM with KDM
Since version 3.0 Skolelinux has been running LDM as its login manager, which uses a secure SSH tunnel to log in. Switching to KDM also requires a switch to XDMCP, which uses lower CPU resources on the clients and on the server.
Warning: XDMCP does not use encryption. Passwords will travel in cleartext over the network, as well as anything else.
Note: local devices with ltspfs will stop working without LDM.
To check if XDMCP is running, run this command from a workstation:
X -query ltspserverXX
If you are on the thin client network, run this command:
X -query 192.168.0.254
The goal is to let your "real" thin client contact the xdmcp-server on 192.168.0.254 (given a standard Skolelinux configuration).
If for some reason XDMCP is accessible on your server which runs KDM, add the following to /etc/kde3/kdm/Xaccess:
* # any host can get a login window
The star before the comment '#' is important; the rest is a comment, of course
Then turn on XDMCP in KDM with the command:
sudo update-ini-file /etc/kde3/kdm/kdmrc Xdmcp Enable true
Finally, restart KDM by running:
sudo invoke-rc.d kdm restart
(with thanks to Finn-Arne Johansen)
Connecting Windows machines to the network / Windows integration
Joining the domain
For Windows clients the Windows domain "SKOLELINUX" is available to be joined. A special service called Samba, installed on the main-server tjener, enables Windows clients to store profiles and user data, and also authenticates the users during the login.
Allowing a Windows client to join the domain requires steps described in the Debian Edu Squeeze 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 tjener instead) and save files into the H: volume rather than under "My Documents".
User groups in Windows
Groupmaps must also be added for any other user group you add through GOsa². If you want your user groups to be available in Windows, e.g. for netlogon scripts or other group dependant actions, you can add them using variations of the following command. Samba will function without these groupmaps, but Windows machines won't be group-aware.
/usr/bin/net groupmap add unixgroup=students \ type=domain ntgroup="students" \ comment="All students in the school"
FIXME: would it be better to explain user groups in Windows first with GOsa², and then with an example for the command line?
If you want to check user groups on Windows, you need to download the tool IFMEMBER.EXE from Microsoft. Then you can use this for example in the logon script which resides on tjener in /etc/samba/netlogon/LOGON.BAT.
XP home
Users bringing in their XP laptops from home can still connect to tjener using their skolelinux credentials, provided the workgroup is set to SKOLELINUX. However, they may need to disable the Windows firewall before tjener will appear in Network Neighbourhood (or whatever it's called now).
Managing roaming profiles
Roaming profiles contain user work environments which include desktop items and settings. Examples include personal files, desktop icons and menus, screen colours, mouse settings, window size and position, application configurations, and network and printer connections. Roaming profiles are available wherever the user logs on, provided the server is available.
Since the profile is copied from the server to the machine during logon, and copied back to the server during logout, a large profile can make Windows login/logout painfully slow. There can be many reasons for a large profile, but the most common problem is that users save their files on the Windows desktop or in the "My Documents" folder instead of in their home directory. Also, some badly designed programs use the profile to store data and as scratch space.
The educational approach: one way to deal with overlarge profiles is to explain the situation to the users. Tell them not to store huge files on the desktop, and if they fail to listen, it's their own fault when login is slow.
Tweaking the profile: a different approach to dealing with the problem is to remove parts of the profile, and redirect other parts to regular file storage. This moves the workload from the users to the administrator, while adding complexity to the installation. There are at least three ways to edit the parts that are removed from the roaming profile.
Example smb.conf files for roaming profiles
You should hopefully find an example smb.conf in your preferred language delivered by the installation on tjener under /usr/share/debian-edu-config/examples/. The source file is in English and is called smb-roaming-profiles-en.conf; look for a file with the appropriate code in the filename (the German translation, for example, will be named smb-roaming-profiles-de.conf). Inside the config file are a lot of explanations which you should have a look at.
Machine policies for roaming profiles
Machine policies can be edited and copied to all the other computers.
Pick a freshly installed Windows computer, and run gpedit.msc
Under the selection "User Configuration" -> "Administrative Templates" -> "System" -> "User Profiles" -> "Exclude directories in roaming profile", you can enter a semicolon-separated list of directories to exclude from the profile. The directories are internationalised and must be written in your own language the way they are in the profile. Examples of directories to exclude are:
- log
- Locale settings
- Temporary Internet Files
- My Documents
- Application Data
- Temporary Internet Files
- Save your changes, and exit the editor.
Copy c:\windows\system32\GroupPolicy to all other Windows machines.
- It's a good idea to copy it to your Windows OS deployment system to have it included at install time.
Global policies for roaming profiles
By using the legacy Windows policy editor (poledit.exe), you can can create a Policy file (NTConfig.pol) and put it in your netlogon share on tjener. This has the advantage of working almost instantly on all Windows machines.
For some time, the policy editor standalone download has been removed from the Microsoft web site, but it's still available as part of the ORK Tools.
With poledit.exe you can create .pol files. If you put such a file on tjener as /etc/samba/netlogon/NTLOGON.POL it will automatically be read by Windows machines and temporarily overwrite the registry, thus applying the changes.
To make sensible use of poledit.exe you also need to download appropriate .adm files for your operating system and applications; otherwise you cannot define many settings in poledit.exe.
Be aware that the new group policy tools, gpedit.msc and gpmc.msc, cannot create .pol files; they either only work for the local machine or need an Active Directory server.
If you understand German, http://gruppenrichtlinien.de is a very good web site on this topic.
Editing Windows registry
You can edit the registry of the local computer, and copy this registry key to other computers
- Start the Registry Editor.
Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Use the menu "Edit menu" -> "New" -> "String Value".
Call it ExcludeProfileDirs
- Enter a semicolon-separated list of paths to exclude (in the same way as for a machine policy)
- Now you can choose to export this registry key as a .reg file. Mark a selection, right-click, and select "Export".
- Save the file and you can double click it, or add it to a script to spread it to other machines.
Sources:
http://technet2.microsoft.com/windowsserver/en/technologies/featured/gp/default.mspx
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/PolicyMgmt.html
Redirecting profile directories
Sometimes just removing directories from the profile is not enough. You may find that users lose files because they mistakenly save things into "My Documents" when this is not saved in the profiles. You may also want to redirect the directories used by some badly programmed applications to normal network shares.
Redirecting using machine policies
All the instructions given above about machine policies apply here too. You can use gpedit.msc to edit the policy and copy it to all machines. The redirection should be available under "User Configuration" -> "Windows Settings" -> "Folder Redirection". Directories that it can be useful to redirect include "Desktop" and "My Documents".
One thing to remember is that if you enable folder redirection, those folders are automatically added to the synchronised folders list. If you do not want this, you should disable it via one of the following routes:
"User Configuration" -> "Administrative Templates" -> "Network" -> "Offline Files"
"Computer Configuration" -> "Administrative Templates" -> "Network" -> "Offline Files"
Redirecting using global policies
FIXME explain how to use profiles from global policies for Windows machines in the skolelinux network
Avoiding roaming profiles
Disabling roaming using a local policy
Using local policies, you can disable the roaming profile on individual machines. This is often wanted on special machines - for instance on dedicated machines, or machines that have lower than usual bandwith.
You can use the machine policy method describe above; the key is in "Administrative Templates" -> "System" -> "User Profiles" -> "Only allow local profiles".
Disabling roaming using global policies
FIXME: describe roaming profile key for the global policy editor here
Disabling roaming in smb.conf
If, perhaps, everyone has their own dedicated machine, and nobody else is allowed to touch it, editing the Samba configuration will let you disable roaming profiles for the entire network. You can alter the smb.conf file on tjener, unsetting the "logon path" and "logon home" variables, then restart samba.
logon path = "" logon home = ""
Remote Desktop
Remote Desktop Service
Beginning with this release, choosing the thin client server profile or the combined server profile installs xrdp, a package which uses the Remote Desktop Protocol to present a graphical login to a remote client. Microsoft Windows users can connect to the thin client 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.
Some municipalities provide a remote desktop solution so that students and teachers can access Skolelinux from their home computer running Windows, Mac or Linux.
Available Remote Desktop clients
freerdp-x11 is installed by default and is captable of RDP and VNC.
RDP - the easiest way to access Windows terminal server. An alternative client package is rdesktop.
VNC client (Virtual Network Computer) gives access to Skolelinux remotely. An alternative client package is xvncviewer.
- NX graphical client gives students and teachers access to Skolelinux remotely on Windows, Mac or Linux PC. One municipality in Norway has provided NX support to all students since 2005. They report that the solution is stable.
Citrix ICA client HowTo to access Windows terminal server from Skolelinux.
HowTos from wiki.debian.org
The HowTos from http://wiki.debian.org/DebianEdu/HowTo/ are either user- or developer-specific. Let's move the user-specific HowTos over here (and delete them over there)! (But first ask the authors (see the history of those pages to find them) if they are fine with moving the howto and putting it under the GPL.)