Differences between revisions 20 and 21
Revision 20 as of 2012-01-16 14:09:29
Size: 26812
Editor: ?WolfgangSchweer
Comment: change LTSP loadbalancing info, get rid of a FIXME
Revision 21 as of 2012-01-20 19:12:34
Size: 26876
Editor: JustinBRye
Comment: proofreading (LTSP section)
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
== Introduction to Thin clients and Diskless workstations == == Introduction to thin clients and diskless workstations ==
Line 10: Line 10:
A thin client setup enables a 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. 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.
Line 14: Line 14:
A diskless workstation runs all software locally. The client machines boot direcly 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 maintanence cost as with thin clients. 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.
Line 17: Line 17:
If one faces problems with netbooting a machine first PXE installation could be used for troubleshooting; 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. 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.
Line 21: Line 21:
# First get firmware packages information
apt-get update && apt-cache search ^firmware-.*"
# First get information about firmware packages
apt-get update && apt-cache search ^firmware-
Line 38: Line 38:
Each LTSP server has two ethernet cards, one is 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 (this subnet is 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 seperate subnet 192.168.0.0/24.
Each LTSP server has two ethernet cards; one is 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 (this subnet is 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.
Line 44: Line 44:
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 one wants all clients to boot as diskless workstations instead of getting the full PXE menu, this can be implemented by changing the symlink:
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:
Line 53: Line 52:
If one wants all clients to boot as thin clients instead, change the symlink like this: If all clients should boot as thin clients instead, change the symlink like this:
Line 59: Line 58:
See also the pxelinux documentation at http://syslinux.zytor.com/wiki/index.php/PXELINUX .

If one wants clients on the 192.168.x.x interface of a thin client server to boot as diskless workstations instead of thin clients, edit
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
Line 69: Line 68:
For performace 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.x.x) network, when tjener is not a combined server, one needs to follow these steps:

 * copy the ltsp directory from /var/lib/tftpboot from ltspserver00 to the same directory on tjener.
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.x.x) 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.
Line 75: Line 74:
 * edit {{{/var/lib/tftpboot/debian-edu/default-diskless.cfg}}} to use the IP address of ltspserver00, the following example uses 10.0.2.10 (which is the default):  * edit {{{/var/lib/tftpboot/debian-edu/default-diskless.cfg}}} to use the IP address of ltspserver00; the following example uses 10.0.2.10 (which is the default):
Line 82: Line 81:
== Changing the IP network settings ==

debian-edu-config 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}}}.
== Changing network settings ==

debian-edu-config 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}}}.
Line 88: Line 87:
To make special adaptations and configurations for specific thinclients, you can edit the file {{{/opt/ltsp/i386/etc/lts.conf}}}. Install the ltsp-docs package and run "man lts.conf" to have a look at available configuration options.

The default values is defined under {{{[default]}}}, to configure one client, specify which client using the client mac adress or ipadress like this {{{[192.168.0.10]}}}.

Example: To make the thinclient ltsp010 use 1280x1024 resolution, add something like this:
To configure specific thin clients with particular features, you can edit the file {{{/opt/ltsp/i386/etc/lts.conf}}}. Install the package [[DebPkg/Squeeze:ltsp-docs]] and 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 {{{[192.168.0.10]}}}.

Example: To make the thin client ltsp010 use 1280x1024 resolution, add something like this:
Line 104: Line 103:
To use ipadresses in {{{lts.conf}}} you should add the client mac-address to your dhcp-server. Otherwise you should use the client mac-address directly in you {{{lts.conf}}} file.

=== Load balancing LTSP servers ===
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.

=== Load-balancing LTSP servers ===
Line 109: Line 108:
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 need to include the ssh host key for each of the servers.

First of all, you must choose one LTSP server to be the loadbalancing 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 loadbalancing 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.)
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 need 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.)
Line 115: Line 114:
Next-server should be the IP-address or hostname of the server you chose to be the loadbalancing 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 loadbalancing, the clients should have direct access to the server LDM chooses. 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.
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.
Line 121: Line 120:
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 names, in the random order. 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.
Line 127: Line 126:
Replace xxxx with either the IP or hostname of the servers, list must be space separated. Then, put the following script in /opt/ltsp/i386/usr/lib/ltsp/get_hosts on the server you chose to be the loadbalancing server.

{{{
#!/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
}}}
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
 # 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
}}}
## why isn't this a oneliner calling the /usr/bin/shuf in coreutils?
Line 146: Line 147:
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 loadbalanced. Save this file as /etc/ltsp/ssh_known_hosts.extra on all loadbalance 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 is some obvious weaknesses with this setup. All clients get their image from the same server, this causes high loads on the server if many clients are booted at the same time. Also the clients require that server to always be available, without it they cannot boot or get a LDM server. Therefore this setup is very dependent on one server, which isn't very good.

Your clients should now be loadbalanced!
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!
Line 156: Line 157:
LTSP thin clients supports 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 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.
Line 176: Line 177:
To install additional software for LTSP client you must perform the installation inside the chroot of the LTSP server. To install additional software for an LTSP client you must perform the installation inside the chroot of the LTSP server.
Line 181: Line 182:
#vim /etc/apt/sources.list #editor /etc/apt/sources.list
Line 189: Line 190:
Skolelinux has added several security features on the client network preventing unauthorised super user access, stopping password sniffing and other tricks which may be used on a local network. One such security measures is secure login using ssh wich is default with LDM. This can slow down some client machines which are older than 10 years, having as little as 160 MHz processor and 32 MB RAM. Even if not recomended, you can add the "True" value in ... 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 default with LDM. This can slow down some client machines which are more than about ten years old, with as little as 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:
Line 194: Line 195:
should be added to the server in the {{{/opt/ltsp/i386/etc/lts.conf}}} file.

/!\ '''Warning''': 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 10 year old thin clients may also get trouble with 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 to hardware, which will also give you the benefit of being able to use them as diskless workstations.

/!\ '''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.
Line 201: Line 201:
Skolelinux since version 3.0 is running LDM as a login manager. It uses a secure ssh tunnel to log in. When using KDM a switch to XDMCP is neccesary. XDMCP uses less CPU ressources on the clients and on the server. 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.
Line 212: Line 212:
If you are on the thin client network, please run this command: If you are on the thin client network, run this command:
Line 217: Line 217:
The goal is to let your "real" thin client to contact the xdmcp-server on the 192.168.0.254 net (given a standard Skolelinux configuration).

If by some reason xdmcp is accessible on your server which runs KDM , please add the following to /etc/kde3/kdm/Xaccess
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`:
Line 224: Line 224:
The star before the comment '#' is important, rest is a comment of course :)

Then turn on xdmcp in kdm with the command:
The star before the comment '#' is important; the rest is a comment, of course :)

Then turn on XDMCP in KDM with the command:
Line 231: Line 231:
At the end please restart kdm by running: Finally, restart KDM by running:
Line 236: Line 236:
(in courtesy of Finn-Arne Johansen) (with thanks to Finn-Arne Johansen)

HowTos for networked clients

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 nonfree 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

Machine type selection based on the network

Each LTSP server has two ethernet cards; one is 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 (this subnet is 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.

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 line. There is no need to add these workstations in GOsa, saving you some work and some "staticxx" IP addresses (see below).

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.x.x) 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 (which is the default):

 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

debian-edu-config 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.

LTSP in detail

lts.conf

To configure specific thin clients with particular features, you can edit the file /opt/ltsp/i386/etc/lts.conf. Install the package ?DebPkg/Squeeze:ltsp-docs and 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 [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.

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.

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 need 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
 # 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

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 default with LDM. This can slow down some client machines which are more than about ten years old, with as little as 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 userdata and also authenticates the users during the login.

In order to make Windows clients join the domain some (few) steps are required:

1. Create a user with membership in the "admins" group (if not already existing)

  • In order to be able to join the "SKOLELINUX" domain a member of the admins group needs to authorize the process. If not yet existing, a user with that membership needs to be added (for more information see <link to GOsa docu>). The user "root" will not work, because there is no password for root in Samba.

2. Configure the Windows client as static host

  • When joining a samba domain some special data is stored on the domain controller (tjener). This data is needed to recognize the Windows client later as being allowed to authenticate users. In order to enable Samba to store this data, Samba requires an static host configuration to be present. This could be added by using the GOsa web interface (see also <link to GOsa>). When adding the static host configuration it is important to check the "Samba host" option, otherwise will lack the required data to be able to join the domain.

3. On the Windows client: Make sure the network and system configuration matches the data stored on tjener (hostname and ip configuration).

  • It's really important, that the Windows hosts have the same data, otherwise Samba will not find the host added in step 2.

4. Join the domain as usual using the user added in step 1.

  • Depending on the version and language of you Windows installation, you should find the configuration about the domain or workgroup of your system somewhere in the system properties. A freshly installed Windows system should belong to a default workgroup. You can join the domain by selecting "Domain" instead of "Workgroup" and entering SKOLELINUX as new domain. Pressing enter will then open a new window, where the login data of the user created in step 1. can be entered. After some time the Windows client opens a popup window with a welcome message. After the obligatory reboot the loginscreen offers a option to login into the domain.

Windows will sync the profile of domain users on every login and logout. Depending on how much data stored in the profile this could take some time. To minimize the time needed, one should deactivate things like local cache in browsers (you could use the squid proxycache installed on tjener instead) and save file into the H: volume instead of "Own files".

User groups in Windows

Groupmaps must also be added for any other user groups you add through GOsa. If you want your user groups to be available in Windows, eg 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: should user groups in windows better be explained with GOsa first, 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 home laptop 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 its called now).

Managing roaming profiles

Roaming profiles contain user work environments, which include the desktop items and settings. Some examples of these environments are personal files, desktop icons and menus, screen colors, 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 problems is that users save their files on the windows desktop or in the My Documents folder instead of in their homedir. Also some badly designed programs use the profile for scratch space, and other data.

The educational approach: One way to deal with to large profiles is to explain the situation for 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 way to deal with the problem is to remove parts of the profile, and redirect other parts to regular file storage. This moves the work load 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's for roaming profiles

Already delivered while installation, you can find an example smb.conf hopefully in your prefered language. You can find the config example files on your tjener under /usr/share/debian-edu-config/examples/. The source file is in English and is called smb-roaming-profiles-en.conf. If it is translated to German for example, it is named smb-roaming-profiles-de.conf. So if you search a file translated to your prefered language, look at the country code part in the filename. Inside the config file are a lot of explanations, so you should have a look at.

Using machine policies

Machine policies can be edited and copied to all the other computers.

  1. Pick a freshly installed Windows computer, and run gpedit.msc
  2. Under the selection User Configuration -> Administrative Templates -> System -> User Profiles -> Exclude directories in roaming profile, you can enter a semicolon separated string of directories to exclude from the profile, the directories are internationalized and must be written in your own language the way they are in the profile. Example of directories to exclude are

    • log
    • Locale settings
    • Temporary Internet Files
    • My Documents
    • Application Data
    • Temporary Internet Files
  3. Save your changes, and exit the editor.
  4. 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.

Using global policies

By using the legacy windows policy editor (poledit.exe), you can can create a Policy file (NTConfig.pol) file and put it in your netlogon share on tjener. This has the advantage of working almost instantly on all windows machines.

Since some time the policy editor standalone download has been removed from the Microsoft website, 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 be read by the windows machine automatically and temporarily overwrite the registry, thus applying the changes.

To make sensible use of poledit.exe you also need to download appriate .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 website on this topic.

Editing Windows registry

You can edit the registry of the local computer, and copy this registry key to other computers

  1. Start the Registry Editor.
  2. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

  3. Use the menu Edit menu->New->String Value.

  4. Call it ExcludeProfileDirs

  5. Enter a semicolon sepatated string of paths to exclude. (same way as 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:

Redirecting parts of profile

Sometimes just removing the directory from the profile is not enough. You may experience that users loose files because they mistakenly save things into my documents, when this is not saved in the profiles. Also you may want to redirect the directories some badly programed applications use to normal network shares.

Using machine policies

Everything under Using machine policies above applies. You edit using gpedit.msc and copy the Policy to all machines The redirection should be available under User Configuration -> Windows Settings->Folder Redirection Things that can be nice to redirect are Desktop or My Documents.

One thing to remember is that if you enable folder redirection, those folders are automatically added to the syncroniced folders list. If you do not want this, you should also disable that in following

  • User Configuration -> Administrative Templates -> Network -> Offline Files

  • Computer Configuration -> Administrative Templates -> Network -> Offline Files

Using global policies

FIXME explain how to use profiles from global policies for windows machines in the skolelinux network

Avoiding roaming profiles

Using a local policy

Using local policies you can disable roaming profile on individual machines. This is often wanted on special machines, for instance on dedicated machines, or machines that have lower then usual bandwith.

You can use the machine policy method describe above, the key is in

  • Administrative Templates -> system -> User Profiles -> Only allow local profiles

Using global policies

FIXME: describe roaming profile key for the global policy editor here

altering samba config

By editing the samba config you can disable roaming profiles for the entire network. Perhaps everyone have their own dedicated machine? and nobody else is allowed to touch it. To disable the roaming profiles for the entire network you can alter the smb.conf file on tjener and unset the logon path and logon home variables, and restart samba.

logon path = ""
logon home = ""

Remote Desktop

Remote Desktops Service

Beginning with this release, choosing the thin client server profile or the combined server profile, xrdp is installed, 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. So simply start your Remote-Desktop-Connection on your Windows[tm] 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.

Remote Desktops clients with RDP, VNC, NX or Citrix

  • RDP - the easiest way to access Windows terminal server. Just install the rdesktop or freerdp-x11 packages.

  • VNC client (Virtual Network Computer) gives access to Skolelinux remotely. Just install the xvncviewer package.

  • 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 their 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.)

CategoryPermalink