The company I was working in had ordered extra machines – all diskless units for Netware. It was about 8 years ago and the machines were 486’s. They were lying unused and already obsolete. We started exploring the idea of using them as diskless workstations in Linux environment. It wasn’t a radical departure because many of the users were using terminals connected to an HP Unix server.

Many of our software developers used the same diskless workstations for the internal development work we were doing. Even some of the secretarial staff were using these systems. It was a very satisfying experience to extend the life of equipment which seemed literally junk. It was also pleasant to find that the performance on a 486 connected to a PIII server was faster than a PII standalone PC. Supporting the setup was much easier. Once it was setup, nothing much went wrong. This project was a set of home grown scripts using some ideas from Linux router project and using parts of the Redhat distribution.

Meanwhile, a number of comprehensive projects addressing the same issues have been quite successful. One such project is the Linux Terminal Server Project (www.ltsp.org). The work of this project has also been used for a K12 school project. An experiment with schools in Goa also used LTSP and we in our College have also been relying upon LTSP for the thin clients. In our College, a dual Xeon with 2 GB RAM could easily handle 50 thin clients, provided we used Icewm but not Gnome or KDE. Another more recent project is ThinStation - http://thinstation.sourceforge.net

LTSP is primarily intended to be used as an X-terminal. The display is on the machine but all applications run on a server. Even poor machines these days have a lot of RAM and processing power and I have been wanting to experiment with using the power of the local machines. In my old job, we had found that running the window manager (FVWM at that time) on the thin clients enabled us to run a number of additional machines off the P3 server.

LTSP in a Nutshell

A thin client downloads the operating system from a server and uses NFS to mount and access the root disk. This file system will contain the local utilities and programs, including the X-server. The architecture of the server does not have to be the same as that of the clients. The applications for the client are likely to be distinct from those on the server. We can create more local applications for the thin clients over and above what is available with the standard LTSP distribution. The possibilities are open ended.

However, running the local GUI applications becomes cumbersome on LTSP. The window manager is running on the server. Hence, if we want to run, say, Firefox, locally, we have to initiate a remote execution of Firefox on the client machine from the server. While the display is local, the window manager running on the server will have to manage all the window activities and then display it back on the local machine. Often people run the browser locally, but not much else.

By contrast, if we could run the window manager on the local machine, we would then have to remote-execute the applications running on the server. Any local application like a calculator or a game or a screensaver would be initiated locally and run locally. Logically, this is easier to understand and likely to give better performance.

LTSP Environments

LTSP has its own deployment environment. In order to create this environment and build additional local applications, we need to have a build environment. This complexity cannot be avoided and conceptually, it is identical to developing for embedded systems. We are building applications for a target environment. The libraries used/required have to be the ones of the thin client environment and not the server environment. The project leader of LTSP, Jim , has created a pretty comprehensive setup for this development. It is called lbe – http://wiki.ltsp.org/twiki/bin/view/Ltsp/LBE.

The system works as follows. We download the lbe core and fire a script to build all. It downloads the source files from the net and builds each module/application. The entire process took over 2 days in my college – mainly because the downloading sources takes time even with a 1MBPS link. The excessive time taken is most likely because of network delays and because wget does not download a file as a set of parallel downloads.

The build_all script will go through the directories – lbe-src, kernel-src and ltsp-src, building the various applications. Most source packages are distributed as tar balls. Each package normally requires us to run configure, make and make install commands. There are, though, minor differences. We may have tar file with gzip or bzip2. Some files may need to be patched. Some may not require configure to be run. The lbe environment allows customisation of the building of each package. Each package is in its own directory and each directory has a file called package.def.

Building a Local Application

One of the additional packages we needed to build is tinylogin. Let us examine its package.def.

VERSION = 1.4

RELEASE = 0

PKG1COMPONENT = lwm

PKG1NAME = lwm-tinylogin

PKG1EXCLUDE = /i386\/man/, \

/i386\/info/

DEPENDS = ltsp-ltsptree, ltsp-glibc

PKG1 = tinylogin-1.4.tar.gz

MD5SUM1 = fd6325c816f3f811b8efcb4d310d7690

SOURCE1 = ${TARBALL_SOURCE}/${PKG1}, \

http://tinylogin.busybox.net/downloads/${PKG1}

UNPACK1 = gunzip < ${TARBALL} | tar xvf -

BUILDDIR = tinylogin-1.4

PREPATCH1 = patch -p0 <../tinylogin-001.patch

BUILD = make -j ${CPUS} CFLAGS_EXTRA="-march=i386"

INSTALL = make PREFIX=${LTSP_ROOT} install

CLEAN = rm -rf ${BUILDDIR}

The keywords and options are mostly self-explanatory. Multiple locations can be mentioned for source. It will try the first one, which is the local repository. If not present, it will download from the website given. It verifies the download using the md5 checksum.

One crucial point to notice is in the install option. Here, we have used a keyword PREFIX. As we had mentioned earlier, we have a build environment and a deployment environment. The PREFIX refers to the deployment location with reference to the build environment. Some makefiles do not understand PREFIX. Another common keyword is DESTDIR, which serves the same purpose. In fact, the latter seems to be more common now.

Creating a new local package reduces to defining a suitable package.def file. This is then followed by running the script in the ltsp-src

./build -only=tinylogin

This will build and install the package. Then, we run

./build -only=tinylogin -makepkg

which will create a suitable pair of installation package files.

Local Window Managers

Since we were interested in running a gui locally, we started with icewm. Icewm required a number of additional local packages as well but was still giving problems. Hence, we looked at Matchbox, which was in the news thanks to Nokia. We needed to download and build the following packages, libmatchbox, matchbox-common, matchbox-panel and matchbox-window-manager, These went through easily without any complications after pkgconfig was installed in the lbe environment.

Meanwhile, the ThinStation project released a new version which included icewm as their local window manager. I used the source of icewm from that project and built it in the LTSP environment. It worked like a charm.

The binaries and instructions have been uploaded on the LTSP wiki - http://wiki.ltsp.org/twiki/bin/view/Main/LocalWindowManager.

Future Direction

Running a window manager on the local desktop makes it easy to run local and remote applications. The one issue which is open is how to construct the menus automatically. The menu will be running on the local machine but should be aware of what is available on the server. A user should select the wordprocessor and it should run. Where it runs should be transparent to the user. It should also be easy to setup for the administrator. The menu program could even be smarter and decide to run the program on local or remote machine based on the runtime environment.

LTSP environment is flexible and versatile enough for us to explore various ways in which we can use the hardware more effectively and for a longer duration. Hardware companies may not be happy but at least, our garbage heaps will be more manageable.