Thin Clients Pay More
At the Superemos community education programme in Esteli, northern Nicaragua, we use secondhand computers as thin (diskless) clients in networks controlled by a Linux server. Many organizations already benefit from the Linux tools available for setting up such networks. They save money, simplify system administration, enhance security and increase autonomy. They are ideal for our low-budget education programmes in Nicaragua. Plenty of information and know-how on setting up these networks is published on the Web. Although that knowledge can be intimidating to try and make work, the effort certainly pays off.
This article explains how we have been using old hard drives and Flash drives to boot diskless clients over a network. It should be helpful to anybody on a tight budget who wants to offer a large group of people low-cost access to computing facilities. At our project, we are especially anxious that educators realise they can recycle older machines to deliver the latest software. But the principles apply equally to better-resourced outfits of all kinds including commercial businesses and government offices.
Before moving on to explain some of the basics for people with no experience of diskless client networks, I should detail and acknowledge our project's sources of tools and information. We have been using Novell's SUSE Linux 10.0 and Ubuntu's Breezy Badger distribution with a variety of new and old machines and parts supplied to us by the Rotary Club of Toronto-Leaside and by SSC Inc., the publishers of Linux Journal. It's worth pointing out that our machines are all PCs. Optimally, it's worth trying to standardise as much as possible. That's always awkward to do when one depends on donated or inherited equipment.
Among the indispensable tools that make our project work smoothly are the superb diskless client software developed by the Linux Terminal Server Project and the comprehensive library of boot-ROM images (see the on-line Resources). The original tool we used for getting old hard disks to substitute for boot-ROM came from Andy Rabagliati (see Resources).
As in any network, diskless client systems consist of a server connected to clients, in our case by Ethernet cable. Once the server is powered up, the diskless clients receive their operating system from it. As each client is switched on, it learns from its BIOS that no system is available on hard disk. It then tries to boot from the local network (LAN) by sending a request via its network card for a server to give it an operating system. The server receives the request and looks to see whether it has the appropriate operating system to send out. If it does, the client boots up as normal using that operating system. For its users, the client machine works just as if it had its own operating system. In fact, it is receiving its operating system from the remote server.
It took us a while to understand the fundamental components of this concept and how they interact. The first thing to find out is whether a potential client has options in its BIOS allowing the machine to “Boot from LAN” (LAN stands for local area network) via boot-ROM. On some machines this is obvious, and on others, the settings are squirrelled away in suboptions of the main BIOS. On still others it just does not exist. If it is available, it enables the machine to boot through a boot-ROM chip, usually with Pre-boot Execution Environment (PXE) capability located in the machine's network card.
If you find the Boot from LAN option and configure the BIOS to boot from LAN you may well be lucky and everything will just work. But don't be dismayed if it does not. One of our machines with a VIA chipset swore solemnly that it would boot from LAN using PXE and persistently refused to do so before finally deciding one day that it would. Such frustrations are a trivial part of setting up a diskless client network and well worth overcoming in order to get a first-class network facility using whatever machines may be available.
Some machines have the network card integrated into their motherboard. If the network card is not integrated into the motherboard, it usually will be plugged in to the PCI slot. (It is possible to work with machines using older ISA cards, but they require special configuration so we have avoided using them.) If the network card is not integrated into the motherboard, it is unlikely to have pre-installed boot-ROM.
We found two main obstacles to using machines as diskless clients. One was that the potential client machine did not offer a Boot from LAN option. The second was that even if the machine offered to boot from LAN, the network card generally had no boot-ROM. We found we could readily overcome those obstacles by putting the necessary files to imitate a boot-ROM on an old hard drive or on a USB Flash drive. The core of this article is devoted to explaining how simple it is to do so. Doing this completely avoids using floppy disks which, in Nicaragua, have simply become too unreliable.
The clients will work with just 32MB of RAM but seem happier with 64MB. Older machines with processor speeds of just 266MHz work okay, but processors with faster speeds obviously work better. Older mice, monitors and non-English keyboard layouts can be configured on the server if necessary. We found no configuration necessary for the majority of our hardware, thanks to the comprehensive LTSP software.
It is well worth investing resources in the server. We now use 1GB of RAM with a 2.4GHz processor and that provides really fast service for more than a dozen clients using Internet, office and game applications. It should be possible to run dozens of clients off one server if the server has adequate specifications. In this article, there's no space to say much about setting up the server for a thin-client network. A couple of excellent articles explaining how Linux Journal helped us do this have already been written by Kevin Brown (see Resources).
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development