A little more than a year ago, one of our customers, Binson’s Home Health Care Centers, came to us for help. The company, which sells wheelchairs, crutches, hospital beds, and about 20,000 other items for the home healthcare industry, was expanding into a new business area and needed to add 35 more workstations to their network.
Binson’s headquarters, its warehouse and five retail locations are located in the Detroit, Mich., area. About 100 of the company’s 280 employees were using 5250 dumb terminals connected to an IBM AS/400 for accounts receivable and customer service. The firm also had a Novell network with about 50 Windows PCs, and an SCO OpenServer applications server. Aside from analysts and programmers, they had two full-time support people managing the network.
We considered deploying traditional PCs, but the price tag seemed awfully steep. Besides hardware and license fees, a big chunk of the cost would come from support: We estimated that supporting 35 workstations running Microsoft Windows would require one full-time person, dedicated solely to keeping the PCs running. Any IT manager responsible for PCs is well aware of the trouble that Windows users can get themselves into. To mention just a few problems, there are e-mail viruses, virus-laden screen savers, deleting important icons from the desktop, installing non-approved applications, taking illegal copies of programs, storing important data locally and not backing it up… the list could go on.
| "We wanted something better, and that meant going diskless. " |
We knew that we had to come up with a better way, and using Linux, we did. As a result, we not only have a customer who’s happily running a good chunk of its business on Linux, but we’ve found ourselves crisscrossing the globe, showing lots of other people that there is indeed an alternative to Microsoft Windows on the desktop. In 1999, we launched the Linux Terminal Server Project (LTSP) an open source / free software project which aims to make it easier to set up and manage diskless workstations in a Linux or Unix environment.
Disk drive failure: not if, but when
When Binson’s came to us last year, we had already been using Linux for e-mail and Web servers, Internet gateways, and as a software development platform for several years. We really wanted to try to find a way to solve this company’s problem using Linux and free software. Connectivity to the IBM AS/400 and the SCO application server were two key requirements. We found the TN5250 project, which provided us with terminal emulation for the AS/400 system. Connectivity to the OpenServer system was easy — good old X-Term was just perfect.
So now, the task at hand was determining how to deploy 35 workstations running Linux. One possibility was to take a standard Intel-based PC and load Linux onto the disk drive. But, aiming to keep support costs down, we were looking for a reliable workstation that wouldn’t require any maintenance. And with a disk drive, let’s face it, it’s not a matter of if the drive will fail, but when. That means not only higher maintenance costs, but downtime and lost productivity for the poor soul using the PC.
We wanted something better, and that meant going diskless. Diskless workstations have been around for a long time. In the 1980s, that was a popular way to run a workstation in a Novell environment. Then, in the late 1980s and into the 1990s, X-Terminals became popular. Diskless workstations got another boost in the fall of 1995 when Oracle CEO Larry Ellison announced at Comdex that "thin clients" would soon take over the desktop. He was wrong, of course — but that was before Linux burst upon the scene.
Learning how to set up a diskless Linux workstation
To understand how a diskless workstation works, it helps to know how a traditional Unix computer with a disk boots. When the power is switched on, the computer goes through something called a ‘Power On Self Test’ or POST. During this process, the BIOS scans the hardware for all of the various devices that are attached. Once it completes the POST, it loads the Master Boot Record (MBR) from the hard disk, which is usually the first sector on the first drive. The MBR contains a pointer to a boot program located elsewhere on the drive. Control is passed to the boot program, which reads the operating system kernel into memory.
Once the kernel is in memory, control is passed to the kernel, which again scans the system, probing for hardware devices such as the keyboard, video card, network card, disk controllers, floppy controllers, and sound cards. Each time the kernel finds a device, it initializes and sets up internal data structures so the device can be used.
Near the end of the kernel boot process, the kernel mounts the root filesystem from the hard drive and then passes control to the ‘init’ program. The init program is directed by entries in the /etc/inittab file. Each line causes a program or a script to run to further bring up the system. Some of the lines will run a series of scripts to prepare the system for use. Additional filesystems may be mounted, additional drivers may be loaded into the kernel, and the network interfaces will be initialized by setting up IP addresses and routes. This whole process is referred to as ‘Bootstrapping the system.’
Depending on how the system is configured, the last process started by the init process will be either ‘getty’ or a display manager such as xdm, gdm or kdm. If getty is started, the user will be presented with a character-based ‘Login:’ prompt. If one of the display managers is started, then the user will see a graphical login prompt, and once they log in, they will be running in a graphical environment such as Gnome or KDE.
A Windows PC goes through a similar process of loading the OS into memory, detecting and initializing devices, and eventually presenting the user with a graphical user interface.
Diskless booting is (almost) the same…
Most PCs, during their initial POST, scan the system memory for extension ROMS. A network interface card can contain an extension ROM that holds the code to boot the workstation from a network server. This ROM is often called a ‘bootrom’. It is usually a chip that plugs into a socket on the network card. Some recent network cards have been built with FLASH RAM that can be programmed with the bootrom image. On some computers, it is also possible to store the bootrom image along with the system’s BIOS, right on the motherboard.
If a network interface card containing such a bootrom chip has been installed in the computer, then just before the system BIOS loads the code from the disk’s MBR, control is instead passed to the program stored in the bootrom chip.
The bootrom code contains a driver for the network card. It first initializes the card, and then sends out a bootp/dhcp broadcast request on the network. If a server on the network sees such a request, it will respond with an IP address and other information for the workstation. The workstation’s bootrom code, in turn, sends a TFTP request to the server to download the kernel. The kernel is then loaded into memory and takes over control of the workstation, beginning with scanning for hardware devices, just like booting from a hard disk. Once it finds and initializes the network card, the root filesystem will be mounted. This time it will be mounted from the server via NFS. From here on, the workstation continues booting exactly as it would if the operating system came from a local hard disk.
Help from the Linux documentation project
We had a lot of help figuring this out from the ‘Diskless Nodes How-to’ which we found on the Linux Documentation Project. That helped us find the Etherboot project and the Netboot project. The purpose of those two related projects are to create the bootrom image that is to be burned onto an EPROM. This was the first step in building a diskless workstation.
By following the Diskless-Nodes How-to, we learned how to set up one workstation to boot from the server. We loaded a full Red Hat Linux distribution onto the server, in a subdirectory under the /tftpboot directory. The workstation booted and ran, with all of the features of an ordinary Linux workstation. Setting up a second workstation, however, meant creating another directory under /tftpboot, and loading a full distribution for the second workstation. Fairly quickly, this method would consume a massive amount of disk space on the server.
The Diskless-Nodes Howto described a way of reducing the size of the root filesystem for each workstation, but it was a trial-and-error exercise. We decided to start from the beginning. Rather than take a full distribution and cut out what we didn’t need, we started with nothing and began adding what we did need. This produced a root directory occupying only about 20 Mb of space, which was a big improvement over the approximately 110 Mb needed before. And since the workstations were all using the same operating system, they could all share the same space.
There was one problem with sharing the same copy of the operating system, however: each workstation needed to be able to write temporary files, and keep them separate from files belonging to other workstations. So we created a 4 Mb ramdisk on each workstation, mounted as its /tmp directory, to contain any transient data that needed to be written while the workstation was running. This required creating symbolic links for the /var directory and some of the device nodes in the /dev directory. This couldn’t be done on the server, since the clients each needed their own /tmp directory, or they would be mixing up their temporary files with those of other workstations. Doing this enabled us to mount the root filesystem in Read-Only mode. Since none of the workstations would be writing to the root filesystem, they could all share one root filesystem.
Cool-running workstations
We still needed to convince Binson’s that this would work. With their approval, we launched a pilot project. From the point of conception to the initial installation of the first 11 workstations took about three weeks. It didn’t take long at all for management at Binson’s to see that the diskless workstations were going to work. They quickly gave the go ahead to install the other 24 workstations.
| "The really beautiful thing is that the workstations require no maintenance at all. " |
Installation turned out to be really easy. Each workstation only required an entry in the /etc/hosts file, mapping a workstation name with an IP address, and an entry in the /etc/bootptab file, mapping its network card’s MAC address (a number which uniquely identifies each network card) with its IP address. That’s it! Two records added for each workstation.
We could easily hand the job over to a couple of staff members who didn’t need to know anything at all about Linux. They could just roll out the workstations, one right after another.
The workstations we used were brand new 166 Mhz Pentium machines with a video card, 32 mb of RAM and a network card with a bootrom chip. As it turned out, the Pentium processor was more processing power than the users needed, but this was the least expensive processor we could get at that time.
Binson’s employees are now happily using the workstations to reach applications such as the patient, insurance, and inventory databases on the AS/400 and SCO servers. And the managers at Binson’s have been so impressed with the diskless workstations, they began finding more uses for them. They soon ordered 35 more, and put them into production just as easily. They even began replacing existing PCs with diskless workstations running StarOffice for word processing and spreadsheets, and Netscape Communicator for e-mail and Web browsing. Today, the company has 100 diskless Linux workstations, all booting from one single Pentium II 400 Mhz server.
The really beautiful thing is that the workstations require no maintenance at all. By removing all of the moving parts, and running a fairly low-end processor, the internal temperature of the workstations remains very low, resulting in an extremely low failure rate.
True spirit of the open source movement
We realized that the problem that we had solved for Binson’s was something that many other people around the world were facing. And, because we had relied upon several existing open source projects, the only logical thing to do was to offer our solution to the world.
In August 1999, we created the Linux Terminal Server Project (LTSP). We registered the domain name, built the Web server, recruited a bunch of friends, created the mailing lists, packaged the software for download, recruited more friends, wrote the documentation and made the announcements on LinuxPR, Freshmeat.net, and the Comp.Os.Linux.Announce news group (COLA). Almost immediately, the traffic started coming. Lots of people downloaded the documentation and the packages and began playing with the technology.
It only took about 24 hours before people were sending us patches and offering to contribute to the project. This was the true spirit of the open source movement. We were impressed.
Since that time, we’ve released several updates, given talks at major Linux and open source trade shows, written a couple of articles and shared experiences with some wonderful people all over the world. Over 12,000 people have downloaded the core packages, while more than 20,000 people have downloaded the documentation. We’ve had reports that thousands of diskless workstations running the LTSP software have been deployed in all parts the world.
The combination of low cost and ease of maintenance seems to make diskless Linux workstations particularly attractive to schools, and small to medium businesses. We think that it is just a matter of time before larger corporations see its advantages as well. For many organizations, it has clearly put new life into older PCs that were deemed "Not powerful enough to run anything useful, like Windows".
Whether you are involved in a project to deploy new hardware or trying to reuse existing hardware, the LTSP could be just what you need to keep costs down and user satisfaction up.
