Colin Mattoon

Subscribe to Colin Mattoon: eMailAlertsEmail Alerts
Get Colin Mattoon: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

How to create a Linux-based network of computers for peanuts (part 4)

Secrets to configuring Linux & X Window System for desktop use. Start with the right distribution!

(LinuxWorld) -- If you're just joining us in this series, I suggest reviewing part 1, part 2, and part 3.

Before we can install Linux on our users' PCs, we must select an appropriate Linux distribution. Back in part 3, we configured an application server, and I made no recommendation about which distribution you should use. I provided general guidelines for configuration of different initialization systems and some of the distributions that use them.

You may be tempted to use the same Linux distribution for the PC X terminals. Don't. At least, not until you read this installment.

Certainly, some of you will use late-model machines with far more RAM than required for the job. If you have 20 350-MHz PII machines with 64 megabytes RAM and 6-gigabyte hard drives at your disposal that another department is throwing away, then go ahead and recycle them as X terminals. If this is your situation, you can use any i386 Linux distribution. (You may skip most of what follows and rejoin us for the final configuration of the machines.)

The rest of us will focus on the hardware more often chosen for X terminal deployments: 80486 and Pentium processors up to 120 MHz, 8 to 16 megabytes of RAM, hard drives as small as 125 megabytes and rarely any larger than 850 megabytes. This is the sort of equipment that is now considered obsolete and worthless in many operations -- and usually becomes available during upgrades.

Step 1a. Pick the Linux distribution

Don't feel slighted if your favorite Linux distribution doesn't get favorable mention here. Different developers focus on their own vision of what a Linux distribution should do, how their customers will use it, and what sort of hardware they want to support. That doesn't mean that a particular distribution is bad.

In part 3, we defined our deployment as a small-scale demonstration to management so they can take a close look at how Linux revitalizes obsolete, fully amortized equipment. In addition to our application server (and one machine running Freesco or E-Smith as a dialup router/gateway), our table top LAN included eight machines as X terminals. These eight have no CD-ROMs, and significantly, no UPSes. Very basic, and very minimal.

XFree86 4.x doesn't provide support for some of the older video adaptors, and is not typically a requirement for a connection to an application server. A distribution based on XFree86 3.x is usually a better choice for older PCs used as X terminals. Don't worry if your application server was configured using the newer version of X. The two work and play well together.

Without CD-ROM drives, we need to look at Linux distributions that will install reliably over the network on older processors, with little RAM and small hard drives. Once installed and configured, the Linux distribution must recover gracefully from unexpected power outages, since we aren't going to provide a $125 UPS on a $25 PC that stores no user-created data.

We need to avoid Pentium II- or III-optimized distributions such as Mandrake and Corel. Provide their features to your users from the application server if you like, but the PC X terminals must run something else.

In my experience, Caldera's "LIZARD" graphical installation is uncooperative with old hardware. On this class of hardware, by the time you struggle through the more obscure (and essentially unsupported) "LISA" installation, you have to ask yourself, "Why bother?" My advice is to use Caldera for your application server, if Caldera is what you want to use, but look elsewhere for an X terminal OS.

Red Hat is installed on more Linux PCs than any other. While it supports network installation and will install on many older PCs, Red Hat is not my favorite. I find its installation utility often fails with a "Signal 11" during network installation on 486 and early Pentium machines with little RAM. I find it time consuming and confusing to eliminate enough unwanted packages to shoehorn Red Hat into small hard drives. In the aftermath of "dirty downs" (power failure, pulling the power cord, etc.), Red Hat often requires manual intervention by root as fsck tries to check and repair inodes on the hard drive. Give Red Hat its due. Like Caldera, Corel, Mandrake, SuSE and others, Red Hat offers an excellent Linux distribution. However, Red Hat focuses on newer hardware than we intend to use.

Debian is good choice. Debian's volunteer developers are rigorous in their adherence to i386 compatibility. It installs reliably both on minimal hardware and via the network. Debian is reasonably easy to fit into small hard drives. In fact, a common error I make when installing Debian is not installing enough packages at first. Of course Debian's apt-get makes adding the additional software quite painless and Debian has proven to me that it is very robust and nearly bullet-proof when recovering from improper shutdowns. Debian also supports installation via the Internet and that can really help introduce managers to the concept of free in all of its meanings.

While I do sometimes use Debian for X terminals, however, it is not my first choice. Debian has made installation much easier over the past year or two, but remains more time consuming than I like. If you intend to install Debian directly from the Internet on eight X terminals over a shared dialup line, pack a sleeping bag and rations. You are going to be at the office for a while. Get a CD instead! I have grown to appreciate Debian for specialized tasks, particularly where "apt" automates upgrade, download and installation of software packages, but not as much for highly repetitive tasks such as configuring a network of X terminals. Once configured, you aren't likely to want to upgrade or install additional software on them anyway, so the apt utility is of limited importance for X terminal administration.

I prefer Slackware. I usually use version 3.5 on the oldest machines and the smallest hard drives with 8 or 12 megabytes of RAM and 7.0 for slightly newer hardware as well as any box with 16 megabytes RAM and a hard drive larger than 200 megabytes. Slackware provides a highly reliable NFS installation, a couple of useful methods to probe for the model, irq and io of network cards, and represents a good compromise between ease of installation and low memory requirements. In addition, Slackware rarely requires manual intervention by an administrator after an improper shutdown. Like Debian, X terminals powered by Slackware almost always reboot and run fine with an automatic check and repair of the file system with fsck. (As you might expect, it doesn't take long to fsck small hard drives).

Slackware 8.0 is the latest release, and as I understand, the only version being packaged for sale in "Official Boxed Sets." Slackware 8.0 is an XFree86 4.x based release, and as such, isn't the ideal version for our purpose. However the earlier releases are readily available to download if you want to burn your own CD. Cheapbytes and others sell version 7.x inexpensively. Some retail outlets may still have some older versions in stock.

The best way to get Slackware 3.5 might be to purchase an Hungry Minds publication entitled Linux System Administration by Anne H. Carasik. This book includes a Slackware 3.5 CD inside the back cover. Hungry Minds also publishes Slackware Linux for Dummies, which includes Slackware 7.0. It never hurts to have a couple of basic books even if you don't need them. Chances are someone else in your organization might benefit from basic documentation.

In Part 5, I'll address network installation of Linux on X terminals for those who need additional help, but in this installment, for the convenience of those who already know how to install Linux over the network, we will move on to the configuration details specific to X terminals. First though, there are two other items that deserve mention.

Part 1b. Or, pick another flavor of Unix

If it runs X, it will probably work. FreeBSD is the only other operating system I have used for X terminals, and it works fine. I also haven't seen any real advantage to using FreeBSD over Linux and, in my limited experience, it appears to support a narrower cross section of hardware and is less extensively documented. Use it if you want, but this is a series on Linux X terminals.

Step 2. Understanding how to run diskless and dataless

I haven't addressed diskless and dataless techniques for several reasons:

  • It isn't specifically a method for configuring X terminals. Diskless Linux workstations can be used for nearly any purpose the same as any other Linux PC.
  • Diskless operation requires more advanced networking knowledge.
  • Bootproms and prom burners are more difficult to obtain in many cases than small, used hard drives. Not to mention that small, used hard drives are often available for free.
  • The alternative to bootproms is bootp on a floppy, and for people concerned about the reliability of "system pull" hard drives, check out the lack of quality control in the manufacture of floppy disks these days.
  • Diskless operation requires a terminal server computer to load their OS from every time they boot. This can be, but does not have to be, the same machine as the application server, but in either case, creates additional demand for server and network resources -- and since servers are usually newer hardware -- this can drive up costs when compared to the "Cheap and Easy" path we are taking.
  • Once it will boot, the essentials of configuring a diskless computer to act as an X terminal don't differ much from configuring a PC with a local hard drive. Most of the configuration, in either case, is a matter of first getting Linux and X to run on the machine, and most people are more familiar with installation on a local hard drive.

Nevertheless, you probably owe it to yourself to learn more about this method at some point. As network size increases, so does the likelihood that the increased complexity of server and network configuration inherent to diskless operation will be offset by reduced administrative overhead per workstation.

I question whether the savings in electrical power consumed by diskless stations is very significant compared to the juice a big CRT monitor on every desk sucks from the grid, but it won't hurt unless it causes you to add an additional server.

For this first deployment, I suggest you stick to "Cheap and Easy" for now and reserve the right to expand the network with diskless machines if the need ever arises.

Step 3. Configuring a PC as an X terminal

Network installation of Linux, for those who need the additional help, will be covered in Part 5 of this series. Beyond those particulars, installation and configuration will be similar to the installation performed on the application server in part 3.

Without regard to the Linux distribution you chose, you need to:

  1. Boot the installation program and create two Linux primary partitions on your hard drive. My suggested minimums for the root partition ( / ) are 125 megabytes and 16 megabytes for swap. More space for either is fine (provided the / partition falls below cylinder 1024 so LILO will work) but is not necessary.
  2. Install a base Linux system along with basic networking utilities and X. You will not need any window managers or user applications, i.e., Netscape, Lynx, etc., although it won't hurt to install those if you have disk space to spare.
  3. Configure the network interface. This is actually the first or second step in most network installations, but if your machines are equipped with CD-ROMs it is often done after the base system is installed. Following the plan described in part 3, our first X terminal will receive a network address of 192.168.1.20, the second will get 192.168.1.21 and so on. The netmask will usually be 255.255.255.0. Unless installing Debian directly from the Internet, it is advisable to leave entries for both DNS server and default gateway blank on a freestanding network. Test the networking configuration by pinging the application server.
  4. Choose a root password, but do not add any ordinary user accounts to the X terminals. (In Part 5 we will discuss an exception to this advice, but you don't need to worry about it now.) Since X terminals are best used behind a firewall, are usually not very powerful (so they aren't puissant tools for use in DOS attacks) and don't store data to corrupt nor Web servers to deface, I suggest using the same root password for each -- BUT NOT the same root password as your application server.
  5. Configure X so that the machine will open a "gray screen" when the "startx" command is entered. Just a blank gray screen with a mouse cursor (unless you wasted time and disk space to install a window manager, there is nothing for X to display). But do not configure /etc/inittab or, as the case may be, /etc/rc2.d or any other initialization script to boot the machine to X. As in the case of the application server configured in part 3, we first configure the X terminal to boot to the multi-user, networking, character-cell (command line) runlevel.
  6. Reboot.

And now (drum roll)...the moment you have been waiting for... as root, and at the command line, enter the following command:

/usr/X11R6/bin/X -query 192.168.1.10

In a few moments the XDM login window of the application server configured in part 3 should magically appear and permit you to login to the server and experience the awesome power of remote X.

Don't login and start celebrating just yet. We aren't done. Kill X with Ctrl + Alt + Backspace and get ready to use the vi text editor that comes standard in the base installation. (Sorry. You have more work to do.)

If you took my advice and installed Slackware, change to the /etc/rc.d directory and open rc.local with vi. At the bottom of that file add the command you tested at the command prompt a few moments ago -- just as you typed it before:

/usr/X11R6/bin/X -query 192.168.1.10

(Why 192.168.1.10? Because that's the address we assigned to the application server in part 3.)

Save your changes to rc.local and reboot. If you are running Slackware, you are done with basic X terminal configuration. Now, go repeat this process on the remaining X terminals.

For Debian users only

Debian users will probably find the following apropos.

As root, change to the /etc/init.d directory and with vi, create a new file called xterminal (or something similar). In it, you will create a two-line bash script that reads:

#!/bin/sh
/usr/X11R6/bin/X -query 192.168.1.10

And save your changes.

Next, make your script executable:

chmod 755 xterminal

And change to the /etc/rc2.d directory. There you will create a symlink to your script as the last step in booting the machine (Quite similar to configuration of the application server, no?)

ln -s ../init.d/xterminal S99xterminal

In that directory, the ls -l command should reveal your symlink as the very last entry:

S99xterminal -> ../init.d/xterminal

And if it does, you can reboot your machine and join the Slackware administrators in an orgy of self-congratulation before you go on to configure the remaining seven machines.

Red Hat, Caldera, SuSE users

One or either of these two methods will get the job done. Adjust your default runlevels and the location of the specific files to edit based on your particular distribution, but the essence for all distributions is:

Boot to a command line only, multi-user, networked runlevel, and as a last step in system initialization, either in rc.local or as a script you create (and link to) in init.d, the machine will run the command:

/usr/X11R6/bin/X -query 192.168.1.10

(Or whatever address you assign to the application server in your network.)

Installing without a CD-ROM drive

Watch for Part 5, where I explain how to install Linux over the network, and use applications, such as AbiWord, remotely from PC X terminals.

More Stories By Colin Mattoon

When not buried under his real job in commercial two-way radio system design and sales, Colin Mattoon is a part-time Linux system administrator at Northwest Communications in Lewiston, ID.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.