As an operating system, Linux has reached the point where it has entered mainstream computing. No longer do people scratch their heads at the mention of its name, nor do they shake it when they hear it's being used for enterprise applications. Linux has proven its value propositions of cost, scalability and performance in the real world. The final frontier for Linux to conquer is the desktop.

The reality of Linux on the desktop is the situation we faced when we worked for an organization in the midst of deploying Linux. Several servers already had been migrated to Linux with much success. Now, the managers were casting a wary eye at the desktop. We demonstrated several desktop-oriented distributions: Lindows, Xandros, Knoppix and Red Hat. Of these, the managers liked the Red Hat environment and support structure the best.

Although they liked what they saw in Linux desktops, the managers felt the responses to the demos were too subjective and too theoretical to commit to mass deployment wholesale. They wanted to see how the users would react to this shift. The only way to do this was through a pilot group.

We were working against two major constraints. First, the managers wanted to run the pilot group without any major disruptions in their day-to-day operations. If we did install Linux on the pilot group's existing desktops, we would have to do the entire job in half a day. If the pilot group did not like what they saw, we would have to restore the existing Windows desktops just as quickly.

Second, we were working with a hodge-podge of old machines. The desktops were a varied mix of Pentium II and Pentium III computers with different memory and hard disk configurations and no CD-ROM drives. Worse, the hard disks generally had less than 500MB of free space. No way could we dual-boot a decent Linux distribution on these machines.

So, here was the challenge: how could we bring Linux quickly onto the desktop to penetrate the users' defenses? Just as importantly, how could we take Linux out of the environment in case the opposition proved overwhelming? We would have to take a guerrilla approach to conquering the desktop.

One of the things we had going in our favor was the office network. Fortunately, the company had invested in a decent Ethernet infrastructure, and all the machines already were connected. This setup immediately led us to consider a thin client approach to our project.

A thin client approach meant we would be running all the applications off a fat server. The desktops themselves would be responsible only for outputting display on the monitor and accepting input from the keyboard and the mouse. But how would we accomplish this?

We were aware of several open-source thin client projects, most notably, the Linux Terminal Server Project (www.ltsp.org) and Netstation (netstation.sourceforge.net). Although these packages have proven popular, we found them complicated to set up and maintain. They required us to put together a tightly coupled server and client environment: critical client files needed to be served through NFS, for example.

An approach we liked better was the Virtual Network Computer (VNC) from AT&T (www.uk.research.att.com/vnc). VNC is a remote display system that allows you to view a computing desktop environment from anywhere on a network and control it as if you were sitting in front of that computer. The beauty of VNC is that it works with a wide variety of platforms for both the client and the server. The server and the clients communicate primarily through the VNC protocol, so they are not as tightly linked. We could run it on almost any type of client and any type of server.

We thought we had found our answer, so we installed the VNC server on our Linux machine. We put VNC clients on the desktop, running within the Windows environment. Using VNC, our users could access the Linux desktop that was running on our server.

Needless to say, this approach failed dismally. Users followed the path of least resistance and opted to ignore the VNC icons on their Windows desktops. Instead of trying Red Hat, they continued to use their old applications. Luckily, we found this out before deployment to our pilot group.

We were left with only one recourse: we would have to package a small floppy-based distribution that contained a VNC client. Then, with their hard drives disconnected for the duration of the pilot, the users would have no option but to use our thin client network. If the pilot failed, we would reconnect their hard disks and they would be back in their old environment.

Here, in broad strokes, is the thin client approach on which we settled. We assembled a small floppy-based distribution with an SVGA VNC client, and then we set up our Linux machine to act as a fat server to our thin clients. We then deployed our floppy distribution to the client machines. All our work was done with a stock distribution of Red Hat 9, with the exception of some packages we downloaded from the Internet.

Figure 1. Thin Client Diagram

We based our thin client boot floppy on BusyBox (www.busybox.net), which provides a complete bootable system on a floppy disk. It originally was created by Bruce Perens and currently is maintained by Erik Andersen. For a full explanation of each step, however, we would refer you to the three articles written by Bruce Perens and published in LJ, as well as the documentation from the BusyBox Web site (see www.linuxjournal.com/article/4335, www.linuxjournal.com/article/4395 and www.linuxjournal.com/article/4528).

Below, we outline the most elaborate part of our thin client approach. If you want to go straight to setting up your thin client network, skip this section and use the floppy image available on our Web site (cng.ateneo.net/cng/wyu/software). You have to modify only the network.cnf and libvga.config files to suit the circumstances of your network.

Step 1: we first created a filesystem with the appropriate nodes and configuration files for our system. We did this first on a Linux workstation. To simplify and automate the process, we wrote a script called genfilesys.sh. You can download this script from cng.ateneo.net/cng/wyu/software. We adapted this script from Bruce Perens' script (also available from the LJ FTP site at ftp.linuxjournal.com/pub/lj/listings/issueXXX/7109.tgz) and added configuration files for SVGALIB and UDHPC:

mkdir svilinux-filesystem
./genfilesys.sh ./svilinux-filesystem

In genfilesys.sh, we also set parameters for the video mode and mouse types, defined in libvga.config. You may want to modify this to suit your environment.

Step 2: build uClibc. uClibc is a C library with supplementary routines that we needed in order to run our VNC viewer. We downloaded the source package uClibc-0.9.20.tar.bz2 from www.uclibc.org and compiled it into our preparatory filesystem:

tar xvjf src/uClibc-0.9.20.tar.bz2
cd uClibc-0.9.20
make 
make install
make PREFIX=../svilinux-filesystem install_target
export PATH=/usr/i386-linux-uclibc/bin:$PATH
cd ..

Step 3: build BusyBox. We downloaded the BusyBox source package, busybox-1.00-pre2.tar.gz, from www.busybox.net and built it in our workstation:

tar xvzf src/busybox-1.00-pre2.tar.gz
cd busybox-1.00-pre2
make config 
make dep
make
make PREFIX=../svilinux-filesystem install
cd ..

For the configuration, we chose to enable CONFIG_AWK, CONFIG_TELNET, CONFIG_UDHCPC and CONFIG_FEATURE_INITRD; we disabled CONFIG_SYSLOGD.

Step 4: configure SVGALIB. Because we were using VNC, at the very least we needed to incorporate SVGA support into our small distribution. To do this, we downloaded SVGALIB from www.svgalib.org and compiled it:

tar xvzf src/svgalib-1.4.3.tar.gz
cd svgalib-1.4.3
vi Makefile.cfg (defaults are okay)
make install
make prefix=../svilinux-filesystem installsharedlib
ln  -s libvgagl.so.1.4.3 \
../svilinux-filesystem/lib/libvgagl.so.1
ln  -s libvga.so.1.4.3 \
../svilinux-filesystem/lib/libvga.so.1

Do not use the experimental version of SVGALIB, as it uses a kernel helper for the frame buffer. Using this would mean recompiling the kernel to include this support, further bloating the kernel.

Step 5: configure the SVGA VNC viewer. We needed to configure our own VNC viewer that would work with SVGA, so we downloaded sources from www.tightvnc.com and packages.qa.debian.org/s/svncviewer.html. This VNC viewer still works with the stock VNC server from Red Hat.

tar xvjf src/tightvnc-1.2.9_unixsrc.tar.bz2
cd vnc_unixsrc 
xmkmf
cd libvncauth
xmkmf
make
cd ../.. 
tar xvzf src/svncviewer-0.1.1.tar.gz
gzip -dc src/svncviewer_0.1.1-5.diff.gz | \
patch -p0
cd svncviewer-0.1.1
vi Imakefile 

(Add -I/usr/local/include to INCLUDES and -L/usr/local/lib -L../vnc_unixsrc/libvncauth to SVGALIB.)

rm makefile
xmkmf
make
strip -s -x -X svncviewer
install svncviewer ../svilinux-filesystem/bin

Step 6: generate a ROM filesystem. We generated a ROM filesystem could load onto our boot floppy:

genromfs -f initrd -d ./svilinux-filesystem
gzip -9 initrd

Step 7: build a small kernel. To minimize the size of our kernel, we decided to build a statically linked bzImage-style kernel. We removed all unnecessary items, such as unneeded drivers and features. The features we need to include are:

We configured and compiled the kernel by invoking in our kernel source directory:

make menuconfig
make dep clean bzImage

Step 8: create a bootable floppy with SYSLINUX. SYSLINUX is a bootloader for Linux that operates off MS-DOS floppies. It is part of a standard Red Hat 9 install. Thus, with our prepared floppy in the drive, we invoked:

syslinux /dev/fd0

This altered the boot sector of our floppy and also copied the second-stage bootstrap ldlinux.sys file to it.

We then copied our RAM disk initrd.gz and the compiled kernel bzImage to the floppy:

mount -t msdos /dev/fd0 /mnt 
cp initrd.gz /mnt/initrd.gz 
cp /usr/src/linux/arch/i386/boot/bzImage /mnt/linux

Step 9: create a SYSLINUX configuration file. We created a file called syslinux.cfg in our floppy that contains the following lines:

TIMEOUT 20 
DEFAULT linux LABEL linux 
    KERNEL linux 
    APPEND root=/dev/ram0 initrd=initrd.gz 

This tells SYSLINUX to wait for two seconds and then boot the default system. The kernel is booted with the arguments root=/dev/ram0 and initrd=initrd.gz.

Step 10: next, we created a bare network configuration file, network.cnf, in our boot floppy:

HOSTNAME=vnc
DEVICE=eth0
DHCP=yes
VNCHOST=192.168.0.100

Step 11: at this time, we tested our boot floppy on one of the target machines to see if it would work.

Step 12: satisfied that our boot floppy would work, we proceeded to make an image from it so we could recreate additional boot floppies:

umount /mnt
dd if=/dev/fd0 of=./vnclinux.img

mkdir loopback
mount -o loop vnclinux.img loopback/
umount loopback/
rm -rf loopback
dd if=./vnclinux.img of=/dev/fd0

Our next major step was to set up a fat server for our thin clients. We began by installing Red Hat 9 on the machine that would be our fat server. Red Hat 9's default GNOME workstation configuration option was sufficient for our needs. GNOME and X needed to be configured properly.

We next checked that our required software already was installed—VNC and GDM were critical. We also installed OpenOffice.org, Mozilla, Evolution and the x3270 client, as these were needed for our users' environment.

We then had to modify the GDM configuration. By default, GDM is configured not to allow XDMCP connections. We edited the GDM configuration file located in /etc/X11/gdm/gdm.conf. The options we needed to change were in the [xdmcp] section. We changed it to enable XDMCP like this:

[xdmcp]
Enable=1
HonorIndirect=1
Port=177

After editing the configuration file, we restarted GDM. This was be done by issuing

killall -HUP gdm

For your own implementation, watch out for any unnecessary error messages in the /var/log/messages file. You can edit the GDM configuration file and enable verbose debugging in the event that GDM does not restart successfully.

We then added the following entry to the /etc/services configuration file for our VNC server:

vnc   5900/tcp

We also created a file named /etc/xinetd.d/vnc, which needed to contain the following lines:

service vnc {
    disable = no
    id = vnc
    socket_type = stream
    protocol = tcp
    wait = no
    user = gdm
    server = /usr/bin/Xvnc
    server_args = -inetd -geometry 800x600 -depth 16 -query localhost
    log_on_failure += USERID
}

In the line that starts with server_args, the parameters after the -inetd parameter are standard X arguments. Any argument normally passed to an X server can be passed here. In this example, the spawned GDM sessions are loaded in an X session with 16-bit color on an 800×600 screen. These values can be changed according to user preferences. The larger the color depth and screen resolution, however, the larger the network bandwidth consumption. The Xinetd superserver is then restarted with:

/sbin/service xinetd restart

From here, the DHCP server is ready to be configured. We wanted to allow workstations to obtain their network configuration options, including their IP addresses, from a DHCP server. Our simple configuration file dhcpd.conf looked like this:

subnet 192.168.0.0 netmask 255.255.255.0 {
    option routers		192.168.0.1;
    option subnet-mask	255.255.255.0;

    option domain-name	"svi.com.ph";
    option doman-name-servers 192.168.1.1;

    range dynamic-bootp 192.168.0.128 192.168.0.255;
    default-lease-time 21600;
    max-lease-time 43200;
}

Once the fat server was set up, it needed to be tested. From Windows, we invoked a VNC client and typed the IP address of our fat server. We then saw the login screen of the fat server. We tried the same with our thin client boot floppy, with similar results.

Over a Thursday and Friday, we conducted the training for our pilot group. This group had simple requirements, representative of half the population in the organization: they needed basic office productivity tools, such as e-mail, Web browsing and terminal access to a mainframe. OpenOffice.org, Evolution, Mozilla and x3270 sufficiently met their requirements.

On Saturday, we disconnected their systems' hard disks and reproduced boot floppies for each workstation. We spent half the day testing each and every machine for any glitches. We also migrated their files to accounts on the fat server so they would have ready access to them. We also connected the printer to the fat server. Finally, we set up the server desktop to have the often-used icons prominently displayed.

When the users arrived on Monday, they were greeted with Red Hat login screens on their desktops. The SVGA-driven VNC displays were crisp, and the overall performance of the applications, from loading time to actual use, was pretty fast. Overall, everything went as users expected from our training.

The first few days of the pilot generated some complaints from the users, but that was to be expected. They were faced, after all, with an environment different from what they were accustomed. The more frequent queries concerned how to use OpenOffice.org, the location of their files and how they would print.

At the end of our first week, the questions tapered to a trickle. Our pilot group even reacted with some pride when coworkers asked them what strange programs they were running on their machines. The real value of our approach popped up inadvertently during the rash of infections from the Blaster worm. As their colleagues were faced with system slowdown and lost productive hours while disinfecting their PCs, our pilot group continued working on their machines.

We strongly feel that the possibility of a graceful exit from the pilot positively affected the outlook of both management and users. So far, they have opted not to use that exit. End-user response has been positive, and some have even offered usability suggestions.

An unexpected side benefit has surfaced: it has allowed the company to observe and document the speed, ease and costs of deployment and support of this approach. This, in turn, provided management with the option of considering its use as a critical component in an enterprise-wide, disaster-ready infrastructure. Thus, without irrevocably committing the company to large-scale migration, prototype systems have been seeded across the organization and are being nurtured by champions.

The current strategy options include continuing deployment of these terminals to increase and improve both support skills and user familiarity. We are confident that this diffusion of skill sets and attitudes across the enterprise will enhance the future decision-making calculus and further bolster Linux as a practical and superior alternative.