The X_kiosk project is an LTSP Kiosk style implementation of a (mostly) stand-alone X terminal.
The current implementation is a hack of the kiosk plugin by Oliver Grawert. It needs a lot of help to make it into a more general, easily installed plugin, like --kiosk.
Goals for the X_kiosk Project
- Avoid exposing less-secure protocols and traffic (TFTP, NSF, others) to the world net
- Keep load on the server(s) low as the number of X_kiosk clients increase
- Minimize the impact of server failures while X_kiosk clients are in use
- Eliminate the need to manage passwords on the X_kiosk client
- Communicate only through secure protocol(s) (SSH2) between the X_kiosk client and its login host
- Make boot time for the X_kiosk client as short as possible (less than 30 seconds)
- The X_kiosk client should work with existing i386 workstations (being retired, but with PXE boot), with i386 notebooks (with PXE boot), and with new, low-cost computers configured for this use
- The X_kiosk client should be energy efficient and quiet
- The X_kiosk client should be (mostly) stateless. Logging out, rebooting, pulling the plug (etc) should reset the machine to a default state, clearing out any changes a previous user might have made. Pulling the plug should cause no local damage.
- The X_kiosk computer and its server connection reside on an isolated, secure network or VPN, with only an SSH2 port open through the firewall (for server(s) residing on the isolated network, proxy ports may also need to be open for server management)
- Server(s) provides only DHCP address resolution and initial image load for the X_kiosk client
- Server(s) does not provide authentication, windows manager, file management or applications while X_kiosk client is in use. These services and applications are provided to the X_kiosk client by the login host
- There are no user accounts on the X_kiosk client. There is one anonymous account with automatic login at boot
- User logs in directly to the login host via SSH. User transfers files to/from local X_kiosk devices (USB, CD/DVD) with SFTP directly to the login host.
- Limit the components and applications in the X_kiosk client image to a minimum. An X-Server (with run time environment and fonts), ssh and gftp are the core components and applications.
- Use ubuntu/Gutsy based LTSP implementations that can adapt to a variety of i386 hardware and display configurations
- Eliminate local disk drives. On new X_kiosk clients, use efficient motherboards, processors, power supplies and cooling systems. X_kiosk clients automatically power down on logout and when not actively in use.
- Keep only a small amount of login information local after start of the X-Server. There is no local hard disk, and changed files are not saved on boot server. All other session state information is kept on the login host.
Things to Fix and Improve
- Additional servers need to be built and configured in DHCP to have automatic switchover/backup in case primary server fails
- A nicer login screen would be good, especially if it can be made to look a lot like more typical login screens
- A better method of mounting USB drives and DVD disks is needed so that the gftp program is only loaded when a drive or disk is plugged in. This would take configuration of automount functionality that should already be in the thin client image. One result would be the elimination of the "Local_Xfer" Xwindows program which complicates things a fair amount.
- Sound should be implemented from the computer used as the host (especially for gnome) to the thin client. This should be available, but so far it doesn't work
- It would be nice to get foreign language support for Gnome sessions to hosts. This may be a problem if lots of fonts need to be loaded on the thin client (takes time and RAMdisk space).
- A better method should be implemented to determine if login has been completed. The current method of detecting number of Xwindows on the screen is not very flexible (pswatcher is mentioned in a Web Kiosk implementation)
- gftp should be modified to limit file transfer access to just the USB and DVD drives. Now it is possible to search around the thin client and possibly make local changes for the current session. Any local changes will go away across a logout/shutdown cycle. But it still feels potentially dangerous
- An "automatic" build plugin could be constructed similar to the kiosk plugin that inserts all the needed changes by using a command-line option while building the image. This would work much better if the "Local_Xfer" Xwindows application could be eliminated
- Create custom GNOME and FVWM session configurations specific to thin client operation. Stop using the user desktop default. This will allow elimination of error message and potential incompatibilities.
- Remove NFS/FS file mounts made to the server (if possible). Ideally, there should be no dependency on the server to be powered up except for the initial load. Currently, the thin client keeps running X with the server shut down, but the thin client will fail at shutdown due to FS mounts.