This is how I installed x11vnc on our Debian Lenny LTSP5 server, these are my notes, nothing more. Use at your peril!

Installing x11vnc

Enter the chroot

$ sudo chroot /opt/ltsp/i386

And update the repositories that the ltsp environment uses for apt-get:

# apt-get update
# apt-get install x11vnc

Create start-up script

Still in the chroot, edit /etc/init.d/x11vnc and copy in the following script:

#!/bin/sh

### BEGIN INIT INFO
# Provides:x11vnc
# Required-Start:$remote_fs $syslog
# Required-Stop:$remote_fs $syslog
# Default-Start:2 3 4 5
# Default-Stop:0 1 6
# Short-Description:Start X11VNC
# Description:Start VNC server X11VNC at boot
### END INIT INFO

case "$1" in
        start) 
                sleep 6
                XAUTH=`find /var/run/ldm-xauth* -type f`
                logger -f /var/log/x11vnc "Starting with $XAUTH"
                start-stop-daemon --start --oknodo --pidfile /var/run/x11vnc.pid --background --nicelevel 15 --make-pidfile --exec /usr/bin/x11vnc -- -display :7 -loop -passwdfile /etc/x11vncpassword -nossl -logfile /var/log/x11vnc -auth $XAUTH
        ;;
        stop)  
                logger -f /var/log/x11vnc "Stopping"
                start-stop-daemon --stop --oknodo --pidfile /var/run/x11vnc.pid
        ;;
        restart)
                logger -f /var/log/x11vnc "Restarting"
                $0 stop
                $0 start
        ;;
        condrestart)
                PID=`cat /var/run/x11vnc.pid`
                RUNNING=`ps h --ppid $PID`
                if [ "$RUNNING" == "" ]; then
                        logger -f /var/log/x11vnc "No process matching /var/run/x11vnc.pid"
                        echo "No process matching /var/run/x11vnc.pid"
                        $0 restart
                else   
                        logger -f /var/log/x11vnc "Process matching /var/run/x11vnc.pid exists"
                        echo "Process matching /var/run/x11vnc.pid exists - no action taken"
                fi
        ;;
        *)
                echo "Usage: $0 start|stop|restart|condrestart"
                exit 1
        ;;
esac

exit 0

Finalise start-up script

Still in the chroot, make the script executable and link it into /etc/rc2.d:

# chmod 755 /etc/init.d/x11vnc
# update-rc.d x11vnc defaults
# ls -al /etc/rc2.d/*x11vnc

Set x11vnc password

Finally, create the /etc/x11vncpassword file with the password you want to use to connect to your thin clients:

# echo "thepassword" > /etc/x11vncpassword
# chmod 400 /etc/x11vncpassword
# chown root:root /etc/x11vncpassword

Replace “thepassword” with your chosen password.

Alternative Method

The issue with the above method is that if you user does not reboot their client after logging off, then x11vnc does not restart. An alternative, remove the above symlink from /etc/rc2.d/S99x11vnc and instead use an ldm start up script by adding the following two scripts:

# /opt/ltsp/i386/usr/share/ldm/rc.d/I99-x11vnc
# LDM Script to start x11vnc

XAUTH=`find /var/run/ldm-xauth* -type f`
start-stop-daemon --start --oknodo --pidfile /var/run/x11vnc.pid --background --nicelevel 15 --make-pidfile --exec /usr/bin/x11vnc -- -display :7 -loop -passwdfile /etc/x11vncpassword -nossl -logfile /var/log/x11vnc -auth $XAUTH

The “I” in I99-x11vnc denotes that this will be run after X and before LDM, which is perfect for VNC.

# /opt/ltsp/i386/usr/share/ldm/rc.d/X99-x11vnc
# LDM Script to stop x11vnc

start-stop-daemon --stop --oknodo --pidfile /var/run/x11vnc.pid

The “X” denotes that this script will be run upon logout, so this is closing down the x11vnc server, ready to restart with LDM.

This method will still not cope with X being terminated with ctrl+alt+backspace, in which scenario you can ssh onto the client and run /etc/init.d/x11vnc condrestart - you could also add this in as a local app to be accessible from the server desktop.

References

• https://wiki.edubuntu.org/InstallX11VncOnLtspClients

You’ve inserted a disk or memory stick in your thin client, and nothing happened, what next?

Check lts.conf

Each user you wish to be able to access their local devices needs LOCALDEV = True in lts.conf, alternatively you may add to the ‘[default]’ section to make this global.

[192.168.1.198]
# Joe Bloggs Desktop
    LOCALDEV             = True

Check user is in fuse group

# groups userid
userid satff users audio fuse

If they are not in the fuse group then:

# adduser userid fuse

Check lts.conf settings are reaching client

A simple typo can mean that your carefully crafted lts.conf file is not reaching its target audience. To test, boot up the thin client and ctrl+alt+f1 to get to the console, login as root and type the following:

See LTSP Client Root Password if you are unable to log into the client.

# getltscfg -a

This will give you a list of all the settings that apply to this particular client, including any default settings. You need to check that you can see the above LOCALDEV=”True” is visible.

Check logs on client

# tail -f /var/log/syslog

Then try inserting the device, and you should see the detection - look for errors that might indicate what has gone wrong.

Check UDEV can see drive

Still on the client:

# udevadm info -q all -n sda1

Replace sda1 with the required device, e.g. sr0 for a cdrom etc.

P: /block/sda/sda1
N: sda1
S: block/8:1
S: disk/by-id/usb-USB_DISK_2.0_J68J5KQHN7TQ0H7G-0:0-part1
S: disk/by-path/pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0-part1
S: disk/by-uuid/99B8-E4E6
S: disk/by-label/PKBACK#\x20001
E: ID_VENDOR=USB
E: ID_MODEL=DISK_2.0
E: ID_REVISION=1219
E: ID_SERIAL=USB_DISK_2.0_J68J5KQHN7TQ0H7G-0:0
E: ID_SERIAL_SHORT=J68J5KQHN7TQ0H7G
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_PATH=pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0
E: ID_FS_USAGE=filesystem
E: ID_FS_TYPE=vfat
E: ID_FS_VERSION=FAT16
E: ID_FS_UUID=99B8-E4E6
E: ID_FS_UUID_ENC=99B8-E4E6
E: ID_FS_LABEL=PKBACK# 001
E: ID_FS_LABEL_ENC=PKBACK#\x20001
E: ID_FS_LABEL_SAFE=PKBACK#_001

An example of a CDROM:

P: /block/sr0
N: sr0
S: block/11:0
S: scd0
S: disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0
S: cdrom
S: cdrw
S: dvd
S: dvdrw
E: ID_CDROM=1
E: ID_CDROM_CD_R=1
E: ID_CDROM_CD_RW=1
E: ID_CDROM_DVD=1
E: ID_CDROM_DVD_R=1
E: ID_CDROM_DVD_RW=1
E: ID_CDROM_DVD_RAM=1
E: ID_CDROM_DVD_PLUS_R=1
E: ID_CDROM_DVD_PLUS_RW=1
E: ID_CDROM_DVD_PLUS_R_DL=1
E: ID_CDROM_MRW=1
E: ID_CDROM_MRW_W=1
E: ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0

Check ltspfs is installed on the server

# dpkg -l ltspfs | grep ^ii
ii  ltspfs                                       0.6-1~bpo50+1                        Fuse based remote filesystem for LTSP thin clients

Check fuse is running

# lsmod | grep fuse
fuse                   47124  3 

If fuse is not running, then:

# echo fuse >> /etc/modules
# modprobe fuse
# adduser USER fuse

KDE Desktop Icons

• Local Device Icons on KDE Desktop

References

For some additional troubleshooting, try: http://wiki.ubuntu.com/DebugLocalDev

These instructions have not been tested since re-writing, in particular there will be permissions issues.

Step 1: Install Wine

Please visit for instructions on how to install Wine:

• http://www.winehq.org/site/download

If you get a problem with applications appearing without any text, then you need to install some Windows fonts in Wine. One option is to simply download them from http://sourceforge.net/projects/corefonts/. You may also be able to install via a debian installer package:

$ sudo apt-get ttf-mscorefonts-installer

Install Wine packages:

$ sudo apt-get install libwine libwine-print libwine-sane libwine-alsa

Your requirements may vary, a non-inclusive list of available libraries is:

• libwine: the core wine library
• libwine-print: the printing library
• libwine-sane: the scanning library
• libwine-alsa: the alsa sound library
• libwine-oss: the oss sound library

You will notice winetools mentioned on several websites, my understanding is that this is no longer supported.

Step 2: Create a Wine directory for your application

By default Windows applications are installed in /home/user/.wine. If you want to install your application in a different directory then you must use the WINEPREFIX variable.

If you want your application to be installed in /usr/local/share/appname you must first create the directory:

$ cd /usr/local/share
$ mkdir appname
$ WINEPREFIX="/usr/local/share/appname" wineprefixcreate

In this directory you will now find a fake Windows drive and the Wine configuration files system.reg and user.reg.

Step 3: Configure your Wine directory

You can probably skip this step for typical installations.

$ WINEPREFIX="/usr/local/share/appname" winecfg

Step 4: Install your application

Installing from an .msi file

You can install .msi files with the msiexec.exe utility. This command is built into Wine, so you don’t have to install Windows Installer from Microsoft. If the .msi file is called msifile.msi you just have to type msiexec /i msifile.msi and the application will be installed.

Make sure you’re not using a native version of msi.dll, but the builtin one. To run the Windows install program, please type the following:

$ WINEPREFIX="/usr/local/share/appname" wine /path/to/setup.exe

Substitute “/path/to/setup.exe” with the installation path executable for your application

Step 5: Test your application

$ WINEPREFIX="/usr/local/share/appname" wine "drive_c/Program Files/app/appname.exe"

Step 6: Configure for multi-user operation

This section needs a re-write (or just refer to Example automation script below)

It is possible to configure the system so that a system Wine installation (and applications) can be shared by all the users, and still let the users all have their own personalized configuration.

# Creating individual user directory, e.g. /home/username/.appname
# Symlink directory structure to /usr/local/share/appname
# Remove symlink for user.reg (will be auto-created for each user on first run)

$ ln -sf /usr/local/share/appname/system.reg system.reg

To assist in this process, please refer to the following guide:

• http://www.winehq.org/site/docs/wineusr-guide/using-regedit

and perhaps even symlink these back to the administrator’s account, to make it easier to install apps system-wide later:

You might be tempted to do the same for user.reg as well, however that file contains user specific settings. Every user should have their own copy of that file along with the permissions to modify it.

You’ll want to pay attention to drive mappings. If you’re sharing the system.reg file you’ll want to make sure the registry settings are compatible with the drive mappings in ~/.wine/dosdevices of each individual user. As a general rule of thumb, the closer you keep your drive mappings to the default configuration provided by wineprefixcreate, the easier this will be to manage. You may or may not be able to share some or all of the actual “c:” drive you originally installed the application to. Some applications require the ability to write specific settings to the drive, especially those designed for Windows 95/98/ME.

Example automation script

This script was probably cobbled together from the superb ies4linux installation, or possibly from Franks Corner,

#!/usr/bin/perl
# Launch script for multiuser appname, master copy in /usr/local/share/appname.

use strict;

my $MASTERPREFIX = '/usr/local/share/appname';
my $WINEPREFIX   = $ENV['HOME'} . '/.appname';

use vars qw($MASTERPREFIX $WINEPREFIX);

# If we're not set up, create the user's magic symlink-copy of the master
# installation.

unless (-d "$WINEPREFIX") {
	system('mkdir', '-p', "$WINEPREFIX") == 0 ](| die "mkdir -p $WINEPREFIX: $?";
	system('lndir', "$MASTERPREFIX", "$WINEPREFIX") == 0 || die "lndir failed: is xutils installed? $?";

	# The profile directory will be recreated automatically by wine on the
	# first run, so it's OK to blow away eny existing copy hanging around in
	# unwritable symlink form from the install, and it's OK to just create a
	# blank one.
   
	$PROFILES = $WINEPREFIX . '/drive_c/windows/profiles';
	system('rm', '-fr', "$PROFILES") == 0 || die "rm -fr $PROFILES failed: $?";
	system('mkdir', '-p', "$PROFILES") == 0 || die "mkdir -p $PROFILES failed: $?";

	# WINE needs to be able to write to the following files, so they can't be
	# symlinks to root-owned ones.
   
	foreach my $file ('.no_prelaunch_window_flag', 'system.reg', 'userdef.reg', 'user.reg') {
		if (-l $WINEPREFIX . '/' . $file) {
			system('rm', '-f', $WINEPREFIX . '/' . $file) == 0 || die "rm -f $WINEPREFIX/$file failed: $?";
			system('cp', $MASTERPREFIX . '/' . $file, $WINEPREFIX . '/' . $file) == 0 || die "Cannot copy $MASTERPREFIX/$file to $WINEPREFIX/$file: $?";
		)
	}
	system('chmod', '-R', 'og-rwx', $WINEPREFIX) == 0 || die "Cannot chmod -R og-rwx $WINEPREFIX: $?";

}

exec('env', 'WINEPREFIX=' . $WINEPREFIX, 'wine', $WINEPREFIX . '/drive_c/Program Files/appname/appname.exe', @ARGV) == 0 || die "Failed to launch appname: $?\n";

exit;

References

• WineHQ
  • Wine Mailing List
• LTSP
  • LTSP Mailing List
• IES4Linux

• Franks Corner

  http://frankscorner.org/}

• Wine printing problems:
  • http://www.la-sorciere.de/Wine-HOWTO/wineprintconfig.html
  • http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/b05da7237281dbab

When I launched our first LTSP server, I was very keen to make the system as pleasurable for the users as possible; to this end, I left users able to customise their desktop pretty much how they liked. I decided that this free-for-all had gone too far, when I saw customers sitting in front of one user’s computer, sporting a desktop wallpaper of his baby son. At the time I just set a system default of a fairly neutral blue / dark blue radial gradient, and put an item on my to-do list to create a desktop wallpaper.

Those who read my earlier post regarding KDE Wallpaper may have seen examples, and basically I created a red background with company logo and a few lighting affects, making suitable wallpapers for most of the common screen sizes. It was when I went to implement these wallpapers that I realised that I had a problem - KDE only allows you to force one single wallpaper to all users, regardless of screen size. I could allow the users to set their own wallpaper, from a select list, but it would be impossible to restrict them only to that list. And what if they hop from one computer to another - the screen size will be wrong again. No, I needed a way of changing the wallpaper at login to the correct wallpaper for their screensize, and that meant a perl script running at login. The task could be broken into three parts:

1. Determine screen size
2. Choose best wallpaper
3. Set wallpaper

To determine the screen size, I used a small Perl Tk routine:

sub get_screen_size {
    use Tk;
    my $mw=tkinit;
    $mw->withdraw;
    return($mw->screenwidth, $mw->screenheight, $mw->screendepth);
}

To select the best wallpaper, I found this far more complicated that I would have liked - the issue is that NX users have screen sizes that are non-standard, so I couldn’t rely on exact matches. In any case, if I relied on perfect matches I would have been creating new wallpapers for each and every obscure monitor resolution. The best approach I found was to score each wallpaper based on aspect, width and height, calculating the percentage error for each compared to the users screen size, summing the errors and picking the wallpaper with the lowest error. Logically aspect would be far more important that the other errors, so I trebled the aspect error to make that the dominant criteria.

Lastly, I set the wallpaper using a simple dcop command:

`dcop kdesktop KBackgroundIface setWallpaper "$newwallpaper" 6`;

After testing it thoroughly, I inserted a shortcut to the script in all users’ Autostart directories last night.

I arrived this morning to the comment “it’s a bit bright any chance we could tone it down a bit”.

I was very polite.

This is just a list of the hacks or fixes that I currently have in place on Iceweasel. These were not my invention, and surely I owe a debt of thanks to various sites; unfortunately I have no way of knowing which sites.

Some of these hacks are too facilitate system wide control, others help to maximise performance on a thin client system.

Iceweasel Global Preferences

/etc/iceweasel/pref/iceweasel.js

// This is the Debian specific preferences file for Iceweasel
// You can make any change in here, it is the purpose of this file.
// You can, with this file and all files present in the
// /etc/iceweasel/pref directory, override any preference that is
// present in /usr/lib/iceweasel/defaults/preferences directory.
// While your changes will be kept on upgrade if you modify files in
// /etc/iceweasel/pref, please note that they won't be kept if you
// do make your changes in /usr/lib/iceweasel/defaults/preferences.
//
// Note that lockPref is allowed in these preferences files if you
// don't want users to be able to override some preferences.

lockPref("extensions.update.enabled", true);

// Use LANG environment variable to choose locale
lockPref("intl.locale.matchOS", true);

// Disable default browser checking.
lockPref("browser.shell.checkDefaultBrowser", false);

// ========= LTSP SPECIFIC HACKS ========

// Disable "safe browsing" feature that hogs CPU, HDD, etc. etc. in LTSP
lockPref("browser.safebrowsing.enabled", false);
lockPref("browser.safebrowsing.malware.enabled", false);

// Disable annoying location-bar suggestion "feature" that is sludgy with thin-clients
lockPref("browser.urlbar.maxRichResults", 0);

// Disable offline/disk caching of web pages
lockPref("browser.cache.offline.enable", false);
lockPref("browser.cache.disk.enable", false);
lockPref("browser.cache.memory.enable", false);

// ========= PROXY HACKS =========

lockPref("network.proxy.type", 1);
lockPref("network.proxy.share_proxy_settings", true);
lockPref("network.proxy.http", "192.168.1.254");
lockPref("network.proxy.http_port", 800);
lockPref("network.proxy.no_proxies_on", "localhost, 127.0.0.1, 192.168.1.0/24");

// ========= MISC HACKS ==========

lockPref("browser.startup.homepage", "http://www.example.co.uk/");
lockPref("app.update.enabled", false);

Iceweasel Image Caching

I understand that, on websites with certain size of image, that the thin client xorg starts to take a ridiculous amount of memory, resulting xorg dieing and the thin client returning to the login page. The following may help:

$ sudo echo "MOZ_DISABLE_IMAGE_OPTIMIZE=1" >> /etc/profile

References

I must apologise for the lack of references, if you recognise some of your work in the above, please do accept my apologies.

This is currently a few scrappy notes just to jog my memory as to things to try. Messing about with monitor settings can blow your monitor, graphics card and probably both; although in practice sensible use should ensure that never happens to you.

Note that some of these commands may not exist on your system, if you need to install them, then remember to install into the chroot, e.g.:

# chroot /opt/ltsp/i386
# apt-get update
# apt-get install lshw
# exit

Erm, suppose I should mention this whole page was tested on Debian Lenny.

Cables

Do consider trying a new monitor cable - as a poor quality or damaged cable can cause problems that are difficult to trace. A few seconds to try a different cable might save you endless time.

A word about drivers

There are often multiple drivers for a particular graphics card, for example with nvidia cards you can sometimes use the opensource “nv” driver and sometimes the proprietary “nvidia” driver, and I believe there is a “nouveau” driver, which I have not yet experienced. Similarly in intel, stipulating that the driver should be “intel” may solve your problem. See lspci below for details.

X Authority

All of the following commands were run from an ssh session to the thin client itself, for this to work you need to install openssh-server in the chroot. Alternatively you can simply go to the client and type ctrl-alt-f1 to access to the client’s console and type the following commands from there. Obviously the benefit to the ssh approach is that you can do it remotely and cut and paste from your browser into the client.

We need to be able to access the xserver from the console, so we need to set the XAUTHORITY:

# export XAUTHORITY=`find /var/run -name Xauthority`
# echo $XAUTHORITY
/var/run/ldm-xauth-qOQkpTdNp/Xauthority
# export DISPLAY=:7
#

Useful Programs

lspci

In order to google your problems, you’ll need to know the make and model of your graphics card, to find this out, run the lspci command:

# lspci
# lspci -v | more

The first command is a summary, the second command gives you more information. The “VGA compatible controller” is probably for what you’re looking.

lshw

List Hardware will list all the hardware on your PC.

# lshw -C display

getltscfg

Report all the settings from lts.conf which apply to this terminal. This helps diagnose those occasions where the client is refusing to obey your lts.conf commands.

# getltscfg -a

xvidtune

xvidtune -show will report the current monitor settings as a modeline:

# xvidtune -show

You can also run xvidtune as a localapp when logged into the thin client:

"/usr/bin/ltsp-localapps xvidtune"

xdpyinfo

xdpyinfo reports a great many details from the xserver, including resolution, colour depth etc:

# xdpyinfo | more

gtf cvt

There are two tools for creating a modeline - gtf and cvt. My understanding is that cvt is the newer tool, in use from 2003, but tbh I really don’t know which you should use. Both tools work in the same way. Some examples:

# gtf 1920 1080 60
# cvt 1280 1024 75

xrandr

To save rebooting endlessly you can test monitor settings on the fly with xrandr:

# xrandr
# xrandr --newmode "1920x1080_60.00"  172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync
# xrandr --addmode VGA "1920x1080_60.00"
# xrandr --output VGA --mode "1920x1080_60.00"
# xrandr --auto

The first command provides you with useful information about your xserver, including the available modes, and most importantly the available “outputs” (these are your monitors/displays); in the above example my only output is a monitor called “VGA”. newmode creates the newmode (e.g. as output by gtf or cvt), addmode makes that mode applicable to the output, and the next command activates that mode. The final command “auto” will reset your display automatically, probably your previous settings.

References

For once almost all of this was my own work, and so all my fault ;). That said the following page was helpful to me in the section about xrandr:

• https://wiki.ubuntu.com/X/Config/Resolution

Introduction

This is a guide to upgrading from Debian Etch and LTSP 4.2 to Debian Etch and LTSP 5. This is largely based on the following page which should be your primary guidance on installation:

• http://wiki.debian.org/LTSP/Howto

Now that Debian Lenny has become the stable release, you should install that instead, see the above document for guidance, and/or my LTSP5 Install page.

Warning

This page seems a little outdated, most importantly it refers to the LTSP Backports repository, which is now obsolete. You should instead visit http://backports.org/ and add the Debian Lenny repository. All references to alioth.debian.org are redundant. You are probably best off going to this page:

• http://wiki.debian.org/LTSP/Howto

Back-up /opt/ltsp

This will copy your entire /opt/ltsp to /opt/ltsp42.

# cd /opt
# mkdir ltsp42
# cd ltsp
# tar cf - * | (cd /opt/ltsp42; tar xfp - )

Backup other configurations

# cd /opt/ltsp42
# mkdir conf
# cp /etc/ltsp.conf /opt/ltsp42/conf/
# cp /etc/ltsp-localdev.conf /opt/ltsp42/conf/
# cp /etc/dhcp3/dhcpd.conf /opt/ltsp42/conf/

This list is not exhaustive - if you can think of any other configurations outside of /opt/ltsp - back them up!

Backup tftpboot

# cd /opt/ltsp42
# mkdir tftpboot
# cd /tftpboot
# tar cf - * | (cd /opt/ltsp42/tftpboot; tar xfp - )

Remove lbe if installed

# cd /usr/local
# rm -r lbe

Add Backports Repository

This section is outdated - the latest packages are simply in Debian Backports for Lenny.

Given that you have chosen to upgrade to LTSP5, it is probably that you want to have the new technologies, which are currently only available in Backports. If you already have Backports listed in /etc/apt/sources.list then you may skip this stage.

Add the key(s) for the repository to your keyring(after verifying that you trust them)

# wget http://pkg-ltsp.alioth.debian.org/debian/pkg-ltsp-keyring
# apt-key add pkg-ltsp-keyring 

Add to /etc/apt/sources.list

deb http://pkg-ltsp.alioth.debian.org/debian etch-ltsp-backports main

Configure pinning in /etc/apt/preferences

If you do not have a preferences file, then an example one might be:

Package: ltsp-server
Pin: origin pkg-ltsp.alioth.debian.org
Pin-Priority: 998

Package: ltsp-server-standalone
Pin: origin pkg-ltsp.alioth.debian.org
Pin-Priority: 998

Package: ltspfs
Pin: origin pkg-ltsp.alioth.debian.org
Pin-Priority: 998

Package: *
Pin: release o=Debian,a=stable
Pin-Priority: 900

Package: *
Pin: origin www.backports.org
Pin-Priority: 700

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 500

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 300

Package: *
Pin: release o=Debian
Pin-Priority: -1

Apt-get Update:

# apt-get update

How you are logged in?

You should be logged in either directly to the console, or via ssh (or perhaps FreeNX). If you are logged in from an LTSP Client, then there is a likelihood that your client will be terminated during installation.

The same clearly applies to your users. In any case some of these processes are CPU intensive (e.g. ltsp-build-client) and it’s a good idea to have everyone off the system (this may even be a necessity).

Remove Old LTSP Packages

# apt-get --purge remove ltsp-utils atftpd
# cd /opt
# rm -r ltsp

Install new packages

# apt-get -t 'etch-ltsp-backports' install ltsp-server-standalone ltsp-server
# dpkg -l ltsp-server | awk '/^ii/{print $2" "$3}'

Make sure the version ltsp-server is 5.0.40~ or greater.

Build the LTSP client environment

The ltsp-build-client script needs a lot of time if you have an older server.

#  ltsp-build-client --extra-mirror "http://pkg-ltsp.alioth.debian.org/debian etch-ltsp-backports main" --apt-key /etc/apt/trusted.gpg

Don’t be tempted to use a simple ltsp-build-client command, as you need to specify backports repository (as shown above).

The ltsp-build-client command will download a complete Debian filesystem into /opt/ltsp/i386 (or specify an alternate location with ‘–base’) and install the ltsp-client and ldm packages (the LTSP Display Manager).

The 2 ltsp configuration files inside the client are /etc/lts.conf and /etc/default/ltsp-client-setup. See the examples in /usr/share/doc/ltsp-client*. Also see the Edubuntu wiki.

Debian LTSP still uses NFS by default.

If you change the IP data after you have done the initial setup and run ltsp-update-sshkeys on the server.

The files the client will boot are installed on the server into /var/lib/tftpboot, unlike LTSP4.2 which installed in /tftpboot.

Configure DHCP Server

Edit /etc/dhcp3/dhcpd.conf.

As you already had DHCP working, under LTSP4.2, then it will just need some modification. In order to configure your dhcpd.conf, you should refer to examples in /usr/share/doc/ltsp-server/examples/dhcpd.conf or /etc/ltsp/dhcpd.conf and adjust for your network.

Specifically, you need to make the following changes:

Root Path

Take the IP address out of your root-path statement as LTSP5 doesn’t support that style of root-path

option root-path  "/opt/ltsp/i386";

Filename

Change the filename entries to:

filename   "/ltsp/i386/pxelinux.0";

Next Server

Etch is still affected by: http://bugs.debian.org/416868 so you need to add this line if the dhcp server and tftp server are the same:

next-server ip.address.of.server;

Restart dhcp3-server

# /etc/init.d/dhcp3-server restart

Watch for errors, if it will not restart then correct errors and try again.

Configure Exports

Edit /etc/exports to include the following line:

/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

Then restart the NFS Kernel Server:

# /etc/init.d/nfs-kernel-server restart

Start tftpd

By default, tftpd-hpa is started from inetd, so you may need to restart inetd after installing tftpd-hpa.

# /etc/init.d/openbsd-inetd restart

Alternately, edit /etc/default/tftpd-hpa to have tftpd-hpa start on it’s own.

RUN_DAEMON="yes"

And then restart with:

# /etc/init.d/tftpd-hpa restart

Test boot a client

Boot a PXE or Etherboot capable machine and enjoy!

Changing the Client

See the following page for details: http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/customizing-thin-client.html

# sudo chroot /opt/ltsp/i386
# apt-get install rdesktop
# sudo ltsp-update-image

Setting root password for client

Screen scripts are how LTSP determines what type of login will run on what virtual screen. Most GNU/Linux machines have 12 virtual consoles, which you can access by pressing Control-Alt-F1, through Control-Alt-F12. There is a text based getty that is started on screen 1, but you normally can’t log into it, as there are no local users on the thin client.

However, for debugging purposes, you may want to set up root to log in on the thin client. You may need to do this if you’re debugging problems with local devices, for example. Fortunately, it’s easy to do: on the server, just chroot into the LTSP chroot, and set the password with passwd.

sudo chroot /opt/ltsp/i386
passwd

Further information

• LTSP5 Sound
• LTSP5 Local Devices

References

• http://wiki.debian.org/LTSP/Howto
  • http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/customizing-thin-client.html
• http://www.mail-archive.com/ltsp-discuss@lists.sourceforge.net/msg33415.html
• http://www.linuxagora.com/vbforum/showthread.php?t=749
• http://www.ltsp.org/twiki/bin/view/Ltsp/Debian#LTSP_5
• http://marc.info/?l=ltsp-discuss&w=2&r=1&s=ltsp5+debian+etch&q=b

Introduction

The selection of client hardware is an interesting topic, that causes much confusion for those unfamiliar with LTSP. When you start out with LTSP, the likelihood is that one of your motivations is to extend the life of your existing clients. But you’d be lucky indeed not to require a few new clients, and of course over time you will need to purchase replacements for hardware failures. So what are your options?

Options

• Existing PCs
• Thin clients designed for LTSP
• Thin clients designed for Citrix
• Barebones PCs
• Self-build PCs
• New PCs

Existing PCs

Well you obviously don’t want to throw out all your existing hardware, but do bear in mind that the electrical cost is likely to be around £40 a year, and so a replacement that brings this down to £15 a year, might be easier to justify than you might imagine. If you do want to keep your existing PCs, then do consider unplugging the hard drives. Hard drives are not required on LTSP clients and they consume unnecessary power. They also can often be noisy, unplugging an old drive can miraculously silence an annoyingly loud older PC.

Thin clients designed for LTSP

I have no experience of this route. One option is to purchase from Diskless Workstations, who support the LTSP project.

• http://www.disklessworkstations.com/

Thin clients designed for Citrix

I have had mixed success with thin clients that were designed for Citrix and/or Windows Terminal Services. The Wyse terminals tend to be very sluggish and quirky, and I find that I cannot recommend them for LTSP.

HP thin clients seem to work very much better, and are certainly an option. Such devices tend to be very low power. On the downside, they do tend to be surprisingly expensive, for what they provide. That said, if you have a good hardware budget, I believe you could do very much worse than buy some HP Linux Thin Clients but, as with any client hardware, do buy one and test before committing yourself to considerable expenditure.

Barebones PCs

Obviously the above is probably not true of dedicated LTSP thin client hardware, designed from the ground up to work with LTSP.

I have found that the best client hardware is to purchase low-cost barebones PCs, low-power and preferably fanless. I tend to only buy barebones PCs that include the CPU, in order to keep down the overall cost and keep commissioning time to a minimum. Previously this meant Via C7 CPUs, which haven’t the best reputation; although so far I have not had any failures. Nowadays I think you’d be searching for “intel atom barebones”.

Yes, you need to open the case, add some RAM, and maybe add an optical drive - perhaps 10 minutes work - the flipside is that you’re not paying for an operating system, and you’re not paying for a hard drive (which you don’t need).

Such barebones PCs currently cost about £125 (plus VAT), seem much less likely to have compatibility issues, perform much faster than dedicated “thin client” devices, and could easily be changed to fat clients, should your requirements subsequently change.

Self-build PCs

I have had great success building small Mini-ITX form factor PCs, on Via CPUs. The hardware was all purchased from LinITX.com, who I found very helpful. Build time was about an hour for the first, but this dropped to about 30 minutes for the remaining ones. The result are stunningly attractive tiny PCs which grace our showroom. Just do concentrate on low-power consumption and look where possible for “fanless”. LTSP uses very little of the local CPU, so heat is unlikely to be an issue.

New PCs

Full blown desktops are, I think, a poor option. These tend to be power hungry, and come with a Windows licence, hard drive and other bits that you will not need. There are a new generation of tiny PCs like the Acer Reevo and the Asus EeeBox, which may be a good option.

References

There are no references for this page, which was written without reference to other information.

Job control turned off nbd0 not found

These instructions do not apply for Ubuntu.

If you receive an error message stating initramfs “job control turned off”, then look further up for a line stating that /path/to/nbd0 not found. If you’re on Debian then this is an indication that the client is trying to boot via NBD instead of NFS. Check the following:

Firstly, see if there is a directory /opt/ltsp/i386/images, this is the default directory for the ltsp-update-image generated unionfs files. If it exists you should probably delete it, reboot the client and all may be well.

If not, then on the server, use the chroot command to maintain the LTSP chroot:

$ sudo chroot /opt/ltsp/i386

Now edit /etc/default/ltsp-client-setup and change the value of the root_write_method variable to use bind mounts instead of unionfs, it should look like this afterwards:

root_write_method="bind_mounts"

Next, create the file /etc/initramfs-tools/conf.d/ltsp and add the following line (set the value of the BOOT variable to nfs):

BOOT=nfs

Regenerate the initramfs:

update-initramfs -u

Hit CTRL-D to exit the chroot now. Make sure LTSP uses the new initramfs to boot:

$ sudo ltsp-update-kernels

Clients cannot login via LDM

If your clients get to the LDM login page, but none of them can login, and particularly if you are aware of recent updates affecting ssh, then:

$ sudo ltsp-update-sshkeys
$ sudo ltsp-update-image  (skip this for debian*)

*It is important that you do not ltsp-update-image for debian (unless you have moved to nbd in which case you presumably know what you are doing), if you do, then you are likely to find that the client will attempt to boot from the generated image.

See https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/144296 for more details (which may not be relevant for Debian).

No client sound

See LTSP5 Client Sound.

Display Problems

See LTSP5 Display Troubleshooting.

Client has loud hissing noise

The microphone has likely been activated by default. With normal PCs the user fixes the problem once and that fix it remembered, with LTSP the problem repeats on every boot. The solution is to mute the microphone on every boot. To achieve this we need to login to the client shell and run “alsamixer” to mute the microphone. Silence, ah bliss. Take a note of the name of the microphone audio channel. The amixer program is also very helpful - see LTSP5 Client Sound for details of how to use this.

Next set the volume on this channel in lts.conf:

Volume parameters take the form of:

"channel_name"_VOLUME, where “channel_name” is the name of the audio channel (you can find audio channel names by running alsamixer or “amixer -c0 scontrols” at a client shell) with unfriendly variable characters replaced or removed. In other words, forward slashes, hyphens, and spaces are replaced by underscores, and anything in parentheses is dropped completely.

So, if you have a channel called “Front Mic”, then FRONT_MIC_VOLUME should already work with no need for special scripts.

Thanks to Gadi for explaining this on the LTSP mailing list.

LDM only prompts for password on login failure

Login window asks for Username and then Password. But, if you enter the username incorrectly then it says “Password incorrect. Try again.”. Of course, no password will work because the username is wrong.

Edit /opt/ltsp/i386/etc/ssh/ssh_config and add this line to the bottom:

NumberOfPasswordPrompts 1

Then for Ubuntu or NBD setups (not Debian) run:

$ sudo ltsp-update-image

Then reboot your thin client.

Credit to Gavin McCullagh from the Edubuntu mailing list for this workaround (read more).

LDM password expiry loop

There is an odd loop that arises with the LDM password expiry process:

• User enters username and hits enter
• User enters password and hits enter
• LDM tells user password has expired enter new password
• User enters new password and hits enter
• LDM tells user to verify password
• User enters new password again and hits enter

It seems that after this process it always returns “No response from server”, and usually logging in with your the password will work just fine. Unfortunately the error leads people to think that the password change has failed and they seem unable to resolve the problem.

But on other occasions, typing the new password does not work, but it is possible that the operator set the password incorrectly.

If there is a bug, it may be related to the following thread:

• ldm problems with debian etch

LDM login screen shows white background

In Debian Etch, the LDM login screen shows a white background with an ugly LTSP logo in the middle. Actually the background is a light grey, but people describe it as white. The LTSP logo was not designed to work with a light grey background, and that’s the reason it looks so ugly. This problem has been fixed in Debian Lenny, and you should now upgrade from Etch.

No known workaround at this time, but see How to Create a custom LDM theme for details of how to change the logo, which really is the only issue with the grey background.

LTSPFS mounts appear strange when running df

util-linux 2.13 fixed this bug; however it is still present in etch. workaround is to make /etc/mtab a symlink to /proc/mounts:

# mv /etc/mtab /etc/mtab.old
# ln -s /proc/mounts /etc/mtab

LTSP client hostname displays as (none)

Workaround set up dns on the thin-client network, or:

# mv /etc/mtab /etc/mtab.old
# ln -s /proc/mounts /etc/mtab

LDM support for mostly insecure logins (LDM_DIRECTX)

Requires getting /root to be writeable:

# echo 'copy_dirs="$copy_dirs /root"' >>/opt/ltsp/i386/etc/default/ltsp-client-setup

KDE local device icons on desktop

In KDE there may not be any local device icons appearing on the desktop. If you find this to be the case, but the device does exist under /media, then you may need to script /usr/sbin/ltspfsmounter code to create symlinks on ~/Desktop.

X Configuration

If X doesn’t automatically configure properly (it uses X.org’s built-in configuration, which doesn’t work as well on the version on X.org in etch), you may want to switch back to the slower but more reliable X configuration using xdebconfigurator:

# chroot /opt/ltsp/i386 apt-get install xdebconfigurator
# cp /opt/ltsp/i386/usr/share/doc/ltsp-client-core/examples/configure-x-xdebconfigurator.gz /opt/ltsp/i386/etc/
# gunzip /opt/ltsp/i386/etc/configure-x-xdebconfigurator.gz
# chmod +x /opt/ltsp/i386/etc/configure-x-xdebconfigurator
# echo CONFIGURE_X_COMMAND=/etc/configure-x-xdebconfigurator >> /opt/ltsp/i386/etc/lts.conf
# echo 'copy_dirs="$copy_dirs /var/cache/debconf"' >> /opt/ltsp/i386/etc/default/ltsp-client-setup
# echo 'temp_copy_dirs=" "' >> /opt/ltsp/i386/etc/default/ltsp-client-setup

Introduction

Time to install a new server - yay! The hardware is an HP Proliant DL360 G5, with a single quad-core processor and 4GB ram. This page is about creating a complete desktop server and, as such, much of this is actually nothing to do with LTSP, but is all about setting up a functional and attractive desktop server.

Server Specification

The following page, which I wrote for LTSP4.2, should largely hold true:

• Server Sizing

Server Set-up

Physically install the server and plug the network into a Gigabit port on your network switch and install your disk drives and configure your RAID volume.

Debian Base Install

Download the netinst ISO from Debian. Burn the ISO to disk. Insert the disk into the optical drive of your server and boot. Follow the installer prompts, until you get to the section on partitioning.

Partitioning

There is no way that I can tell you what to do here - there are just too many variables - but here is what I did:

In addition to the following, you will need to create a swap partition which should be roughly equal to your RAM. Opinions do differ on this point, and if you have plenty of RAM, then you should be able to have a much smaller swap partition, perhaps only 1 GB. For low-memory systems, you should probably create a swap partition that is much larger than your RAM, but expect the performance to suffer as a result! Server based systems should be given adequate RAM, and the swap should really only be used occasionally.

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p5       885436    150672    689784  18% /
/dev/cciss/c0d0p1        85528     28829     52283  36% /boot
/dev/cciss/c0d0p2        85549      5664     75468   7% /rescue
/dev/cciss/c0d0p6     48062440    184344  45436620   1% /home
/dev/cciss/c0d0p7     48062440    184324  45436640   1% /opt
/dev/cciss/c0d0p8     28834716    176200  27193792   1% /srv
/dev/cciss/c0d0p11     2529920     69384   2332020   3% /tmp
/dev/cciss/c0d0p9      6728280    293660   6092840   5% /usr
/dev/cciss/c0d0p10     2885780    256356   2482836  10% /var

With an LTSP system it is sensible to have a separate /opt partition; it doesn’t need to be as large as this, but I choose to use /opt for my virtual machines, 10GB should be adequate. On servers it is sensible to have separate /usr, /var and /tmp file systems. The /srv is simply going to be for shared documents - so your requirements may be different - perhaps you have a NAS for that purpose. A separate /home is recommended for all systems. The /tmp partition here is HUGE, this is because I will be installing a virtualised Windows server using KVM in snapshot mode, which uses /tmp for working files; you should be able to get away with 0.5GB. Lastly the /rescue partition is optional, it should be a mirrored copy of /boot and then should be removed from /etc/fstab, as a rescue partition.

Installing Debian

My personal preference is to install a base system only, unchecking even the “Standard system” when prompted. This leaves you with a perfectly working system on which to build your LTSP server. Follow the prompts to remove the install CD and reboot.

Install OpenSSH Server and Screen

These packages make it easy to remotely administer your server, openssh creates the connection, screen enables you to use multiple terminals and to disconnect and reconnect to each (Simple Tutorial). Screen is optional but recommended, this tutorial will make no further mention of it, you should just use it as appropriate, or if you don’t wish to use it, simply remove it from the following command.

Log into the server as root and install openssh:

# apt-get install openssh-server screen

You may need to create some static routes in /etc/network/interfaces, depending from where you will be ssh’ing.

Return to the comfort of your workstation and ssh into the server in the usual way (this isn’t a tutorial on ssh!).

Install K Desktop Environment (KDE)

We use KDE, so these instructions are specific to KDE; however you can simply change the install command below according to the desktop environment that you prefer.

N.B. Note that I am installing the minimum software, if you prefer to have KDE in total, then just install kde-desktop instead of kde-core kdm.

N.B. Change kde-i18n-engbi for the correct package for your language.

# apt-get install kde-core kdm kde-i18n-engb

N.B. Even installing a base KDE will result in a large number of packages being downloaded, go get yourself a cup of coffee.

Reboot

Now reboot the server, and ensure that you get a graphical login on the console.

Install LTSP

N.B. Please read the Debian LTSP Howto before continuing.

N.B. Please note that there are now lenny-backports available.

# apt-get install ltsp-server-standalone

You can safely ignore the error message about DHCP server not being “authoritative”, and don’t worry that your DHCP server doesn’t start - you need to configure it before it will start cleanly.

Build LTSP Client

N.B. Please note that there are now lenny-backports available.

$ ltsp-build-client

The ltsp-build-client command will download a complete Debian filesystem into /opt/ltsp/i386 (or specify an alternate location with ‘–base’) and install the ltsp-client and ldm packages (the LTSP Display Manager).

N.B. If you change the IP data after you have done the initial setup and run ltsp-update-sshkeys on the server.

N.B. The files the client will boot are installed on the server into /var/lib/tftpboot, unlike LTSP4.2 which installed in /tftpboot.

Set-up NFS Share

$ nano /etc/exports
/opt/ltsp       *(ro,no_root_squash,async,no_subtree_check)
$ invoke-rc.d nfs-kernel-server reload

The 2 ltsp configuration files inside the client are /etc/lts.conf and /etc/default/ltsp-client-setup. See the examples in /usr/share/doc/ltsp-client*. Also see the Edubuntu wiki.

Configure DHCP Server

# cp /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.conf.lenny
# cp /etc/ltsp/dhcpd.conf /etc/dhcp3/
# nano /etc/dhcp3/dhcpd.conf

Edit /etc/dhcp3/dhcpd.conf, updating the IP addresses according for your network.

Test Client Boot

Now is the time to test that your client is booting okay.

Audio Set-up

Next we need to set-up the audio, and to that end please follow the instructions on our LTSP5 Sound page:

• LTSP5 Sound

Local Devices Set-up

Next we need to set-up local devices, and to that end please follow the instructions on our LTSP5 Local Devices page:

• LTSP5 Local Devices

Optional - Installing FreeNX

If you wish to be able to remotely support your server with a GUI, then you may like to install freeNX:

• Install FreeNX

Then visit the NoMachine website and download the client for your PC.

Optional - KDE Style Changes

N.B. These instructions will increase server load, but do make KDE look a great deal more attractive - your choice.

I apologise in advance for this section; I know that “Bling” has no place on a server, but equally I know that getting Linux adopted in your workplace is tough, and a little bling goes a long way towards user acceptance. Unfortunately these changes WILL increase the load on the server, if you are not happy with this, then simply skip this section.

Crystal Windows Decoration

# apt-get install kwin-style-crystal

Go to the KDE Control Panel, Appearance & Themes and change the Windows Decorations to Crystal. Then, under the General tab, make the top corners rounded, and increase the titlebar size to 21. Under the Buttons tab, change the buttons to Kubuntu-Edgy. Under the Background tab, I suggest you switch off transparency, which will but an unnecessary load on the server. Under the Overlay tab, change both active and inactive to Simple Lighting.

NuoveXT

# apt-get install kde-icons-nuovext

Go to the KDE Control Panel, Appearance & Themes and change the Icons to nuoveXT. Under the Advanced tab you may like to increase the Desktop icon size to 48, which suits these icons.

Desktop Background

I believe one of the most attractive backgrounds is a simple two colour elliptic gradient. To achieve this, simply go to KDE Control Panel, Appearance & Themes, Background. Change the Background picture to “No Picture” and set colours to Elliptic Gradient. You can choose any two colours, but these two look good:

#2E3B4E
#7698CA

Other colours may not go well with the rest of my suggested changes.

Panel

The default panel doesn’t look that great, you can download any number of Kicker Wallpapers from KDE Look, but one that I think looks very good is this one:

• Apple-like Kicker Wallpaper

It looks plain on that page, but much better in KDE.

Add Debian Multimedia Repository

The Debian Multimedia is a useful resource for multimedia codecs, converters and players. In particularly it includes Adobe Flash Player. This is not an official repository, although it is a very common one. I have decided to take the risk of installing this software on my system, you may not agree!

Edit /etc/apt/sources.list and add the following repository:

deb http://www.debian-multimedia.org lenny main

Download and install the following:

• debian-multimedia.org keyring

# dpkg -i debian-multimedia-keyring_2008.10.16_all.deb
# aptitude update

Optional - Iceweasel

In my opinion, Konqueror, whilst an amazing piece of software, is not going to be suitable as your main web-browser. Mozilla Firefox is the answer, and this is available in the Lenny repositories, named “Iceweasel”.

# apt-get install iceweasel icedtea-gcjwebplugin flashplayer-mozilla mozilla-acroread mozilla-mplayer

Unfortunately, being a GTK application (not native to KDE) it looks ghastly, so…

Optional - GTK Applications in KDE

GTK applications in KDE always look horrible. In Kubuntu this is taken care of for you, but in Debian it is only a quick install away:

# apt-get install gtk-qt-engine

There are other ways of achieving this, e.g. qtcurve, but for me this seems perfectly satisfactory. Having installed, you visit your control panel and you will find a new option under “Appearance & Themes” called “GTK Styles and Fonts” change this to use your KDE style for your GTK applications, and restart KDE.

Optional - Other Applications

Applications you might consider installing for your users are:

• KUser : apt-get install kuser
• The Gimp : apt-get install gimp gimp-help-en gimp-data-extras
• Inkscape : apt-get install inkscape
• Scribus : apt-get install scribus-ng scribus-ng-doc scribus-template (Development branch, but more up-to-date than “scribus”)
• OpenOffice : apt-get install openoffice.org-kde openoffice.org-help-en-gb openoffice.org-l10n-en-gb openclipart-openoffice.org
• Freemind : apt-get install freemind
• KCalc : apt-get install kcalc
• Microsoft Fonts : apt-get install ttf-mscorefonts-installer
• KeePassX : apt-get install keepassx
• Unison : apt-get install unison unison-gtk
• Wine : apt-get install wine wine-utils
• Kontact : apt-get install kontact
• Ark : apt-get install ark
• Dia : apt-get install dia

Optional - Install KVM Virtualisation

If you intend adding a virtualised Windows server on top of the LTSP server (not recommended - but we do it and it works well), then you need KVM (or an alternative) installed:

N.B. I suggest you right-click on the following link and Open in New Tab, so that you don’t lose your place in this document.

• How to install KVM

Optional - UMask

I dislike that every created file is given read access to all users, to change this behaviour we need to change umask. In KDE the easiest way to achieve this system wide is by editing /etc/profile and changing the umask line from the default line of umask 022 to your preferred setting. We use umask 007, which gives full access to the user and group, but no access to other.

Default permissions umask 022: -rw-r--r--
New permissions     umask 007: -rw-rw----

Your view may well vary from mine.

Set Client Root Password

You will almost certainly need access to the client, in order to troubleshoot:

# chroot /opt/ltsp/i386
# passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
# exit
exit
# ltsp-update-image

References

• Debian LTSP
  • Debian Lenny Howto
  • Debian Lenny Backports Howto
• HP Proliant Debian Lenny Installation Instructions by HP Alternative link
• GNU Screen Manual
  • Simple Tutorial
• Linux Partitioning mini-FAQ
• Installing KDE
• Installing Adobe Flash in Debian
• Ubuntu Thin Client Howto

Paths

The ldm-theme is loaded from a symlink at:

/opt/ltsp/i386/usr/share/ldm/themes/default

Which points to further symlink at:

/opt/ltsp/i386/etc/alternatives/ldm-theme

Which points back to :

/opt/ltsp/i386/usr/share/ldm/themes/ltsp

Copy existing theme

Copy this ltsp directory, e.g.:

# cd /opt/ltsp/i386/usr/share/ldm/themes
# cp -r ltsp custom
# cd custom
# ls -al

Set symlink to new theme

Then you need to change the symlink to point to your new theme:

# cd /opt/ltsp/i386/etc/alternatives
# rm ldm-theme
# ln -s /usr/share/ldm/themes/custom ldm-theme

Customise your custom LDM theme

Now you can customise your ldm theme to your heart’s content. Please note that editing the bg.png currently has no effect (hence the existence of this page!), but you can at least tidy up the login page by replacing the logo.png with something tidier than the current ltsp.org logo, which looks dreadful on the grey background (because of a transparency issue).

Change background colour

Firstly change the background colour to your desired background colour (personally I quite like the light grey of “efebe7”), so left it like that.

You can change the colour of the background by opening the greeter-gtkrc in your theme and looking for the following line:

    bg[NORMAL]        = "#efebe7"

Change the colour for whatever colour you wish. Under KDE you can use the KColorChooser for this purpose, or indeed the colour picker in Gimp.

Create new logo

Next open your organisation’s logo in the Gimp (or whatever logo you wish to appear on LDM login). Add a shadow (Script4u → Shadow → Drop Shadow), I would suggest making the X/Y offsets 0/0. You can play with the radius and opacity to create the effect you desire.

Next create a new layer of the same colour as the background (e.g. efebe7 unless you changed it) and put that background at the bottom of the layers. The gimp makes this easy by enabling you to key in the efebe7 in the colour picker.

Save the resulting image as logo.png into your custom ldm theme.

Command

ltsp-update-kernels

Introduction

The ltsp-update-kernels script copies it into the chroot environment and automatically updates the symlinks for the boot loader in the process.

ltsp-update-kernels updates the current client kernel by using the current kernel from the chroot and copying it to the tftpboot directory (/var/lib/tftpboot/ltsp/i386/). It also copies the initramfs across and sets up the PXE linux boot files.

This command must be run each time the kernel changes in the chroot. There should be no harm in running this command each time you update the chroot, just in case.

Command

ltsp-update-image

Comment

For systems that use NBD (not Debian), this command will create a client image from the contents of /opt/ltsp/i386, and store it in /opt/ltsp/i386/images.

Any change you make in the chroot will only take effect for the clients after you run ltsp-update-image. As such, this is the command that you will run most often.

As Debian uses NFS, this command is not necessary, unless you have chosen to change to NBD, in which case you presumably know that you are “different”.

If you are on Debian and you have a directory /opt/ltsp/i386/images, then this is likely to mean that you have run this command by mistake. This may trigger the clients to attempt to use NBD, so you should probably remove this directory, or explicitly tell your clients to use NFS - see LTSP5 Troubleshooting for details.

Command

ltsp-build-client

Introduction

The ltsp-build-client command will download a complete Debian filesystem into /opt/ltsp/i386 (or specify an alternate location with --base) and install the ltsp-client and ldm (LTSP Display Manager) packages. As such, you will probably only run this command the first time you install LTSP5.

You should move /opt/ltsp to /opt/ltsp_old before you start.

Man Page

You should see the man page appropriate for your system, but the Debian Lenny man page current states:

ltsp-build-client(8)                                                                                                                                                                                               ltsp-build-client(8)

NAME
    ltsp-build-client - Builds an LTSP client system for use with the LTSP server

SYNOPSIS
    ltsp-build-client  <options>

DESCRIPTION
    ltsp-build-client  builds  an  ltsp client chroot using standard packages for use with the ltsp server.  This chroot installation  can be modified in a number of ways as outlined in the OPTIONS section.  If present, defaults
    will be read from the configuration file /etc/ltsp/ltsp-build-client.conf, and will be overridden by using the command line options. ltsp-build-client is usually run as the root  user.   Visit  http://www.ltsp.org  for  more
    information.

OPTIONS
    Not all options are available on all installations. For a complete list of available options, use the --help and --extra-help options.

    --arch arch
                Builds a chroot with the specified architecture. Must be a supported architecture of the distribution, and compatible with the host architecture.  Defaults vary by distribution.

    --base dir
                Sets the default path for the ltsp chroots to be installed into. Defaults to /opt/ltsp/.

    --chroot file
                Sets the default name for the ltsp chroot. Defaults to the architecture selected with --arch or the running architecture.

    --conf file
                Load configuration defaults from specified file. See CONFIG FILE below for more information.

    --dist distribution
                Distribution : Sets the distribution to be installed in the client chroot.  Defaults to the running distribution.

    --extra-help
                Displays all available commandline options.

    --help    Displays the ltsp-build-client help message.

    --mirror mirror_url
                Select the mirror to download packages from. file:/// and http:// URLs are supported.

CONFIG FILE
    ltsp-build-client will read a configuration file to override built-in defaults. the default location for this configuration file is /etc/ltsp/ltsp-build-client.conf, and can be specified with the --conf commandline option.

    values are NAME="VALUE" pairs, with # representing commented lines. most commandline options have an equivalent. an example Debian based system with an alternate base location, architecture, and distribution:

        # set alternate default location for ltsp chroot (--base)
        BASE="/srv/ltsp"
        # build an amd64 chroot by default (--arch)
        ARCH="amd64"
        # build a Debian sid environment (--dist)
        DIST="sid"

SEE ALSO
    ltsp-update-sshkeys(8), ltsp-update-kernels(8).

AVAILABILITY
    ltsp-build-client is part of ltsp package and the latest versions are available in source form from https://launchpad.net/products/ltsp.

MAN PAGE AUTHOR
    Peter Savage
    updated 2006, 2009 by Vagrant Cascadian

Command

ltsp-update-sshkeys

Introduction

Secure Shell Handler or SSH is a network protocol that allows data to be exchanged using a secure channel between two computers. LTSP uses it to enable secure communication between clients and the Server. SSH uses public-key cryptography to authenticate the client, this command rebuilds the keys.

You would run this command only at first install, or upon subsequent change of server IP addressing or DHCP or possibly hosts. Basically if you get the “workstation not authorised” message, then you should run this command.

All the following commands are entered on the server. Normally this would be having logged into your normal LTSP desktop and opened a terminal session, but it could equally be from an ssh session to the server. The key thing is that you do not run these commands from a client shell, as the client system is read-only.

These instructions are for Debian, Ubuntu users will also need to update the client image afterwards.

Step by Step Process

$ sudo chroot /opt/ltsp/i386
# mount -t proc /proc /proc
# mount -t sysfs sys /sys
# apt-get update
# apt-get upgrade
# umount sys
# umount /proc
# exit
$ sudo ltsp-update-kernels

The mount proc and mount sysfs commands are not always required, and can be omitted in many instances, but if in doubt I don’t believe they cause any harm.

The ltsp-update-kernels command is only required if the client kernel has been upgraded, but again I don’t believe it causes any harm to run it unnecessarily.

RAM

LTSP website recommends 256mb for the core system plus 50mb per user:

Total RAM = 256mb + (25 users x 50mb)
          = 1506mb

However Edubuntu recommends a different formula:

Total RAM = 150mb x 25 users
          = 3750mb

We recommend you choose the greater of the two, and double-it if you can (see update below).

Post install update

This memory has proved a little low, mainly because we are also virtualising Windows on the same server. If you don’t require Windows, or you are providing that service from a different server, then the higher of these two figures should be sufficient; I would certainly recommend the higher figure, because of the high memory demands of Firefox and Adobe Flash.

CPU

LTSP website states that each user is likely to require around 3% of a CPU:

Total CPU = 3% x 25
          = 0.75
          = 75% of a CPU

So a single processor should be sufficient; however this requirement doubles or even trebles if we opt to virtualise a Windows server on the installation. We would say that a minimum of a quad-core would be sensible if virtualising Windows on the LTSP server. If this is a problem for you, simply host the Windows server elsewhere; which is probably better anyway.

Post install update

We have now upgraded both servers to dual quad-core, which is proving ample capacity. I believe a single quad-core would have been ample had we not been virtualising windows on the same server.

Network

LTSP recommend a Gigabit connection for the server and fast Ethernet for the terminals. Many fast ethernet switches include a gigabit connection, alternatively gigabit switches are becoming quite affordable.

There can be issues running LTSP via multiple switches - so if you’re buying a new switch - consider the greatest number of ports that you are likely to require.

Post install update

This has all provided to be correct - Gigabit on the server is nearly essential if you want decent performance and similarly, PCs with only old 10-base-t internet are noticeably slower to boot.

Scanning with LTSP 5 in Debian Etch or Lenny

At the time of writing these instructions worked for Etch, but have not been completed for Lenny.

Introduction

This is a description for a scanner physically connected to a terminal (not to the server).

For LTSP scanning to work, you just need to remember that the roles are reversed - that is the client is the scanning server and the server is the scanning client. With the exception of the fact that you have to chroot to get at the client, the set-up is an ordinary Linux network scanning set-up.

Configure client

Install client packages

You have to be root in the chroot LTSP client environment for the next steps:

$ sudo chroot /opt/ltsp/i386
# mount -t proc /proc /proc
# mount -t sysfs sys /sys
# apt-get install libexif12 libgphoto2-2 libgphoto2-port0 libieee1284-3 libltdl3 libsane libsane-extras sane-utils
# umount sys
# umount /proc

User ‘saned’ needs an additional group:

Still in the chroot:

# usermod -a -G scanner saned

Modify /etc/inetd.conf (Etch)

Still in the chroot, open /etc/inetd.conf (e.g. with vi) and add at the end of the file (after ‘#:OTHER: Other services’) this line:

sane-port stream tcp nowait saned.saned /usr/sbin/saned saned

Modify /etc/default/saned (Lenny)

The problem with this is that it will run for all users, which seems a bit pointless, should be possible to use an ldm rc.d script, but this did not work correctly for me.

Still in the chroot, open /etc/default/saned and change RUN=no to RUN=yes.

On an upgraded server, this was not enough, I also needed to symlink:

# cd /etc/rc2.d
# ln -s ../init.d/saned S99saned

The initial openbsd-inetd links are wrong. (Etch)

Still in the chroot, Delete openbsd-inetd links with:

# rm /etc/rc*/*openbsd*

Create new one’s:

# ln -s ../init.d/openbsd-inetd /etc/rc2.d/S20openbsd-inetd
# ln -s ../init.d/openbsd-inetd /etc/rc3.d/S20openbsd-inetd
# ln -s ../init.d/openbsd-inetd /etc/rc4.d/S20openbsd-inetd
# ln -s ../init.d/openbsd-inetd /etc/rc5.d/S20openbsd-inetd
# ln -s ../init.d/openbsd-inetd /etc/rc0.d/K20openbsd-inetd
# ln -s ../init.d/openbsd-inetd /etc/rc1.d/K20openbsd-inetd
# ln -s ../init.d/openbsd-inetd /etc/rc6.d/K20openbsd-inetd

Check if everything is fine:

# ls -l /etc/rc*/*openbsd*

Leave chroot

# exit or [Ctrl]+[d]

Configure server

Install server packages

Thanks to the Debian package system it’s easy to get almost all software (as root):

# apt-get install libsane libsane-extras sane-utils

Set user grants

You have to set the saned group for every scanner user:

# usermod -a -G saned ~username~

saned.conf Configuration (client)

Modify the saned.conf file. Put the IP address of your server, e.g.:

/opt/ltsp/i386/etc/sane.d/saned.conf

#
# saned.conf
#
# The contents of the saned.conf  file  is  a  list  of  host  names,  IP
# addresses or IP subnets (CIDR notation) that are permitted to use local
# SANE devices. IPv6 addresses must be enclosed in brackets,  and  should
# always  be specified in their compressed form.
#
# The hostname matching is not case-sensitive.
#
~serverip~

net.conf Configuration (client)

Modify the net.conf file. Put the IP addresses & names of your server, scanner terminal; client and localhost here, e.g.:

/opt/ltsp/i386/etc/sane.d/net.conf

# This is the net config file.  Each line names a host to attach to.
# If you list "localhost" then your backends can be accessed either
# directly or through the net backend.  Going through the net backend
# may be necessary to access devices that need special privileges.

localhost
~server-ip~
~server-hostname~

Modify the dll.conf (client)

Enable only two lines, one with ‘net’ and the other one with the name of your (!) scanner backend (for me: snapscan -> works with Epson scanner).

/opt/ltsp/i386/etc/sane.d/dll.conf

# enable the next line if you want to allow access through the network:
net
snapscan
#abaton
#agfafocus
#apple
#avision
#artec
#artec_eplus48u
#as6e
...

Here you find an overview of supported backends:

• http://www.sane-project.org/sane-mfgs.html

Modify dll.conf (server)

Modify dll.conf. Enable only the line with ‘net’ (disable all others):

/etc/sane.d/dll.conf

# enable the next line if you want to allow access through the network:
net
#abaton
#agfafocus
#apple
#avision
#artec
#artec_eplus48u
#as6e
...

Modify net.conf (server)

Modify net.conf. Put the IP address of your scanner terminal client (!) here, e.g.:

/etc/sane.d/net.conf

# This is the net config file.  Each line names a host to attach to.
# If you list "localhost" then your backends can be accessed either
# directly or through the net backend.  Going through the net backend
# may be necessary to access devices that need special privileges.
~client-ip~

Alternatively (and better in my opinion) is to script the scanner program, so that it starts with:

SANE_NET_HOSTS=client-ip
export SANE_NET_HOSTS
scanimage > test.pnm

See Alternative Configuration.

Restart your client terminal

Restart hplip (Etch only)

$ sudo /etc/init.d/hplip restart
Stopping HP Linux Printing and Imaging System: hpiod hpssd.
Starting HP Linux Printing and Imaging System: hpiod hpssd.

Test

If it doesn’t work - take a look at your syslog.

Alternative configuration

If your client doesn’t have a static ip and hostname (as with the default ltsp set-up), then you can either configure /etc/dhcp3/dhcpd.conf to provide you with a static ip and hostname, or use this alternative scanner configuration.

Step 1: Remove all client references above

Work back through the above configurations, commenting out all references to your client-ip and client-hostname.

Step 2: Write a script

Here is a simple test script to determine your client, and list your connected scanner:

SANE_NET_HOSTS=`echo $SSH_CLIENT | cut -d " "  -f 1`
export SANE_NET_HOSTS
scanimage -L

You would need to modify this script to do something more useful with scanimage.

References

• http://wiki.ltsp.org/twiki/bin/view/Ltsp/Debian#Scanning_with_LTSP_5_in_Debian_E
• http://wiki.ltsp.org/twiki/bin/view/Ltsp/Scanners
• http://www.enterprisenetworkingplanet.com/nethub/article.php/%203637076
• http://www.jumako.de/cms/index.php?option=com_content&task=view&id=26&Itemid=31

Our Debian Lenny LTSP5 Install has hit a road block: currently the site are using a Citrix server at another location over a 256k connection to pick up their emails. I really didn’t feel that I could ask them all to collect their emails over a 256k connection, so what are the alternatives?

Well I could upgrade the bandwidth by creating an inter-site VPN, but that will still only provide perhaps 600k (that being the upload bandwidth of the host site). The solution is to move the mailserver onto the ‘net, so that they can benefit from a full 8mb ADSL download.

After seeking advice, I choose Bytemark as a trusted Debian VPS supplier, a day later I had my login to my new virtual server. But what to install? Advice pointed me in the direction of Postfix and Dovecot, which were not much more than an apt-get install:

• Debian Admin Mailserver

Great, a working mailserver, but the problem with the installation was that the users were local system accounts, which made it more cumbersome to administer. The best solution seemed to be LDAP, and I duly followed the guide Debuntu to install, and I managed to integrate LDAP with PAM thus giving me the ability to allow users to login with an LDAP account; but in a nutshell that was exactly what was wrong with this solution - the users had to login to the server, before their system account would be created, and if that was the case I might as well have stuck with local system accounts in the first place. What I needed was a true virtual mail host. To that end, I was pointed in the direction of a Ubuntu howto on Howtoforge.

Okay but this was for Ubuntu not Debian and for one reason and another I simply could not get it working. After starting from scratch a couple of times, but ending up in the same place, I found that I had to combine the howto with this one for 8.10.

Even then it took a fair amount of battling to get it working on Debian Lenny. The key to most of my problems was in reading the comments on every page, as these include invaluable corrections and suggestions.

So after a week of pain, I now have a working virtual mail host, now I just need to set-up the domains, users and mailgroups.

Instructions

These instructions are for installing NoMachine’s NX Client for Linux on LTSP, to enable connection to a FreeNX (or NX) server from a screen script.

Warning

These instructions are for Debian Lenny. They are my notes of what I did, and may contain errors or missed steps.

This assumes you have FreeNX installed somewhere to which to connect. You might like to see my Install FreeNX for details.

Download NXClient

Visit NoMachine.com and download the Debian .deb installation. Copy the deb file into /opt/ltsp/i386/root.

Install NXClient in chroot

$ sudo chroot /opt/ltsp/i386
# cd root
# apt-get install libaudiofile0
# dpkg -i nxclient_3.3.0-6_i386.deb (or whatever the name of the file is)
# exit

Install OpenBox in chroot

Unfortunately running nxclient restarts X every time that it’s about to connect. The solution is to install a lightweight Window Manager like xfwm4 or openbox.

$ sudo chroot /opt/ltsp/i386
# apt-get install openbox
# exit

Create User Settings

Easiest way is to install NXClient on the server, and run it to create your settings, then copy your /home/user/.nx directory into the chroot.

$ sudo cp -r /home/userid/.nx /opt/ltsp/i386/home/

Move your /home/userid/.ssh/known_hosts file sideways, and connect to any and all freenx servers that you wish to be able to use. Then copy this file to /opt/ltsp/i386/home/.ssh/.

Edit nx settings

Unfortunately these settings include duff information, change to /opt/ltsp/i386/home/.nx/config and edit nxclient.cfg file, change the location in the following line to:

<option key="Personal NX dir" value="/home/.nx" />

Create Screen Script

Create a new screen script:

$ sudo nano /opt/ltsp/i386/usr/share/ltsp/screen.d/openbox

And copy the following into it:

#!/bin/sh

PATH=/bin:$PATH; export PATH
HOME=/home; export HOME

. /usr/share/ltsp/screen-x-common

if [ -x /usr/share/ltsp/xinitrc ]; then
    xinitrc=/usr/share/ltsp/xinitrc
fi

xinit $xinitrc /usr/bin/openbox-session -- ${DISPLAY} vt${TTY} ${X_ARGS} -br >/dev/null

This script will make the root user’s home directory to be /home. I probably should have set it to /root, but when I experimented with that it didn’t work correctly, I suspect I should have persevered, but I did not, with the result that I am pointing everything to /home instead.

Make OpenBox Autostart NXClient

Create the Openbox configuration directory:

$ sudo mkdir -p /opt/ltsp/i386/home/.config/openbox

Then create a new file autostart.sh:

$ sudo nano /opt/ltsp/i386/home/.config/openbox/autostart.sh

And paste in the following:

(sleep 2 && /usr/NX/bin/nxclient) &

And make it executable:

$ sudo chmod a+x /opt/ltsp/i386/home/.config/openbox/autostart.sh

Update lts.conf

In lts.conf, on the client you wish to test, just set SCREEN_07 = openbox.

Reboot Client

Reboot client the and test!

References

None, sadly. No-one to blame but me.

Background

On Ubuntu and Debian sound on the client gets started automatically during boot by default (the distros udev and the alsa scripts will detect your soundcard and start all needed services if a soundcard was detected on your client). LDM (the default display manager we use in ltsp5) then sets up a virtual ALSA device in the users session during login. The tunnel ALSA uses as endpoint is set up through LDM by setting the PULSE_SERVER variable, it should point to the clients IP at port 4713 (check that by runing “env” in a terminal when logged in).

The pulse server only runs on the client, it has nothing to do with sound but being the transport endpoint… do not play with any pulse audio on the server, it’s all ALSA.

Warning

This document is the LTSP 4.2 Client Sound document, which I am in the process of migrating to LTSP 5. I think it’s pretty much there now down to the last step, which may or may not be appropriate for LTSP 5.

Step 1 - Ensure users are in the audio group

LDM (the default display manager we use in ltsp5) then sets up a virtual ALSA device in the users session during login. The users that shall use sound need to be in the audio group to have access to the virtual sound device and volume control.

$ sudo adduser kate audio
Password: *******
The user `kate' is already a member of `audio'.

Step 2 - Switch on sound

You need to switch sound on for the clients, either for all clients by adding to [default] group at the top of the lts.conf file, or by adding to the specific client in the usual way.

# File: /opt/ltsp/i386/etc/lts.conf
#
[default] 
    SOUND_DAEMON       = pulse
    SOUND              = True

Step 3 - Check alsa set-up

To check the alsa setup is proper, have a look at /etc/asound.conf. There should be two lines like the following:

pcm.!default { type pulse }
ctl.!default { type pulse }

You may also have a file in the user’s home directory .asound.conf, which should probably be removed in order to default to the global setting?

Step 4 - Check port

The tunnel ALSA uses as endpoint is set up through LDM by setting the PULSE_SERVER variable, it should point to the clients IP at port 4713 (check that by runing “env” in a terminal when logged in).

Open a shell and type:

$ env | grep PULSE
PULSE_SERVER=tcp:192.168.0.48:4713
$

Step 5 - Identify soundcard

To determine what Soundcard is installed in your PC, key [Ctrl]+[Alt]+[F1] and log in as root. If you cannot log in, you may need to set the LTSP Client Root Password.

In the shell, to show any PCI Soundcards, type:

# lspci -v | more

Look for a device stating “audio” and make a note of the salient details.

Step 5b - Check Sound not Muted

Some soundcards seem to suffer from a problem that they start-up muted. To test this, whilst logged onto the client type:

# alsamixer

If for example the main volume is at nil and there is “MM” (Muted left and Muted right) at the bottom of the slider, then pressing M to unmute, and the cursor keys to increase the volume, will resolve the problem. The only thing is that this fix will be lost next time you boot the client.

See Unmute Fix for details on how to permanently cure this problem.

Step 6 - Identify sound module with Knoppix

Boot the client with Knoppix or another live CD and from a terminal window type lsmod to identify the sound module. Use this information to help you in the next step.

Step 7 - Determine appropriate driver

To decide the appropriate driver to use, typing the following command on the server or functioning client, will give you a list of available drivers:

$ find /opt/ltsp/i386/lib/modules/ | grep snd

Step 8 - Trial and error

At this point it’s probably worth removing, or commenting out the sound options, so that the client boots without any sound modules loaded. Once booted key Ctrl+Alt+F1.

Unless you have a good knowledge of sound drives, this is going to be a little bit of trial and error - remember Google is your friend. In this instance I Googled for “LTSP Intel 82801EB” and found a page detailing the following:

Intel Corp. 82801EB/ER (ICH5/ICH5R) AC’97 Audio Controller

lsmod

grep -i intel

snd_intel8x0m 20036 1

I compared this with the output from Step 4 and decided the best match was snd-intel8x0.

# modprobe snd-intel8x0

The command responded with some clean output. I therefore added the following to LTS.CONF:

SMODULE_01         = "snd-intel8x0"

And success!

A common Soundblaster compatible card is:

# File: /opt/ltsp/i386/etc/lts.conf
#
SMODULE_01 = "sb io=0x220 irq=5 dma=1"

Related Pages

• LTSP5 Sound Client :: Configure Compaq Deskpro ENSFF
• LTSP5 Sound Client :: Unmute Fix

Introduction

One of the many benefits of LTSP5 is that it does away with the need for ESD sound (or other hacks), and instead utilises Pulseaudio on the client and Alsa on the server.

The rest of this document is largely based on the following Ubuntu/Gnome instructions:

• http://developer.novell.com/wiki/index.php/Feisty/HOWTO:_PulseAudio

Those instruction now state that they are obsolete for new versions of Ubuntu; however they still seem to be required for Debian Lenny.

Install packages on server

$ sudo apt-get install pulseaudio liboil0.3 pulseaudio-utils libpulse-browse0 libpulse-mainloop-glib0 padevchooser pulseaudio-esound-compat
$ sudo apt-get install libao-pulse (for etch)
$ sudo apt-get install libao2 (for lenny)
$ sudo apt-get install alsa-base alsa-utils libasound2-plugins

Install packages on client

I believe that these packages are already installed in Lenny, but no harm in checking:

$ sudo chroot /opt/ltsp/i386/
# apt-get install pulseaudio pulseaudio-esound-compat pulseaudio-module-x11
# exit

ALSA configuration

On the server, configure ALSA to forward audio to PulseAudio by creating a file /etc/asound.conf with the following:

pcm.!default {
        type pulse
}

ctl.!default {
        type pulse
}

PulseAudio configuration

Configure the PulseAudio daemon, create /opt/ltsp/i386/etc/pulse/daemon.conf as follows:

daemonize = 1
high-priority = 1
log-target = stderr
resample-method = trivial
no-cpu-limit = 1
system-instance = 1
disable-shm = 1

Conclusion

In my experience there is no need to reboot the server, in KDE I just restarted the sound system by switching sound off and back on in the KDE Control Panel, and clicked Test button. I could probably just have logged off/on.

References

• http://developer.novell.com/wiki/index.php/Feisty/HOWTO:_PulseAudio

Warning

After completing this installation, the clients received an error on login about port 5900 already in use. Upgrading italc-client (by temporarily adding the sid repository to /etc/apt/source.list in the chroot and re-installing italc-client) fixed this problem.

However, I was unable to get an acceptable performance from italc for shadowing, and ended up install x11vnc. See Install x11vnc on LTSP5 for more information.

Install italc-client in chroot

$ sudo chroot /opt/ltsp/i386
# mount -t proc /proc /proc
# mount -t sysfs sys /sys
# apt-get install italc-client
# umount sys
# umount /proc
# exit

If you are using ubuntu rather than debian, or have switched to nbd instead of nfs, remember to do an ltsp-update-client after leaving the chroot.

Install italc-master on server

$ sudo apt-get install italc-master

Generate Key Pairs

$ sudo ica -role teacher -createkeypair

I tried in vain to stipulate -role admin - could not get the keys to work.

Set Permissions

$ sudo addgroup italc
$ sudo addgroup <userid> italc
$ sudo chgrp -R italc /etc/italc/keys
$ sudo chmod -R 640 /etc/italc/keys/private/
$ sudo chmod -R ug+X /etc/italc/keys/private/

Transfer keys to client

This assumes a standard /opt/ltsp/i386 chroot, change path to suit your installation.

$ sudo mkdir /opt/ltsp/i386/etc/italc/keys
$ sudo cp -r /etc/italc/keys/public /opt/ltsp/i386/etc/italc/keys/

Create client start script

Enter the chroot:

$ sudo chroot /opt/ltsp/i386

And create the following script:

#!/bin/sh
# /usr/share/ldm/rc.d/S20-ica-launcher
/usr/bin/ica &
true

Test

• Reboot client
• Log into client
• Open a terminal on the server and run /usr/bin/ica -noshm
• Run italc

References

• https://help.ubuntu.com/community/UbuntuLTSP/iTalc
• http://indianalinux.blogspot.com/2007/02/howto-install-italc-from-source-on.html
• http://wiki.ubuntu-fi.org/LTSP5_iTalc (Finnish)
• http://www.mail-archive.com/debian-edu@lists.debian.org/msg15477.html

Introduction

Stop! I believe there are now instructions on the ‘net for installing the client on the client instead of on the server

iTalc is a “teacher tool” including screen shadowing functionality. It has replaced Thin Client Manager in Edubuntu 8.04.

The problem with italc is that the documentation is, I believe, for LTSP4.2, not LTSP5. Worse, the Download → Debian points at a defunct location, and goes on to state that the official Debian repositories contain out-of-date packages.

The following is a description for installing from source; which largely the document I followed, and you should read it in conjunction with this:

• http://indianalinux.blogspot.com/2007/02/howto-install-italc-from-source-on.html

Warnings

This is a description of how I personally installed iTalc on Debian Etch with KDE 3.55.

The installation worked fine, except that iTalc kept bombing out every few seconds, making it completely useable. It was quite obvious that this was down to Qt4, which Etch’s version is too old for iTalc. Unfortunately there was no backports, so I ended up installing Qt4 from Lenny; resulting in several additional packages needing to be installed. This immediately resolved the stability issues.

Download source

Navigate to the italc download page and copy the link to the latest tar.gz file.

$ cd /usr/src
$ sudo wget http://downloads.sourceforge.net/italc/italc-1.0.9-rc4.tar.bz2?modtime=1215423893&big_mirror=0

Extract

$ sudo tar -xvvjf italc-1.0.9-rc4.tar.bz2
$ cd italc*

Read installation notes

Yes, believe it or not you shouldn’t follow howto’s like this blindly, instead read the developer’s installation instructions and make your own judgements!

$ cat INSTALL | more

Install dependencies

At the time of writing the above install file stated the following dependencies, which you should now install:

$ sudo apt-get install libqt4-dev qt4-dev-tools xorg-dev libxtst-dev libjpeg62-dev zlib1g-dev libssl-dev

xorg-dev will install a great many other files (probably worth removing them later)

In addition, we will need build-essential, in order to compile from source:

$ sudo apt-get install build-essential

And lastly, this page included the following dependency, which we may as well install:

$ sudo apt-get install libxtst-dev

Compile and install

As normal we need to ensure that we are in the source directory and then:

$ ./configure --prefix=/usr

If that completes successfully, we can proceed to make:

$ make

And, if that completes successfully, we can proceed to install:

$ sudo make install

Client installation on the server

The installation was done as part of the server install, so all we need to do is create the client keys:

$ sudo ica -role teacher -createkeypair

Change permissions to increase security:

$ sudo addgroup italc
$ sudo adduser username italc
$ sudo chgrp -R italc /etc/italc/keys/private
$ sudo chmod -R o-rwx /etc/italc/keys/private

This method has a problem in that all the clients are going to be coming from the same IP address, i.e. the server IP, so we need to give each user their own port. A good idea is to base the port number on 10000 + the last segment of their IP address. Edubuntu has a script for this, which requires the $LTSP_CLIENT variable to be present. I have modified so that it instead uses the $SSH_CLIENT variable, as follows:

#!/bin/sh

# /usr/bin/ica-launcher
if [ "$SSH_CLIENT" ]
then
        PORT=`echo $SSH_CLIENT | awk -F . '{print \$4}' | awk -F " " '{print \$1}'`
        IVS=$((10000 + $PORT))
        ISD=$((11000 + $PORT))
        ica -noshm -ivsport $IVS -isdport $ISD &
else
        ica -noshm
fi

Autostart

We need the client to run automatically when users log in. In KDE this means a .desktop file in /usr/share/autostart. If you’re unsure how to do this, then an example “italc.desktop” file is shown below:

/usr/share/autostart/italc.desktop:

[Desktop Entry]
Comment=
Comment[en_GB]=
Encoding=UTF-8
Exec=/usr/bin/ica-launcher
GenericName=
GenericName[en_GB]=
Icon=/usr/share/icons/italc.png
MimeType=
Name=iTalc Client
Name[en_GB]=iTalc Client
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DCOP-ServiceType=
X-KDE-SubstituteUID=false
X-KDE-Username=

You also need to exclude from session restoring for all users (if you use KDE session restore):

/home/username/.kde/share/config/ksmserverrc:

[General]
excludeApps=ica

Do the same for /etc/skel/.kde/share/config/ksmserverrc to effect new users when they are created.

Alternative Method - client installation in chroot

In theory I would have liked to have the client installed in the chroot. This should run quicker and provide full functionality of logon/logoff etc. In practice I was unable to get this working, with very much the same results as I had with x11vnc, in that the software would run, but netstat would not show any ports opened. A mystery. After spending a couple of days on this, I decided to give up and instead run both client and server on the server.

If you are determined to install in the chroot, I found that it was possible to download and install the following prebuilt binaries for Ubuntu (requires some packages installing from lenny):

• http://www.stgraber.org/download/ubuntu/italc/hardy-i386/

This will automatically generate the keys, and you will need to copy the private key to the server.

Also, you should probably make the X.Org Module change (see below).

And don’t forget to update the image:

$ sudo ltsp-update-image

References

• http://italc.sourceforge.net/
  • http://italc.sourceforge.net/wiki/index.php?title=ITALC_in_a_ThinClient_environment
• https://wiki.ubuntu.com/iTalc
• http://italc.sourceforge.net/home.php
• http://wiki.skolelinux.de/Etch/Italc
• http://www.stgraber.org/
• http://indianalinux.blogspot.com/2007/02/howto-install-italc-from-source-on.html

Background

Rdesktop is a problem, because it uses /dev/dsp as the sound device (for version 1.5 at least). This is incompatible with ALSA.

Solution

Specifying “oss” as the sound driver, instead of the default, worked fine:

$ padsp rdesktop -r sound:local:oss 192.168.0.1

/usr/share/doc/ltspfs/examples/kde-desktop-icons

Add follow instructions. You’ll need to create the directory mentioned.

Step 1 - Switch on sound

Firstly, you need to switch sound on for the clients.

# File: /opt/ltsp/i386/etc/lts.conf
#
# enable sound by default
SOUND                   = Y
# choose either esd or nasd to be the default (esd only on x86_64)
SOUND_DAEMON            = esd
VOLUME                  = 100 # Speaker & WAVE volume pecentage
MIC_VOLUME              = 100 # Microphone volume
CD_VOLUME               = 75  # CD Audio volume

Step 2 - Identify soundcard

To determine what Soundcard is installed in your PC, add the line:

# File: /opt/ltsp/i386/etc/lts.conf
#
SCREEN_02          = shell

Then enter after rebooting, enter shell by typing Ctrl+Alt+F2. In the shell, to show any PCI Soundcards, type:

# lspci -v | more

Look for a device stating “audio” and make a note of the salient details. For example my test PC has the following details:

Intel 82801EB/ER AC97 IRQ5 IO Port d400 @ 256k and d800 @ 64k.

Step 3 - Check LTSP.org

Check the following website - you might strike lucky!

• http://wiki.ltsp.org/twiki/bin/view/Ltsp/SoundCards

Step 4 - Determine appropriate driver

To decide the appropriate driver to use, typing the following command on the server or functioning client, will give you a list of available drivers:

$ find /opt/ltsp/i386/lib/modules/ | grep snd

Step 5 - Identify sound module with Knoppix

Boot the client with Knoppix and from a terminal window type “lsmod” to identify the sound module.

Step 6 - Trial and error

At this point it’s probably worth removing, or commenting out the sound options, so that the client boots without any sound modules loaded. Once booted key Ctrl+Alt+F2.

Unless you have a good knowledge of sound drives, this is going to be a little bit of trial and error - remember Google is your friend. In this instance I Googled for “LTSP Intel 82801EB” and found a page detailing the following:

Intel Corp. 82801EB/ER (ICH5/ICH5R) AC’97 Audio Controller

lsmod

grep -i intel

snd_intel8x0m 20036 1

I compared this with the output from Step 4 and decided the best match was “snd-intel8x0”.

# modprobe snd-intel8x0

The command responded with some clean output. I therefore added the following to LTS.CONF:

SMODULE_01         = "snd-intel8x0"

And success!

A common Soundblaster compatible card is:

# File: /opt/ltsp/i386/etc/lts.conf
#
SMODULE_01 = "sb io=0x220 irq=5 dma=1"

Other issues

Soundcard okay but no sound

If you are confident that the soundcard is being identified correctly and there are no errors on boot-up, then perhaps the volume is muted. The only volume controls at our disposal are:

VOLUME                  = 100 # Speaker & WAVE volume pecentage
MIC_VOLUME              = 100 # Microphone volume
CD_VOLUME               = 75  # CD Audio volume

However from a client shell you can try the following:

$ cd /share/sounds/alsa
$ esdplay Noise.wav
$ amixer scontrols              # Take a note of them
$ amixer sget Front             # To view each control
$ amixer sset Front 75% unmute   # To set a control called Front to 75% volume

snd-hda-intel issues

Oh, so may issues. Try each of the following in lts.conf:

Google for ALSA-Configuration.txt and review section on snd-hda-intel.

SMODULE_01              = "snd-hda-intel model=auto"
SMODULE_01              = "snd-hda-intel model=3stack"
SMODULE_01              = "snd-hda-intel model=3stack-dig"
SMODULE_01              = "snd-hda-intel index=0 probe_mask=3 position_fix=3"
SMODULE_01              = "snd-hda-intel position_fix=1 model=3stack"

Sound muted

All working but sound muted. Save this script as “unmute” in /opt/ltsp/i386/etc/rc.d:

#!/bin/bash
#
# Copyright Gideon Romm, Symbio Technologies
#
# Released under GPLv2
#
# This is a script to set up certain things 
# that are not already setup in an SBA environment
#
# Specifically:
#   1. restore sound levels
#

# Set up local environment
if [ -f /etc/lts.conf ]; then
    eval `getltscfg -a`
fi

# Set up sound
if [ -n "$VOLUME" ]; then
    amixer sset Master,0 ${VOLUME}% unmute 2>/dev/null
    amixer sset 'Master Digital',0 ${VOLUME}% unmute 2>/dev/null
    amixer sset Headphone,0 ${HEADPHONE_VOLUME:-$VOLUME}% unmute 2>/dev/null
fi

if [ -n "$PCM_VOLUME" ]; then
    amixer sset PCM,0 ${PCM_VOLUME}% unmute 2>/dev/null
fi

if [ -n "$MIC_VOLUME" ]; then
    amixer sset Mic,0 ${MIC_VOLUME}% unmute cap 2>/dev/null
fi

if [ -n "$CD_VOLUME" ]; then
    amixer sset CD,0 ${CD_VOLUME}% unmute 2>/dev/null
fi

if [ -n "$FRONT_VOLUME" ]; then
    amixer sset Front,0 ${FRONT_VOLUME}% unmute 2>/dev/null
fi

Then add the following line to LTS.conf:

RCFILE_01          = unmute

This unmute script also adds the functionality of FRONT_VOLUME, which may be set in LTS.CONF:

FRONT_VOLUME       = 100

The script could be easily modified to enable other volume controls is required.

Introduction

Warning: sound on LTSP should only be contemplated by those who enjoy good health and have no history of heart disease in their family. If you are of a nervous disposition you should not attempt sound on LTSP.

Please note that this solution, at best, result in poor quality sound. High fidelity it is not.

The absolute gospel according to LTSP sound is the following web page. You may consider this page to be disjointed and contradictory, that is because it is disjointed and contradictory.

• http://wiki.ltsp.org/twiki/bin/view/Ltsp/Sound

Good luck!

ESD Socket

ESD requires a socket to run, but if your server doesn’t have a sound card, then the odds are that you do not have a socket. You will need to create this manually:

$ sudo mkdir /tmp/.esd
$ sudo touch /tmp/.esd/socket

You will need some form of script and cron job in order to make this persist beyond server reboots.

#!/bin/bash
if [ ! -e /tmp/.esd/socket ]; then
    /bin/mkdir /tmp/.esd
    /bin/touch /tmp/.esd/socket
fi

Save this script somewhere, make it executable and add it to crontab.

OSS transparent redirection to esd

There are other ways of getting sound, but this seems to work. Most Linux application can use /dev/oss, KDE, RealPlayer, Skype, … support it. Also if sound redirection by OSS might not be the best quality, in order to listen voicemails and/or online training it is more than enough.

The other nice thing with OSS redirection, is that from a system admin point of view it is a piece of cake !!! After you’ve started esound server from lts.conf as explained before, make it available automatically from X11 startup. In order to do so add in /etc/X11/Xsession somewhere before it launches your window manager.

REMOTE_X11=${DISPLAY%:*}
if test "$REMOTE_X11" == ""
then
  export REMOTEX_11=false
else
  export ESPEAKER=$REMOTE_X11:16001
  export ESDDSP_MIXER=1
# export LD_PRELOAD="/usr/lib/libesddsp.so.0 /usr/lib/libesd.so.0 $LD_PRELOAD"        # Non-debian
  export LD_PRELOAD="/usr/lib/esound/libesddsp.so.0 /usr/lib/libesd.so.0 $LD_PRELOAD" # Debian
  export REMOTE_X11=true
fi

Note that the line:

export LD_PRELOAD="/usr/lib/libesddsp.so.0 /usr/lib/libesd.so.0 $LD_PRELOAD"

must be changed to

export LD_PRELOAD="/usr/lib/esound/libesddsp.so.0 /usr/lib/libesd.so.0 $LD_PRELOAD"

In order to check, connect from your LSTP client and check $ESPEAKER. It’s value should look like ltsp-client-name:16001.

$ echo $ESPEAKER
ws179.ltsp:16001

Next step is to try it, by finding a .wav file somewhere is /usr/share/sounds and run it using esdplay:

$ esdplay /usr/share/sounds/alsa/test.wav

Hopefully you heard some sound?

Flash Sound

For YouTube and other flash websites, if you want sound, you should download and run this deb:

• http://pulseaudio.vdbonline.net/libflashsupport/

This is experimental and unsupported, but it worked first time.

Realplayer

References

• http://forms.real.com/real/player/blackjack.html
• http://linux.derkeiler.com/Mailing-Lists/Debian/2004-02/3778.html

Step 1: Create download directory

$ cd ~
$ mkdir realplayer8
$ cd realplayer8

Step 2: Download Realplayer 8

$ wget http://software-dl.real.com/2241543e04bd76d81218//support/unix/rp8_linux20_libc6_i386_cs1_rpm.htm

Step 3: Correct name of downloaded file

$ mv rp8_linux20_libc6_i386_cs1_rpm.htm rp8_linux20_libc6_i386_cs1.rpm

Step 4: Convert and install deb

I have tested and the –scripts option seems to work well.

$ alien --scripts rp8_linux20_libc6_i386_cs1.rpm
$ dpkg -i rp8_linux20_libc6_i386_cs1.deb

Step 5: Create symlink to Mozilla Plugins

$ sudo ln -s /usr/local/netscape/plugins/rpnp.so /usr/lib/mozilla/plugins/rpnp.so

ESound on VMWare

If Enlightenment Sound Daemon is enabled on the Linux host, the software opens the host machine’s sound device by the time X starts. When a virtual machine with sound configured is started on a host with ESD running, Workstation will not be able to access the sound device because it is in use. As a workaround, you can start the Workstation session using the esddsp wrapper. Start the session by typing esddsp vmware or esddsp <virtualmachinename>.cfg. The wrapper will pass the sound output generated by the virtual machine as an audio stream to the ESD audio server.

MPlayer

MPlayer must be configured

/etc/mplayer$ sudo nano mplayer.conf
vo=x11
ao=esd
framedrop=1

$ sudo nano /etc/mplayerplug-in.conf

# See http://mplayerplug-in.sourceforge.net/config.php
# for a description of these options
vo=x11
ao=esd
cachesize=512
cache-percent=25
dload-dir=$HOME/tmp
autostart=1
enable-wmp=1
enable-qt=1
enable-rm=1
enable-gmp=1
enable-dvx=1
enable-mpeg=1
enable-mp3=1
enable-midi=0
enable-pls=1
enable-ogg=1
enable-smil=1
enable-helix=1
nomediacache=0
nopauseonhide=0
rtsp-use-tcp=0
rtsp-use-http=0
framedrop=1

• http://mplayerplug-in.sourceforge.net/config.php

Enable saned on terminal

• Edit /opt/ltsp/i386/etc/lts.conf and add XINETD_SERVICES = "saned" to the [default] or relevant terminal section
• Restart the terminal
• Run scanimage -L on workstation shell to verify that scanner has been detected

Usage

• Physically plug the scanner into the terminal using USB or parallel port.
• Edit /etc/sane.d/net.conf and add the hostname or address of client running saned
• Use xsane, OpenOffice.org, GIMP, or any other scanner-aware application, as they should now list the scanner.

Alternative to net.conf

If you do not wish to add the host to net.conf (as shown above) then you can run the following:

$ SANE_NET_HOSTS=`echo $DISPLAY | cut -d: -f1`
$ export SANE_NET_HOSTS

This will only work for the life of the terminal window - so you will need to run the application from the command line. Alternatively add this to a script that does the scanning.

Scanning from the command line

Check scanner detected

$ scanimage -L

Scan

$ scanimage -l 0 -t 0 -x 215 -y 297 --mode {Lineart|Gray|Color} --resolution {75..600} --format {pnm|tiff} --brightness {-100..100} --contrast {-100..100} >test.pnm

References

• http://wiki.ltsp.org/twiki/bin/view/Ltsp/Scanners

Choosing your version of LTSP

There are two versions of LTSP currently available:

• LTSP4.2
• LTSP5

If you visit the LTSP website, then you can’t help but notice that all the information is on LTSP4.2. If you do some Googling about LTSP5, you will quickly determine that LTSP5 is full of problems, at an early stage of development and best avoided.

Wrong, wrong, wrong. You are just about to make a mistake.

In fact LTSP5 is the current version and has been since 2006. Indeed, if you try and seek any help in respect of version 4.2, and you will invariably get the response - “LTSP4.2 is obsolete, unmaintained and you are an idiot to have installed it”.

Okay I exaggerate, but not by much! If you do install 4.2, at some point you are going to want to update the client. Well that requires LBE (read the Wiki for details) - then you will hit the problem that LBE is broken and will not install. You’ll ask for help and the response you will receive is pretty much as above.

Good luck sorting that little problem out, for myself I upgraded to LTSP5 (see LTSP5 Upgrade) and I have never looked back. The client is up-to-date and configurable, the local devices work, sound works, and little fluffy bunny rabbits nibble the grass while the sun shines.

In short all his just fine and dandy in the world of LTSP5. Always assuming it’s been packaged for your distro, it has for Debian and Ubuntu, for the rest you’ll need to make your own enquiries.

What you can expect from LTSP4.2

Positives

A working reliable system. Sound (see LTSP4.2 Sound). Local Devices that appear on the desktop when you plug them in. Works particularly well for older clients (Pentium II with 32mb RAM).

Negatives

Expect to fight any PC built in the last two or three years. Expect to have battles getting sound working on your clients (usually solvable, usually you have wounds to lick afterwards). I am told that USB keys don’t work quite as well, although I never found any problem in this area. Indeed I managed to get USB keys working better under LTSP4.2 than I have subsequently managed to do in LTSP5.

What you can expect from LTSP5

A system that pretty much works as you expect. Sound was simple to configure and works well. Scanning took a little bit of working out (see LTSP5 Scanning). Local devices work just fine (with the exception of some incorrectly partitioned devices). The client system works very well, although I am still learning exactly how it all hangs together. Newer PCs work perfectly, and all but the oldest PCs seem fine. The ones I did have to get rid of were no great loss; but if you feel differently then I understand it is technically possible to install LTSP4.2 and LTSP5 on the same server, and get the benefits of each. You’ll need to search the LTSP Mailing List to find out how.

I understand that it is even conceivable to deliver a full-blown desktop client system - although you need LDAP on your network to enable client logon. Again, search the LTSP Mailing List for details.

Internet Explorer for Linux

Recent developments

Bugs

Versions of Wine greater than 0.92 seem to cause IES4Linux to consume vast amounts of CPU both for wineserver and iexplore.exe. This problem seems to occur when accessing SSL pages (possibly Active-X pages). Bugs have been logged with Ubuntu which was quite rightly redirected to Wine, which was rejected pending a regression test, which in turn was redirected to IES4Linux. The issue seems to be that Wine do not support native DLLs, but these are essential in making IE work under Linux.

Deb package

There may be a multi-user install deb package (for Ubuntu at least):

• http://ubuntuforums.org/showthread.php?t=636758

Install Wine

Make sure you’ve installed Wine.

Read Debian Installation

• http://www.tatanka.com.br/ies4linux/page/Installation:Debian

Master Installation IES4Linux

First you must create a master installation of ies4linux under /usr/local. To create the master copy, perform a standard ies4linux install as an ordinary desktop user (i.e. unpack the tarball, run ./ies4linux):

$ wget http://www.tatanka.com.br/ies4linux/downloads/ies4linux-latest.tar.gz
$ tar zxvf ies4linux-latest.tar.gz
$ cd ies4linux-*
$ ./ies4linux

Convert to Multi-user System

$ cd
$ rm bin/ie{5,55,6}
$ sudo mkdir -p /usr/local/share
$ sudo chmod a+rX /usr/local/share
$ sudo mv .ies4linux /usr/local/share/ies4linux
$ sudo chown -R root:root /usr/local/share/ies4linux
$ sudo chmod -R a+rX /usr/local/share/ies4linux

• http://www.tatanka.com.br/ies4linux/forum/viewtopic.php?t=431

Then install this script as any or all of /usr/local/bin/ie{5,55,6} and let your users run it:

#!/bin/sh
# Launch script for multiuser ies4linux, master copy in /usr/local/share.
# Install as /usr/local/bin/ie6 (or ie55 or ie5)
#
# Blame Andrew Chadwick <andrewc-ies4linux0606@piffle.org>, not Sergio.
#
# Released under the GNU GPL version 2 (or later, your call).
# See ies4linux's own LICENSE or COPYING file for more information.
####################################################

IE=`basename "$0"`
MASTERPREFIX="/usr/local/share/ies4linux/$IE"
WINEPREFIX="${HOME}/.ies4linux/$IE"

# If we're not set up, create the user's magic symlink-copy of the master
# installation.

if ! test -d "$WINEPREFIX"; then
    if ! mkdir -p "$WINEPREFIX"; then
        echo "mkdir $WINEPREFIX failed"
        exit 1
    fi
    if ! lndir "$MASTERPREFIX" "$WINEPREFIX"; then
        echo "lndir failed: is xutils installed?"
        exit 1
    fi

    # The profile directory will be recreated automatically by wine on the
    # first run, so it's OK to blow away eny existing copy hanging around in
    # unwritable symlink form from the install, and it's OK to just create a
    # blank one.
   
    PROFILES="$WINEPREFIX/drive_c/windows/profiles"
    rm -fr "$PROFILES"
    mkdir -p "$PROFILES"

    # WINE needs to be able to write to the following files, so they can't be
    # symlinks to root-owned ones.
   
    for file in .no_prelaunch_window_flag system.reg userdef.reg user.reg; do
        if test -L "$WINEPREFIX/$file"; then
            rm -f "$WINEPREFIX/$file"
            cp "$MASTERPREFIX/$file" "$WINEPREFIX/$file"
        fi
    done
    chmod -R og-rwx "$WINEPREFIX"
fi

export WINEPREFIX
exec wine "$WINEPREFIX/drive_c/Program Files/Internet Explorer/IEXPLORE.EXE"
echo "Failed to launch WINE: see above for details"
exit 1

Run the script above as an ordinary desktop user. When it runs, this script tries to create a WINE prefix location under the user’s home, consisting mainly of symlinks to the master copy’s files. It then launches IE in the normal way.

If it screws up, delete your ~/.ies4linux directory and try again.

After a week spent trying to install our Debian Lenny LTSP server, with the clients failing to boot with an error “rpc failed: 2”, and everyone I spoke to baffled as to how this could occur, I decided that enough was enough, and deleted the partitions and started again. Within 2 hours the server was back up and running without any of the same problems.

And a lesson learned: don’t invest too much time in an install, without testing that the fundamentals are in place!

• LTSP5 Install

Local floppy drives do not seem to work well under LTSP, in any case they are obsolete technology. This page describes how to disable under LTSP5.

Find and edit the following file and comment out the legacy floppy drive command:

Extract from /opt/ltsp/i386/etc/udev/ltspfsd.rules:

# legacy floppy drives:
#ACTION=="add", KERNEL=="fd[0-9]", RUN+="ltspfs_entry add %k auto"
^
----------------------------------

# exit
$ sudo ltsp-update-image

Introduction

Most GNU/Linux machines have 12 virtual consoles, which you can access by pressing Control-Alt-F1, through Control-Alt-F12. There is a text based getty that is started on screen 1, but you normally can’t log into it, as there are no local users on the thin client.

Setting the root password for client

However, for debugging purposes, you may want to set up root to log in on the thin client. You may need to do this if you’re debugging problems with local devices, for example. Fortunately, it’s easy to do: on the server, just chroot into the LTSP chroot, and set the password with passwd.

$ sudo chroot /opt/ltsp/i386
# passwd
# exit
$ sudo ltsp-update-image

Logging in

Just enter Ctrl-Alt-F1 on your terminal, and at the text login, login with “root” and the password you have set.

Introduction

There is a problem with some sound cards that start up muted. This installs a script which responds to settings in lts.conf.

To test this, whilst logged onto the client type:

# alsamixer

If the main volume is at nil and there is “MM” (Muted left and Muted right) at the bottom of the slider, then pressing M to unmute, and the cursor keys to increase the volume, will resolve the problem. You can experiment with the different channels, like PCM, FRONT and MASTER. Play to your heart’s content, any changes will be lost on reboot.

The only thing is that this fix will be lost next time you boot the client.

Step 1: Install Script

#!/bin/bash
#
# Copyright Gideon Romm, Symbio Technologies
#
# Released under GPLv2
#
# This is a script to set up certain things 
# that are not already setup in an SBA environment
#
# Specifically:
#   1. restore sound levels
#
# lts.conf:
# VOLUME
# PCM_VOLUME
# MIC_VOLUME
# CD_VOLUME
# FRONT_VOLUME

echo "Restoring sound levels" > /tmp/unmute.log

amixer
while [ $? != 0 ]; do
sleep 1
amixer
done

# Set up local environment
if [ -f /etc/lts.conf ]; then
    eval `getltscfg -a`
fi

# Set up sound
if [ -n "$VOLUME" ]; then
amixer sset Master,0 ${VOLUME}% unmute 2>/dev/null
echo "amixer sset Master,0 ${VOLUME}% unmute 2: $?" >> /tmp/unmute.log
amixer sset 'Master Digital',0 ${VOLUME}% unmute 2>/dev/null
echo "amixer sset 'Master Digital',0 ${VOLUME}% unmute 2: $?" >> /tmp/unmute.log
amixer sset Headphone,0 ${HEADPHONE_VOLUME:-$VOLUME}% unmute 2>/dev/null
echo "amixer sset Headphone,0 ${HEADPHONE_VOLUME}% unmute 2: $?" >> /tmp/unmute.log
fi

if [ -n "$PCM_VOLUME" ]; then
amixer sset PCM,0 ${PCM_VOLUME}% unmute 2>/dev/null
echo "amixer sset PCM,0 ${PCM_VOLUME}% unmute 2: $?" >> /tmp/unmute.log
fi

if [ -n "$MIC_VOLUME" ]; then
amixer sset Mic,0 ${MIC_VOLUME}% unmute cap 2>/dev/null
echo "amixer sset Mic,0 ${MIC_VOLUME}% unmute 2: $?" >> /tmp/unmute.log
fi

if [ -n "$CD_VOLUME" ]; then
amixer sset CD,0 ${CD_VOLUME}% unmute 2>/dev/null
echo "amixer sset CD,0 ${CD_VOLUME}% unmute 2: $?" >> /tmp/unmute.log
fi

if [ -n "$FRONT_VOLUME" ]; then
amixer sset Front,0 ${FRONT_VOLUME}% unmute 2>/dev/null
echo "amixer sset Front,0 ${FRONT_VOLUME}% unmute 2: $?" >> /tmp/unmute.log
fi

echo "Sound levels restored" >> /tmp/unmute.log

Step 2: Generate rc.d

$ sudo chroot /opt/ltsp/i386
# update-rc.d unmute defaults
# exit
$ sudo ltsp-update-image

Step 3: Configure lts.conf

Use the following settings for the particular client:

VOLUME            = 100
PCM_VOLUME        = 100
MIC_VOLUME        = 100
CD_VOLUME         = 100
FRONT_VOLUME      = 100

Step 4: Reboot client

Reboot the client. You can check that the script has run by looking at /tmp/unmute.log on the client. You can get to the client by pressing Ctrl-Alt-F1 and logging in with the root password.

References

• http://www.debian-administration.org/articles/28

I have today started a clean install on a new server, and I am documenting the entire process; not just the LTSP install, but everything, from the installation of a virtualised Windows server, to the installation of KDE and end-user apps.

• LTSP5 Install

I have solved the issue with PXE booting on the Viglen MPC-L!

To get past the kernel panic, it was necessary to switch of acpi in the kernel. In LTSP that means copying the following file:

N.B. Replace 00-00-00-00-00-00 with the MAC address of the Viglen but note it has to have the leading 01 at the beginning

# cp /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/01-00-00-00-00-00-00

Then edit the file and add acpi=off to the end of the line (I also added pnpbios=off to reduce the boot-up error messages):

DEFAULT vmlinuz ro initrd=initrd.img quiet root=/dev/nfs ip=dhcp boot=nfs acpi=off pnpbios=off

And it now boots up fine.

Persistence paid off, in that F1 will work, but it is a race between the detection of the USB keyboard and the completion of the boot loader. I found that if I moved the cursor on the grub screen it paused, enabling me to Ctrl-Alt-Del, which seemed to enable to USB detection to complete quicker. Or perhaps I was just lucky. But in fact it’s immaterial as the PXE boot settings are not there, but are instead under Shift-F10, which seems to work fine.

Unfortunately the PXE boot to LTSP ends in a kernel panic - but at least I am one step closer!

The Viglen MPC-L is a very small thin-client device, running Xubuntu with the XFCE desktop. At £99 including VAT, this is a very inexpensive PC. I recently listened to a review of the device on the Ubuntu UK Podcast. They described the device as slow, but explained that the Viglen MPC-L is really intended as a thin client device anyway. I decided to order a test unit for evaluation, in the hope that it would work as a thin client for our LTSP server.

My test unit has arrived, and I have added a review to my site, and include below for your interest…

First impressions are that the device is even smaller than I was expecting, it really is small enough to go on the back of a LCD panel; however the device is functional rather than attractive. Sleek it is not. Secondly I noticed that in common with many thin client devices there are no legacy keyboard and mouse ports, just USB (2 front and 2 back). The device comes with a Viglen USB keyboard and Microsoft USB optical mouse, which are both fairly cheap and cheerful devices.

Next I connected it up and booted. It was slow to boot - 2 minutes and 30 seconds. On the flipside, once it is up power consumption is just 9 watts, increasing to 11 watts under load, so this is a device that can be left on. Logging in only took another 10 seconds.

Once into Xubuntu, I noticed a desktop icon for “888M Volume” which apparently the standard user cannot mount, a minor point perhaps, but I would question why it is on the user’s desktop.

One disappointment is that the device only has a 40GB hard drive, as stated in the Ubuntu UK Podcast, but in contrast with the 80GB promised by Viglen Sales. A further disappointment was the screen clarity which was a long way from being pin-sharp. A quick sudo dpkg-reconfigure xserver-xorg increased the screen resolution from 1024x768 to 1280x1024, but as yet I have not managed to achieve a pin-sharp display on my AG Neovo S-19 LCD Panel. Possibly that’s a limitation of the on-board graphics, but if so, health and safety would prevent its use in a corporate environment. I will take this up with their support team.

I opened Firefox (another 20 seconds gone). Flash isn’t installed, and given the sluggish browsing performance, I don’t think I’d be tempted to install it; but that does reduce the number of websites that can be accessed via this device. Next I visited Googlemail; Googlemail took 30 seconds to load, but it was very sluggish to use. Interestingly Viglen have also installed Opera, which was slightly quicker, probably the reason Viglen installed it. I wonder whether they wouldn’t have been better installing Seamonkey?

The Viglen MPC-L comes with Abiword, Gnumeric and Gimp, which I believe are the default XFCE applications and probably a wise choice for a device this slow.

Interestingly Viglen state in their literature:

“Viglen have tuned and tweaked this distribution for optimal performance on the MPC through the use of various techniques and tricks. Load times and startup times have been greatly reduced through adaptive analysis techniques and removing unnecessary startup scripts.”

Hmmm.

So as a standalone PC, it has few merits beyond size and price, but we must remember, that this is a £100 PC, and Viglen have been clear about the fact that this device is really designed to be a thin client.

So, with my corporate hat on, I looked for Citrix Presentation Server Client, the preferred method of connecting to a Citrix server. Not installed. Oh well, I guess most people will be connecting to an ordinary Microsoft Terminal Server via RDP. Looked for an RDP application (krdc on KDE - anyone know for XFCE?), but couldn’t find one. Okay, so any sysadmin is going to set up a desktop shortcut for rdesktop, but rdesktop is also not installed. Only an apt-get away perhaps, but the minimum I would have thought for a device purporting to be a thin client device. Next I looked for NoMachine’s NX client, again not installed. VNC? 2X? No.

If Viglen really want this device to be considered a thin client device, then those applications really ought to be there, and it would cost them nothing so to do, as all the software is free. I installed rdesktop and was quickly able to connect to our virtualised W2K3 server, no problems there then.

I then decided to test the device as a thin client for LTSP. So rebooted and tried to get into the BIOS. The boot splash states F1 for Setup, but when you press it nothing happens, instead there is a message stating “VSA USB Enumeration” and the boot process continues regardless. So configuring PXE booting is going to be a little difficult, perhaps impossible. The inability to reach the BIOS screen must surely be a fault - and something that I will investigate further.

The problem with the Viglen MPC-L is that it is neither fish nor fowl - it is too slow to be seen as a viable PC, but it has not been properly set up to use as a thin client. This means that the cost of these devices needs to include some not insignificant time for a sysadmin to install and configure the requisite software to access their server.

Criticisms aside, this is tremendously good value at £99 and an environmentally friendly device. At the current promotional price of £80 it really is tremendous value for money, and if you deduct VAT and then a further £8 for the keyboard and mouse, then this device will cost a company just £60, an astonishing price. For me, though, unless I can resolve the PXE issue, the device is going to be of little use.

Cheap, but not entirely cheerful.

Some time ago I bought the following kit:

• Pack-box £ 38.26
• Jetway J7F2 1.2Ghz Eden CN700 Mainboard - Fanless £ 87.55
• 6-26V 60W picoPSU-60-WI £ 27.55
• 12V 60W AC Adapter £ 19.06

With the intention of attaching them to the underside of showroom desks as an LTSP Client. Unfortunately they don’t provide anywhere for an optical drive, which our MD felt was essential. So what to do with it? Well, I decided to try and set it up as a low-wattage PC for potential use in a car, caravan, boat, or simple a green PC for home use. To that end I purchased the following additional items:

• Compact Flash IDE Adapter on PCI Mounting Bracket £ 15.34
• Kingston 8GB Ultimate Compact Flash 266x £ 63.47

So the total cost of the system was £ 251.23 + VAT = £ 295.19. Not a cheap system, but the amazing thing about it is the huge range of power input from 6V through to 26V, which means you don’t need a voltage regulator for this PC to work in a car, boat or caravan.

A word about Compact Flash - there are two important things to discover before purchasing Compact Flash:

1. Speed: Speed is expensive, but to have a system that compares favourably with a traditional hard-drive you need speed - 266x is recommended
2. Life expectancy: Flash drives have a finite number of write cycles, and therefore you need a drive that has “wear levelling”.

Whilst Kingston advertise that their drives include wear levelling, I probably would have been safer to purchase a Industrial Flash Drive available from LinITX. At the time of writing LinITX did not offer any 8GB drives, and their 4GB drives were comparable in cost to the 8GB drive from Dabs. Only time will tell whether this was a mistake.

My next problem was how to install without an optical drive. In the end I followed these instructions and chose UNetBootin method, although I found that I did have to follow the additional steps required.

From that point on the installation was no more difficult than a traditional live CD install; however I did configure tmpfs file systems in /etc/fstab in order to reduce disk-writes.

Now I just need to find a use for it!

Following the installation of Italc on our LTSP Server, users reported that they had several green icons in their system tray. This transpired to be the KDE session manager, which automatically restores all applications running at time of logging-off. I have updated my Install Italc instructions to include excluding ica from KDE session manager.

In trying to kill off the multiple ica processes, I found that ps can do more than just ps aux. I found that ps -fHu username would provide a tree-view of the specified user, which is much neater than piping ps through grep.

And then our /tmp filesystem filled up, and I just simply could not work out why. Until, at least, I managed to trash our virtualised Windows Server 2003 (running under Qemu), by inadvertently disabling its network card and thus triggering the server monitoring - which automatically killed and restarted it; 600mb freed up in a second.

This turned out to be a complete nightmare, and took several days to resolve. I never did manage to get x11vnc working on the client, nor did I manage to get italc (which I think also uses x11vnc) working on the client. In the end I settled for installing italc-client on the server, so that the client runs when users log onto the server, allocating each user a unique port, and putting a little green italc icon in their system tray.

This required upgrading qt4 from lenny (hardly ideal) and still works like a pig. Well viewing is fine, but the remote control is unusably slow.

I found it impossible to manage the list of users in italc; which changes according to the whims of DHCP. I ended up writing a script to use the output of “who” to populate the globalconfig.xml file in /home/username/.italc; if I have time I will add the script to my install italc instructions.

The Issue

Currently the only method of accessing LTSP from a wireless device (e.g. laptop) is by running the local operating system and installing NoMachine on the client. It would be extremely useful to boot laptops directly into LTSP.

The Options

The following two pages would seem to outline the possibilities:

• http://www.ltsp.org/twiki/bin/view/Ltsp/WirelessLtsp
  • http://www.ltsp.org/twiki/bin/view/Ltsp/WirelessLTSPClientsUsingAnEthernetBridge

I cannot help but conclude that, time being an important factor, the Ethernet Bridge option is the sensible course to take.

Proof of Concept

As it happened, I had an old Lucent Wireless Ethernet Converter, sadly only a 10-base-T model. I configured it with a static IP address, and attached it to my laptop’s network port. Rebooted my laptop and, joy of joys, it immediately PXE booted. Unfortunately it was painfully slow, so a better device is clearly required.

Possible Wireless Bridges

• ASUS WL330GE Wireless Access Point
• Linksys model number WET54G
• Belkin Wireless G Ethernet Adapter F5D7330uk
• Buffalo Wireless Ethernet Controller WLI-TX4-G54HP-1

After initially opting for the Belkin, I ended up opting for the Buffalo, largely off the back of some decent reviews.

Buffalo Wireless Ethernet Controller

My Buffalo Wireless Ethernet Controller WLI-TX4-G54HP-1 arrived today, so I eagerly installed it at home. As usual there is no configurator for Linux, so you have to use the web-admin page, this requires you to connect via a wired port configured for the same network 1.1.1.0/24. Once done it was very simple to configure - I gave it a static IP (not sure whether that was really required) and rebooted into Edubuntu.

Very straightforward, but the performance, whilst infinitely better than my old Lucent Ethernet Converter described in my Proof of Concept, was less than stunning. Launching Gcompris, struggled with the music, but once the music was switched off the moving images and sound seemed fine. Gnome seems a little sluggish at times, but probably quicker than my ageing Dell Inspiron 8200 is normally!

I guess I would describe performance of Edubuntu via Wireless as satisfactory - but if you require sound/video I think you’ll struggle. That said it is a useful additional method of accessing LTSP and will no doubt have its place at work, e.g. adhoc workstations.

References

• http://www.ltsp.org/twiki/bin/view/Ltsp/WirelessLtsp
  • http://www.ltsp.org/twiki/bin/view/Ltsp/WirelessLTSPClientsUsingAnEthernetBridge
• http://www.lug-kr.de/wiki/ThinClientLokalBooten
  • http://translate.google.co.uk/translate?u=http%3A%2F%2Fwww.lug-kr.de%2Fwiki%2FThinClientLokalBooten&sl=de&tl=en&hl=en&ie=UTF-8

Something that we have become used to having under Citrix is the ability to shadow users, and I have been missing this since our forays into LTSP. I know it is possible, and I have been attempting to use the KDE built-in Krfb Desktop Sharing module. The problem with this has been that, all users being on the same hardware, it’s difficult to know to which screen number to connect. I guess there probably is a way, but when I used trial and error to find the right display, the performance was less than impressive.

So I decided to follow the masses and install x11vnc on the client, but suffice don’t have it working yet!

You may recall my recent installation of Edubuntu at home. Well I was surprised to find that the Thin Client Manager, AKA the Student Control Panel, missing. I Googled without joy, and ended up finding that thin-client-manager-gnome needed to be installed via Synaptic. I reported this at #edubuntu and ogra informed that they have replaced this with iTalc. I therefore removed thin-client-manager-gnome, but again I could not find any reference to iTalc in the menus. Again I Googled fruitlessly and again the solution was as simple as installing italc-master (the client was already installed). And it worked, straight off including screen shadowing.

Now all I need to do is to work out how to install iTalc on Etch! Perhaps not. At least not just yet.

My Buffalo Wireless Ethernet Controller WLI-TX4-G54HP-1 arrived today, so I eagerly installed it at home. As usual there is no configurator for Linux, so you have to use the web-admin page, this requires you to connect via a wired port configured for the same network 1.1.1.0/24. Once done it was very simple to configure - I gave it a static IP (not sure whether that was really required) and rebooted into Edubuntu.

Very straightforward, but the performance, whilst infinitely better than my old Lucent Ethernet Converter, was less than stunning. Launching Gcompris, struggled with the music, but once the music was switched off the moving images and sound seemed fine. Gnome seems a little sluggish at times, but probably quicker than my ageing Dell Inspiron 8200 is normally!

I guess I would describe performance of Edubuntu via Wireless as satisfactory - but if you require sound/video I think you’ll struggle. That said it is a useful additional method of accessing LTSP and will no doubt have its place at work, e.g. ad-hoc workstations.

Then one user, running a simple shell application using kdialog, started seeing kdialog sessions spiralling wildly out of control, in the end we had hundreds, possibly thousands, of kdialogs running. It transpired that the application was supposed to talk to the user’s scanner, but couldn’t and therefore kept forking another error message ad infinitum.

So the day ended with two additional items for my to-do list:

1. Fix scanning
2. Sort out Windows load

On the plus side I did manage to get somewhere with a long-standing issue of open multipage tiffs in kde.

Tonight I installed edubuntu-desktop from the Edubuntu add-ons CD - didn’t take very long and very pretty it was too, once I rebooted.

Next I wanted to see if I could get my laptop working wirelessly. I had an old Lucent Wireless Ethernet Converter, sadly only a 10-base-T model. Configured it with a static IP address, and attached it to my laptop’s network port. Rebooted and, joy of joys, it immediately PXE booted off the Edubuntu server.

Unfortunately it was painfully slow, but nevertheless a great proof of concept for Wireless access to LTSP.

Now I just need to order a decent modern Wireless bridge and hopefully we’ll have decent wireless LTSP!

Having a brand new HP ML115 Server which I bought new for £107, I decided to have a play with Ubuntu LTSP at home. Actually I decided on Edubuntu, as I wanted to investigate the thin client management which I believe are included.

I downloaded the Ubuntu Alternate CD and burned it to disk. I booted the server onto the CD, missed the fact that I needed to hit F4 Modes and select LTSP before selecting install, whereon I wasted an hour installing Ubuntu-ordinaire.

Second attempt was pretty straightforward, but, only having a single network card, it warned me to edit /etc/ltsp/dhcpd.conf. Booted into Ubuntu without a problem and opened my router’s web interface and cribbed the DHCP settings and DNS settings into /etc/ltsp/dhcpd.conf. Switched off the DHCP on my router. Set-up the server static IP address via the Gnome network manager. Restarted DHCP with /etc/init.d/dhcp3-server restart.

Tested a client and got the “workstation not authorized”.

Ran sudo ltsp-update-sshkeys and sudo ltsp-update-image, rebooted the client and it worked beautifully, by which I mean that the laptop’s full 1600x1200 resolution was detected, and sound kicked in immediately.

So, even with the false starts, I managed to install a working Ubuntu LTSP server with all the bells and whistles in two and a half hours. And I could have done it at least an hour quicker than that. I know Ubuntu come in for some criticism, but that really is impressive usability. To be fair, I was helped by having knowledge of LTSP, DHCP, and Debian, but supposedly a second network card would have enabled the whole kit-and-kaboodle to work out of the box.

Tomorrow I will have a crack at installing the Edubuntu-Desktop!

Good night.

Having agonised about the correct version of LTSP to install, chosen the wrong one, and upgraded, I thought it would be worthwhile to type up my thoughts on the subject. There are two versions of LTSP currently available:

• LTSP4.2
• LTSP5

If you visit the LTSP website, then you can’t help but notice that all the information is on LTSP4.2. If you do some Googling about LTSP5, you will quickly determine that LTSP5 is full of problems, at an early stage of development and best avoided.

Wrong, wrong, wrong. You are just about to make a mistake.

In fact LTSP5 is the current version and has been since 2006. Indeed, if you try and seek any help in respect of version 4.2, and you will invariably get the response - “LTSP4.2 is obsolete, unmaintained and you are an idiot to have installed it”.

Okay I exaggerate, but not by much! If you do install 4.2, at some point you are going to want to update the client. Well that requires LBE (read the Wiki for details) - then you will hit the problem that LBE is broken and will not install. You’ll ask for help and the response you will receive is pretty much as above.

Good luck sorting that little problem out, for myself I upgraded to LTSP5 (see LTSP5 Upgrade) and I have never looked back. The client is up-to-date and configurable, the local devices work, sound works, and little fluffy bunny rabbits nibble the grass while the sun shines.

In short all his just fine and dandy in the world of LTSP5. Always assuming it’s been packaged for your distro, it has for Debian and Ubuntu, for the rest you’ll need to make your own enquiries.

What you can expect from LTSP4.2

Positives

A working reliable system. Sound (see LTSP4.2 Sound). Local Devices that appear on the desktop when you plug them in. Works particularly well for older clients (Pentium II with 32mb RAM).

Negatives

Expect to fight any PC built in the last two or three years. Expect to have battles getting sound working on your clients (usually solvable, usually you have wounds to lick afterwards). I am told that USB keys don’t work quite as well, although I never found any problem in this area. Indeed I managed to get USB keys working better under LTSP4.2 than I have subsequently managed to do in LTSP5.

What you can expect from LTSP5

A system that pretty much works as you expect. Sound was simple to configure and works well. Scanning took a little bit of working out - see LTSP Scanning. Local devices work just fine (with the exception of some incorrectly partitioned devices). The client system works very well, although I am still learning exactly how it all hangs together. Newer PCs work perfectly, and all but the oldest PCs seem fine. The ones I did have to get rid of were no great loss; but if you feel differently then I understand it is technically possible to install LTSP4.2 and LTSP5 on the same server, and get the benefits of each. You’ll need to search the LTSP Mailing List to find out how.

I understand that it is even conceivable to deliver a full-blown desktop client system - although you need LDAP on your network to enable client logon. Again, search the LTSP Mailing List for details.

I can’t believe a week has passed, with no blog entry. Apologies.

This week I have added my About Linux and About Windows pages, including Why Linux and Protecting your Windows PC. I hope that these pages will help users to recognise the issues running Windows systems and consider using Linux instead. I have also moved my Windows for Linux page under the About Linux. Still don’t think I have the site layout quite right yet, so don’t be surprised if they all move around again!

This week has seen a big push to get our last Windows users over to LTSP. It’s gone pretty well, although we still have problems printing to our Konica Minolta C250 photocopier. I have three users remaining, all three of which will prove the greatest challenge, but also the greatest opportunity - in some ways they have the most to gain from Linux. They just don’t know it yet!

Since upgrading to LTSP5, our scanning has ceased to work. I have created a Work in Progress page called LTSP5 Scanning. Having worked through the instructions contained on that page, scanning is still not working. The logs show that the request scanimage -L is being detected by the client and the client is confirming that the LTSP server has permission, but it is then failing with:

Jun 24 12:16:55 juno scanimage: unable to open /var/run/hplip/hpssd.port: No such file or directory: prnt/hpijs/hplip_api.c 94
Jun 24 12:16:55 juno scanimage: unable to connect hpssd socket 50002: Connection refused: prnt/hpijs/hplip_api.c 719

Not realising that HP had any involvement in scanning on Linux, I assumed that this was a port conflict with some utilities installed on our HP server, but reading into the matter further I believe that this is because the client has detected that the scanner is an HP model and has attempted to run an HP scan utility that is not installed on the client. Just guesses, if you have any ideas, please contact me. Any useful messages will be posted here!

What is the Linux Terminal Server Project (LTSP)

If you come from a Windows background, you may be familiar with Windows Terminal Services and/or Citrix. Windows Terminal Services basically enables users from different clients to connect to servers and work concurrently on them using the RDP (Remote Desktop) protocol. Perhaps you’ve connected to your work PC using Remote Desktop - it’s the same thing, just Terminal Services just allows multiple users to connect concurrently. Citrix is just the same, but uses the ICA protocol.

Big Deal. All Linux machines are inherently multi-user machines and all Linux machines can accept concurrent connections, either using X directly, or using ssh -XC ~serverip~ (the -X switch enables the X-forwarding so that you have a GUI and the -C switch compresses the data stream which generally improves performance, particularly over low-bandwidth connections).

LTSP goes a massive step further, in that it actually serves a complete operating system to the client. This means that the client hardware does not require a host operating system, or even a hard drive; instead the client PXE boots over the network, downloading the operating system, installs it, configures it, boots it, and finally runs a login manager to provide a secure login to the server.

In contrast, a Windows thin client usually includes a flash disk with a local operating system. LTSP does not need this, all LTSP requires is a PXE compatible network card and a pretty minimal amount of RAM and CPU (a Pentium II with 64mb is probably the minimum required).

Benefits of LTSP

• Performance
  • LTSP requires around half the processing power - for same performance as Windows Server
    • See Server Sizing for more information
  • LTSP requires around half the memory - for same load as Windows Server
    • See Server Sizing for more information
  • LTSP doesn’t require on-access virus scanning - because Linux is inherently secure
  • LTSP runs fast on Pentium II hardware (say Pentium III for LTSP5)
  • LTSP clients boot fast
• Reliability
  • LTSP will run for longer between reboots - months not weeks
  • PC hard disks can be removed to enable silent running
• Simplicity
  • No host operating system - boots Linux directly over the network
• Functional
  • Attractive modern desktop
  • Copes with sound and video (depending on client hardware)
  • Copes with local CDROM and flash memory (depending on client hardware)
• Cost
  • No need for wholesale PC replacement
  • Hardware-only cost
  • Can afford to over-spec the servers for phenomenal performance

Problems with LTSP

• Requires a fast-Ethernet or Gigabit network - Install FreeNX for serving desktops to remote locations
• Incompatible with Windows applications - see Windows for Linux for guidance

I have had my first user’s password expire since our LTSP5 Upgrade.

1. User enters username and hits enter
2. User enters password and hits enter
3. LDM tells user password has expired enter new password
4. User enters new password and hits enter
5. LDM tells user to verify password
6. User enters new password again and hits enter

And then it enters a crazy loop where it just continually prompts for the password. If you reboot the client you start from the beginning again, so clearly the password change has not been accepted. I confidently told user that he had obviously entered his password incorrectly - I then rebooted the client and did exactly the same myself. I believe this could be a bug, and I suspect it may be related to the following thread:

• ldm problems with debian etch

We have a number of Compaq Deskpro ENSFF P450s for which sound stopped working since our LTSP5 Upgrade. I spent some time this morning solving this problem and have detailed my solution below.

The bulk of the fix was simply changing SMODULE_01 to MODULE_01 in LTS.conf, although this particular PC was a little more involved.

Configure Compaq Deskpro ENSFF for LTSP5 Sound

Introduction

We have a number of Compaq Deskpro EN-SFF P450 PCs. These are small-form-factor Pentium IIIs with Compaq quality. I believe these have the ESS1869 soundcard.

The BIOS settings on our PCs are io=0x220 irq=5 dma=1 dma16=5; your settings may be different!

LTSP4.2

They worked flawlessly under LTSP4.2 with the following LTS.conf configuration:

SMODULE_01         = "snd-es18xx irq=5"

Since upgrading to LTSP5, sound has ceased to function.

Testing

I booted the client and typed [Ctrl]+[Alt]+[F1] to bring up the client console and typed:

# lsmod | grep snd

Which returned nothing, showing that sound was definitely not loaded (no surprise there!).

Next I tried typing:

# modprobe snd-es18xx
ESS AudioDrive ES18xx soundcard not found or device busy
FATAL: Error inserting snd_es18xx (/lib/modules/2.6.18-6-486/kernel/sound/isa/snd-es18xx.ko): No such device

Research

• http://ubuntuforums.org/showthread.php?t=148077

This was not specific to LTSP5, nevertheless it gave a useful configuration:

/etc/modprobe.d/alsa-base

alias char-major-116 snd
alias snd-card-0 snd-es18xx
options snd-es18xx index=0 enable=1 isapnp=0 port=0x220 mpu_port=0x388 fm_port=0x330 irq=5 dma1=1 dma2=0

alias char-major-14 soundcore
alias sound-slot-0 snd-card-0

alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

In particular the following line looked useful:

options snd-es18xx index=0 enable=1 isapnp=0 port=0x220 mpu_port=0x388 fm_port=0x330 irq=5 dma1=1 dma2=0

Still in the client console I typed:

# modprobe snd-es18xx index=0 enable=1 isapnp=0 port=0x220 mpu_port=0x388 fm_port=0x330 irq=5 dma1=1 dma2=0

And the sound module loaded fine. I then ran:

# speaker-test
speaker-test 1.0.13
Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
...

And sound was working fine.

LTS.conf

So obviously all we need to do is to set in LTS.conf and we should be sorted:

SMODULE_01         = "snd-es18xx index=0 enable=1 isapnp=0 port=0x220 mpu_port=0x388 fm_port=0x330 irq=5 dma1=1 dma2=0"

But no joy! Thinking that the issue was with an incompatibility with one of the above switches and LTSP, I experimented with removing all the switches and just adding some back; the aim being to end up with a minimal set of switches that worked. On a hunch I tried:

# modprobe snd-es18xx isapnp=0

And the speaker-test worked. Adding this to LTS.conf

SMODULE_01         = "snd-es18xx isapnp=0"

And it still didn’t work. For some reason, that I cannot find documented, SMODULE is no longer working, and needs replacing with MODULE - thus:

MODULE_01         = "snd-es18xx isapnp=0"

All now working.

Further to my recent post, it transpired that rdesktop uses /dev/dsp which is incompatible with alsa. Specifying “oss” as the sound driver, instead of the default, worked fine.

$ padsp rdesktop -r sound:local:oss 192.168.0.1

This is apparently because rdesktop version 1.5 does not support alsa, but still uses /dev/dsp as the sound device. A new version 1.6 of rdesktop is now available (albeit not in the debian etch or etch-backports repositories), which should address this issue. Unfortunately we are using a patched version of rdesktop, provided by fontis, and I know they were struggling to integrate their patches into the latest versions. I should probably attempt to contact them at some point.

This also represented my first attempt at using IRC #ltsp - which proved invaluable. Installed Konversation, as I could not get on with Kirc.

Today I discovered that since our upgrade to LTSP5, sound has stopped working in rdesktop sessions. Worse, it bombs users out of their Windows session with the error:

rdesktop: pcm_params.c:2351: sndrv_pcm_hw_params: Assertion `err >= 0' failed.
Aborted

Under 4.2 it was working beautifully simply by prefixing rdesktop with esddsp, e.g.

$ esddsp rdesktop -r sound:local 192.168.0.1

But removing esddsp or replacing with padsp causes exactly the same error message. I suspect with alsa the esddsp/padsp fix is no longer required, but why does it not work?

I have even tried pointing padsp at the client pulseaudio device…

$ padsp -d -s 192.168.0.41:4713 -n rdesktop rdesktop -r sound:local 192.168.0.1

I have posted this as a question on the LTSP Mailing List and am hopeful of a solution!