r98 - 26 Oct 2007 - 13:19:21 - PetreScheieYou are here: TWiki >  Ltsp Web  > WorkInProgress

Work In Progress

* Cleanup Notice * It has been suggested that this page is too long and too diverse and that the contents be moved to other pages. For example, several parts could be moved to the existing Scanner and local device pages.


NX client: I have done some preliminary work to incorporate NoMachine's NX client into LTSP, to provide a secure and compressed X connection, either to an LTSP server running NX or freeNX server or to another application server running the same. The following package should work, but it is not yet worthy of official incorporation into the LTSP core.

I am looking for testers! So, if you have a working NX or freeNX server, please give this a whirl. The tarball has a README file that will explain how to get everything set up.

Download here: http://sourceforge.net/project/showfiles.php?group_id=110959&package_id=134524&release_id=279804

NOTE: IF you are using this package under LTSP 4.2, you have to make one small change in /opt/ltsp/i386/etc/screen.d/startnx (this will be incorporated into a newer package as soon as I come up for air wink ):

 Edit /opt/ltsp/i386/etc/screen.d/startnx and change the line that
 TTY=`/usr/bin/basename \`/usr/bin/tty\``
 TTY=`/usr/bin/basename \`/usr/bin/tty\` | sed s/tty//`


1) in /etc/screen.d/startnx remove any reference to /dev/ram* and change
setenv HOME=/root
on the top to :
setenv HOME=/tmp

2) in /usr/bin/startnx change
setenv USER_NX_DIR=/root/.nx
to read
setenv USER_NX_DIR="$HOME/.nx"

**Special thanks to Ondrej Valousek for these last 2 steps...

-- GideonRomm

One important feature left out..In lts.conf you have the option of specifying a different server, even one outside your network,assuming you have provided the workstation with both a gateway (option routers) and a valid client.id_dsa.key from that server.So sitting at a thin client behind a firewall you can get a desktop from a server in Taiwan. SCREEN_01= startnx cliebow@ltsp.org

NX in Breezy and Dapper

useful url http://www.ubuntuforums.org/showthread.php?t=156019
sources.list add-ons for breezy
deb http://mirror3.ubuntulinux.nl/ breezy-seveas freenx
deb src http://mirror3.ubuntulinux.nl/ breezy-seveas freenx

sources.list addon for dapper
deb http://free.linux.hp.com/~brett/seveas/freenx dapper-seveas freenx
apt-get install each of these..
freenx version 0.4.4+0.4.5-3ubuntu0
nxclient version 1.5.0-141
libxcomp1 version 1.4.92+1.5.0-4ubuntu0
libxcompext1 version 1.4.92+1.5.0-4ubuntu0
nxagent version 1.4.92+1.5.0-4ubuntu0
nxdesktop version 1.4.92+1.5.0-4ubuntu0
nxlibs version 1.4.92+1.5.0-4ubuntu0
nxproxy version 1.4.92+1.5.0-4ubuntu0
nxviewer version 1.4.92+1.5.0-4ubuntu0
I had to manually get nxproxy and install with dpkg -i. Should be 12 pieces in /usr/lib/nx. Nxdesktop seems to install to /usr/bin so ln -s /usr/bin/nxdesktop /usr/lib/nx/nxdesktop.That should make 13 packages now in that directory. Run sudo nxsetup..answer no to the abort,yes to the custom key..Be ready to type yes at third prompt or it will crap out.. Grab client.id_dsa.key from /var/lib/nxserver/home/.ssh and use it on your nxclient machine cliebow@ltsp.org

Public and private use of the workstations

In most cases, our workstations (running GNOME) are used by visitors. They use a guest account. But some specials users have an own account. While setting this up we ran into some trouble:
The users with an own account are no problem. They're responsible for their own desktop. The guest accounts are another story. A short summary of the problems we encountered:
1. when users share the same guest account, changes to the desktop on one workstation show up on another.
2. the next guest should always start with fresh environment.
3. guests should log in automatic, without password or whatsoever.

We solved these issues, maybe not in the most elegant way, but it works:

To solve issue 1 and 3 we edited the gdm.conf and we created a script, /usr/local/bin/autologin.sh

in the gdm.conf, we changed the autologin and timed login lines:

   TimedLogin=/usr/local/bin/autologin.sh|     #please notice the pipe at the end of the line

If a user with an own account wishes to log in, he/she can do so during that 10 seconds. After ten seconds the workstation log's in automatic with a user name provided by the autologin.sh script. The first part of that script looks (in our case) like this:

   case "${DISPLAY}" in
        "cerberus_b1.cerberus:0")       LOGNAME=gast1;;
        "cerberus_b1.cerberus:0.0")     LOGNAME=gast1;;
        "cerberus_b2.cerberus:0")       LOGNAME=gast2;;
        "cerberus_b2.cerberus:0.0")     LOGNAME=gast2;;
        *)                              LOGNAME=gast
                                        echo $LOGNAME
                                        exit 0
   echo $LOGNAME

So for each workstation we can control which guest account will be used. Issue no 2 is solved as follows. I created a account gast0 and tweaked this one the way I wanted the guest account to look (a custom toolbar and background). Next I created a number of guest accounts (gast1 ... gastXX). There home directories are removed by the next part of the autologin.sh script and recreated like my gast0 account. The second half of the script looks like this:

   pkill -9 -u ${LOGNAME} # to clean up running processes from a previous user

   NEWHOME=/home/${LOGNAME}   # maybe better to get this value from /etc/passwd
   rm -fr ${NEWHOME}
   mkdir ${NEWHOME}

   cp -rp /home/gast0 ${LOGNAME}
   # the next two lines are to change some pathnames for applications and for gtk
   # if you setup for instance OpenOffice in your gast0 account you have to add more lines
   # You can find files to change with:
   #     cd /home/gast0
   #     for x in `find .`
   #     do
   #            grep gast0 $x >/dev/null 2>&1 && echo $x
   #     done

   sed -e '1,$s/gast###/${LOGNAME}/g' /home/gast0/.amsn/config.xml \
   sed -e '1,$s/gast###/${LOGNAME}/g' /home/gast0/.gtkrc-1.2-gnome2 \

   # and the last action
   chown -R ${LOGNAME} /home/${LOGNAME}

These scripts are not exactly the same as we use them, but could be a guideline for a similar situation. If you make a autologin.sh script like this one, please test it and make sure the only output you get is the username. The output is used by GDM to detemine the TIMED_LOGIN user, so you don't want any crap coming out of the script.
If you've any questions, please mail me.

-- MarkLeeuw - 03 Jan 2005

To make Mark's autologin example work you may also need to change the following directive in your gdm.conf, you can find it under the [security] section:

# This will allow remote timed login

-- NetRix - 12 Feb 2005

The GDM that is shipped with Fedora Core 5 (used in K12LTSP version 5) is broken, such that all thin clients will display, on their login screens, "/usr/bin/autologin| will login in X seconds". When the timer gets to zero, those clients that should autologin will do so, but those that should not will go black briefly and then the GDM greeter will restart with a bit of an initial 'jump & wiggle'. This doesn't hurt anything but it's annoying to look at, and isn't the way it should work. Andrew Ziem provided a patched GDM in RPM format that fixes this problem. A How-To for setting up autologin with this patch GDM is available on the K12LTSP wiki.

-- PetreScheie - 22 Nov 2006


This is a package to create a secure (via ssh) connection in which to wrap X traffic. The idea is that this client will ssh into the server and execute a command such as "gnome-session" which will push a desktop back to the terminal, but wrapped in ssh, so the username/password are not sent via cleartext over the network.

This project is really immature, so DO NOT USE IT for anything but development and testing.

The package can be found here: http://prdownloads.sourceforge.net/symbiont/securex_LTSP.0.2.tgz?download?

...and here is a secure console package:

-- GideonRomm

Bootsplash Patch for LTSP

I have made a patch for the LBE that adds bootsplash to the kernel. Take a look at this page: BootsplashPatch

-- RasmusOryNielsen - 31 Jan 2005

NOTE the bootsplash integrated into LTSP 4.2? Sometimes, I see a framebuffer penguin above the kernel messages.


For information about LTSP 4.2 where SANE has been integrated, see the page Scanners.

There are two ways to use scanners attached to terminals.

Gideon Romm's packages

Here is a link to some packages that will enable scanners on your thin client. These have been created with the LBE, so hopefully will be incorporated in future releases. There are a few files that you will need to edit in addition to just untarring the files. Click on the LTSP Scanners link on the page for more details.

This is hot off the presses, so please send feedback to me at: support at symbio-technologies dot com


-- GideonRomm - 23 Feb 2005

Peter Ehrenberg's scanner packages

See Scanner Access Now Easy for Linux Terminal Server Project 4.1.1.

Local Dev with USB sticks


Here is a package that slightly modifies the 4.1 localdev system to support USB sticks. This will be obsoleted once hotplug gets incorporated into the LTSP tree and a more proper approach is taken, but it works for me. smile


-- GideonRomm - 01 Mar 2005


Here is a file that I have written to replace $LTSP_DIR/i386/sbin/hotplug . I found that the script that currently ships with LTSP 4.1.1 did not work completely for some of my devices. This one adds, I hope, improved support. Please send me feedback if you have a chance to test this!

  • hotplug: Hotplug v. 0.5 - added support for USB sticks that report bad partition tables

-- GideonRomm - 07 Oct 2005

LTSP-4.2 using LTSPFS

LTSP-4.2 hasn't been released yet, but a powerful new feature is the local device support using something we call LTSPFS.

LTSPFS is a new FUSE based filesystem that gets around most of the problems associated with removable devices. You can read all about it at LtspFS.

-- ScottBalneaves - 20 Feb 2006

Palm Pilots

See the page PalmPilots.

SSH keys stored in USB memory

There was an excellent thread on the debian-devel mailing list in March 2005, regarding using a USB device to store SSH and GPG keys. There also was a script for part of it, and a discussion of the issues. one of the messages in the thread is:



Thanks to Jim Gettys for bringing this to my attention

Client Web Server based on tserver

Tserver (Andrew Tridgells tiny web server) install and usage instructions are here.

-- DarrylBond - 28 Mar 2005

-- JimMcQuillan - 14 Mar 2005

More on local devices

NOTE This section on LDA obsolete as of LTSP version 4.2 because Samba is no longer used.

There is a quirk that some of you may come across where removable media may appear on the server side as files rather than directories. This occurs because when the media is supermounted on the thin client, the mountpoint has a filesize of zero before it is accessed. Samba, in turn, reports anything with zero filesize as an empty file to the server.

The solution would be to access the media on the client immediately after supermount mounts the media. A means for doing this will eventually be integrated into the removable media scripts. But, until that happens, you can try placing this rc.localdev2 file in $LTSP_DIR/i386/etc/rc.d/ and placing an RCFILE_01 = rc.localdev2 in your lts.conf. Hope that helps!

* rc.localdev2: A little patch script to ls a dir when supermounted

-- GideonRomm - 22 Apr 2005

I've found that this rc.localdev2 script doesn't really work because it has to be launched in background. You can use it by moving it in another directory, for example $LTSP_DIR/i386/usr/bin, making sure to give it exacutable rights, and create a rc.localdev3 script (remember +x perms) with the following content:


cd /tmp && nohup /usr/bin/rc.localdev2 &

Then put the new rc.localdev3 file in the RCFILE_XX entry of lts.conf instead of rc.localdev2.

The nohup command turn the script into an init child when the caller shell exits, so the script can run in background like a daemon. Unluckily there isn't the nohup executable in ltsp, and so you have to copy it from your server. It shouldn't depend to any external library but libc.

-- NicolaGigante - 16 Mar 2006

There is still something wrong with it but it is going to work.

-- NicolaGigante - 17 Mar 2006

CDRom Polling

NOTE This section on LDA obsolete as of LTSP version 4.2 because Samba is no longer used.

A mechanism for polling for the status of a CDROM drive. A program polls the device every 2 seconds, if a disk has been inserted a script is run to create the directory and mount the CD using supermount. If the disk is ejected, the script unmounts the CD and deletes the directory.

  • cdstatus.c: Source for cdstatus
  • cdstatus: Binary for cdstatus
  • rc.localdev: Startup file for local devices using cdstatus
  • cdrom: Shell script placed in /usr/sbin to mount/umount the CDROM

The cdstatus program daemonises properly and logs events to syslog

-- DarrylBond - 30 Nov 2005

Local CD Burning

I've just begun to get this working. You need to install smake in lbe-src and cdrtools in ltsp-src. Then you can burn CD's on the client by including the appropriate modules in the kernel. In my case, I need ide-generic and ide-cdrom. Then you need an ISO image file. The cdrtools don't know how to burn a directory tree. It needs to be made into an ISO image first. The cdrtools includes mkisofs for this purpose, though I wouldn't recommend running it on the client!

* smake.def: smake package.def file for use with cdrtools

* cdrtools.def: cdrtools for use with local cd burning

By the way, the Perl LWP module used to fetch packages doesn't seem to work with these. You will probably have to fetch them manually and place them in lbe/tarballs.

I used the 2.6.9 kernel and an IDE CD-RW, using the following cdrecord command: cdrecord -dev=ATA:1,1,0 speed=12 /path/to/file.iso

See LocalCDWriting for more details. -- MischkO - 23 May 2005

Hotplug in 2.6.9 kernel.

My work is focused on the 2.6.9 kernel and USB is a biggie for acceptance of LTSP in our organization. I've been working with hotplug and found a couple things of note.

  • http://linux-hotplug.sourceforge.net/?selected=usb has some useful information. The important thing for us is that there are now TWO kinds of hotplug USB events: device, and interface. The 2.6.x kernel calls hotplug 5+ times for each device insertion so it gets messy! The way to tell what you have is whether or not a PRODUCT environment variable. If so, it's an interface event. In my experimentation, I've found that these are the only events we need to worry about so I check for the presence of the PRODUCT variable and exit if it's not there (just after the logger logs the relevant variables for debugging purposes). I have the logger include the hotplug PID with each log so that I can sort out the mess.

  • Need sysfs. I modified rc.localdev by adding these lines to take care of adding sysfs if it's a 2.6 kernel and if it's not already there:

if grep -q 'sysfs' /proc/filesystems; then
   echo "Mounting sysfs on ${SYSDIR}..."
   if [ ! -e ${SYSDIR} ]; then
      mkdir ${SYSDIR} || exit;
   mount -n -t sysfs sysfs ${SYSDIR} >/dev/null 2>&1

  • /proc/scsi/scsi is empty when the remove events are fired. I've checked immediately at the beginning of the hotplug script for the contents of /proc/scsi/scsi and it's essentially empty on all remove events. It appears that the 2.6 kernel is removing the relevant information from the /proc/scsi/scsi file immediately upon the device being pulled from the machine. Hotplug relies on the contents of this file to know which device to work on at any given event. This is leading me to the idea of logging the relevant information in a /tmp/drives/.hotplug/notes directory, at the time the USB device is inserted, so it's readily available when the drive is pulled.

I need feedback from Gadi and others who are familiar with this to know if I'm missing anything relevant.

-- MischkO - 26 May 2005

  • localdev.tgz: Files needed for proper USB stick functionality 4.1.1

Local Window Manager

  • It seems much easier to manage local applications if the window manager is running locally. Matchbox windowmanger works fine locally. So does icewm provided the source from the ThinStation? project is used.
  • I have written the usage details and kept the binaries for the 4.1.1 version at http://wiki.ltsp.org/twiki/bin/view/Main/LocalWindowManager

Linux Terminal Server / Windows Terminal Server - select menu at boot

When the need to connect to a windows terminal server arises, many users have logged into the LTSP server and then run rdesktop to connect to the windows server.

The problem doing this is that the rdesktop client is running on the ltsp server and adding a small but unecessary load on the LTSP server. The startx_rdesktop_menu screen script will allow users on boot to select whether they want to connect to Linux or Windows. This needs to be placed into /opt/ltsp/i386/etc/screen.d/ with the same permissions as the other screen scripts in the directory.

* startx_rdesktop_menu: startx_rdesktop_menu screen script

-- LuisMontes - 15 Aug 2005

LTSP-4.2 upcoming changes

Switch from initrd to initramfs

The switch from initrd to initramfs will simplify the early boot stuff, and it will reduce the amount of ram required on a workstation. In early testing, I've found it uses about 6mb less ram than the older initrd implementation that we have previously to LTSP-4.2. That is a significant reduction in ram if you are considering a workstation with only 16mb or 32mb of ram. Although a method of swapping over the network will still be needed when you have only 16mb, it will still be much better than previous versions.

Diagram of initramfs/nfs layout

Here's a diagram showing the layout of the initramfs, and how the nfs-root fits into the scheme:

  +-- This is the initramfs, mounted by the kernel at boot time.
                   +-- This is a ramfs filesystem that the thin-client
/-+                |   will use as its root filesystem.
  +- bin           |   It contains symlinks to the nfs mounted filesystem
  +- dev           |   that is on the LTSP server in '/opt/ltsp/i386'.
  +- etc           |
  +- init          |
  +- lib           v
  +- mnt
  +- newroot ------/
  +- proc          +- bin     -> nfsroot/bin
  +- sbin          +- dev                             +-- This is the nfs mounted
  +- sys           +- etc     -> nfsroot/etc          |   directory, from the server
  +- tmp           +- home                            |   It is typically
  +- usr           +- lib     -> nfsroot/lib          |      /opt/ltsp/i386
  +- var           +- libexec -> nfsroot/libexec      v
                   +- mnt
                   +- nfsroot  -----------------------/
                   +- oldroot                         +- bin
                   +- proc                            +- dev
                   +- root    -> nfsroot/root         +- etc
                   +- sbin    -> nfsroot/sbin         +- home
                   +- share   -> nfsroot/share        +- include
                   +- sys                             +- lib
                   +- tmp                             +- libexec
                   +- usr     -> nfsroot/usr          +- root
                   +- var                             +- sbin
                                                      +- share
                                                      +- usr

The basic sequence in the /init script is:

   1. Create a mount-point for the ram-based root filesystem:

        mkdir /newroot

   2. Create the new ram-based filesystem and mount it

        mount -n -t ramfs none /newroot

   3. Create a mountpoint for the NFS filesystem

        mkdir /newroot/nfsroot

   4. Mount (via NFS) the /opt/ltsp/i386 directory from the LTSP server

        mount -n -o nolock,ro  /newroot/nfsroot

   5. Create the subdirectories in the ram-based filesystem

        for i in dev home mnt oldroot proc sys tmp var; do
          mkdir /newroot/$i
   6. Create the symlinks pointing to the things we need from the NFS-mounted filesystem

        for i in bin etc lib libexec root sbin share usr; do
          ln -s /nfsroot/$i  /newroot/$i

   7. Change the current directory to the ram-based filesystem

        cd /newroot

   8. Do the 'pivot_root', to make /newroot become the root filesystem for this

        /sbin/pivot_root . oldroot

   9. Free unused ram being used by the initramfs by deleting the files in the initramfs:

        for i in usr bin etc lib var sbin dev init lost+found oldroot proc root tmp; do
          rm -rf /oldroot/$i

  10. Mount /proc, /sys, and start udev

  11. Run /etc/rc.early_sysinit script, which will create a /etc/inittab file, based on entries in the /etc/lts.conf file

  12. Passes control to init, which runs the rc scripts, which ultimately launch X, and let you log in

        exec /sbin/init

Managing user preferences, configuration, and profiles

Say you want to enable passwordless remote desktop, reduce Firefox disk cache, or require a web proxy? It would be tedious to set this up for each individual account.

Managing user configuration

Sending popup messages to users

For example, you want to send a popup message to all users "System is going down for maintenance in 30 minutes. Please save your work."


General System Setup

These are recommendations for Linux multiuser or terminal server systems. For example, you should not allow any user to reboot the server.


Mouse Autodetection

So you have a lot of thinclient workstations and several mouses, like PS2, USB, SERIAL, with or without WHEEL? How about to forget about setting up this on the lts.conf and autodetect and configure everything on the fly?

I mean... no more:



In order to do this you have to install the mdetect binary on the root of the LTSP, modify the rc.sysinit and the build_x4_cfg script.

1) Install the mdetect on the LTSP root:

Ok. First of all, you need the mdetect. Get it from: http://packages.debian.org/stable/utils/mdetect Here you can find the binary for debian or the source to compile. How to compile the mdetect goes beyond this how to. Is simple.

The mdetect dosen't need any libraries, so you can just put the mdetect binary on /usr/local/bin.

2) Modify the rc.sysinit to use the mdetect:

The mdetect needs to run BEFORE the devfsd is started. So I add the following.


#Creating the necesary devices.
mknod /dev/psaux c 10 1
mknod /dev/ttyS0 c 4 64

#Autodetecting the mouse
/usr/local/bin/mdetect -x >/tmp/mdetect.log

#Erasing the devices created by hand
rm /dev/psaux
rm /dev/ttyS0

#Running the devfsd like always
/sbin/devfsd /dev

If you look close, i don't create the devices for the USB. But you could, to try to detect this. Im currently using mdetect to just configure the wheel or not by detecting the Protocol. But you could just create the USB device with mknod and detect a intellimouse, for example.

When the mdetect finish is task, you should have on the /tmp/mdetect.log something like this:


The first line is the Protocol and the second line is the device. From here you can parse this mdetect.log in the build_x4_cfg and apply what the mdetect discover on the on the xorg.conf

3) Im adding the build_x4_cfg coz I made a lot of changes:

First, i configure every single mouse in the xorg.conf, usb, serial or ps2. So if you plug any mouse, it works. Now i will only use the "Protocol" that the mdetect gives me to set the correct configuration.

You should have something like this:

Section "ServerLayout"
        Identifier "XFree86 Configured"
        Screen      0   "Screen0" 0 0
        InputDevice     "Keyboard0" "CoreKeyboard"
        InputDevice     "Serial Mouse" "CorePointer"
        InputDevice     "PS/2 Mouse" "CorePointer"
        InputDevice     "USB Mouse" "CorePointer"

Section "ServerFlags"
        Option "AllowMouseOpenFail"  "true"

Section "InputDevice"
       Identifier  "Serial Mouse"
       Driver      "mouse"
       Option      "Device"          "/dev/ttyS0"
       Option      "Protocol"        "Microsoft"
       Option      "BaudRate"        "1200"
       Option      "Resolution"      "400"
       Option      "Emulate3Buttons" "off"
       Option      "ZAxisMapping"     "4 5"
       Option      "Buttons"         "2"
       Option      "SendCoreEvents"  "true"

Section "InputDevice"
        Identifier      "USB Mouse"
        Driver          "mouse"
        Option          "Device"                "/dev/input/mouse0"
        Option          "Protocol"              "IMPS/2"
        Option          "ZAxisMapping"          "4 5"
        Option          "Buttons"               "5"
        Option          "SendCoreEvents"        "true"

Section "InputDevice"
        Identifier  "PS/2 Mouse"
        Driver      "mouse"
        Option      "Protocol" "PS/2"
        Option      "Device" "/dev/psaux"
        Option      "Emulate3Buttons" "true"
        Option      "Emulate3Timeout" "70"
        Option      "SendCoreEvents"  "true"

Enjoy! -- GuidoLorenzutti - 07 Dec 2005

X Load Balancing

Based on a conversation with GideonRomm, I've implemented some rudimentary XDMCP-time load balancing. You'll have to patch your startx script and list your application (XDMCP) servers in your lts.conf, but that's it.

I am looking for testers! I've tested a bit on LTSP 4.2, but there's more to be done. Here's how you can help:

Download the patch here (right-click and Save As!): http://wiki.ltsp.org/twiki/pub/Ltsp/WorkInProgress/startx.diff

1) Enable XDMCP on your application server(s). Click XDMCP for instructions.

2) Apply the patch. The following instructions assume you downloaded startx.diff into your home directory:

$ cd /opt/ltsp/i386/etc/screen.d
$ patch < ~/startx.diff

3) Edit your lts.conf to list your application servers. lts.conf is usually found in /opt/ltsp/i386/etc/. You can do either (or both) of the following:

XDM_SERVER         =
SCREEN_01          = startx -query
Of course, you'll want to use the IP addresses of your own application servers instead of, etc.

XDM_SERVER will apply to all "startx" screens; "SCREEN_## = startx -query ..." will override for a particular screen. You should probably just use XDM_SERVER unless you have the need to override for a particular screen.

Don't forget the "-query" if you use the "startx -query" method!

If you want the load balancing to be non-deterministic, set XDM_RANDOM = true in lts.conf.


If you don't want the load balancing algorithm to ping the application server(s) before connecting to them, set XDM_PING = false in lts.conf. (I don't know why you'd want to disable pinging.)

XDM_PING = false

4) Mount /home. You'll probably want to mount your home directories from your fileserver. I recommend NFS for this, doing something like the following:

Edit /etc/exports on your fileserver (which may be your "main" LTSP server) and add a line like this:

/home,sync) is the network which will be able to mount /home on this server, so modify it for your site.

Edit /etc/fstab on each application server (except the one that's exporting /home, if one of them is) and add a line like this:     /home   nfs     defaults        0       0 is the IP address of the server that is exporting /home, so modify this for your site. Then type 'mount -a' or reboot.

Note: This will mount the remote /home directory OVER the local /home directory, so you will not be able to access pre-existing contents in the local /home while the remote directory is mounted.

5) Configure single-sign-on. Your users will need to authenticate to whichever application server their thin clients choose, so you'll probably want to use LDAP or NIS to centralize your user authentication data. OpenLDAP? is recommended for this purpose, and my (self-plug, beware!) smbldap-installer can simplify this configuration: http://majen.net/smbldap/.

Substitute "ppc" (or whatever your thin clients' architecture is) for "i386" above, as necessary.

How it works: Each thin client extracts the numbers from its MAC address and does a modulus by the number of specified application servers. If the selected server answers a ping, the thin client attempts to start an XDMCP connection with the server. If the selected server fails to answer a ping, it is removed from the thin clients list of available servers and a new modulus is performed based on the newly shortened list of servers.

The algorithm is deterministic (if XDM_RANDOM is not set to "true") because each thin client always uses a modulus of its MAC address to select from among the available servers. Therefore, if ThinClientA? selects the third-listed server out of five total, then it will always select the third server out of five.

Setting XDM_RANDOM = true tells the load balancing algorithm just to choose from the list of servers at random until it finds one that answers a ping.

Best Practices: Use regular ISC DHCP server failover (See http://www.madboa.com/geek/dhcp-failover/ or just Google) for a fault-tolerant pair of boot/root servers. Set up as many application servers as you like and use X load balancing as described here, and you should have an extensible, fault-tolerant, load-balancing LTSP solution!

-- MattOquist 24 July 2006

esd+ALSA sound on LTSP 4.2

Some of you may find that when you go from LTSP 4.1.1 to LTSP 4.2, sound either no longer works, or you have some clients that you know have drivers for Linux, but you still cannot get them going. Perhaps they are newer clients with newer sound drivers?

Part of the problem may be that LTSP 4.2 started pushing the 2.6 kernel back to the thin client, and while the 2.4 kernel used OSS drivers by default, the 2.6 kernel uses ALSA drivers. Thus, any manufacturer taking the time to write sound drivers for Linux today, will most likely produce only an ALSA driver and not an OSS one.

If you find yourself in this dilemma, then this package is for you. Download it, unpack it, and run "install" as root, and after a few easy questions, your thin clients will start enjoying esd sound using the ALSA sound drivers. An added bonus, is that ALSA drivers tend, IMHO, to produce better sound, and do provide for more complex control of the soundcard, should you have a need for a more rich audio experience.

Latest release: http://downloads.sourceforge.net/symbiont/LTSP-esd-alsa_1.0.0-2.tgz?use_mirror=osdn

All releases:



-- GideonRomm - 11 Jan 2007


NOTE: I just updated this package today (August 21, 2006). With some testing help from David Trask, I fixed two troublesome issues with esd. One was sound problems in flash and mplayer, which were due to esd not releasing its lock on the audio device and remedied with a "-as 1" flag in rc.sound. The second, was an issue that came up a lot on the listserv where the first user gets sound, but the second does not. For this, I cheated, and rerolled esd with an inability to lock the audio stream to any user. This alleviates the issue, but could pose a security concern. It's a temporary band-aid until a more secure fix can be made and tested.

-- GideonRomm - 28 Jul 2006

Some Dell Latitude laptops come with a Maestro3 sound chip that won't work with LTSP's stock ESD binary. To make sound work, I had to install the LTSP-esd-alsa package above, AND modify the /opt/ltsp/i386/etc/audiolist-alsa file, changing

125d:1998 snd-es1968


125d:1988 snd-maestro3

-- PetreScheie - 09 Nov 2006

This has been fixed in the latest package.

-- GideonRomm - 11 Jan 2007

If you're using ISA Sound Blaster cards, change the line in lts.conf from

SMODULE_01       = "sb io=0x220 irq=5 dma=1"
SMODULE_01       = "snd-sb16 irq=5"

-- PetreScheie - 06 Mar 2007

Unpartitioned USB Stick LTSP 4.2

The localdev that is shipped as of LTSP 4.2u2 lacks support for unpartitioned USB sticks. The following two changes adds such support:

1. Edit /opt/ltsp/i386/etc/udev/rules.d/15-ltsp-block.rules : Add the following line to the "# USB Pens" section:

KERNEL=="sd[a-z]",      RUN+="/etc/udev/scripts/ltsp-device.sh %s{size}"
2. Edit /opt/ltsp/i386/etc/udev/scripts/ltsp-device.sh : Add the lines preceded by the "+" sign (removing the '+' sign before adding):
   /dev/*/part*)      LTSP_DEVTYPE="disk"
+  /dev/sd*)          LTSP_DEVTYPE="disk"
+                     ;;

-- GideonRomm - 31 Jul 2006

LTSP via OpenVPN?

This is the easy way to make all traffic beetwen server and client via OpenVPN?. I used Ubuntu DapperDrake? 6.06.

-- MarcinKuk - 17 Sep 2006

LTSP 4.2 - RDP+localdev

Here is a package for getting local devices going when you only use rdesktop as your screen script in LTSP 4.2:


-- GideonRomm - 27 Sep 2006

LTSP load-balancer

Some loadbalancing is possible using the advice here : http://wiki.ltsp.org/twiki/bin/view/Ltsp/WorkInProgress#X_Load_Balancing

For more accurate loadbalancing, we must have data about available servers available. If this is what you want, it's possible to use the ltsp-loadbalancer.

The goal is to set the XDM_SERVER variable from a loadbalancer, that returns the optimal server. For more information :

It has been aded to REVU on Nov 17 :

-- FrancisGiraldeau - 7 Nov 2006

Shutdown LTSP terminal using ACPI power button

You can make your LTSP terminal correctly shutdown after pressing the power button, given that your terminal supports ACPI (most modern computers do).

Download acpid-1.0.2-1.i386.rpm or a newer version, from http://sourceforge.net/project/showfiles.php?group_id=33140

Extract just the acpid binary file from the rpm package, because this is the only one you will need, using the following command.

rpm2cpio acpid-1.0.2-1.i386.rpm | cpio -iv --make-directories usr/sbin/acpid
This will extract acpid and create usr/sbin/acpid under your current directory. You just have to copy it to the correct location, with

cp usr/sbin/acpid /opt/ltsp/i386/sbin

Create or copy the file named power.sh in /opt/ltsp/i386/bin

# a sample skeleton for handling ACPI events

if [ $# != 1 ]; then
   exit 1
set $*

case "$1" in
      case "$2" in
         PWRF)   /sbin/init 0
         *)   logger "ACPI action $2 is not defined"

      logger "ACPI group $1 is not defined"

Create the acpi daemon configuration directory with

mkdir /opt/ltsp/i386/etc/acpid

Create or copy the file named acpid.conf into /opt/ltsp/i386/etc/acpid/. This file will configure the acpid daemon in order to trigger the action in case of a power button event.

# This is a sample ACPID configuration

action=/bin/power.sh "%e"

Create or copy the rcacpid file into /opt/ltsp/i386/etc/rc.d. This file will be called to start the acpid daemon from the lts.conf configuration file.

#    /etc/rc.d/acpid
# Starts the acpi daemon
# description: Listen and dispatch ACPI events from the kernel

echo "Starting acpid daemon ..."
/sbin/acpid -c /etc/acpid

Edit /opt/ltsp/i386/lts.conf, and under your terminal configuration, add the following configurations: MODULE_01 = "button", that will insert the acpi button kernel module into the running kernel of the terminal, and RCFILE_01 = rcacpid that will start the acpid daemon that will handle the events and call the power.sh script, to shutdown the terminal.

   MODULE_01 = "button"
   RCFILE_01 = rcacpid

Thats it! The power button should work after rebooting the terminal.

If things do not go as smooth as expected, you can make the following checks, starting from a shell in your terminal:

  • If your kernel is supporting ACPI, look for files and directories under /proc/apci. If this directory is not present, your kernel, or the terminal do not support ACPI.
  • Check if the module "button" is there, with lsmod command. If not, check lts.conf, or call "modprobe button" directly from the shell to see what happens.
  • Calling /sbin/init 0 efectively shuts down the terminal. It should.
  • Check if acpid is running. Use ps -aef | grep acpi and see if the process is running. If it is not, review lts.conf.
  • You can run acpid in debug mode (with -d) directly from the shell /sbin/acpid -d -c /etc/acpid, and press the power button to see if the event is triggered.

PS: You can download the needed files here

-- AntonioMartins - 30 Nov 2006

DHCPD based load balancing

If your LTSP network is successful you will soon find that your single server is over loaded. When that happens you will need to add another server without dividing users in to two subnets. The easiest method is to do DHCPD load balancing. This works on statistical principle that the server which responds fastest is having lowest load. So the server that responds to IP request from client at boot gets the load for that client for the session.

To do this you will:

First you will build a new LTSP server just like stand alone configuration with only change being that server IP should be different. If the first server is then the new server should be Note this is 253! It is recommended that you do this without plugging in the server in to the network.

Second you will edit the /etc/dhcpd.conf file on old (master) server as per example given below and restart the DHCPD service on old server by command "/etc/init.d/dhcpd restart"

Third you will set up first server to "export" home directories by adding the following line in /etc/exports and restarting NFS by command "/etc/initd./nfs restart"


Fourth you will mount the exported "Home" files from old server in the new server by editing /etc/fstab and adding the following line: /home nfs defaults 0 2

Fifth You will edit the /etc/dhcpd.conf file on new server (slave) as per example given below. After these two edits on new server it is best to reboot the server after plugging it in to the existing network.

Sixth If you have LDAP or any such third party authentication server then nothing further needs to be done excpet you define the authentication mechnism on the new server. However if users authentication is also to be done by new server you can copy the following from old server on to new server: /etc/passwd /etc/shadow /etc/group

This imposes restriction on doing password changes but in absence of independent authentication mechanism this is best way out. It may be possible to run "rsync" with updates regularly between the two servers for these files but I have not tried this yet.

Presto you are ready to go and all users are once again hopefully happy. For more details on how to have load balancing read http://theseus.sourceforge.net/projects/ets/supplemental.html#Supplemental_Information

###DHCP failover and load balancing stuff Master###
 failover peer "ltsp" {
  port 519;
  peer address;
  peer port 520;
  mclt 3600;
  max-response-delay 30;
  max-unacked-updates 10;
  load balance max seconds 3;
  ###Next two lines are important and should be there in master###
  hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:

 ddns-update-style            none;
 default-lease-time           21600;
 max-lease-time               21600;
 option time-offset              19800;
 option subnet-mask ;
 option broadcast-address;
 option routers     ;
 option domain-name-servers;
 option domain-name           "ltsp";
 option root-path             "";
 option option-128 code 128 = string;
 option option-129 code 129 = text;

 shared-network WORKSTATIONS {
   subnet netmask {
   use-host-decl-names      on;
   option log-servers;
   if substring (option vendor-class-identifier, 0, 9) = "PXEClient"
               filename             "/lts/2.4.26-ltsp-3/pxelinux.0";
               filename             "/lts/vmlinuz-2.4.26-ltsp-3";

   pool {
          failover peer "ltsp";
          default-lease-time 21600;
          max-lease-time 21600;
          deny dynamic bootp clients;

###DHCP failover and load balancing stuff Slave###
 failover peer "ltsp" {
  port 520;
  peer address;
  peer port 519;
  max-response-delay 30;
  max-unacked-updates 10;
  load balance max seconds 3;

 ddns-update-style            none;
 default-lease-time           21600;
 max-lease-time               21600;
 option time-offset      19200;
 option subnet-mask ;
 option broadcast-address;
 option routers     ;
 option domain-name-servers;
 option domain-name           "ltsp";
 option root-path             "";
 option option-128 code 128 = string;
 option option-129 code 129 = text;

 shared-network WORKSTATIONS {
   subnet netmask {
   use-host-decl-names      on;
   option log-servers;
   if substring (option vendor-class-identifier, 0, 9) = "PXEClient"
               filename             "/lts/2.4.26-ltsp-3/pxelinux.0";
               filename             "/lts/vmlinuz-2.4.26-ltsp-3";

   pool {
          failover peer "ltsp";
          default-lease-time 21600;
          max-lease-time 21600;
          deny dynamic bootp clients;

-- SudevBarar - 16 Dec 2006

With LTSP5 you don't need the IP adress of the root-path. You can write:

 option root-path             "/opt/ltsp/i386";
-- XavierBrochard - 22 Jan 2007

toggleopenShow attachmentstogglecloseHide attachments
Topic attachments
I Attachment Action Size Date Who Comment
ziptgz secure_console_LTSP.0.1.tgz manage 755.5 K 19 May 2005 - 14:36 GideonRomm a secure console script
elsedef smake.def manage 0.9 K 24 May 2005 - 05:01 MischkO smake package.def file for use with cdrtools
elsedef cdrtools.def manage 0.9 K 24 May 2005 - 05:01 MischkO cdrtools for use with local cd burning
ziptgz localdev.tgz manage 5.0 K 11 Jul 2005 - 16:17 GideonRomm Files needed for proper USB stick functionality 4.1.1
elseEXT startx_rdesktop_menu manage 0.6 K 16 Aug 2005 - 06:17 LuisMontes  
elseEXT hotplug manage 10.9 K 07 Oct 2005 - 15:51 GideonRomm Hotplug v. 0.5 - added support for USB sticks that report bad partition tables
elselocaldev rc.localdev manage 3.3 K 30 Nov 2005 - 04:01 DarrylBond CDRom polling rc.localdev
elseEXT cdrom manage 0.4 K 30 Nov 2005 - 04:23 DarrylBond Script for use with cdstatus CDROM Polling
cc cdstatus.c manage 2.2 K 30 Nov 2005 - 22:54 DarrylBond CDRom polling script and info
elseEXT cdstatus manage 7.4 K 30 Nov 2005 - 22:54 DarrylBond Binary for cdstatus
elseEXT build_x4_cfg manage 6.4 K 07 Dec 2005 - 23:14 GuidoLorenzutti Modified build_x4_cfg to use with the mdetect binary
elsediff startx.diff manage 3.0 K 25 Jul 2006 - 16:42 MattOquist patch for startx script (usually found in /opt/ltsp/i386/etc/screen.d, substitute your arch for i386 if necessary)
elserpm gdm-2.14.9-2.i386.rpm manage 3674.4 K 22 Nov 2006 - 14:46 PetreScheie Patched GDM for FC5 that fixes autologin problems
ziptgz acpi-poweroff.tgz manage 13.6 K 30 Nov 2006 - 22:03 AntonioMartins Files to use for terminal ACPI poweroff button
elserpm gdm-2.16.5-2.i386.ps.rpm manage 3970.3 K 26 Oct 2007 - 13:19 PetreScheie Rebuilt GDM for CentOS?-5/K12LTSP-5EL that fixes autologin problems
Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r98 < r97 < r96 < r95 < r94 | More topic actions
Powered by TWiki
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback