Desktop Guerrilla Tactics: a Portable Thin Client Approach
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.
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
|Firefox Security Exploit Targets Linux Users and Web Developers||Aug 17, 2015|
- A Project to Guarantee Better Security for Open-Source Projects
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Doing Astronomy with Python
- Firefox Security Exploit Targets Linux Users and Web Developers
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Three More Lessons
- August 2015 Issue of Linux Journal: Programming