Red Hat Linux Idiosyncrasies | Tuning and Customizing a Linux System

< Free Open Study >

So far, everything that's been discussed in this chapter is more or less applicable to other Linux systems and even some other Unix-like systems. That is, so far I've only covered the ins and outs of particular software packages and tools that Red Hat Linux uses. In this section, I cover some idiosyncrasies specific to Red Hat Linux.

Using the GRUB Boot Loader

All operating systems require a boot loader to start up. A boot loader is a very small program that is executed automatically by the system hardware and is responsible for locating, setting up, and executing the primary operating system—in this case, the Linux kernel. Most distributions use the Linux Loader (LILO) as their boot loader, but as of version 7.2 Red Hat Linux uses GRUB.

GRUB, the "GRand Unified Bootloader", was developed by the GNU project. It is a very full-featured boot loader that contains features frequently only found in higher-end commercial systems and hardware. For example, GRUB allows users to edit the boot configuration manually when the system starts up, while LILO can only set up boot configurations from within an already-running system. GRUB's feature is extremely useful in cases where you accidentally misconfigure your boot configuration. Installing GRUB is as easy as installing the appropriate RPM. (Of course, you should probably uninstall LILO just in case.) GRUB is also the default boot loader, so unless you manually change it during installation, you'll have it already.

GRUB is configured via a text file. Because this file has to be accessible to GRUB during system bootup, it has to be located on the /boot partition. (The RPM for GRUB also creates a symbolic link in /etc/grub.conf that points to the real file in /boot/grub/grub.conf.) Managing the operating systems installed on your computer is then as easy as editing the contents of this file. However, GRUB is very adequately documented in its manual page and via its home page at http://www.gnu.org/software/grub/, so I don't cover the details of configuring GRUB here.

Managing Similar Software

Sometimes you might find yourself needing or wanting to install two independent but similar programs. For example, both KDE and GNOME include "desktop managers" that allow users to log into the X Window system. However, only one of these programs can be used at a time, so one of them has to be designated as the default.

Red Hat Linux addresses this situation through the use of the alternatives mechanism. This is simply a directory (specifically, /etc/alternatives) that contains symbolic links to the default version of a particular program in cases where more than one program fulfills a given need. (For instance, the /etc/alternatives/mta link points to the system's default mail transfer agent.)

The alternatives system was actually borrowed from the Debian GNU/Linux distribution. Because Debian is discussed in Chapter 6 (along with the alternatives system), you should consult that chapter for more information.

Upgrading to a Stock Kernel

Red Hat does extensive quality assurance tests on any kernel they officially ship. However, since Red Hat's focus is on the operating system as a whole, they generally don't release updated kernels unless they must in order to address some important bug or functionality. So, it is not uncommon to need to install a stock kernel on a Red Hat Linux system if the need for a new feature or bug fix in the kernel is too urgent to wait for Red Hat's next release. This section describes how to install a stock kernel on a Red Hat Linux 7.3 system without breaking any other software that might be installed.

Caution

Before performing any of these steps, it is important to understand the dangers involved. The kernel is the most crucial part of the operating system, and if it is misconfigured or damaged, the system will not boot up correctly, or at all. These days, Linux systems are becoming more and more stable, so users shouldn't upgrade the kernel just for the sake of doing so. However, if the kernel must be upgraded to a stock kernel, these instructions can be used. Be extremely careful in using these instructions, read all the documentation (both here and elsewhere), and make certain that you have a working rescue boot disk before beginning.

To install a stock kernel on Red Hat Linux 7.3, follow these steps:

Install the required libraries, if needed (such as the dev86 package on Intel).
Remove the /usr/src/linux-2.4 symbolic link.
Extract the stock kernel into /usr/src.
Create a symbolic link to the new kernel as /usr/src/linux-2.4.
Copy the Red Hat kernel configuration into the new source tree (customize if necessary).
Build the new kernel.
Copy the bzImage and System.map files into /boot, named appropriately.
Update //etc/grub.conf to use the new kernel.
Rebuild the system initrd via the mkinitrd command, if the system uses one.
Install the new kernel for bootup by running lilo.

Note that this list is probably not detailed enough to follow verbatim; however, Red Hat and other sources provide documentation on upgrading the kernel. You can use the steps here as a checklist when performing one of these installations. Note that if you wish to switch back to a stock Red Hat kernel later, you will have to undo some of these changes (notably step 7, since that symbolic link will conflict with a kernel-source package of a Red Hat kernel).

The first step is to make sure the required software is installed. Intel systems need the dev86 package installed. If the kernel source code is already installed, this package will also be installed. If you do have the kernel source code installed, you should leave it installed until after you've completed the upgrade. Once you've verified that your new kernel is working properly, you can reclaim the disk space if you really need to by erasing the kernel-source RPM.

The kernel-headers RPM

You may notice a second RPM installed on your system called kernel-headers. This package, even though it appears to be related to the kernel, does not actually need to be upgraded or uninstalled. This package contains the kernel include files used by certain userspace software, such as the system C libraries (glibc). The version of glibc installed on the system is dependent on a particular version of these kernel header files, and there is generally no reason to upgrade them in normal use, even if the kernel itself is upgraded. In fact, doing so might cause problems. Since these files are unrelated to the process of building or running a new kernel, there is no need to update them, unless there is a strong legitimate need. In order to build a new kernel, only the kernel-source package needs to be upgraded.

The /usr/src/linux-2.4 Symbolic Link

Various software and other parts of the system expect to find kernel source for a 2.4-series kernel in the directory /usr/src/linux-2.4. This directory should be a symbolic link to the actual directory where the source code is installed. So, after removing the source code RPMs, the next step is to extract the stock kernel source code into a directory in /usr/src, and then update the /usr/src/linux-2.4 symbolic link to point at the new stock kernel directory.

A related issue worth mentioning is that Red Hat's approach is to install the kernel source code in the /usr directory. However, it doesn't strictly need to be there; a normal user can (and perhaps should) build a kernel in her own home directory and then become root to actually install the kernel. On the other hand, the whole process of upgrading a kernel is a system administration task, so an argument can be made for placing the source code in /usr/src. For the purposes of this chapter, let's try and stay within Red Hat's own conventions.

Building the Kernel from Source Code

At this point, the kernel source code will properly installed. The next step is to actually build the kernel from the source code. In order to do this, the kernel must be configured. You can use the standard make menuconfig or other methods to configure the source code, but Red Hat also provides their standard kernel configuration files with the system. By reusing these files, you can make sure that your new stock kernel configuration will match Red Hat's, reducing the chance that you will accidentally omit a kernel option required by the system. (However, the Red Hat configuration may require minor customizations because Red Hat kernels sometimes include options that stock kernels do not have. This will vary on a case-by-case basis.)

Red Hat's configuration files is located in /lib/modules/<version>/build/configs; copy the file appropriate to your system to /usr/src/linux-2.4/.config and it will be located by the build process. (The <version> in the path refers to the version of the old kernel being upgraded: 2.4.2-2 on a stock 7.3 system. These files will not be present if the kernel source RPM has already been uninstalled, which is why that should be done last.)

Once the Red Hat configuration file has been copied (or the kernel source otherwise configured), the actual kernel can be built. At this point, the instructions for building a standard kernel apply; users should consult that documentation for more detail. Essentially, this involves running the build, which creates a new kernel in arch/i386/bzImage (on Intel systems, or something else on other architectures) as well as a System.map file. These files must be placed in the /boot directory, the boot loader configuration file (/etc/grub.conf or /etc/lilo.conf on Intel systems) must be updated, and on systems that require it, a new /boot/initrd file must be built via the mkinitrd command. When configuring the boot loader, make certain to add the new kernel, rather than replace the old; if the new kernel is bad for any reason, you can recover by booting the old configuration.

Tip

These instructions are somewhat skeletal. However, you can find extensive documentation at the Linux Documentation Project (LDP) at http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html and at Red Hat's web site. The LDP actually has documentation on many aspects of Linux systems and is a great resource to bookmark.

Once you've completed the preceding steps, you can reboot the system (via the shutdown command, running telinit 6, or simply using the Ctrl-Alt-Delete sequence), and the new kernel should be running. After the system is rebooted, you can log in and use the command uname -a to verify the upgrade.

User Environment

Users of Unix-like systems get especially ornery about their command shells; perhaps the only issue touchier than this is the stalwart emacs vs. vi text editor debate that has plagued Unix users since the very earliest days. Almost invariably, the first thing a Unix hacker does when given an account on a new system is customize his shell environment. This section is dedicated to these hackers and describes how the Red Hat Linux user environment configuration—you can't customize what you don't know.

Every command shell reads its configuration from specially named files. Generally, they start with a file in the /etc directory containing global and systemspecific configuration information and then move on to a given user's personal files. What actually goes on in these files is totally up to the user (and the system administrator). One of the hardest things to handle, though, is the case where new software is installed that requires users to set some environment variables. In this case, the global configuration files must be modified, for the changes to take effect for all users. However, the administrator may have customized these files, and so automatically installing new files may clobber those customizations.

This should be starting to sound familiar; it's the same problem that motivated the "drop-in files" approach to the SysV init script configuration. (I first mentioned this technique in the section "The Runlevel Configuration Script.") It isn't surprising, then, that Red Hat approached this similar problem in a similar way: with the /etc/profile.d directory. The global shell configurations on Red Hat Linux systems are constructed to read any files placed in /etc/profile.d as part of their execution.

The global configuration files /etc/profile and /etc/bashrc (for bash), and /etc/cshrc and /etc/csh.login (for tcsh) are fairly simple files. (Actually, these files are for sh and csh rather than bash and tcsh, but most Linux distributions use bash and tcsh as their sh and csh implementations.) They set some basic parameters such as a prompt and some system defaults and then simply source any files present in /etc/profile.d with a certain extension. (The bash configuration reads any files ending in ".sh", while the tcsh configuration reads any files ending in ".csh".) Each such file serves a specific purpose. For example, kde.sh configures KDE for bash users, while colorls.csh configures the color-ls program for tcsh users.

Whenever new software is installed on the system that requires configuration in users' shells, the administrator can simply write two shell scripts (one in sh syntax and another in csh syntax, but otherwise functionally identical) containing the required configuration, and place them in the /etc/profile.d directory as executable files. They will be picked up automatically by the users' shells on their next login. This work can obviously be automated within RPM packages, making it very easy to hook new software installations into a user's shell environment.

Red Hat Linux and Inetd

There are a lot of venerable programs in the Unix world, hailing from the very earliest days of the first systems. Except for init and sh (the first command shell) perhaps the most venerable program on Unix systems is inetd, the Internet superserver. This section describes xinetd, the implementation of inetd used on Red Hat Linux 7.3.

Readers who are already familiar with Unix-like systems will most likely be intimately acquainted with inetd. This program is responsible for listening on various TCP/IP ports and kicking off server processes when client connections are received. Client programs using inetd can be a bit simpler to write than those that handle their own TCP/IP connections. The configuration file for inetd is traditionally /etc/inetd.conf, and is essentially a large list of ports and commands; inetd binds to each port, and executes the indicated program whenever a connection is received.

Versions of Red Hat Linux earlier than 7.3 used the traditional inetd program, with a traditional inetd.conf file. As of version 7.3, however, Red Hat Linux switched to a program known as xinetd, which, though it serves the same function, is quite a bit different than the traditional inetd.

Cross-Reference

Other Linux distributions, including Debian and Slackware, still use the traditional inetd. If you are interested in the older inetd, see Chapter 5.

Why did Red Hat switch to xinetd? The long and the short of it is that xinetd is easier to work with. Traditional inetd implementations (including the one commonly used on Linux) have various restrictions (such as a limit on the number of arguments you can pass to a program) that make them inconvenient to use. Also, the /etc/inetd.conf file has to be modified for each program that wishes to make use of inetd; this leads to the same problems already described for the SysV init scripts and user shell environment.

The version of inetd that Red Hat switched to (xinetd) nicely solves all these problems. The directory /etc/xinetd.d contains configuration files for inetd services; this is another example of Red Hat's "drop-in configuration file" approach, which I first mentioned earlier in this chapter in the context of the runlevel configuration script. Additionally, the syntax of these configuration files is much richer than that supported by the older inetd.conf format, allowing for more flexibility in configuring the services.

xinetd is also supported by the chkconfig program mentioned earlier in this chapter. The chkconfig program is used to configure which services are enabled for a given runlevel. Normally, chkconfig works on the SysV init scripts to enable or disable services for specific runlevels. However, chkconfig also supports similar functionality for xinetd services, with the same syntax for enabling and disabling services. This integration makes chkconfig a truly one-stop shop for service configuration and was made much easier to implement with the switch to xinetd.

Mastering Red Hat's Configuration Directories

So far you've seen the "drop-in configuration file" mechanism used on Red Hat Linux in the SysV init scripts, the user environment, and the xinetd Internet superserver. There are, in fact, other examples of this technique. Simply looking in the /etc directory reveals several of them. Table 4-11 summarizes the most important examples. Understanding Red Hat's use of this technique will lead to a much better understanding of Red Hat Linux systems.

Table 4-11: Red Hat Linux Configuration Directories
DIRECTORY	PACKAGE	BEHAVIOR
/etc/rc.d	initscripts	All scripts in the directory corresponding to a runlevel are executed when that runlevel is entered.
/etc/profile.d	Red Hat Setup	All scripts are sourced when a user opens a shell.
/etc/xinetd.d	xinetd	Each file contains configuration information for a particular service.
/etc/cron*	crontabs	Each directory contains cron scripts that get run at that periodicity (e.g., /etc/cron.weekly contains scripts that get run on a weekly basis).
/etc/pam.d	pam	PAM is the Pluggable Authentication Modules. Each file configures the PAM permissions for a particular program or service.
/etc/logrotate.d	logrotate	Each file contains log rotation parameters for a given log file or service.
/etc/makedev.d	Core Red Hat	Each file contains information on generating a particular class of device files in /dev.
/etc/sysconfig	Core Red Hat	Each file contains system-specific configuration data for a particular aspect of the system.

Each of the directories in Table 4-11 has the same basic contents: Each contains a set of files that individually configure some small part or subset of the package. For example, the individual files in /etc/pam.d each configure some service to work with the Pluggable Authenticating Module (PAM) system, while the contents of /etc/logrotate.d configure the policies on rotating and cleaning the log files for a particular service. Even though each directory configures a different high-level service, they all use the same "drop-in individual configuration file" technique.

Working with Kudzu

Kudzu is a vine that was imported to the United States from overseas that has rapidly become ubiquitous in the southeastern part of the country. In a quest for similar "rapid ubiquity", Red Hat chose "kudzu" as the name for their program that scans the computer for new hardware and configures the system if any is detected. Of course, kudzu the vine also attacks trees, blocking their sunlight and causing them to slowly die. This section will help you avoid letting the same thing happen to your Red Hat Linux system.

Generally, kudzu does a fairly good job of checking for new hardware. Almost by definition, no hardware scanner can be perfect, but kudzu has been becoming steadily more reliable over the past few versions of Red Hat Linux. However, every now and then, users run into a particular hardware configuration that causes kudzu to behave incorrectly. Fortunately, kudzu is configured to run as a service via the SysV init scripts. If you find yourself in a situation where kudzu is doing more harm than good, you can disable it by using chkconfig: A quick chkconfig kudzu off and it will no longer be invoked for your current runlevel. (Of course, if you add new hardware, you will have to configure it manually.)

If you want to look at the files kudzu uses to do its work, they are installed in /usr/share/kudzu. Generally they map hardware device ID strings to kernel device driver modules. When it's run, kudzu scans for new hardware and configures the system to use any kernel modules mapped to the device. In theory, you could hook in support for new hardware by modifying these files, but that is definitely something that should only be attempted by developers. During system startup, the filesystem-management portion of kudzu is kicked off from /etc/rc.d/rc.sysinit, so if that is causing problems, you can disable it by commenting out the call to /usr/sbin/updfstab in that file.

Installing TrueType Fonts

One of the most highly anticipated features of recent Red Hat Linux versions has been the inclusion of support in XFree86 for the TrueType fonts that are ubiquitous on Windows systems. However, it isn't necessarily obvious how one goes about installing these fonts on a Red Hat Linux system. This section explains how this is done.

To install TrueType fonts on Red Hat Linux 7.3, follow these steps:

Create /usr/share/fonts/default/TrueType if it does not already exist.
Place the font (.ttf) files in /usr/share/fonts/default/TrueType.
Run ttmkfdir > fonts.scale in /usr/share/fonts/default/TrueType.
Run mkfontdir in /usr/share/fonts/default/TrueType.
(Optional) Modify the font directory order in /etc/X11/fs/config to list the TrueType fonts first.
Restart the X Font Server (xfs) service (service xfs restart).

The preceding instructions describe how to install the TrueType fonts in the standard location. You can actually place these files in any convenient directory; however, if you place them anywhere other than /usr/share/fonts/default/TrueType, you must modify the configuration file for the X Font Server (xfs) to include the new directory. (The xfs configuration file is /etc/X11/fs/config.) You can also use this file to change the order in which font directories are searched when a font name is being located. This allows users to give priority to TrueType fonts over other types if they happen to have the same name. It should be noted, however, that not all programs use the X Window font services; some (such as TeX, ghostscript, and the OpenOffice application) use their own mechanism. Such programs will still not be able to use the TrueType fonts, even after they have been installed.

Ensuring System Security

One of the major concerns about older versions of Red Hat Linux was the company's comparatively weak emphasis on security. In the past, Linux systems have traditionally been the playgrounds of technical experts. The various distributions generally took the stance of providing maximum functionality and let the users customize and secure the systems. However, as the market penetration of Linux systems increases, so does the number of less experienced users, who may not be able to secure their systems, or worse, might not even know their systems need to be secured! So, along with most vendors, Red Hat is gradually becoming more security conscious in their distributions.

Using a Firewall

Recent versions of Red Hat Linux no longer leave all the standard inetd services enabled, and version 7.3 actually includes a firewall by default. A firewall increases security by preventing attackers from accessing any potentially insecure servers that may be running, either intentionally or inadvertently. The installation process prompts the user to select a firewall security level and allows him or her to exclude specific ports from protection for specific applications (such as for the SSH protocol for remote access). This firewall can be configured after the system is up and running via the lokkit command. (Red Hat Linux firewalls are currently based on the ipchains system developed in the older 2.2 kernel series; Red Hat has not yet ported the configuration to the newer iptables system created for the 2.4 series, though there is no loss in functionality.)

Cross-Reference

An actual network firewall server configuration is one of this book's case studies. See Chapter 16 for much more detailed information.

Managing Security Settings with PAM

While firewalls help protect the system from external attackers, they don't do much for keeping users who already have accounts on the system from attacking other users or the root account. This type of security is handled on Red Hat Linux systems (like most other distributions) via the Pluggable Authentication Modules (PAM) package.

PAM provides an extensible, pluggable, and transparent mechanism for adding authentication methods against various sources. For example, PAM modules exist for authenticating against LDAP and RADIUS servers as easily as against the traditional Unix /etc/passwd mechanism. PAM also allows for specific services and programs to have specific requirements for authentication. Finally, PAM also allows administrators to configure things such as the times of day when users may access a system.

PAM is configured via the /etc/pam.d and /etc/security directories. The first directory contains application-specific security parameters. As listed in Table 4-11, this directory uses Red Hat's typical drop-in-files scheme: Each file in /etc/pam.d contains security configuration information for a particular program. The second directory contains more global configuration options, governing how users are granted permissions to various resources and when they may log in.

The files end users are probably most likely to interact with are /etc/security/console.perms and /etc/pam.d files. The console.perms file specifies which devices users gain access to when they log in on particular consoles. For example, users are granted read and write access to the /dev/floppy device (which represents the floppy disk drive) when they log in either on the console or via X, but not when they log in remotely (since they would not be sitting at the machine in that case and would not need the floppy drive). The files in /etc/pam.d, meanwhile, control access for specific programs, such as the Apache HTTP server: Users who install software that has specific or nonstandard security requirements may need to create or modify files in this directory. Most of the time users will not need to modify these files. However, it is important to know that they exist for future use. When the time comes, users can consult the documentation for more detailed information.

< Free Open Study >