Sysadmin

(LinuxWorld) -- In part 2 in this series, we reviewed the minimum specifications for both the application server and the PC X terminal machines. Each of these is equipped with a Linux-compatible Network Interface Card (NIC) and all are connected to an Ethernet -- either Thinnet (50-Ohm coaxial cable) or twisted pair (CAT-5) and a hub.

But first, a digression on networks

While this series is not an Ethernet HOWTO, I received a surprising amount of e-mail from readers protesting what they seem to interpret as an endorsement of Thinnet. A bit of clarification is in order.

There are few technical reasons not to use twisted-pair and 10- or 100BaseT Ethernet if that is what you prefer, and don't mind spending the money. Any up-to-date book on networks explains the advantages of this newer technology. My advice is for 50 or fewer devices, don't rip out an existing Thinnet installation and upgrade to new NICs and cabling thinking this will increase performance. For 50 or more PC X terminals, however, the equation tilts in the other direction.

Because practical use of X on Linux requires beefier graphics cards than Windows 3.x or Windows 95 (see part 2 for details), it might seem intuitive that running remote X applications will require tremendous network bandwidth. Not true! The X Window System is lean and elegant. As a result, packet collisions, network latency, and bandwidth are non-issues for networks of 40 or fewer PC X terminals.

Reliability issues with Thinnet are often the result of poor quality coaxial cable and connectors, improper installation of connectors, inadequate strain relief of cables, and people who disconnect cables without permission. If any of these are concerns in your organization, then by all means use twisted-pair.

However, there are a number of reasons why some may find Thinnet a good solution:

1. Many offices are already wired with Thinnet and upgrade is not an option. If the network is working with Windows 98 and NT, it will certainly work for X terminals.
2. Thinnet, particularly 100 percent shielded cables such as Times Microwave LMR-195, is less subject to Radio Frequency Interference (RFI) than twisted pair. If you are in an industry or location where this is a potential problem, you may wish to use Thinnet.
3. SOHO users may find that Thinnet lends itself to a relatively easy and unobtrusive installation on the exterior walls of older homes, by using the same techniques cable TV follow.
4. Thinnet is ideal for some demonstration and experimental deployments. The use of "obsolete" networking technology to connect a row of older machines on a large conference table can send a powerful message to managers who have been conditioned to accept the need for constant upgrade.
5. Thinnet is cheap. BNC NICs are often free and that can be a big plus for home users, students as well as cash-strapped small businesses and non-profit organizations.

That said, there might be a hidden cost to Thinnet. Here's a cautionary note, courtesy of William A. Yohman, who wrote me to say:

"...I think that those who would need to spend a small amount of money would be likely to skimp on the (coaxial) cables and cause themselves large headaches in the future..."

Configuring the application server

Application server configuration is an almost-trivial task. Everything you need is waiting, at no extra cost, in any major Linux distribution, including Caldera, Debian, Libranet, Mandrake, Red Hat, Slackware, SuSE, and TurboLinux.

Let's break this process into manageable blocks. If you already have an installed and at least partially configured Linux system, you can skip ahead.

Step 1. Knowledge you need before proceeding

You need a basic understanding of how to get Linux running, including how to

• Install a base Linux system
• Get the X Window System running on a local console
• Connect to the Internet (if desired)
• Configure a printer
• Add users and home directories
• Configure Ethernet, or at least understand network configuration scripts while installing Linux.

If you aren't ready, obtain a beginners guide to installing Linux and resume this project after some study and experimentation. The Linux Documentation Project is a good resource.

Step 2. Consider security

Security needs differ between organizations, and it is up to each system administrator to ensure that the basic configurations detailed in this series are adapted to meet their own requirements. In my opinion (I'm certain some will disagree!) this basic configuration is adequately secure for the majority of small business and home use. I do recommend a separate Internet gateway/router such as Freesco, or your own custom configured Linux firewall, although nothing prevents you from installing a modem on the application server and configuring diald or other utility for a direct connection to the Internet -- either on demand or by script.

As always, it's up to you to ensure that your network meets your organization's security needs. Start with the Linux Security HOWTO to learn more.

Step 3. Define the scope of this deployment

Let's assume we are setting up a freestanding network. Therefore, we'll use a static IP address for each machine. We won't complicate this article with dhcp and nameservers.

Let's set up 10 machines.

• File/print/application server (our mini-mainframe)
• Dialup gateway/router running a specialized Linux distribution such as Freesco or E-Smith
• Eight PCs configured as X terminals

Why eight X terminals? I'm assuming you're following along warily, and are devoting cast-off PCs and two tables to this effort. Each X terminal gets a side of a table, and our two servers get the floor. (No doubt once you see how well a "Linux network of computers for peanuts" works your network will expand greatly.)

Step 4. Assign network addresses

We will arbitrarily decide to use Class C addresses and assign a static address of 192.168.1.1 to our gateway/router, an address of 192.168.1.10 to our server, and addresses in the range of 192.168.1.20 through 192.168.1.27 to the X terminal PCs.

We can name the machines and our domain as well. These names and addresses won't get out on the Internet, so we can be creative. Our gateway will be named "gateway," our application server, "server," and each of the X terminals will be called "Xterm1, Xterm2," and so on. We can call our domain, "conference.table." Thus, our application server is "server.conference.table," and one of the X terminals is "Xterm5.conference.table."

I recommend tagging each machine with its address and host/domain names using a Dymo Label Maker.

Step 5. Get started

If the Linux distribution you chose will be installed from the Internet, the first order of business is to get the gateway up and running. If not, then install Linux and configure the application server as a networked workstation with X Window System that several people might share -- one at a time -- by sitting down to the local console and logging on.

Nothing out of the ordinary here. Don't be confused by the fact that this machine will serve as an application server. We want a basic graphical workstation installation. With many, perhaps most, Linux distributions you can follow the default choices for a workstation. Red Hat users in particular will want to avoid a "Server Installation" and choose instead, "Custom."

If you like, you may as well add some of the user accounts now, and set up their /home directories. Again, nothing out of the ordinary -- just set them up as if each user will sit down to this machine's local console to work.

Step 6. Configure the network interface

Our network configuration will not be complicated. We should be able to, at minimum, ping between machines -- for example, the gateway machine from the application server and vice versa. One of the reasons I appreciate Slackware is its netconfig utility. This is an easy-to-use tool that permits the administrator to enter the host name, domain name, netmask, IP address and so on. No matter what distribution you elect to use, if it is reasonably up-to-date it will provide a script during the installation to enter your network information.

The Linux kernel needs support for specific network cards compiled in, or loaded as a module. The distribution you use may be able to "autoprobe" for the NIC installed in your machine and configure the system to automatically load a kernel module -- you may be able to use "modprobe" or you might have to uncomment the line for your NIC in a rc.modules file -- but if not -- about the only generic remedy common to most all Linux distributions is to compile in support for your card.

Of course, this isn't unique to networks of X terminals. Any use of Ethernet requires configuration of the network interface, and detailed directions are readily available.

Step 7. Start XDM automatically

For our demonstration, we will use XDM, the X Display Manager, to provide a graphical login window for users, rather than logging in at the command line and starting X with the startx command. The method used to boot to XDM varies somewhat between distributions and there is some latitude available to system administrators as to how they invoke XDM. Different distributions also define runlevels differently.

For example, Red Hat customarily defines runlevel 3 as the multi-user, networking, command line runlevel and runlevel 5 as the multi-user, networking, graphical runlevel. Slackware, on the other hand, defines runlevel 4 as the graphical runlevel. Debian typically uses the default runlevel and starts XDM from a script in /etc/init.d.

Let's look at some real world examples:

If running Slackware, you can open /etc/inittab with a text editor and change a line that reads:

id:3:initdefault

to

id:4:initdefault

Alternatively, you could leave /etc/inittab alone, and simply allow the computer to boot to runlevel 3. In /etc/rc.d/rc.local, you would use a text editor to add a line at the bottom of the file that reads:

/usr/X11R6/bin/xdm

This causes the machine to start XDM after the other initializations scripts are complete.

Following installation of XDM, a Debian administrator might need to add a symlink to the XDM script in /etc/init.d by changing to the /etc/rc2.d directory and entering the following command:

ln -s ../init.d/xdm S99xdm

If you now run the "ls" utility in the rc2.d directory, the resulting link in rc2.d will look like this:

S99xdm -> ../init.d/xdm

which will cause the xdm startup script to run when the machine boots to the default runlevel.

There are slight differences between distributions in the precise location of files and whether they follow a "System V" style initialization scheme, or if they emulate BSD in appearance. Some distributions provide a choice between using rc.local or symlinking to a bash script in init.d. But, without regard to the individual differences, all these scripts will be found in the /etc directory and can be found in a matter of a few seconds.

Step 8. Allow remote X users to login

In fact, if you are installing an older distribution on this machine, and don't intend to use it during a network installation of Linux on the X terminal PCs, you may be done.

Most contemporary Linux distributions, however, no longer permit remote X devices to grab the XDM login window by default. Until you deliberately edit one or two files, no other machine can act as a dumb terminal connected to this server machine through the network.

Most XFree86 3.x based distributions require you to open a file called Xaccess, usually located in /etc/X11/xdm. Using a text editor, such as vi, open this file and scroll down to about line number 40. You should see a line that reads:

#*                    #any host can get a login window

Your immediate task is to "uncomment" that line -- in other words -- to remove that "#" at the beginning of the line, because you want other hosts -- your X terminals -- to be able to get the GUI login window of your application server. Once you are done, the line should read:

*                     #any host can get a login window

Save this change to the file.

If you happen to be installing a distribution that uses the newer XFree86 4.x windowing system, you have one more file to edit, called xdm-config, and also found in /etc/X11/xdm.

Open xdm-config with a text editor and scroll to the bottom of the file. You will note that lines are commented out in this file with "!" rather than "#" -- but don't let that bother you! Here you should find three lines that read:

! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
DisplayManager.requestPort:  0

Well, duh. We do want to manage X terminals with xdm. That's why you are reading this article! So add ! to that last line so that it now reads:

! DisplayManager.requestPort:  0

And save your changes to the file.

That's it? That's all there is to setting up an application server? Yes. Don't be surprised. You were promised cheap and easy. At this point, remote users (i.e., users not on the console) can use X applications running on the server as if the applications we running locally.

Step 9. Enable remote use of the server's CD-ROM drive

There is one other thing you might want to do on the server. If you want to use the CD-ROM drive in this application server to install Linux on each of the X terminal PCs, open /etc/exports and add a line that reads either:

/mnt (ro)

or

/mnt/cdrom (ro)

depending on how you mount the CD-ROM on this machine with the distribution you use.

Reboot the application server, grab your favorite beverage to celebrate a job well done and stay tuned for Part 4. You will find X terminal configuration to be just as easy, and we will cover a few tips and tricks to tailor the installation to various common Linux distributions.