How to install Red Hat over a network

Part 6 in our series 'How to create a Linux-based network of computers for peanuts'

(LinuxWorld) -- It is tempting to draw an analogy between cooking and network administration. Slapping together pre-packaged convenience food may be easier than preparing a meal from scratch using fresh ingredients, but it isn't easier to eat, it actually costs far more and isn't as healthy over the long run.

Likewise, it might be easy for an administrator to set up a network using the pre-packaged convenience food from Microsoft that lines the shelves of software retailers. It is expensive, however, and saps resources while the lack of essential elements lowers your company's resistance to illness -- viral attack and ultimately, loss of data.

Linux server-centrism is similar to a kitchen that serves a family or a much larger organization. One cook can exploit economies of scale to satisfy the appetite of many. The Windows alternative is similar to forcing everyone to rummage through the cupboards for whatever they can find in a hurry.

Much as a moderately competent cook can combine simple and inexpensive ingredients to create a memorable and healthful meal, the Linux administrator can combine inexpensive hardware along with a free operating system and applications to create a minor server-centric masterpiece that provides users the necessities of computing while boosting their immunity to attack.

Ordinary users find the server-centric Linux system as easy to use as Windows: All the difficult system administrative tasks are handled for them by an administrator. The user simply points-and-clicks his or her way to applications that are similar, and often the same, as found in a Windows environment... just as eating a freshly prepared soup is no more difficult than sucking down salty, vitamin-depleted slop from a can.

This is why I believe Linux will conquer the enterprise desktop before it reigns supreme on the home front. Linux server-centrism is ideally suited to groups of people because it requires only one person to learn some basic recipes to cook-up Linux for droves of ordinary users who have no desire, and frankly, no need to learn much more than how to manipulate a mouse and enter their passwords.

In Part 1, Part 2, Part 3, Part 4, and Part 5 of this series, we explored the economy and technique of creating a basic server-centric network of Linux X terminals. In this installment, we take up the matter of performance as well as more tips for installing Linux on X terminals over the network. We also examine a problem reported by some Red Hat 7.1 users that dragged their configuration attempts to a screeching halt.

Unleash raw Pentium 75 power to blow the doors off a network of Pentium IIIs

A network of inexpensive X terminals that connect to an application server isn't for everyone. (Although maybe it is with the right server. The mental image of a physicist garbed in white lab coat, hunched over while pecking away at the keyboard of a ratty old 80386, his back turned to an IBM S/390 -- and a CAT 5 crossover cable connecting the two machines -- tickles me.)

This series, however, has been devoted to a more mundane collection of gear. Some people question how a time-sharing network that requires even a handful of users to coexist on one machine can provide acceptable performance running the latest desktop environments and applications -- unless that machine is so powerful that it dwarfs the specifications of the typical current production desktop box. OEMs are rising to the challenge of Windows XP and basic office productivity tasks are being conducted on single-user workstations with 1.4-GHz processors and 256 megabytes of RAM. How can something like an inexpensive 700-MHz machine -- even if it has 512 megabytes of RAM -- compete when five, 10, 15 or more users are logged on and sharing, what are by today's standards, minimal machine resources?

The answer, of course, depends on the applications these users are running. Huge number-crunching jobs and software compiling are probably not well suited to this approach and provide the impetus for other networking models that throw more processors, not fewer, at the problem. Hence, distributed processing across a network of powerful workstations, the Beowulf, the suspended Linux NOW project, and others.

Spreading the weight of StarOffice

Modern offices, however, share more basic needs:

  • Word processing and spreadsheets, including desktop publishing and image manipulation
  • E-mail
  • Web browsing
  • Financial accounting and book keeping

Browse the many Linux forums on the Internet and two primary objections emerge to more widespread adoption of Linux on the desktop: The learning curve for ordinary users and the need to maintain document exchange capabilities with other departments and organizations that persist in running Windows and Microsoft Office.

Server-centrism defeats the first objection. There is no user learning curve to overcome. Only the administrator, or administrators, need to learn anything about the operating system.

Sun Microsystems' "Free as in beer" StarOffice Suite (and increasingly, it's fraternal twin, Open Office) is the battering ram that breaks down the barriers to document exchange. StarOffice 5.2 is far more compatible with Microsoft Office 2000 applications than Microsoft's own Office 97. The still-beta StarOffice 6.0 promises to smash the doors to Microsoft Office XP. Alas, like a battering ram, StarOffice is big and heavy. Ponderous to load, the sheer size of the StarOffice binary ranks high among complaints when installed on workstations.

User's of powerful workstations with lots of RAM often report that StarOffice's splash screen takes 30 or 40 seconds to appear and as long as 1 minute before the desktop is ready for use. It's a shame they must suffer so. Typical load times at our company are less than 15 seconds for the splash screen and another 10 to 12 seconds for the desktop to load. That's with 486 and first-generation Pentium workstations, and a 586 as an application server over Thinnet.

Disk I/O, not processor speed, is the major problem for StarOffice use in a network of powerful workstations. The solution is time-sharing and a single installation of the StarOffice binary. Any organization that relies heavily on an office suite is likely to have, at any given time, at least a few people using that suite.

In a network that relies on distributed processing (a typical Windows implementation, or a network of Linux computers that relies on NFS), every time a user opens StarOffice, it loads a jillion megabytes worth of code from either the local hard drive, or across the network from a server's hard drive, to RAM in that user's workstation. Any Linux workstation with much less than 64 megabytes of RAM will begin to use swap space (virtual memory) heavily and with less than 32 megabytes of RAM many Linux machines will begin to thrash. StarOffice is also ported to Windows. On the Windows 98 installations I've seen, StarOffice requires between 96 and 128 megabytes RAM simply to run reliably without regard to load times.

Upgrading workstations to 1- or 2-GHz processors doesn't help much. Faster disk access times help some, as does ensuring that all the workstations have 128 megabytes of RAM or more, but the fact is that it takes time, and lots of it, to load a big application. Once loaded, the component applications within StarOffice will run okay, because they are dependent upon human input and people aren't any quicker than they were 1,000 years ago. It can take an eternity to open the suite and to switch between applications within it.

By contrast, our server-centric network typically loads the StarOffice suite once per shift. That's when the first user on a shift logs on and opens the suite. If they do this as soon as they report to work, chances are the first user sees a quick load time because the server hasn't paged StarOffice out of RAM after the departing workers log out. Even if the first user has to endure a 50-second delay while StarOffice opens, subsequent users scarcely have enough time to take a sip of coffee between clicking on the StarOffice icon and seeing the desktop ready for work.

The top utility helps tell the story. If you log in at the application server and at the command line enter: top while several users open the StarOffice Suite, you will see something interesting. The first instance of StarOffice will typically use 50 to 70 megabytes of RAM, but as each additional user opens the application in turn, top reports total RAM usage increasing by about 1 megabyte per user.

What's happening? Well, you bragged up Linux as a robust multi-user, multitasking operating system to your friends, didn't you? This is what it is all about. Load once, serve many from RAM. Share libraries and exploit unused processor cycles. It is the same principle as car pooling. An automobile with all the seats full will transport six people down the same highway at the same speed as six automobiles with only a driver on board -- and at less than one-sixth of the expense.

Seasoned Unix administrators aren't impressed with this bit of news -- they have known about it for years. Those whose experience is limited to peer-to-peer networking are often astounded. From a user perspective, the network seemingly speeds up under increasing load until finally, the server begins to swap. As administrator, your job is to determine how much RAM will prevent excessive use of swap space, and to see to it that enough RAM is installed. While 96 to 128 megabytes RAM in a standalone machine running KDE and StarOffice is becoming almost a necessity, our modest time-sharing application server with about 256 megabytes will easily handle five to 10 users -- and with 512 megabytes, its capabilities become very impressive.

Other large applications such as Corel's WordPerfect and Netscape also benefit, but don't illustrate the phenomenon quite as dramatically as StarOffice. There are not very many productivity applications that weigh in as heavy as StarOffice! There are also few productivity applications that enable migration from Windows to Linux like StarOffice.

Slackware network installation revisited

In Part 5 of this series, you learned how to deal with X terminals that don't sport local CD-ROM drives. Our example covered the basic steps to install Slackware 3.5 via the network, using the CD-ROM in our application server and the Network File System (NFS) to export the contents of the Slackware CD.

The technique as described in Part 5 will usually work well for other versions of Slackware up through version 4.0, but the newer Slackware 7.0, 7.1 and 8.0 releases require a different approach. Of course, many people will want to try another distribution. While I recommend Slackware for easy creation of X terminals, Red Hat stockholders and Debian fans may have other priorities! You might want to review Part 2, Part 4 and Part 5 of this series though. The least-expensive X terminal machine has a slow processor and little RAM. Don't waste effort trying to install a distribution that cannot work on the machine you intend to use. If the developers call for a Pentium II or better and 32 megabytes RAM or more, it isn't a good choice for a 486 with 12 megabytes RAM.

Remember that Slackware net.i boot disk I told you about in Part 5? No matter what Linux distribution or release number you choose to install, the Slackware net.i boot disk can be a very handy tool to discover information about your Ethernet card. Just pop it in the first floppy drive of the machine you intend to use as an X terminal and boot the floppy. Write down the results of it's probe for eth0 just as you did in Part 5, but then reboot the machine with the appropriate boot disk for the distribution you are installing, rather than proceeding with the Slackware installation. I might suggest the Slackware 4.0 net.i boot disk as the most appropriate diagnostic tool. You can download it to your application server's hard drive from Slackware's ftp site and use the dd utility to install it on a floppy:

dd if=net.i of=/dev/fd0

It isn't perfect, nor is it 100 percent reliable -- nothing is. But when confronted with a large stack of older machines and NICs, the Slackware net.i boot disk can save you hours you might have spent otherwise -- opening cases and examining NICs -- particularly if the distribution you are installing doesn't include auto-detection for the network device.

Since it fits on a single 3.5-inch floppy diskette, the net.i file is a reasonably quick and easy download even if all you have is a 33.6 kbps dial-up connection to the Internet.

Now, let's look at the changes in later versions of Slackware

It is slightly ironic that after touting the virtues of the net.i boot disk, newer versions of Slackware often won't install when using it! Time marches on and so does Linux -- and as a result, a different method is preferred.

If you are installing Slackware 7.0 through 8.0, you will require three freshly formatted floppies. Mount the CD in your application server's CD-ROM as per Part 5:

mount /dev/cdrom /mnt

Change to the bootdsks.144 directory:

cd /mnt/bootdsks.144

Use the ls command with the -l option to display the contents of the directory:

ls -l

You are looking for the bare.i boot image -- not the net.i image we used to install Slackware 3.5 or as a stand-alone diagnostic tool. The bare.i image is more or less the "standard" Slackware installation boot image used for most installations today whether the machine is equipped with an IDE ATAPI CD-ROM. Use dd (sort of repetitive, isn't it?) to create the boot disk:

dd if=bare.i of=/dev/fd0

(It goes without saying [since you already read Part 5] that you should remove and label the floppy after the lamp on the floppy drive goes out and you are returned to the command line, doesn't it?)

Next change to the rootdsks directory:

cd ../rootdsks

Just as with Slackware 3.5, create a color.gz root disk:

dd if=color.gz of=/dev/fd0

By now, you know the drill: Remove and label the floppy after the light goes out, etc.

Create the third installation disk. It is located in the rootdsks directory as well and is named network.dsk. Intuitive, isn't it?

dd if=network.dsk of=/dev/fd0

Stagger under the combined weight of all these floppies to the machine you propose to configure as an X terminal. Before you charge in and begin to install the latest version of Slackware, unless you already know what NIC is installed, I suggest you consider booting the machine with a Slackware 3.5 through 4.0 net.i boot disk to see if it detects your NIC. For example, ISA NE2000 cards are notorious and you really need to know the IO and IRQ values before you begin.

Place the Slackware bare.i disk in the first floppy drive and boot the machine. When asked for the root disk, replace the bare.i floppy with the color.gz disk and press enter. When instructed to login, login as root (no password) and just as with Slackware 3.5, create two primary partitions with fdisk.

After partitioning the hard drive, we don't simply type setup as we did under Slackware 3.5. We have to load a module for our network card before we can use it to access the remote CD-ROM on our application server. We simply type:


Press enter. You will be instructed to place the network disk you created in the floppy drive, so replace the color.gz root disk with network.dsk in the drive and press enter.

As you follow the prompts, the Slackware script will offer to probe for the NIC. This is fine unless you have a NIC that it can't autoprobe such as most NE2000 ISA cards. If that is your situation, decline the offer to autoprobe and open another console by pressing:


Login as root in this new console (no password) and enter the following command (the example assumes an NE2000 card with specific IO and IRQ values -- you must, of course, substitute the actual values for your card):

modprobe ne io=0x300 irq=10

After being returned to the command line, switch back to the first console:


Follow the prompts to remove the network disk. Once clear of the network utility, type:


Press enter, and proceed with the installation just as detailed for Slackware 3.5 in Part 5. The consistency of the Slackware installation between different releases is one of this distribution's many strong points.

Let's take a look at Red Hat

Red Hat's network installation is somewhat different from Slackware's. Like Slackware, it doesn't differ much from a "standard" installation from a locally installed CD-ROM. In Part 4, I wrote that my experience with Red Hat is that it is less tolerant of low memory and slow processors than either the earlier versions of Slackware or the latest stable Debian release. I also wrote that with Red Hat, it is more difficult to delete enough packages to shoe-horn it into the small hard drives that characterize our cheap-and-easy X terminals.

Because more people have installed Red Hat than any other distribution, I won't waste your time with a detailed description. I'll cover the essential points that make an NFS installation possible. We will cover a potential pitfall that renders a contemporary Red Hat installation temporarily unusable as either an X terminal or application server for a network of X terminals. Not to worry, though. The fix is easy.

Thanks to Ken Conrad, a helpful reader and experienced sysadmin, who e-mailed me to describe a problem he encountered with Red Hat 7.1, I became aware that Red Hat now incorporates a "personal firewall" configuration into the installation. This is not present in the 5.x and 6.x releases I am more familiar with, but is potentially, as Ken writes, "...a showstopper for many of your readers who may be newer to Linux. Perhaps you could address this in a paragraph or two in the next segment?"

Mea Culpa! I didn't know about this because I had not used the latest version of Red Hat. Thanks, Ken! We'll discuss below this firewall utility as part of the Red Hat 7.1 installation process.

I didn't have any CDs containing Red Hat 7.1 and its FTP server was under heavy load. Rather than wait out UPS or FedEx , I decided to drop in at a local software retailer and pick up an official boxed set. No luck -- they were sold out. Fortunately, they did have the latest edition of a Hungry Minds' publication entitled Linux Weekend Crash Course, authored by Naba Barkakati, and with a two-CD Publisher's Edition of Red Hat 7.1 inside the back cover. Good enough, and I saved enough loot to pick up a couple of six packs at the local supermarket on the way home. The guy who coined the phrase, "Free, as in beer" doesn't drink beer in my town.

The next morning, at work I sat down to configure an X terminal with Red Hat 7.1. The machine has only 16 megabytes RAM, but is a Pentium 75, and the installer ran without problem. With only a 400-megabyte hard drive, I had to root out a lot of packages to fit it in, and I also wanted to take the opportunity to test the personal firewall configuration on both X terminals and application servers in this one installation. Naturally, this made installation of a window manager necessary, and I chose TWM as the most lightweight option available.

You will require, in addition to the Red Hat 7.1 CDs, two freshly formatted floppies for the boot and driver disks. A third floppy, used to create a system boot disk during the installation, is optional. Refer to Part 3 of this series for some basics of configuring the application server as an NFS server before installation.

Red Hat step 1. Mount the CD-ROM

Login as root at your application server. Place the first CD from the Red Hat 7.1 distribution in the CD-ROM and use the same procedure to mount it as when performing a Slackware NFS installation:

mount /dev/cdrom /mnt

Change to the /mnt directory

cd /mnt

Red Hat step 2. Examine the file contents of the Red Hat CD

Use the now familiar ls -l command to display the contents:

ls -l

You should see a directory named images as the last entry. Change into that directory:

cd images

Run ls -l again to display this directory's contents. You should find seven files here in the Publisher's Edition. We are interested in two of them: bootnet.img and drivers.img. The bootnet.img is a compressed disk image used to boot the installation utility when a network installation is to be performed. (boot.img is the "standard" image used when installing from a local CD-ROM). drivers.img is necessary because the bootnet.img disk has only enough space for a few of the more common network card modules.

Red Hat step 3. Create the two floppies for installation

Place the first of the two freshly formatted floppy diskettes in the first floppy drive of the application server and use dd to create the boot floppy:

dd if=bootnet.img of=/dev/fd0

When the lamp on the floppy drive is extinguished and you are returned to the command prompt, remove the floppy and label it.

Place the second freshly formatted floppy in the server's first floppy drive and create the drivers disk:

dd if=drivers.img of=/dev/fd0

Same procedure. Wait for the light to go out. Label it, I tell you!

You are done at the application server, but leave the CD-ROM mounted.

Red Hat step 4. Prepare to boot the machine to be configured as an X terminal

Even though you are installing Red Hat, the additional step of booting a Slackware net.i disk first can save you some time. No, I'm not suggesting you boot into the Red Hat installation utility with a Slackware boot disk. Rather, I am suggesting you use the net.i disk as a diagnostic tool to discover the parameters of your NIC before installation. See above and Part 5 for details.

Place the bootnet.img disk in the X terminal's first (more likely, only) floppy drive and power on the machine. You may have to enter the BIOS setup to cause the computer to boot first from the floppy drive.

You will be presented with several installation options and information about them. Odds are, you will be okay with the default, so simply press enter to start the process.

Red Hat step 5. Select installation method

The Red Hat installer is pretty easy to use -- just follow the prompts and select NFS when it is time to do so. Enter the same values for network address and netmask as detailed in the Slackware 3.5 installation in Part 4: Static IP for our demonstration assumed to fall in the range of through, no DHCP, no default gateway. One difference between the Red Hat installation and a Slackware installation is that the host name entry includes the host and domain as one entry. Following the scheme for this demonstration deployment defined in Part 3:


for the first X terminal, and Xterm5.conference.table for the second, and so on.

Red Hat step 6. The drivers.img disk

Unless you are lucky enough to have a NIC that is both included in the netboot.img disk's limited selection and that can be auto-probed, you will be prompted to load the drivers disk. In this case, the machine has an Etherexpress 16 NIC that required me to use the drivers disk and select the module. Easy and intuitive provided you know what the card is. The Slackware net.iboot disk gave me this information.

Red Hat step 7. Tell the installer where to find the Red Hat installation directory

The CD with Red Hat 7.1 is in the CD-ROM of the application server, so enter that machine's IP. In our example, we use because that's the IP assigned to our cheap-and-easy application server.

You will be asked for the directory. Unlike Slackware, there isn't a subdirectory to worry about, so just enter:


The time that elapses between this step and resumption of an ordinary Red Hat installation will depend on:

  • Processor speed and RAM
  • Network speed and topology
  • Other network traffic
  • Speed of the CD-ROM in the application server

But get there, it will and from here on out, if you can perform a custom install of Red Hat from a locally mounted CD-ROM, you are on familiar ground.

Red Hat step 8a. One MAJOR exception!

Between disk partitioning (either with fdisk or Red Hat's Disk Druid utility) and Package selection you will encounter Red Hat's personal firewall configuration. This appears to be a front end to Gnome-Lokkit.

The screen will present you with three choices of firewalls: "Secure, Medium and No Firewall." Below that are three buttons: "OK, Customize and Back." The Publisher's Edition I installed defaulted to "Medium."

That doesn't work. The default firewall rejects packets on ports 177 and 6000. An X terminal must accept, as an absolute minimum, TCP connection on port 6000 (x11) or else the application server cannot connect to the xserver on the X terminal workstation. An application server, must accept, as an absolute minimum, UDP connection on port 177 (xdmcp) to manage X sessions for the X terminal machines.

Your choices are:

  1. Select "No Fire Wall" and rely on the separate firewall/gateway/router for security.
  2. Accept the default or secure entry and use "Customize" to define eth0 as a "trusted interface."
  3. Accept the default or secure choices and use "Customize" to open some ports.

If you select "No Firewall" and select "Customize," the installation utility points out that you are an idiot because you can't customize something that doesn't exist!

If you just want to open a port, and if this machine is to be used only as an X terminal, a line is provided for you to type:


Or, if this is only an application server for a network of X terminals you could open nothing more than port 177 with


Red Hat step 8b. After the fact

If you already installed Red Hat 7.1 and are having difficulties with X terminal operation, you can look at the firewall rules in effect by logging in as root and entering at the command line:

ipchains -L

The output will show you what connections are permitted. You still need to change the rules if they aren't what you need. As root, and at the command line, enter:


The front-end to the Gnome-Lokkit utility will appear as it did during initial installation for you to customize or eliminate as you see fit. Curiously, the default after installation is "Secure," whereas during installation it is "Medium," but is otherwise no different and you can run it as often as you like.

I regard a network of X terminals and the application server as inherently insecure and something to be protected from outside attack by a separate firewall machine. There are numerous exploits that use X and these ports, and by the time enough holes are poked into a firewall that NFS, telnet, etc., can be used, it is no longer a firewall -- it's a sieve.

You need to decide if the personal firewall included with Red Hat 7.1 is something you need. The Internet abounds with information on ports, firewalls, and security to help you decide. (See the resources below.) Just remember you can't have total security while providing services over a network, and there is no real substitute for a separate firewall to protect your LAN. Remember too, you can't reject services and expect to use them. The X terminal must accept an x11 connection and the application server must allow connection for xdmcp.

In the next installment, we will compare a Debian installation via the Internet to our NFS installations of Slackware and Red Hat, and explore some enhancements to our basic network. If more readers who are helpful provide input, we may also include additional tips and workarounds under the heading of "Not quite errata, and not quite Murphy's Law."

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.