Desktop Guerrilla Tactics: a Portable Thin Client Approach

Roll out a desktop Linux pilot project quickly without disturbing the legacy desktop OS.

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:


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

Setting Up a Fat Server

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, 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:


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 netmask {
    option routers;
    option subnet-mask;

    option domain-name	"";
    option doman-name-servers;

    range dynamic-bootp;
    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.

Our 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., 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, 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.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Numbers, numbers, numbers ...

Anonymous's picture

I imagine you would have to pay for the detailed service information.

They spend hard money obtaining it...