DNA Lounge: Source Code: Diskless Linux Kiosks

Originally I was planning on using cheap laptops to do this: In early 2000, one could obtain refurbished P90 laptops with 800x600 displays and PCMCIA ethernet for around $450 each. I got the above goals (booting read-only, logging in, etc) working with laptops; but it turned out to be a a bad idea.

I came to the realization that laptop hardware is just too flaky. Pretty much everything about a laptop is inferior to a desktop machine, in terms of performance, reliability, and expense: their only benefit is that they run off batteries, and that's not a concern in this application. They're also hellaciously difficult to service: if something goes wrong, you throw the whole thing away and get a new one.

So, we decided to spend a bit more money on the kiosks to get something more reliable: diskless desktop computers for the kiosks, plus external flatscreens. The benefits here are that: the machine itself can be serviced; and if the machine gets toasted, I don't have to buy a new screen too. The screens can be secured such that they are fairly indestructible, and they also have a warranty. Plus, commodity hardware is both cheaper and more reliable than laptop hardware.

Currently, the hardware we're using for the kiosks is:

KDS Radius S-3F 15" LCD screens (1024x768 resolution) which, in June 2001, we bought for around $580.
Custom-welded steel enclosures for the monitors.
Cheap keyboards ($5) and trackballs ($20), screwed down to the enclosure's table.
MSI 6390 motherboard with an Athlon 1200 CPU;
256MB of PC2100 DDR RAM;
Enlight HPC-150-101 150W small form factor power supply;
And (in some cases) enclosures made from $20 worth plexiglass and misc. connectors.

From late 2000 through 2006, these machines ran as "fat client" computers: the machines each ran all of their applications locally, but had no local disks. Everything was mounted via NFS from a remote file server. Users would auto-login as a "guest" user on the client machine, which would run X11, a web browser, a basic GNOME desktop, etc.

As much was mounted shared and read-only as possible; and when the machine rebooted, everything was reset to a default state.

That worked reasonably well for six years, but it was hellaciously complicated. We wasted a lot of time fighting with stupid hardware compatibility problems (e.g., the kernel not liking the onboard NIC, crap like that) and they often ran out of RAM and crashed, especially if someone tried to run a Java applet.

So, these days, they are "thin clients" instead of "fat clients". The back-room server machine (which had been merely the file server for the fat clients) is now a much beefier machine which runs all of the applications for the kiosks. Each kiosk is, essentially, an X terminal. All that the kiosks run locally is an X11 server; the window managers and web browsers are all running on the same remote host. That machine has a 1GHz processor and 1.2GB RAM, which (it turns out) is plenty to run six copies of GNOME and Firefox under the kind of light usage they get in our environment.

_______________________________________________

Here are the steps I followed in creating this system:

Configure a server machine.
Install and configure LTSP.
Customize the kiosk startup sequence.
Configure auto-login.
Configure auto-reset.
Other usability tweaks.

Configure a server machine.

Do a standard "Workstation" install of Red Hat 9. Also install NFS, DHCP, and TFTP.

Create a passwordless user for each remote kiosk you will be using:

groupadd -g 666 guest
useradd -u 1001 -g guest -c 'Kiosk User' -p '' guest01
useradd -u 1002 -g guest -c 'Kiosk User' -p '' guest02
useradd -u 1003 -g guest -c 'Kiosk User' -p '' guest03
useradd -u 1004 -g guest -c 'Kiosk User' -p '' guest04
useradd -u 1005 -g guest -c 'Kiosk User' -p '' guest05
useradd -u 1006 -g guest -c 'Kiosk User' -p '' guest06
useradd -u 1007 -g guest -c 'Kiosk User' -p '' guest07

useradd -u 1000 -g guest -c 'Kiosk User Template' guest-ro
passwd -l guest-ro

Install and configure LTSP.

Linux Terminal Server Project

/opt/ltsp-4.2/i386/

/tftpboot/

Make sure the LTSP installer edited /etc/exports correctly.

Make sure the firewall on the server allows NFS (TCP 111, all UDP) and BOOTP and TFTP (TCP 67, 69, 4011 and 1759).

At this point, when you boot one of the kiosks, it should launch X and show you a login prompt. You should be able to log in as a normal user. If that's not working, repeat until done.

If you need to tweak the X server configuration, it's in
/opt/ltsp-4.2/i386/etc/X11/XF86Config-4.

Customize the kiosk startup sequence.

You can skip this part.

But, if there are any other applications you want to run on the thin clients themselves, you can do that by creating a custom LTSP "screen.d" file. In my environment, I need to run "gpm" on the clients, and for debugging, I also run "sshd". I created this dnakiosk file, which is installed in /opt/ltsp-4.2/i386/etc/screen.d/. To use it, edit /home/local/ltsp-4.2/i386/etc/lts.conf to include SCREEN_01=dnakiosk.

Here is the lts.conf that we use. Note that it runs different X servers for different kiosks (depending on what graphics chipsets they have) and that it uses gpm.

To get the "gpm" executable to be accessible from the remote machines, simply copy it into the directory that will be NFS mounted on the client:

Getting sshd working is a little tricker:

cp -p /usr/sbin/sshd /home/local/ltsp-4.2/i386/sbin/
mkdir /home/local/ltsp-4.2/i386/etc/ssh/
ssh-keygen -q -t rsa1 -f etc/ssh/ssh_host_key     -C 'kiosks' -N ''
ssh-keygen -q -t rsa  -f etc/ssh/ssh_host_rsa_key -C 'kiosks' -N ''
ssh-keygen -q -t dsa  -f etc/ssh/ssh_host_dsa_key -C 'kiosks' -N ''

(Yeah, this means that all kiosks will use the same host key. Yeah, that's bad. So sue me.)

Then create /opt/ltsp-4.2/i386/etc/shadow to give the local "root" user on the thin clients a password.

Make it possible to remotely reboot the kiosks:
Create a file /opt/ltsp-4.2/i386/sbin/rebootme that contains only two lines:
and in /opt/ltsp-4.2/i386/etc/passwd, add:
Now you can do "ssh reboot@kiosk07" to reboot it without a password.
Make Ctrl-Alt-DEL reboot the remote clients by adding
to /usr/local/ltsp-4.2/i386/etc/inittab.base.

Make the kiosks know what time it is:

cd /home/local/ltsp-4.2/i386/etc
ln -sf ../usr/share/zoneinfo/US/Pacific localtime
cp -p /usr/sbin/hwclock /home/local/ltsp-4.2/i386/usr/sbin

and then for each kiosk:

ssh root@kioskNN date `date +%m%d%H%M.%S`
ssh root@kioskNN hwclock --noadjfile --utc --systohc

Configure auto-login.

Right now, the kiosks are remote X terminals. The next step is to make them be anonymous terminals. The basic idea here is that instead of having GDM put up login prompt, we want it to automatically log in as the user "guest" as soon as it starts up. Or rather, we want the kiosk03 host to log in as the user "guest03", and so on.

Furthermore, when a guest user logs in, their home directory should be re-initialized from a read-only known state (so that simply typing Ctrl-Alt-Backspace will reset things to a known state, and get rid of any configuration changes and files that the previous user of the terminal might have made.)

First, log in as one of the guest users, and set up their X environment the way you want it to be. Log out and save the configuration. Then make a copy of that guest user's directory in the guest-ro directory (that we created earlier), which we will use as a template:
Delete all the files in /etc/X11/gdm/Sessions/ except for "Default". Things get confused if a user ever selects a non-default session-style, so make there be only one available. The "Default" session is the one that runs ~/.xsession to launch the user's applications.
Since GDM will auto-login, avoid confusion by removing the login box from the GDM greeter screen by using a custom GDM theme that just leaves out all the various text-areas and displays our "loading, please wait" image. Install this directory in /usr/share/gdm/themes/dnalounge/.
Configure GDM itself: edit /etc/X11/gdm/gdm.conf with these options:
Now, here's the tricky part! For GDM to know which user to auto-login as, we set both the "AutomaticLogin" and "TimedLogin" fields to /usr/local/sbin/kioskname|. Note the bar at the end: that means that instead of being a user name, this is a script to run that prints out the name of the user to log in as. That script is a shell script that looks at $DISPLAY to figure out the name/number of the kiosk in question, and prints out an appropriate user.
So this means, gdm will launch, and then 5 seconds later, will run this script and then auto-login as (e.g.) "guest05".
NOTE: This works with GDM 2.4.1 on Red Hat 9.
I was never able to get TimedLogin to run a script with the version of GDM (2.6) that shipped with Fedora Core 4. Nor was I able to get GDM 2.4.1 to build on FC4.
That is why I'm still running RH9 on the kiosks instead of something newer!

Configure auto-reset.

Since this is a public space, people don't log in and log out. They just walk up to the machine, start using it, and walk away when they are done. Consequently, lots of applications tend to be left running, consuming memory and cluttering the screen.

I've written some scripts that kill off "stale" programs. If the kiosk is in use, nothing happens; but if the screen saver is active, meaning the kiosk is idle, then we kill off any unwanted processes. Install these scripts into /usr/local/sbin:

`xsession`	The guest user's `.xsession` file. It doesn't do much more than invoke `gnome-session`.
`kiosk-home-reset-ltsp`	This script re-initializes the contents of the kiosk directories with the template in `/home/kiosk-ro/`. (It must be run as root, in order to set the ownerships properly.)
`kiosk-nanny-ltsp`	This script kills any processes owned by the various "guestNN" users that don't match a list of "allowed" executables. This is not only for security reasons, as for cleanliness: if we run this script when the screensaver activates, we can kill off any apps that other users have left cluttering up the screen.

Set up the guest user's .xsession file:

rm /home/guest-ro/.xsession
ln -s /usr/local/sbin/xsession /home/guest-ro/.xsession

And set root's crontab to contain:

0,10,20,30,40,50 * * * *   /usr/local/sbin/kiosk-nanny-ltsp
0                7 * * *   /usr/local/sbin/kiosk-nanny-ltsp --reset

That will do a "light" reset of the kiosks every 10 minutes if the screen saver is active; and will do an unconditional "hard" reset every morning at 7AM.

Other usability tweaks.

After I installed these kiosks in the club, I spent some time standing around and looking over people's shoulders as they tried to use them.

I found that there were five major usability problems. I believe I have solved four of them...

Using the machine too early.
People kept trying to start using the machines while they were still starting X, and thrashing around. They, of course, found that the machines weren't working very well and seemed really slow. This was a bad way to introduce them!
I came up with a really simple solution to this: the first thing my startup scripts do is set the root window image to be one that has ``Loading, Please Wait'' written on it in inch high letters. The last thing the startup scripts do is set the background image to something prettier.
Of course, this problem went away when we upgraded to newer machines that boot really fast.
Mouse buttons.
The kiosks are set up with a three-button trackball as a pointing device. Experience shows that people had no idea which button to use: I watched people try to select things with the right button (causing menus to pop up, and stay up, cluttering the screen.) Then every now and then they'd hit the left button, and something would work right; but then they'd go back to using the right button or middle again.
This may be partly because people aren't familiar with trackballs, and it may be partly because of the position of the trackball; but the bottom line is, it wasn't working. We needed all three buttons to do the same thing. Opening up the trackball and rewiring it would have been a lot of work, so I found a software solution.
(I decided that, for the applications we're using, it was ok to discard the middle and right buttons: none of the apps that we expect to be used require usage of the right button to work properly, and people can always paste using Edit/Paste on the menubar.)
GPM:
Normally, the gpm program is used for making the mouse work on the text console and things like that, but you can also use it as a layer that sits between your actual mouse, and the X server. And you can use it to re-map buttons! But, not to re-map all buttons to the same button... For that you need to patch the gpm source (as of gpm-1.20.1.)
Then run gpm like this:
and add this to XF86Config-4 to tell X to read mouse events from gpm's socket instead of the real mouse:
Note that you have to be careful about the mouse protocol: the -t option to gpm tells you what protocol your actual mouse speaks, but the -R redirection stuff seems to only work with the MouseSystems (msc) protocol, so what the X server sees is MouseSystems data.
Multi-clicks.
Every single person assumed that they had to double-click on icons to launch programs, and so every single person ended up launching multiple copies of it. And then that slowed the machine down, so they assumed their click didn't work, and clicked again. And so on.
I solved this by writing a program that sits between the panel icons and the applications: It's called runonce.c, and what it does is, notice when the program it's trying to launch is already running, and in that case, simply raise its window. It also keeps track of programs it has just launched that haven't had time to map their windows yet. Use it by editing the command executed by the panel icons like so:
Where ``XTerm'' is the application name, application class, or window title of the window that the program maps; and the rest of the line is the command-line used to launch the program.
Obscure icons.
The Gnome panel doesn't have text titles underneath the icons: it only has tooltips that appear when the mouse hovers over the icon for a while.
Nobody realizes this.
So what they do is, they click on the icons to see what they do. Thus launching applications they don't need, and slowing down the machine while five programs they don't even really want to use try to start up at once.
I solved this by giving the applications different icons that include text in them (``IRC'', ``AIM'', etc.) A better solution, of course, would be for the panel to have an option to display the tooltip text right in the panel. Then it would be localized and everything.
Stale and bloated programs.
As described above.

_______________________________________________

If you have any suggestions of a better way to go about this, or if you see any problems with the above, I'd love to hear them. It seems far more complicated than it ought to be.

_______________________________________________