Kernel, Cron, and User Administration, Part 1

Today, get started with your RHCE certification. Learn about shell configuration files, setting up and managing disk quotas, and the basics of the kernel. This comes from chapter five of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7).

Red Hat Certified EngineerIn this chapter, you will learn how to set up the Linux startup shell configuration scripts so that users’ sessions are configured according to your (and their) requirements. You will learn how to create and implement policies for managing disk usage—by user or by group.

Next, you will learn how to upgrade, configure, compile, and install your own custom kernels. You will learn about the advantages and disadvantages of monolithic and modular kernels. You have three different ways to customize and optimize your kernel configuration for size and functionality. You will also learn the recommended techniques for configuring and installing the kernel. Finally, you’ll learn how to schedule the one-time and periodic execution of jobs.

For the Red Hat exams, the skills you learn in this chapter are important for the Installation and Configuration exam. As described in the Red Hat Exam Prep guide, you need to know how to manage accounts and set up the user environment.

Inside the Exam

Configuring Users
You need to know how to create and configure users on the Red Hat exams. This means that you need to know how to configure the environment associated with each user account—in configuration files and in user settings. You also need to know how to specify the configuration files associated with the default bash shell. Finally, you need to know how to limit the resources allocated to each user through quotas. These requirements are all explicitly cited in the Red Hat Exam Prep guide for both exams.

Managing Kernels
As a competent Linux administrator, you need to know how to install, patch, and recompile kernels. It’s easy to install a new kernel from an RPM, which makes it a reasonable requirement on the RHCT and RHCE exams. However, the latest RHCE Exam Prep guide no longer explicitly requires that you need to know how to recompile the Linux kernel. Therefore, the long discussion on recompiling kernels is “only” important if you want the skills needed to become a Linux systems administrator.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Certification Objective: Shell Configuration Files}

All system-wide shell configuration files are kept in the /etc directory. These files are bashrc, profile, and the scripts in the /etc/profile.d directory. These files and scripts are supplemented by hidden files in each user’s home directory, as described in Chapter 4. Let’s take a look at these files.

The /etc/bashrc file is used for aliases and functions, on a system-wide basis. Open this file in the text editor of your choice. Read each line in this file. Even if you don’t understand the programming commands, you can see that this file sets the following bash shell parameters for each user. For example:
  • It assigns a value of umask, which creates the default permissions for newly created files. It supports one set of permissions for root and system users (with user IDs below 100), and another for regular users.

  • It assigns a prompt, which is what you see just before the cursor at the command prompt.

The settings here are called by the .bashrc file in each user’s home directory. The settings are supplemented by the .bash_history and .bash_logout files in each user’s home directory.

The /etc/profile file is used for system-wide environments and startup files. The following is the profile script from my copy of the RHEL 3 operating system. The first part of the file sets the PATH for searching for commands. Then it sets the PATH, USER, LOGNAME, MAIL, HOSTNAME, HISTSIZE, and INPUTRC variables, and finally it runs the scripts in the /etc/profile.d directory. You can check the current value of any of these variables with the echo $variable command.

# /etc/profile

# System wide environment and startup programs, for login setup

# Functions and aliases go in /etc/bashrc

pathmunge () {
  if ! echo $PATH | /bin/egrep -q “(^|:)$1($|:)” ; then
    if [ “$2” = “after” ] ; then

# Path manipulation
if [ `id -u` = 0 ]; then
  pathmunge /sbin
  pathmunge /usr/sbin
  pathmunge /usr/local/sbin

pathmunge /usr/X11R6/bin after

unset pathmunge

# No core files by default
ulimit -S -c 0 > /dev/null 2>&1

USER=”`id -un`”


if [ -z “$INPUTRC” -a ! -f “$HOME/.inputrc” ]; then
    INPUTRC=/etc/inputrc fi


for i in /etc/profile.d/*.sh ; do
  if [ -r “$i” ]; then
    . $i

unset i

Actually, /etc/profile.d is not a script, but a directory of scripts. As I just noted, /etc/ profile runs the scripts in this directory. Here is a partial listing of the files, which apply to the default bash shell:

-rwxr-xr-x  1 root  root  724  Aug 12 11:34
-rwxr-xr-x  1 root  root  190  Sep  8 11:32
-rwxr-xr-x  1 root  root  70   Sep 17 12:13
-rwxr-xr-x  1 root  root  210  Sep 23 15:42
-rwxr-xr-x  1 root  root  53   Mar 26  2003
-rwxr-xr-x  1 root  root  2595 Sep 26 00:39
-rwxr-xr-x  1 root  root  435  Sep  1 10:32
-rwxr-xr-x  1 root  root  70   May  1  2003
-rwxr-xr-x  1 root  root  181  Sep  1 11:01
-rwxr-xr-x  1 root  root  170  Jul 17 15:09

By looking at the /etc/profile script, you can see that any script in this directory that ends with an “sh” and is set as an executable will be run when /etc/profile is executed.

Exercise 5.1

Securing Your System

We want to keep our system as secure as possible. One approach is to change the default permissions users have for new files and directories they make. We’ll set all new files and directories to No Access to group or other members.

  1. Back up your current /etc/bashrc file. If you want to cancel any changes that you make during this exercise, restore from the backup after the final step.

  2. Edit the /etc/bashrc file. Two lines in the file set the umask. One of the two lines is selected depending on the if statement above them. See if you can determine which line gets executed for an average (non-root) user.

  3. The if statement tests to see if the user ID (uid) and group ID (gid) are the same, and that the uid is greater than 99. If this is true, then the first umask is executed; otherwise, the second is executed. The second umask is for root and other key system accounts. The first is for users.

  4. Change the first umask statement to exclude all permissions for groups and others. Use umask 077 to do the job.

  5. Save and exit the file.

  6. Log in as a nonprivileged user. Use the touch command to make a new empty file. Use ls -l to verify the permissions on that file.

  7. Log in as root. Again, use the touch command to make a new empty file and use ls -l to verify the permissions on that new file.

You have just changed the default umask for all shell users. If you backed up your /etc/bashrc in step 1, you can now restore the original version of this file.

User Shell Configuration Files

As described in Chapter 4, each user gets a copy of the hidden files from the /etc/skel directory. As your users start working with their accounts, more configuration files are added to their home directories. Some are based on shells such as bash (.bash*); others draw their settings from the GUI desktops that you use, typically GNOME and KDE. I’ll describe the GUIs in more detail in Chapter 6.

The default Linux shell is bash. However, if you or your users work with other shells, you’ll find configuration files associated with those shells hidden in each user’s home directory.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Setting Up and Managing Disk Quotas}

Quotas are used to limit a user’s or a group of users’ ability to consume disk space. This prevents a small group of users from monopolizing disk capacity and potentially interfering with other users or the entire system. Disk quotas are commonly used by ISPs, by Web hosting companies, on FTP sites, and on corporate file servers to ensure continued availability of their systems.

Without quotas, one or more users can upload files on an FTP server to the point of filling a filesystem. Once the affected partition is full, other users are effectively denied upload access to the disk. This is also a reason to mount different filesystem directories on different partitions. For example, if you only had partitions for your root (/) directory and swap space, someone uploading to your computer could fill up all of the space in your root directory (/). Without at least a little free space in the root directory (/), your system could become unstable or even crash.

You have two ways to set quotas for users. You can limit users by inodes or by kilobyte-sized disk blocks. Every Linux file requires an inode. Therefore, you can limit users by the number of files or by absolute space. You can set up different quotas for different filesystems. For example, you can set different quotas for users on the /home and /tmp directories if they are mounted on their own partitions.

Limits on disk blocks restrict the amount of disk space available to a user on your system. Older versions of Red Hat Linux included LinuxConf, which included a graphical tool to configure quotas. As of this writing, Red Hat no longer has a graphical quota configuration tool. Today, you can configure quotas on RHEL only through the command line interface.

ON THE JOB!  Learn to focus on command line tools. Red Hat used to make LinuxConf available as a graphical and console tool for a number of system administration functions, including quotas. While Red Hat may eventually create another GUI quota manager, don’t count on it. And GUI tools have been known to crash. On the job, as well as on the exam, command line tools are the only sure way to address just about any Linux configuration issue. Besides, command line tools are faster, and time is often of the essence on the Red Hat exams.

Quota Settings in the Kernel

By default, the Linux kernel as configured by Red Hat supports quotas. However, if you install and compile a new kernel from a remote source, you should make sure that this feature is active. The basic kernel configuration is stored in the /boot directory. For the default RHEL 3 system, you’ll find the configuration in the config-2.4.21-4.EL file. If you’ve configured a custom kernel file, you’ll find it listed under a different name.

To verify that quotas are enabled in the default RHEL 3 kernel, run the following command:

# grep CONFIG_QUOTA /boot/config-2.4.21-4.EL

There are three possible results. If you see the following, quota support is enabled:


Alternatively, if you see the following, quota support is not enabled:


If you don’t see any output, then you haven’t installed the kernel source files.

If you have a custom or upgraded kernel, use either the make menuconfig or make xconfig command to make sure support is enabled for quotas. The quota support option is located in the filesystem section. All you need to do is turn on quota support and then rebuild and install your new kernel. I’ll describe this process in more detail later in this chapter.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=The Quota Package}

The quota RPM package is installed by default on RHEL 3, as well as Red Hat Linux 9. You can find out more about RPMs such as quota with the following command:

# rpm -qi quota

Assuming you haven’t removed the quota RPM, you’ll see the following description of the package which tells you that it includes a number of tools:

The quota package contains system administration tools for monitoring and limiting user and or group disk usage per filesystem.

You can find out more about these tools by reviewing a list of associated files. You can find a list of files installed through the quota RPM with the following command:

# rpm -ql quota

As you can see for yourself, the quota package includes the following commands:

  • /sbin/quotaon /fs  Enables quotas for the /fs filesystem.
  • /sbin/quotaoff /fs  Disables quota tracking.
  • /usr/sbin/edquota name  Edits the quota settings for user name. Can also be used to set defaults, or to copy quota settings from one user to another.
  • /usr/bin/quota  Allows users to see their current resource consumption and limits.
  • /usr/sbin/repquota  Generates a report of disk consumption by all users for a quota-enabled filesystem.’
  • /sbin/quotacheck  Scans a filesystem for quota usage. Initializes the quota databases.

I’ve included the entire path to each command for your reference. But as discussed earlier in this book, I recommend that you normally work as the root user during the Red Hat exams. As the noted directories are all part of the root user’s PATH, you don’t need to specify the full path to each command. (You can verify the directories in your path with the echo $PATH command.)

The next step is to ensure that the quotas are active and checked when Linux boots on your system.

sysinit Quota Handling

The /etc/rc.sysinit script as described in Chapter 4 initializes Linux system services during the boot process. This script includes commands which start quota services. Specifically, this script runs both the quotacheck (to ensure that disk consumption usage records are accurate) and quotaon commands (to enable quotas on all filesystems indicated in /etc/fstab). You don’t have to run these commands manually.

Quota Activation in /etc/fstab

As described in Chapter 4, the file /etc/fstab tells Linux which filesystems to mount during the boot process. The options column of this file configures how Linux mounts a directory. You can include quota settings in /etc/fstab for users and or groups.

ON THE JOB!  Before you edit a key configuration file such as /etc/fstab, it’s a good idea to back it up and save it to any boot or rescue disks that you may have. If your changes lead to a catastrophic failure, you can boot your system from a rescue disk and then restore the original configuration file.

Here is a sample /etc/fstab before editing:

Device      Mount point Filesys Options          dump Fsck
LABEL=/     /           ext3    defaults          1    1
LABEL=/boot /boot       ext3    defaults          1    2
none        /dev/pts    devpts  gid=5,mode=620    0    0
none        /proc       proc    defaults          0    0
none        /dev/shm    proc    tmpfs             0    0
/dev/hda3   swap        swap    defaults          0    0
/dev/hdd1   /home       ext3    defaults          1    2
/dev/cdrom  /mnt/cdrom  udf,iso9660  noauto,owner,kudzu,ro  0 0
/dev/floppy /mnt/floppy auto    noauto,owner,kudzu 0    0

In this configuration, we may want to enable quotas on the root (/) and /home directory filesystems. You can tell Linux to start tracking user quotas by adding the keyword usrquota under the options column. Similarly, you can tell Linux to start tracking group quotas with the grpquota option. Use vi or your favorite text editor to update /etc/fstab.

In our example, we will add both user and group quotas to the /home directory filesystem:

Device      Mount point Filesys Options          dump Fsck LABEL=/     /           ext3    defaults          1    1
LABEL=/boot /boot       ext3    defaults          1    2
none        /dev/pts    devpts  gid=5,mode=620    0    0
none        /proc       proc    defaults          0    0
none        /dev/shm    proc    tmpfs             0    0
/dev/hda3   swap        swap    defaults          0    0
/dev/hdd1   /home       ext3 exec,dev,suid,rw,usrquota,grpquota  1    2
/dev/cdrom  /mnt/cdrom  udf,iso9660  noauto,owner,kudzu,ro  0    0
/dev/floppy /mnt/floppy auto    noauto,owner,kudzu 0    0

If you edit the /etc/fstab file by hand, you’ll need to ensure that the line you are editing does not wrap to the next line. If it does, the format for your /etc/fstab will be invalid and you may not be able to successfully boot Linux.

ON THE JOB!  You can test changes to /etc/fstab by rebooting your computer or remounting a filesystem. For example, if you’ve just added usrquota and grpquota entries as shown to the /home directory filesystem, you can test it with the mount -o remount /home command.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Quota Management Commands}

The next step is to create quota files. For user and group quotas, you’ll need the aquota.user and files in the selected filesystem. You need these files before you can activate actual quotas. You no longer need to create those files; once you’ve remounted the desired directory, you can create them directly with the appropriate quotacheck command. For the /home directory described earlier, you’d use the following commands:

# mount -o remount /home
# quotacheck -avugm

The quotacheck -avugm command automatically scans /etc/mtab, which includes the mounted directories from /etc/fstab. The options for quotacheck are

  • -a Scans all filesystems with quotas enabled by checking /etc/mtab.
  • -v Performs a verbose scan.
  • -u Scans for user quotas.
  • -g Scans for group quotas.
  • -m Remounts the scanned filesystem.

This will check the current quota information for all users, groups, and partitions. It stores this information in the appropriate quota partitions. You should also find the aquota.user and files in the configured directory. If you’re configuring quotas on the /home directory, you can check that it worked with the following command:

# ls -l /home/aquota.*

Using edquota to Set Up Disk Quotas

To specify disk quotas, you need to run the edquota command. This edits the aquota.user or file with the vi editor. In our example, we will pretend we have a user named nancy, and we want to restrict how much disk space she is allowed to use. We type the following command to edit their quota records:

# edquota -u nancy

This command launches the vi editor and opens the quota information for user nancy, as shown in Figure 5-1.

Disk Quotas for user nancy (uid 507):
  FileSystem       blocks   soft   hard   inodes    soft
    hard               52      0      0       13       0

Figure 5-1  Quota information

The quota information is formatted strangely. There are actually seven columns. The lines are wrapped. In this case, the filesystem with the quota is mounted on partition /dev/hdd1. There are soft and hard limits for both inodes and files. By default, soft and hard limits of 0 means that there are no limits for nancy.

We can see that nancy is currently using 52 blocks and has 13 files (inodes) on this partition. Each block takes up 1KB of space; thus, user nancy’s files total 52KB. We want to set a limit so that nancy does not take more than 20MB of space with her files.

First, we need to elaborate on the meaning of soft and hard limits.

  • Soft limit  This is the maximum amount of space a user can have on that partition. If you have set a grace period, then this will act as an alarm. The user will then be notified he is in quota violation. If you have set a grace period, you will also need to set a hard limit. A grace period is the number of days a user is allowed to be above the given quota. After the grace period is over, the user must get under the soft limit to continue.

  • Hard limit  Hard limits are necessary only when you are using grace periods. If grace periods are enabled, this will be the absolute limit a person can use. Any attempt to consume resources beyond this limit will be denied. If you are not using grace periods, the soft limit is the maximum amount of available to each user.

In our example, we will set our user an 18MB soft limit and a 20MB hard limit. As shown in Figure 5-2, this is written as a number of 1KB blocks in the quota file.

Disk Quotas for user nancy (uid 507):
  FileSystem       blocks   soft   hard   inodes    soft
  /dev/hdd1            52  18000  20000       13       0

Figure 5-2  Quotas with hard and soft limits

Note that we have not limited user nancy’s use of inodes. She is still able to use as many inodes (thus as many files) as she likes. To implement these quotas, we must save these settings. Assuming you’re still using the default vi editor, the :wq command does this job nicely.

We will also give user nancy a seven-day grace period, if and when she exceeds the soft limit. She has that amount of time to get back under the soft limit. To set the grace period for all users, run the edquota -t command. The result should look similar to what you see in Figure 5-3.

Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
  Filesystem     block grace period    Inode grace period
  /dev/hdd1             7 days               7 days

Figure 5-3  Quota grace period

Here, Linux has provided us with the default of seven days for both inodes and block usage. That is, a user may exceed his soft limit on either resource for up to seven days. After that, further requests by that user to use files will be denied. Our user nancy would have to delete files to get her total disk block consumption under 18MB before she could create new files or grow existing files. You can edit the grace period directly, using vi commands. To activate the new grace period, just save the file.

There is a quirk to quota grace periods. When you use edquota and specify the grace period, you cannot have a space between the number and the unit (for example, 7days, not 7 days). Fortunately, the quota system in RHEL 3 automatically fixes this problem.

ON THE JOB!  In older versions of Red Hat Linux, a space between the number and the unit would lead to a quota error.

The edquota command allows you to use an already configured user’s quota as a template for new users. To use this feature, you need to add the following switch and options, -p configured_user arguments:

# edquota -up nancy michael randy donna

This command will not provide any output, but it will take the quota configuration settings of user nancy and apply them to michael, randy, and donna. You can list as many users as you want to edit or apply templates to.

You can also set up quotas on a per-group basis. To do this, simply run edquota with the -g group_name argument. Here, group_name would need to be a valid group as specified in the /etc/group file.

# edquota -g nancy

This opens the block and inode quota for group nancy, as shown in Figure 5-4.

Disk Quotas for group nancy (uid 507):
  FileSystem       blocks   soft   hard   inodes    soft
  /dev/hdd1            52      0      0       13       0

Figure 5-4  Group quota

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Automating Quota Settings}

As an administrator, you’ll want to maintain any quotas that you create. For that purpose, it’s useful to run the aforementioned quotacheck command on a regular basis. As you’ll see later in this chapter, that is easy to do through the cron system. A simple command in the right cron file automatically runs the quotacheck command on a regular basis. For example, the following command in the right cron file runs the quotacheck command at 4:00 A.M. every Saturday:

0 4 * * 6 /sbin/quotacheck -avug

You can also use the edquota command to apply quotas to all users on your system. For example, the following command applies the quotas that you’ve already set on user mj to all other real users on the system:

edquota -p mj `awk -F: ‘$3 > 499 {print $1}’ /etc/passwd`

Note that this command lists the first column ($1) of /etc/passwd, which is the user name. And in keeping with the UIDs for regular Red Hat users (from the third column, $3, of /etc/passwd), this is limited to users with UIDs of 500 or higher. You can add this type of command to the appropriate cron file as well, which makes sure that the quotas are applied to all existing and new users.

Quota Reports

As an administrator, it can be useful to see reports on who is using the most disk space. You can generate reports on users, groups, or everybody on every partition. To view a report showing quota information for all, run the repquota -a command. You’ll see a list of quotas for all users similar to what is shown in Figure 5-5.

[root@Enterprise3 root]# repquota -a
*** Report for user quotas on device /dev/hdd1
Block grace time: 7days; Inode grace time: 7days
             Block Limits                   File limits
User        used   soft  hard  grace   used soft hard grace ———————————————————–
root      —  36      0                   3    0    0
michael   —  52  18000                  13    0    0
donna     —  52      0                  13    0    0
elizabeth —  52      0                  13    0    0
nancy     —  52  18000                  13    0    0
randy     —  52  18000                  13    0    0

[root@Enterprise3 root]#

Figure 5-5   A quota report

If you have multiple filesystems with quotas, you can use the repquota command to isolate a specific filesystem. For example, if you wanted to view the quota report for the partition with the /home directory, you’d run the following command:

# repquota -u /home

Alternatively, if you wanted to view quota information on user nancy, run the following quota command:

# quota -uv nancy
Disk quotas for user nancy(uid 507):
Filesystem blocks quota limit grace files quota limit grace
/dev/hdd1    52   18000 20000       13     0      0

An individual user can check his or her own usage with the quota command, but only the administrative root user can examine the quotas for other users.

Quotas on NFS Directories

The Network File System (NFS) allows users to share files and directories on a network with Linux and Unix computers. Users across the network mount a shared NFS directory from a specific computer. Users are normally in a single database in an NFS setup. Disk quotas can be applied to these users in virtually the same way as on a regular Linux computer. For example, if you create a local user called nfsuser, and you translate all remote requests to this user, then you need to set up quota restrictions for nfsuser on the mounted partition. This will limit the disk consumption of all incoming NFS users. See Chapter 9 for more about NFS.

Excercise 5-2

Configure Quotas

In this exercise, we will set up user quotas for one user on your system. These quotas will allow a soft limit of 80MB and a hard limit of 100MB for each user. No limits are to be placed on the number of inodes. Assume the /home directory is mounted on a separate partition. (If /home is not mounted separately, apply the commands to the top-level root directory /.) The first couple of steps should be formalities, as quotas should be active and installed by default. However, it’s a good habit to check. To set up quotas in this exercise, use the following steps:

  1. Check your kernel configuration for the CONFIG_QUOTA variable, using the /boot/config-2.4.21-4.EL file. It should be set to “Y.” If not, proceed to the Lab Question at the end of this chapter for instructions on how to revise your kernel. If you’re using a different version of Linux such as Red Hat Linux 9, substitute the /boot/config-* file associated with your kernel version.

  2. Check to make sure that the quota package is installed. Install from the RHEL 3 installation source if required.

  3. Add quotas to /etc/fstab. Add the usrquota variable to the Options column for the partition with the /home directory. Make sure the info stays on one line in /etc/fstab.

  4. Activate the quotas. You can unmount and remount the /home directory, reboot Linux, or use the following command:

    # mount -o remount /home

  5. Use the quotacheck -avum command to activate the quota files in the /home directory.

  6. Make sure this command worked. Look for the aquota.user file in the /home directory.

  7. Now you’re ready to set up quotas for a specific user. If necessary, look up usernames in /etc/passwd. Use the edquota -u username command to edit the quotas for the user of your choice.

  8. Under the soft and hard columns, change the 0 to 80000 and 100000, respectively. Remember, these files are set up for 1KB blocks. Save the file.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=The Basics of the Kernel}

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.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=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.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=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.

Table 5-1 Available Red Hat Enterprise Linux 3 Kernels (and Related Packages)

Kernel RPMDescription
kernel-2.4.21-4.EL.athlon.rpmSuitable for PCs with a single AMD Athlon CPU.
kernel-2.4.21-4.EL.i686.rpmDesigned for PCs with a single Intel CPU.
kernel-unsupported-2.4.21-4.EL.athlon.rpmThe Athlon kernel with additional unsupported modules.
kernel-unsupported-2.4.21-4.EL.i686.rpmThe Intel kernel with additional unsupported modules.
kernel-BOOT-2.4.21-4.EL.i386.rpmKernel used only during the RHEL 3 installation process.
kernel-hugemem-2.4.21-4.EL.i686.rpmSupports multiple CPUs and systems with more than 4GB of RAM.
kernel-hugemem-unsupported-2.4.21-4.EL.i686.rpmThe hugemem kernel configured with additional untested kernel modules.
kernel-pcmcia-cs-3.1.31-13.i386.rpmAdds PCMCIA (PC Card) modules to your current kernel.
kernel-smp-2.4.21-4.EL.athlon.rpmThe symmetric multiprocessing (SMP) kernel suitable for multi-CPU AMD Athlon systems. Also supports more than 4GB of RAM.
kernel-smp-2.4.21-4.EL.i386.rpmThe symmetric multiprocessing (SMP) kernel suitable for multi-CPU Intel systems. Also supports more than 4GB of RAM.
kernel-smp-unsupported-2.4.21-4.EL.athlon.rpmThe SMP kernel with additional untested kernel modules for Athlon CPUs.
kernel-smp-unsupported-2.4.21-4.EL.i386.rpmThe SMP kernel with additional untested kernel modules for Intel CPUs.
kernel-source-2.4.21-4.EL.i386.rpmIncludes the source code for the RHEL 3 kernel.

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

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 helpyou diagnose a wide range of problems. Figure 5-6 shows the /proc from a typical RHEL 3 computer.

[root@Enterprise3 root]# ls /proc/
1    1880 1950 2159 2245 2762    devices     ksyms      stat
1175 1903 1960 2170 2246 3       dma         loadavg    swaps
1182 1907 1969 2171 2254 4       driver      locks      sys
16   1908 1999 2174 2256 5       execdomains mdstat     sysrq-trigger
1655 1909 2    2191 2261 6       fb          meminfo    sysvipc
1659 1910 2008 2216 2365 7       filesystems misc       tty
1685 1911 2022 2218 2420 74      fs          modules    uptime
17   1912 2023 2223 2485 8       ide         mounts     version
1704 1913 2024 2230 2586 9       interrupts  mtrr
1772 1914 2025 2234 2655 apm     iomem       net
18   1915 2026 2236 2713 bus     ioports     partitions
1811 1916 2027 2238 2714 cmdline irq         pci
1851 1922 2028 2241 2715 cpuinfo kcore       self
1865 1941 2085 2243 2749 crypto  kmsg        slabinfo

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.

[root@Enterprise3 root]# cat /proc/meminfo
      total:    used:      free:   shared: buffers: cached:
Mem:  128675840 126464000  2211840     0  14028800 63885312
Swap: 394805248 31461376 363343872
Memtotal:       125660 kB
MemFree:          2160 kB
MemShared:           0 kB
Buffers:         13700 kB
Cached:          51304 kB
SwapCached:      11084 kB
Active:          87704 kB     
ActiveAnon:      49664 kB
ActiveCache:     38040 kB
Inact_dirty:         0 kB
Inact_laundry:   18908 kB
Inact_cleam:      2208 kB
Inact_target:    21764 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       125660 kB
LowFree:          2160 kB
SwapTotal:      385552 kB
SwapFreeL:      354828 kB
HugePages_Total:     0
HugePages_Free:      0
HUgepagessize:    4096 kB
[root@Enterprise3 root]#

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.

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

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

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

Kernel Cron and User Administration

Detected CPU information

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.

Kernel Cron and User Administration

FIGURE 5-9  Tuning the kernel through /proc

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=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.

EXAM WATCH!  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 commandinstead of insmod on this module.
  • pre-install module command  Run commandbefore installing this module.
  • post-install module command  Run commandafter installing this module.
  • remove module command  Use commandinstead of rmmod on this module.
  • pre-remove module command  Run commandbefore loading this module.
  • post-remove module command  Run commandafter 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


# 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]
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.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title= /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


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.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye