RCHE Red Hat Certified Engineer Linux Study Guide[c] Exam (Rh302)

The kernel is the heart of the whole operating system. It manages communication with hardware, decides which processes to run, and provides each process with an isolated, virtual address space in which to run. The kernel is what your boot loader, GRUB or LILO, loads into memory. The kernel loads device driver modules. It also allocates hardware resources such as IRQ ports, I/O addresses, and DMA channels. When you recompile your kernel, you can

• Greatly improve the speed at which kernel services operate.

• Build in direct support for commonly used drivers.

• Configure the dynamic loading of appropriate drivers as modules.

• Lower the memory consumption of your kernel by removing unneeded components.

• Configure support for high-end hardware, such as memory above 4GB, hardware array controllers, symmetric multiprocessing (multiple CPU) support, and more.

In essence, you can customize the Linux kernel any way you want. The best way to do it is to make it fit every detail of your hardware. However, you may not need to be so picky. In many cases, where there's a small update to the kernel, all you need to do is install the updated kernel RPM.

Best Practices

You should compile your kernel with only the elements you need. The more you can leave out, the faster your whole system will run. For example, if you don't have a sound card, you can remove sound card support from your kernel. By removing unneeded devices, you will

• Decrease the size of the kernel.

• Provide a modest increase in speed for the devices that are present.

• Make more hardware resources (I/O addresses, IRQ ports, and so on) available for other hardware such as network cards, disk controllers, and more.

• Reduce the chance of hardware limits, such as those that may be based on the size of the compressed kernel.

Generally, it is a good idea to have device drivers compiled as modules for any equipment that you may add in the near future. For example, if you may use your Linux computer as a router, you'll need a second network card, and you can add support for that card to your kernel. For example, if you have a 3Com 3c595 network card installed but you also have some 3Com 3c905 cards in storage, then it may be a good idea to include the 3c905 module. That way, you will just have to swap in the new card and let the module load, causing minimum downtime.

Modules are kernel extensions. They are not compiled directly into the kernel but can be plugged in and removed as needed. When configured as a module, a hardware failure such as that of a network card will not cause the whole system to fail.

Kernel Concepts

You will need to understand some basic kernel concepts before you can compile your own kernel. Kernels can be organized as one big unit, or as a lot of interconnected pieces. Kernels are called up by boot loaders when you boot your computer.

Monolithic versus Modular

A monolithic kernel is a kernel where all the device modules are built directly into the kernel. Modular kernels have many of their devices built as separate loadable modules. Monolithic kernels can communicate with devices faster, since modular kernels can talk to the hardware only indirectly through a module table. Unfortunately, monolithic Linux kernels are huge. Bigger kernels reduce available RAM. In addition, some systems just can't boot a kernel that's too large.

There used to be advantages to a monolithic kernel. Linux once had problems loading modular kernels for some hardware. With a monolithic kernel, the drivers would already be there. But now modular kernels load new drivers a lot more reliably.

A modular kernel has greater flexibility. You can compile almost all your drivers as modules, and then each module can be inserted into the kernel whenever you need it. Modules keep the initial kernel size low, which decreases the boot time and improves overall performance. If Linux has trouble loading a kernel module, you can use the modprobe or insmod commands to load modules as needed.

Updating the Kernel

Updating the kernel is not as difficult as it looks. You should always keep a copy of your old kernel around in case you make a mistake. New kernels are handled by installing the newly built kernel in /boot and then adding another boot option to your boot loader configuration file (/etc/grub.conf or /etc/lilo.conf) for the new kernel. GRUB or LILO treats the new kernel as if it were an entirely new operating system.

If you install the new kernel directly from a Red Hat configured RPM, it updates your boot loader automatically.

If you do make a drastic mistake and the kernel doesn't boot, then you can simply reboot the server and select your old kernel at the GRUB or LILO prompt. You should also save your kernel configuration files so that you can easily copy to the newer kernels and use them as a guideline. This will be discussed in more detail later in this chapter.

Other RHEL 3 Kernels

There are a number of different kernels included with the RHEL 3 installation files. You can and should install the kernel best suited to your system. I briefly describe available RHEL 3 kernels in Table 5-1. The 'EL' in each of these kernels refers to their customization for Red Hat Enterprise Linux. The version numbers shown is what was released with RHEL 3. If you've used the Red Hat update agent, your kernel version number may vary.

This is just a short list of kernels available for RHEL 3. As the Red Hat exams assume the use of standard PCs with a single CPU, I've limited the list in Table 5-1 to such kernels. For more information on RHEL 3 kernels available for multi-CPU or higher-end CPUs, refer to the RHEL 3 documentation available online from www.redhat.com/docs/manuals/enterprise/.

The /boot Partition

The Linux kernel is stored in the partition with the /boot directory. New kernels must also be transferred to this directory. By default, RHEL 3 configures a partition of about 100MB for this directory. This provides enough room for your current kernel plus several additional upgraded kernels.

The /proc Filesystem

The /proc directory is based on a virtual filesystem; in other words, it does not include any files that are stored on the hard drive. But it is a window into what the kernel sees of your computer. It's a good idea to study the files and directories in /proc, as it can help you diagnose a wide range of problems. Figure 5-6 shows the /proc from a typical RHEL 3 computer.

Figure 5-6: A Red Hat Enterprise Linux 3 /proc directory

The numbered items are based on process IDs. For example, the process ID of init is 1. The files in this directory include the memory segments that make up the active process. The contents of each of these files include the active memory for that process.

The other items in the listing are files and directories that correspond to configuration information for components such as DMA channels or whole subsystems such as memory information.

Take a look at some of these files. For example, the /proc/meminfo file provides excellent information as to the state of memory on the local computer, as shown in Figure 5-7. It can help you determine if RHEL 3 is having trouble detecting all of the memory on your computer.

Figure 5-7: Detected memory information

It can also help you measure the current memory state of your system. For example, if your system is overloaded, you'll probably find very little free swap space. The HugePage settings are associated with systems with over 4GB of RAM.

Now you can examine how Linux looks at your CPU in the /proc/cpuinfo file, as shown in Figure 5-8. In this particular case, the cpu family information is important; the number 6 in this figure corresponds to a 686 CPU. Some of this information is available through the top utility.

Figure 5-8: Detected CPU information

Many programs are available that simply look at the information stored in /proc and interpret it in a more readable format. The top utility is a perfect example. It reads the process table, queries RAM and swap usage and the level of CPU use, and presents it all on one screen.

IP Forwarding

More importantly, there are kernel variables you can alter to change the way the kernel behaves while it's running. Sometimes it's appropriate to configure a Linux computer as a router between networks. By default, it does not forward TCP/IP information. You can confirm it with the following command:

# cat /proc/sys/net/ipv4/ip_forward 0

If your computer has two or more network cards, you may want to activate IP forwarding with the following command:

# echo 1 >> /proc/sys/net/ipv4/ip_forward # cat /proc/sys/net/ipv4/ip_forward 1

Preventing the Ping of Death

The following is another useful change to a proc kernel variable, which enables the use of TCP SYN packet cookies. These cookies prevent SYN flood attacks on your system, including the so-called 'ping of death.'

# echo 1 >> /proc/sys/net/ipv4/tcp_syncookies

Managing /proc Graphically

There is a Red Hat graphical tool that you can use to manage /proc directories. It's known as the Kernel Tuning tool, which you can start from a GUI command line with the redhat-config-proc command. For example, you can use it to set up IP Forwarding, as shown in Figure 5-9.

Figure 5-9: Tuning the kernel through /proc

Understanding Kernel Modules

When you compile your kernel, you can set up a monolithic kernel with every driver that you might ever need. Unfortunately, such kernels are large, unwieldy, and take a lot of time to load. Generally, most Linux administrators use kernel modules. As described earlier, a kernel module is not compiled directly into the kernel but instead operates as a pluggable driver that can be loaded and unloaded into the kernel as needed.

If you're having problems with hardware related kernel modules, one utility you can try is kudzu, the Red Hat hardware detection and configuration utility. It is normally run during the boot process, but you might try running it again if you're having a problem.

To have the kernel dynamically load and unload kernel modules as needed, the kernel module loader, kmod, is used to control the loading and unloading of modules. For special parameters and options, edit the /etc/modules.conf file.

Most hardware modules are automatically detected. If you've just installed new undetected hardware, you could issue the following command:

# depmod -a

This will scan through your modules, find out what the different dependencies for all your modules are, and map them out to a file (modules.dep). This command also creates a number of other files in the /lib/modules/2.4.21-4.EL/ directory (if you've installed another kernel, the directory version changes accordingly).

RHEL 3 runs this command automatically through the /etc/rc.sysinit script. Once the depmod module scan is complete, you can load additional kernel modules. If that module has dependencies, then all the needed modules will automatically load first.

To load a module, you can use the modprobe command with the name of a specific driver:

# modprobe 3c503

In this example, the Ethernet module for a 3Com 503 network card requires the 8390 module to work properly. If depmod was run first, then 8390 would have loaded automatically before the 3c503 driver. If a dependency in the list fails during loading, then all modules will be automatically unloaded.

Alternatively, you can set up these modules in /etc/modules.conf. It should already be configured during the RHEL 3 installation process. Unfortunately, this work can be rather tedious. The following commands are accepted in this file:

• alias Allows you to bind a name to a module.

• options Allows you to specify options for a module.

• install module command Use command instead of insmod on this module.

• pre-install module command Run command before installing this module.

• post-install module command Run command after installing this module.

• remove module command Use command instead of rmmod on this module.

• pre-remove module command Run command before loading this module.

• post-remove module command Run command after loading this module.

Here is an example of what a common modules.conf file may look like:

alias eth0 pcnet32 alias usb-controller usb-uhci options sb irq=5 io=0x220 dma=1 alias midi awe_wave alias parport_lowlevel parport_pc

Here the eth0 device is bound to the pcnet32 module. To load the network card, you can then simply type modprobe eth0 without knowing what card is in the computer. The next command sets the USB controller. The following two lines show the configuration of a soundblaster (sb) module. This information includes a specific IRQ port, I/O address, and DMA channel. The options line specifies these options and binds them to the sb alias. The sound card happens to be a Sound Blaster AWE 32 model card; therefore, the midi alias is bound to the awe_wave module. Finally, a parallel port module is bound to the parport_lowlevel alias.

The /etc/rc.sysinit script recognizes certain aliases and will load them if it finds them in this file. You need to specifically place the sound modules in modules.conf to have them automatically loaded. To have the sound modules automatically loaded during the Linux boot process without having to edit the /etc/rc.sysinit file, you can simply create an alias to sound and or midi in the modules.conf file.

To see what modules are loaded, you can type either

# cat /proc/modules

or

# lsmod

Both commands return output that looks something like the following:

Module                  Size  Used by    Not tainted nfs                    92912   1  (autoclean) ide-cd                 35680   0  (autoclean) cdrom                  33696   0  (autoclean) [ide-cd] smbfs                  44528   1  (autoclean) nfsd                   85456   8  (autoclean) lockd                  59856   1  (autoclean) [nfs nfsd] sunrpc                 85692   1  (autoclean) [nfs nfsd lockd] parport_pc             19076   1  (autoclean) lp                      9028   0  (autoclean) parport                37088   1  (autoclean) [parport_pc lp] autofs                 13364   0  (autoclean) (unused) pcnet32                18080   1 mii                     3976   0  [pcnet32] crc32                   3712   0  [pcnet32] ipt_REJECT              4632   1  (autoclean) ipt_state               1080   1  (autoclean) ip_conntrack           27304   1  (autoclean) [ipt_state] iptable_filter          2412   1  (autoclean) ip_tables              15776   3  [ipt_REJECT ipt_state iptable_filter] floppy                 58160   0  (autoclean) microcode               4724   0  (autoclean) keybdev                 2976   0  (unused) mousedev                5524   1 hid                    22212   0  (unused) input                   5888   0  [keybdev mousedev hid] usb-uhci               26412   0  (unused) usbcore                79392   1  [hid usb-uhci] ext3                   91592   3 jbd                    52336   3  [ext3] raid1                  14988   2

The module name is listed on the left, and its size is in the second column. The 'Used by' column shows more detail on how the module is being handled. An autoclean message means that the kernel, using the kmod thread is taking care of the module and will handle removing it. If a module name, such as ext3, is listed in brackets, then the module depends on the module in brackets. In our example, jbd depends on the ext3 module.

The /lib/modules/kernel_version/ Directory Structure

All kernel modules are stored in the /lib/modules/kernel_version/ directory. When RHEL 3 is installed, kernel_version=2.4.21-4.EL. If you have recently compiled a new kernel and your modules are not loading properly, then you have probably forgotten to compile and install the modules. In the /usr/src/kernel_version source directory, run the following commands:

# make modules # make modules_install

The first line compiles the modules, while the second places them under the proper directory tree. In this directory tree, different subdirectories represent different groupings. The following is a sample of a module directory:

# ls -l /lib/modules/2.4.21-4.EL/kernel/drivers total 60 drwxr-xr-x    7 root     root         4096 Oct 23 15:22 addon drwxr-xr-x    2 root     root         4096 Oct 23 15:22 block drwxr-xr-x    2 root     root         4096 Oct 23 15:22 cdrom drwxr-xr-x    8 root     root         4096 Oct 23 15:22 char drwxr-xr-x    2 root     root         4096 Oct 23 15:22 ide drwxr-xr-x    2 root     root         4096 Oct 23 15:22 input drwxr-xr-x    2 root     root         4096 Oct 23 15:22 md drwxr-xr-x    3 root     root         4096 Oct 23 15:22 message drwxr-xr-x   10 root     root         4096 Oct 23 15:22 net drwxr-xr-x    2 root     root         4096 Oct 23 15:22 parport drwxr-xr-x    2 root     root         4096 Oct 23 15:22 pcmcia drwxr-xr-x    5 root     root         4096 Oct 23 15:22 scsi drwxr-xr-x    5 root     root         4096 Oct 23 15:22 sound drwxr-xr-x    5 root     root         4096 Oct 23 15:22 usb drwxr-xr-x    3 root     root         4096 Oct 23 15:22 video

Remember that each /lib/modules/kernel_version directory contains a modules.dep file that lists all the dependencies for all the modules within the directories. Each of these module directories includes a group of kernel modules for a common type of hardware. You might want to become familiar with where to find certain modules when needed. Here are some module types you can find under each directory:

• addon High-end cards such as for server racks

• block Block devices: parallel port ide drives, network block devices, XT disks, hardware raid devices

• cdrom Non-ATAPI CD-ROM drivers: Mitsumi, Sony

• char Miscellaneous input and serial devices

• ide Hard disk drivers

• input Input devices (keyboards, mice)

• md raid devices

• message Specialized I/O adapters

• net Network modules: basic network cards, generic ppp, slip

• parport Parallel port devices (not printers)

• pcmcia Drivers used by the pcmcia cardmgr daemon (the actual cards use separate drivers)

• scsi SCSI tape, RAID, and hard drive modules, video (special video modules for Linux)

• sound Sound adapters

• usb Universal Serial Bus hubs and devices

• video Graphics adapters

All modules have .o for an extension (such as pcnet32.o). You do not need to specify the full name, just the first part of the module file (pcnet32). Once you know the directory structure, you can have the modprobe command load all modules for a certain category. For instance, if you are on a PC and you don't know the network card, you can simply type

modprobe -t net

This will attempt to load all modules in /lib/modules/kernel_version/net, stopping when a match is found. To remove a module such as pcnet32 and all its dependencies, you can type either

modprobe -r pcnet32

or

rmmod -r pcnet32

Either of these commands will remove the modules and all their dependencies, provided they are not in use by another module or not currently active. For example, if your network is active, you can't remove the network pcnet32 driver module. If you want to remove only the module and leave the other dependent drivers, run the rmmod command without the -r switch.