Rolling out your own Linux thin clients
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 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 whenWhen 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 workstationTo 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.
Page 1 of 2