Installing Red Hat Linux

This installation guide assumes you will boot off the CD-ROM to start the Red Hat installation
procedure. If you have an older machine not capable of booting off the CD-ROM, you will
need to use a boot disk and start the procedure from there.

Creating a Boot Disk
Once Windows has started and the CD-ROM is in the appropriate drive, open an MS-DOS
Prompt window (Start | Program Menu | MS-DOS Prompt), which will give you a command
shell prompt. Change over to the CD-ROM drive letter and go into the dosutils directory.
There you will find the rawrite.exe program. Simply run the executable; you will be prompted
for the source file and destination floppy. The source file will be on the same drive and is called /images/boot.img.
You can find more detail on this process at http://www.redhat.com/docs/manuals/linux/
RHL-8.0-Manual/install-guide/s1-steps-install-cdrom.html.

Starting the Installation
To begin the installation process, boot off the CD-ROM. This will present you with a splash
screen introducing you to Red Hat 8.0. At the bottom of the screen will be a prompt that reads

boot:

If you do not press any key, the prompt will automatically time out and begin the graphical
installation process. You can press ENTER to start the process immediately.

If you don’t have a mouse, or if the installer cannot find yours, you will be presented with
a screen that asks whether you want to use the text mode installation or you want to help the
installer figure out what kind of mouse you have. Use the TAB key to select which choice you
want, and press ENTER to continue. If you proceed with the text mode, you will find that the
basic steps to the installation are similar to those for the graphical interface, and you should be
able to follow along with this installation guide. If you need additional help, you can visit Red
Hat’s help page for the text-mode installation at http://www.redhat.com/docs/manuals/linux/
RHL-8.0-Manual/install-guide/s1-guimode-textinterface.html.

Welcome to Red Hat Linux
The installer’s first graphical screen welcomes you to Red Hat Linux (see Figure 2-1). The
interface works much like any other GUI interface. Simply point to your selection and click.
Notice that context-sensitive help appears on the left side of the screen. If you don’t want
to see it, you can click the Hide Help button at the lower-left part of the screen. The Back
button in the lower right of the screen is grayed out at this point, because there have been no
prior options to select.

This screen isn’t very challenging: there aren’t any choices to be made. When you are
ready to continue, click the Next button in the lower-right portion of the screen.

Choosing a Language
The first menu will ask which language you want to use to continue the installation process
(see Figure 2-2). Once you have chosen the desired language, click Next to continue.

Figure 2-1 The first installer screen welcomes you to Red Hat Linux.

Figure 2-2 Select the language to be used during installation.

Selecting a Keyboard Type
This next menu enables you to select what kind of keyboard you have. For most people,
the keyboard type will be selected according to language and geography (see Figure 2-3).
A Dvorak keyboard layout may be selected here if you prefer it. When you are done, click Next to continue, or click Back to go back to the language selection menu.Figure 2-3 Select the preferred keyboard layout.

Selecting a Mouse
You now can select the type of mouse you want to use with the X Window environment. More
than likely, the autoprobe will have been able to identify what kind of mouse you have.
If you need to help Linux, simply pick your mouse type from the top menu box (see
Figure 2-4). The Generic settings work well in most cases, but you can scroll through the list
of manufacturers and look for the maker of your particular mouse. Click on the triangle to the
left of the vendor’s name to open a new level of choices for that particular brand.
If you have a serial mouse, you will also need to select the serial port it is using, which
you can do in the lower box of the screen.

If you have a two-button mouse, click Emulate 3 Buttons at the bottom of the screen,
because some features of the X Window environment work with a three-button mouse only.
The emulation allows you to click both buttons of a two-button mouse to simulate the third
(middle) button.

Figure 2-4 Select the mouse description that most closely matches your hardware.

Installation Type
With the language and input devices selected, you are now ready to begin the actual installation
phase of Red Hat Linux. You will see a screen that lets you pick how you want to install Red
Hat Linux. If you are on an upgrade path, this selection is easy—simply click Upgrade and
then click Next. You’ll see some screens informing you of what is being currently upgraded.
This module assumes that you’re doing a clean installation. This will wipe all the existing
contents of the disk before freshly installing Red Hat 8.0.

Note that under the Install button is an option to install Linux in a Server configuration
(see Figure 2-5). This method has all of the packages selected for you, as well as a disk partitioning scheme. While that can be a fine starting point for playing with Linux, for this
module, you want to choose Custom so that you can fine-tune what you install and how you
configure it.

Creating Partitions for Linux
Since you selected the custom installation, you will need to create partitions for Linux to
install on. If you are used to the Windows installation process, you will find that this process
is a little different from how you partition Windows into separate drives.

In short, each partition is mounted at boot time. The mount process makes the contents of
that partition available as if it were just another directory on the system. For example, the root

Figure 2-5 For this module, perform a Custom installation of Red Hat Linux.

directory (/) is the topmost directory in the structure. In a simple configuration (for example, the one performed when you choose the Automatically Partition option in a custom installation),
the system’s entire directory structure will be created on a single partition. More complicated
configurations make more sense in most cases. For example, a standard Linux subdirectory
called /usr will exist in the root directory, but it will have nothing in it. A separate partition
can then be mounted such that going into the /usr directory will allow you to see the contents
of the newly mounted partition (see Figure 2-6).

Since all of the partitions, when mounted, appear as a unified directory tree rather than
as separate drives, the installation software does not differentiate one partition from another.
All it cares about is into which directory each file goes. As a result, the installation process
automatically distributes its files across all the mounted partitions, as long as the mounted
partitions represent different parts of the directory tree where files are usually placed. Under
Linux, the most significant grouping of files is in the /usr directory, where all of the actual
programs reside. (In Windows terms, this is similar to C:\Program Files.) Because you are configuring a server, you need to be aware of the additional large groupings of files that will exist over the life of the server. They are:
● /usr, where all of the program files will reside (similar to C:\Program Files).
● /home, where everyone’s home directory will be (assuming this server will house them).
This is useful for keeping users from consuming an entire disk and leaving other critical
components without space (such as log files).
● /var, the final destination for log files. Because log files can be affected by outside users
(for instance, individuals visiting a web site), it is important to partition them off so that no
one can perform a Denial of Service (DoS) attack by generating so many log entries that
the entire disk fills up.

Figure 2-6 The contents of the /usr directory can be mounted on a separate partition from the
root directory.

● /tmp, where temporary files are placed. Because this directory is designed so that it is
writable by any user (similar to the C:\Temp directory under Windows), you need to
make sure arbitrary users don’t abuse it and fill up the entire disk; you ensure this by
keeping it on a separate partition.
● Swap. This isn’t a user-accessible file system, but it is where the virtual memory file is
stored. Although Linux (and other UNIXs, as well) can use a normal disk file to hold
virtual memory the way Windows does, you’ll find that having it on its own partition
improves performance.

Now you see why it is a good idea to create multiple partitions on a disk rather than a
single large partition, which you may be used to doing under Microsoft Windows. As you
become more familiar with the hows and whys of partitioning disks under Linux, you may
choose to go back to a single large partition. At that point, of course, you will have enough
knowledge of both systems to understand why one may work better for you than the other.
Now that you have some background on partitioning under Linux, let’s go back to the
installation process itself. The installation screen gives you three options (see Figure 2-7):
automatically partition the disk, manually partition the disk with Disk Druid, or manually
partition the disk with fdisk.

Figure 2-7 Hard disk partitions can be configured automatically, or manually using Disk
Druid or fdisk.

You don’t want to use the first option, because you want tight control over how the disk
gets allocated in a server environment. And while using fdisk is extremely powerful, it can
also be a bit daunting at first. (Don’t worry: it is covered in Module 7.) So this leaves you with
Disk Druid. Simply select Disk Druid and click Next. This will take you to Figure 2-8.
The Disk Druid partitioning tool was developed by Red Hat as an easy way to create
partitions and associate them to the directories as which they will be mounted. When starting
Disk Druid, you will see a graphical representation of the disk’s partition layout, as well as
detail on all of the existing partitions on your disk. Each partition entry will show the
following information:
● Device Linux associates each partition with a separate device. For the purpose of
installation, you need to know only that under IDE disks, each device begins with
/dev/hdXY. Here, X is either:
● a for IDE Master on the first chain
● b for IDE Slave on the first chain
● c for IDE Master on the second chain
● d for IDE Slave on the second chain

Figure 2-8 The Disk Druid starts by displaying the existing disk partitions.

Y is the partition number of the disk. For example, /dev/hda1 is the first partition on the
primary chain, primary disk. SCSI follows the same basic idea, except instead of starting
with /dev/hd, each partition starts with /dev/sd and follows the format /dev/sdXY, where X
is a letter representing a unique physical drive (a is for SCSI id 1, b is for SCSI id 2, and
so on). The Y represents the partition number. Thus /dev/sdb4 is the fourth partition on the
SCSI disk with id 2. The system is a little more complex than Windows, but each partition’s
location is explicit—no more guessing, “What physical device does E: correspond to?”
● Mount point The location where the partition is mounted. Initially, this should not
contain any entries.
● Type The partition’s type. Red Hat Linux’s default type is ext3, but Disk Druid also
understands many others, including FAT, FAT32, and NTFS.
● Format Indicates whether the partition will be formatted before Linux installation.
● Size Partition size in MB.
● Start Partition’s initial cylinder number.
● End Partition’s ending cylinder number.

In the middle of the screen are the buttons for controlling what you do with Disk Druid.
These buttons are:
● New Create a new partition.
● Edit Change the parameters on the highlighted partition.
● Delete Delete the highlighted partition.
● Reset Undo all of the changes you’ve made to the partition table but have not committed to.
● RAID Use this button to create a partition in which data is distributed among multiple
drives. This can be useful for increasing disk read performance or providing data redundancy.
While this installation guide does not cover RAID installations, Red Hat provides extensive
information on RAID concepts and configuration at http://www.redhat.com/docs/manuals/
linux/RHL-8.0-Manual/custom-guide/ch-raid-intro.html.
● LVM The Logical Volume Manager (LVM) approach to disk space allocation is
designed to make resizing the system’s disk space easier on the fly. Configuring LVM is
beyond the scope of this guide, but more information is available at http://www.redhat.com/
docs/manuals/linux/RHL-8.0-Manual/custom-guide/ch-lvm.html.
● Next Commit all changes to disk.
● Back Abort all changes made using Disk Druid and exit the program.

Sizing Partitions: The exact amount of space you allocate to each partition depends on
how much space you have and what you plan to do with it. All the same, there are some basic
guidelines for sizing partitions in Red Hat Linux 8.0. If you install all the partitions suggested
in this module, the basic sizing parameters look like this:
Adding a Partition: To create a new partition, click New. This will bring up a dialog box
where each of the elements in the dialog box should resemble those in Figure 2-9:
● Mount Point The directory where you want this partition to be automatically mounted
at boot time.
● File System Type The type of partition that will reside on that disk. By default, you will
want to select ext3 except for the swap partition (which should be of type “swap”).
● Allowable Drives Specifies onto which drives the partition can be created.
● Size (MB) The size of the partition in megabytes.
● Additional Size Options If you know the exact size you wish to make the partition,
select Fixed Size. The second option allows you to instead set a maximum size, while the
last option allows Disk Druid to make the partition as large as possible.
● Force to be a primary partition If this box is checked, the partition being added cannot
be an “extended” partition. You are unlikely to have a reason to set this option; let Disk
Druid configure the disk partition details.
● Check for bad blocks If you have an old or questionable hard disk, it’s worth setting
this option, but it takes much longer to format the partition if you do. Once you are done
entering all of the information, click OK to continue.

Figure 2-9 Add a new partition using Disk Druid.

At a minimum, you need to have two partitions: one for holding all of the files and the other
for swap space. Swap space is usually sized to be double the available RAM if there are fewer
than 128MB of RAM, or the same size as the amount of RAM if there are more than 128MB.
Ideally, you will want to separate partitions for /usr, /var, /home, and /tmp in addition to a
root partition. Obviously, you can adjust this equation according to the purpose of the server.

Other Partition Manipulation Tasks : Once you have gone through the steps of adding a partition, and you are comfortable with the variables involved (mount points, sizes, types, devices, and so on), the actual process of editing and deleting partitions is quite simple. Editing an entry means changing the exact same entries that you established when you added the partition, and deleting an entry requires only that you confirm that you really want to perform the deletion.
After you have configured the partitions and mount points as you want them, click Next to continue.

Installing the Boot Loader
GRUB is the default boot manager for Red Hat Linux 8.0. If you aren’t already familiar with
what it does, a boot manager handles the process of actually starting the load process of an operating system. If you’re familiar with Windows NT, you have already dealt with the NT
Loader (NTLDR), which presents the menu at boot time, allowing you to select whether you
want Windows NT or Windows NT (VGA only). You may also have run across NTLDR if
you’ve set up a Windows machine in a dual boot configuration. GRUB performs the same
function for Linux systems.

The Red Hat tool’s screen for setting up GRUB has three sections (see Figure 2-10). The top section includes a list of the bootable partitions and a button for changing the boot loader to LILO (or for not enabling a boot loader at all).

The middle block of this configuration screen allows you to select whether you want
to enable password protection on the boot loader. You want to enable this to prevent

Figure 2-10 Configure the GRUB boot loader to boot Linux.

unauthorized access to the boot settings, so click the check box, which will bring up the
password box as shown.

The check box in the last section of the boot loader configuration screen allows you to set
somewhat more esoteric features of the boot loader. If you check the box and click Next, you
will get an advanced configuration screen (see Figure 2-11).

GRUB sets up on the master boot record (MBR) or the first partition on which Linux resides. The MBR is the very first thing the system will read when booting a system. It is essentially the point where the built-in hardware tests finish and pass off control to the

Figure 2-11 Set the boot loader’s location and pass parameters to the kernel.

software. This is the default; if you allow GRUB to be installed here, its graphical boot menu will load when you power on or reboot your system, and it will allow you to select which operating system to load. In a server configuration, there may be choices of Linux kernels to load, but there should just be one operating system option!

If you are already using another boot loader and prefer it, then you will want to place GRUB
on the first sector of the root partition. This will allow your preferred boot loader to run first
and then pass control off to GRUB, should you decide to start Linux. Figuring out how to notify
your preferred boot loader that there’s a new operating system available is up to you. This screen also has an option to Force LBA32, which uses linear mode. This applies only to some SCSI drives or drives that are accessed in LBA mode, so unless you know that it applies to you, or are experimenting, leave the box unchecked.

The last option on this advanced configuration screen is a box that allows you to enter kernel parameters to be used at boot time. Most people can ignore this box. If the documentation for a particular feature or device requires you to pass a parameter here, add it; otherwise, leave it blank.

Installing Linux in a Server Configuration

Akey attribute in Linux’s recent success is the remarkable improvement in installation
tools. What once was a mildly frightening process many years back has now become
almost trivial. Even better, there are many ways to install the software; CD-ROMs are no
longer the only choice (although they are still the most common). Network installations are
part of the default list of options as well, and they can be a wonderful help when installing a
large number of hosts.

In most cases, designating a system as a server will enable more services than you want.
A single Linux system is capable of providing all sorts of services: disk, printers, mail, news,
web, chat, and more. Many of these services are turned on automatically. But the reality is that
most servers are dedicated to performing one or two tasks, and any other installed services
simply take up memory and drag on performance, as well as provide hackers another avenue
of attack.

This module discusses the installation process as it pertains to servers. This requires you to
do two things: differentiate between a server and a client workstation and streamline a server’s
operation in terms of its dedicated functions.
You will go through this process for Red Hat Linux, which you will find on the CD-ROM
that came with this book.

Performing Preinstallation Evaluation
Before getting into the actual installation phase, it is important that you take a moment and
evaluate two things:
● The hardware the system is going to run on
● The server’s ideal configuration to provide the services you need
Let’s start by examining hardware issues.

Hardware
As with any operating system, before getting started with the installation process, you should
determine what hardware configurations would work. Each commercial vendor publishes a
hardware compatibility list (HCL) and makes it available on its web site. Red Hat’s hardware
support site is at http://hardware.redhat.com, where you can search a compatibility database
for systems or components. In general, most popular Intel-based configurations work without
difficulty.

A general suggestion that applies to all operating systems is to avoid cutting-edge hardware
and software configurations. While they appear to be really impressive, they haven’t had the
maturing process some of the slightly older hardware has gone through. For servers, this usually isn’t an issue, since there is no need for a server to have the latest and greatest toys,
such as 3-D video cards. After all, your main goal is to provide a highly available server for
your users, not to play Doom. (Although it should be noted that I, myself, during my less
responsible days as a junior-level administrator, found that Linux is wonderfully stable even
while running Doom and being a file server.)

Server Design
When a system becomes a server, its stability, availability, and performance become a
significant issue. These three factors are usually improved through the purchase of more
hardware, which is unfortunate. It’s a shame to pay thousands of dollars extra to get a system
capable of achieving in all three areas when you could have extracted the desired level of
performance out of existing hardware with a little tuning. With Linux, this is not hard. Even
better, the gains are outstanding!

The most significant design decision you must make when managing a server configuration
is not technical but administrative. You must design a server to be unfriendly to casual users.
This means no cute multimedia tools, no sound card support, and no fancy web browsers
(when at all possible). In fact, it should be a rule that casual use of a server is strictly prohibited—not only to site users but site administrators as well.

Another important aspect of designing a server is making sure that it has a good environment.
As a system administrator, you must ensure the physical safety of your servers by keeping
them in a separate room under lock and key (or the equivalent). The only access to the servers
for nonadministrative personnel should be through the network. The server room itself should
be well ventilated and kept cool. The wrong environment is an accident waiting to happen.
Systems that overheat and nosy users who think they know how to fix problems can be as
great a danger to server stability as bad software (arguably even more so).

Once the system is in a safe place, installing battery backup is also crucial. Backup power
serves two key purposes: to keep the system running during a power failure so that it may
gracefully shut down, thereby avoiding file damage or loss; and to ensure that voltage spikes,
drops, and other noises don’t interfere with the health of your system.

Here are some specific things you can do to improve your server situation:
● Take advantage of the fact that the graphical user interface is uncoupled from the core
operating system, and avoid starting the XWindow System (Linux’s GUI) unless someone
needs to sit at the console and run an application. After all, like any other application, X
requires memory and CPU time to work, both of which are better off going to the server
processes instead.
● Determine what functions the server is to perform, and disable all other functions. Not
only are unused functions a waste of memory and CPU, they complicate the process of
securing the server.
● Unlike some other operating systems, Linux allows you to pick and choose the features
you want in the kernel. The default kernel will already be reasonably well tuned, so you
won’t have to worry about it; but if you do need to change a feature or upgrade the kernel,
be picky about what you add and what you don’t. Make sure you really need a feature
before adding it.

NOTE
You may hear an old recommendation that you recompile your kernel to make the most
effective use of your system resources. This is no longer true—the only reason to recompile
your kernel is to upgrade or add support for a new device. Remember: Once a server is
in use, don’t change what’s stable and performs reasonably well without a good reason.

Uptime
All of this chatter about taking care of servers and making sure silly things don’t cause them to
crash stems from a long-time UNIX philosophy: Uptime is good. More uptime is better.
The UNIX (Linux) uptime command tells the user how long the system has been running
since its last boot, how many users are currently logged in, and how much load the system is
experiencing. The last two are useful measures that are necessary for day-to-day system health
and long-term planning. (For example, the server load has been staying high lately, so maybe
it’s time to buy a faster/bigger/better server.)

But the all-important number is how long the server has been running since its last reboot.
Long uptimes are a sign of proper care, maintenance, and, from a practical standpoint, system
stability. You’ll often find UNIX administrators boasting about their server’s uptimes the way
you hear car buffs boast about horsepower. This is also why you’ll hear UNIX administrators
cursing at system changes (regardless of operating system) that require a reboot to take effect,
even though applying the latest kernel security patch may justify that reboot. You may deny
caring about it now, but in six months you’ll probably scream at anyone who reboots the system
unnecessarily. Don’t bother trying to explain this phenomenon to a nonadmin, because they’ll
just look at you oddly. You’ll just know in your heart that your uptime is better than theirs.

Dual-Booting Issues
If you are new to Linux, you may not be ready to commit to a complete system when you just
want a test drive. All distributions of Linux can be installed on only certain partitions of your
hard disk while leaving others alone. Typically, this means allowing Microsoft Windows to
coexist with Linux.

Because you are focusing on server installations, the text will not cover the details of
building a dual-booting system; however, anyone with a little experience in creating partitions on a disk should be able to figure this out. If you are having difficulty, you may want to refer
to the installation guide that comes with your distribution or another one of the many available
beginner’s guides to Linux.
Some quick hints: If a Windows 95 or Windows 98 partition currently consumes an entire
hard disk as drive C:, you can use the fips tool to repartition the disk. Simply defragment and
then run fips.exe. If you are using Windows NT/2000 with NTFS and have already allocated
all the disk with data on each partition, you may have to move data around a bit by hand to
free up a partition. Don’t bother trying to shrink an NTFS partition, though; because of its
complexity, it doesn’t like being resized, and doing so will lead to corruption.

You may find using a commercial tool such as Partition Magic to be especially helpful,
because it offers support for NTFS, FAT32, and regular FAT, as well as a large number of
other file system types. Its user interface is also significantly nicer than fips.

If you’re going to be installing a dual-boot system, install Linux last. If you install
Windows last, it will clobber the boot information for your Linux system. If you install Linux
last, it will recognize that you have Windows installed and let you choose which one you want
to boot by default. Linux gets an “A” for citizenship.

Methods of Installation
With the improved connectivity and speed of both local area networks and Internet connections,
it is becoming an increasingly popular option to perform installations over the network rather
than using a local CD-ROM.

In general, you’ll find that network installations become important once you’ve decided to
deploy Linux over many machines and therefore require a fast installation procedure in which
many systems can install at the same time.

Typically, server installations aren’t well suited to automation, because each server usually
has a unique task; thus, each server will have a slightly different configuration. For example, a
server dedicated to handling logging information sent to it over the network is going to have
especially large partitions set up for the appropriate logging directories, compared with a file
server that performs no logging of its own. (The obvious exception is for server farms where
you have large numbers of replicated servers. But even those installations have their nuances
that require attention to detail specific to the installation.)

Because of this, you will focus exclusively on the technique for installing a system from a
CD-ROM. Of course, once you have gone through the process from a CD-ROM, you will find
performing the network-based installations to be very straightforward.

If It Just Won’t Work Right . . .
You’ve gone through the installation procedure . . . twice. This book said it should work.
The installation manual said it should work. The Linux guru you spoke with last week said
it should work. But it’s just not working.

In the immortal words of Douglas Adams, don’t panic. No operating system installs
smoothly 100 percent of the time. (Yes, not even the Mac OS!) Hardware doesn’t always work
as advertised, combinations of hardware conflict with each other, that CD-ROM your friend
burned for you has CRC errors on it (remember: it is legal for your buddy to burn you a copy
of Linux!), or (hopefully not) the software has a bug.

With Linux, you have several paths you can follow for help. If you have purchased your
copy from a commercial vendor such as SuSE or Red Hat, you can always call tech support
and reach a knowledgeable person who is dedicated to working through the problem with you.
If you didn’t purchase a box set, you can purchase support from Red Hat and other distributors
of Linux. Last, but certainly not least, is the option of going online for help. An incredible
number of web sites are available to help you get started. They contain not only useful tips
and tricks but also documentation and discussion forums where you can post your questions.
Obviously, you’ll want to start with the site dedicated to your distribution: www.redhat.com
for Red Hat Linux. Other distributions have their own sites. Check your distribution for its
appropriate web site information.

Here are some recommended sites for installation help:
● comp.os.linux.admin This is a newsgroup, not a web site. You can read it with a news
client, or through the web at http://groups.google.com.
● comp.os.linux.redhat This is another newsgroup, but Red Hat Linux–specific.
● linux.redhat This is another Red Hat Linux newsgroup.
● http://www.linuxdoc.org/ This site is a collection of wonderful information about all
sorts of Linux-related topics, including installation guides. Just a warning, though: Not all
documents are up to date. Be sure to check the date of any document’s last update before
following the directions. There is a mix of cookbook-style help guides as well as guides
that give more complete explanations of what is going on.
● http://linuxnewbie.org/ This site features “Newbie-ized Help Files” that help with a
variety of hardware and software issues.
● http://everythinglinux.org/ Everything Linux, as you might expect, has a wide variety
of resources for the Linux user, including how-to information and reviews.

Exploring Other Linux Resources

If you are interested in getting under the hood of the technology revolution (and it’s always
helpful to know how things work), I recommend the following texts:

● Computer: A History of the Information Machine by Martin Campbell-Kelly and William
Aspray (Harper Collins, 1997)
● A Quarter Century of Unix by Peter Salus (Addison-Wesley, 1994)

Neither of these texts discusses Linux specifically. A Quarter Century of Unix does tell
the Linux history up to the point where the system was just becoming a serious player. Peter
Salus writes an interesting discussion of why Linus Torvalds saw a need to create Linux in
the first place.

To get the scoop on Linux itself, start with the Linux home page at http://www.linux.org.
For Linux-related news, http://linuxtoday.com is one of several good resources, and the “News
for Nerds” at http://slashdot.org can be an entertaining—and often Linux-related—read.

Active Directory

So how does NIS stack up to Active Directory? Good question. The answer is “it doesn’t.”
Active Directory was designed to be much more than what NIS was designed for. This really
places the two into different classes of applications.

Active Directory (AD) is designed to be a generic solution to the problem of large sites
that need to have their different departments share administrative control—something that the
older Windows NT Domain model did very poorly. (Setting up interdomain trusts under NT
often required a great deal of patience and a willingness to fix “broken” trusts on a regular
basis.) AD is also an opportunity for Microsoft to fix many of its broken naming schemes and
move toward an Internet-centric scheme based on DNS. The result is quite beastly and requires
a lot of time to master. Mark Minasi’s book, Mastering Windows 2000 Server, Second Edition
(Sybex, 2000), dedicates well over 100 pages to the subject. However, in a smaller network,
most folks will find that it looks and feels mostly like the old-style NT domains with some
new whiz-bang features thrown in for good measure.

Don’t get me wrong, though—AD is a strong step in the right direction for Windows 2000
and presents solid competition for the Linux camp to think about how directory services can be
better integrated into their designs. But despite what Microsoft tells you, AD will not solve all
the world’s problems, let alone all of yours, in one easy step.

So does Linux have anything that compares to AD? Yes, actually, it does. Several
implementations of LDAP (Lightweight Directory Access Protocol) now exist for Linux, and
work is actively being done to allow NIS to tie into LDAP servers. (The RADIUS authentication
protocol is also becoming more common.) LDAP is also interesting because it uses the same
underlying technology that Active Directory uses in Windows 2000 and Windows .NET
Server. This means that, in theory, it is possible to share LDAP databases between both your
UNIX and Windows systems and possibly unify authentication between them.

Domains

For a group of Windows 2000 systems to work well together, they should exist in a domain.
This requires a Windows 2000 Server system configured as a Domain Controller (DC).
Domains are the basis of the Windows 2000 security model.

The basis of Linux’s network security model is NIS, Network Information Service. NIS is
a simple text file–based database that is shared with client workstations. Each primary NIS
server establishes a domain. Any client workstation wanting to join this domain is allowed to
do so, as long as it can set its domain name. To set the domain name, you must use the root
user—Linux’s equivalent to an Administrator user. Being part of the domain does not,
however, immediately grant you rights that you would otherwise not have. The domain
administrator must still add your login to the master NIS password list so that the rest of the
systems in the network recognize your presence.

The key difference between NIS and Windows 2000 domains is that the NIS server by
itself does not perform authentication the way a DC does. Instead, each host looks up the login
and password information from the server and compares it to the user’s entered information.
It’s up to the individual application to properly authenticate a user. Thankfully, the code
necessary to authenticate a user is very trivial.

Another important difference is that NIS can be used as a general-purpose database and
thus hold any kind of information that needs to be shared with the rest of the network. (This
usually includes mount tables for NFS and e-mail aliases.) The only limitation is that each NIS
map can have only one key, and the database mechanism doesn’t scale well beyond about 20,000 entries. Of course, a site with 20,000 users shouldn’t keep them all in a single NIS
domain, anyway!

Neither Windows nor Linux requires use of domains for the base operating system to
work. Nevertheless, they are key if you need to maintain a multiuser site with a reasonable
level of security.

The Registry vs. Text Files

I think of the Windows Registry as the ultimate configuration database—thousands upon
thousands of entries, very few of which are completely documented, some located on servers
and some located on clients. While it is possible to edit Registry entries manually, the fact that
one does so using a graphical tool doesn’t make the process intuitive.

Consider this Windows .NET Server Registry setting: In HKEY_LOCAL_MACHINE\
SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters, set EnablePrefetcher to 0x00000003 to enable application and boot prefetching. Even assuming you know what prefetching is and want to enable it, that’s a daunting configuration change, and not one that I remember offhand.

If you’re not getting my message, I’m saying that the Windows Registry system is, at best,
very difficult to manage. Although it’s a good idea in theory, I’ve never emerged without
injury from a battle with the Registry.

Linux does not have a registry. This is both a blessing and a curse. The blessing is that
configuration files are most often kept as a series of text files (think of the Windows .INI files
before the days of the Registry). This setup means you’re able to edit configuration files using
the text editor of your choice rather than tools like regedit. In many cases, it also means you
can liberally comment those configuration files so that six months from now you won’t forget
why you set something up in a particular way. With most tools that come with Linux,
configuration files exist in the /etc directory or one of its subdirectories.

The curse of a no-registry arrangement is that there is no standard way of writing
configuration files. Each application or server can have its own format. Many applications are
now coming bundled with GUI-based configuration tools, so you can do a basic setup easily
and then manually edit the configuration file when you need to do more complex adjustments.
In reality, having text files to hold configuration information usually turns out to be an
efficient method. Once set, they rarely need to be changed; even so, they are straight text files
and thus easy to view when needed. Even more helpful is that it’s easy to write scripts to read
the same configuration files and modify their behavior accordingly. This is especially true
when automating server maintenance operations, an ability that is crucial in a large site with
many servers.

Because Linux configuration files are text files, configuring systems automatically can
be done quickly and easily without special tools. Simple scripts can be written to set the
configuration values, making deployment of a new operating system, software package, or
utility very easy. Windows requires third-party software (often licensed on a per-machine
basis, which can become very expensive for large projects) to perform similar feats.

The Network Neighborhood

The native mechanism for Windows folk to share disks on servers or with each other is
through the Network Neighborhood. In a typical scenario, users attach to a share and have the
system assign it a drive letter. As a result, the separation between client and server is clear.
The only problem is that this method of sharing data is more people-oriented than technologyoriented:
People have to know which servers contain which data. Windows 2000 introduced a feature long available on UNIX systems: mounting. By mounting a share, Windows makes the share look as if it were just another directory located on the user’s local disk. This gives the illusion that a single unified directory structure exists, completely local to the machine. Microsoft’s Distributed File System (Dfs) allows a network wide amalgamation of directories that can be configured and accessed as a directory tree. Windows .NET Server improves Dfs management features and allows a single server to host multiple Dfs trees.

Linux, using the Network File System (NFS), has supported the concept of mounting
since its inception. This allows any directory to be “exported” for mounting on other systems.
The mounted directory can be placed anywhere in the remote system’s directory tree.
A common example of mounting partitions under Linux is with mounted home directories:
The user’s home directories reside on a server, and the client mounts the directories at boot
time (automatically). So /home exists on the client, but the contents of /home/username exist on the server.

Under Linux NFS, users never have to know server names or directory paths, and their
ignorance is your bliss! As with Dfs, there are no more questions about which server to
connect to. Users need not know when the need arises to change the server configuration.

Under Linux, you can change the names of servers and adjust this information on client-side
systems without making any announcements or having to reeducate users. Anyone who has
ever had to reorient users to new server arrangements is aware of the repercussions that may
occur. Module 8 discusses the Linux Automounter, which dynamically mounts and unmounts
partitions on an as-needed basis.

Printing works in much the same way. Under Linux, printers receive names that are
independent of the printer’s actual host name. (This is especially important if the printer
doesn’t speak TCP/IP.) Clients point to a print server whose name cannot be changed without
administrative authorization. Settings don’t get changed without your knowing it. The print
server can then redirect all print requests as needed. The Linux uniform interface will go a
long way toward improving what may be a chaotic printer arrangement in your installation.
It also means you don’t have to install print drivers in several locations.