In 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 Managing Kernels |
|
{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.
/etc/bashrcThe /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.
/etc/profileThe /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=$PATH:$1
else
PATH=$1:$PATH
fi
fi
}# Path manipulation
if [ `id -u` = 0 ]; then
pathmunge /sbin
pathmunge /usr/sbin
pathmunge /usr/local/sbin
fipathmunge /usr/X11R6/bin after
unset pathmunge
# No core files by default
ulimit -S -c 0 > /dev/null 2>&1USER=”`id -un`”
LOGNAME=$USER
MAIL=”/var/spool/mail/$USER”HOSTNAME=`/bin/hostname`
HISTSIZE=1000if [ -z “$INPUTRC” -a ! -f “$HOME/.inputrc” ]; then
INPUTRC=/etc/inputrc fiexport PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC
for i in /etc/profile.d/*.sh ; do
if [ -r “$i” ]; then
. $i
fi
doneunset i
/etc/profile.d/
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 colorls.sh
-rwxr-xr-x 1 root root 190 Sep 8 11:32 glib2.sh
-rwxr-xr-x 1 root root 70 Sep 17 12:13 gnome-ssh-askpass.sh
-rwxr-xr-x 1 root root 210 Sep 23 15:42 krb5.sh
-rwxr-xr-x 1 root root 53 Mar 26 2003 lam.sh
-rwxr-xr-x 1 root root 2595 Sep 26 00:39 lang.sh
-rwxr-xr-x 1 root root 435 Sep 1 10:32 less.sh
-rwxr-xr-x 1 root root 70 May 1 2003 pvm.sh
-rwxr-xr-x 1 root root 181 Sep 1 11:01 vim.sh
-rwxr-xr-x 1 root root 170 Jul 17 15:09 which-2.sh
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.
- 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.
- 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.
- 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.
- Change the first umask statement to exclude all permissions for groups and others. Use umask 077 to do the job.
- Save and exit the file.
- 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.
- 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.
|
{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:
CONFIG_QUOTA=y
Alternatively, if you see the following, quota support is not enabled:
CONFIG_QUOTA=n
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.
|
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 HandlingThe /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/fstabAs 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.
|
{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 aquota.group 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 aquota.group files in the configured directory. If you’re configuring quotas on the /home directory, you can check that it worked with the following command:
Using edquota to Set Up Disk Quotas# ls -l /home/aquota.*
To specify disk quotas, you need to run the edquota command. This edits the aquota.user or aquota.group 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
/dev/hdd1
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
hard
/dev/hdd1 52 18000 20000 13 0
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
hard
/dev/hdd1 52 0 0 13 0
0
Figure 5-4 Group quota
|
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 ReportsAs 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 DirectoriesThe 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:
- 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.
- Check to make sure that the quota package is installed. Install from the RHEL 3 installation source if required.
- 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.
- Activate the quotas. You can unmount and remount the /home directory, reboot Linux, or use the following command:
# mount -o remount /home - Use the quotacheck -avum command to activate the quota files in the /home directory.
- Make sure this command worked. Look for the aquota.user file in the /home directory.
- 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.
- 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.
|
{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 PracticesYou 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.
|
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 ModularA 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 KernelUpdating 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.
|
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 RPM | Description |
| kernel-2.4.21-4.EL.athlon.rpm | Suitable for PCs with a single AMD Athlon CPU. |
| kernel-2.4.21-4.EL.i686.rpm | Designed for PCs with a single Intel CPU. |
| kernel-unsupported-2.4.21-4.EL.athlon.rpm | The Athlon kernel with additional unsupported modules. |
| kernel-unsupported-2.4.21-4.EL.i686.rpm | The Intel kernel with additional unsupported modules. |
| kernel-BOOT-2.4.21-4.EL.i386.rpm | Kernel used only during the RHEL 3 installation process. |
| kernel-hugemem-2.4.21-4.EL.i686.rpm | Supports multiple CPUs and systems with more than 4GB of RAM. |
| kernel-hugemem-unsupported-2.4.21-4.EL.i686.rpm | The hugemem kernel configured with additional untested kernel modules. |
| kernel-pcmcia-cs-3.1.31-13.i386.rpm | Adds PCMCIA (PC Card) modules to your current kernel. |
| kernel-smp-2.4.21-4.EL.athlon.rpm | The 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.rpm | The 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.rpm | The SMP kernel with additional untested kernel modules for Athlon CPUs. |
| kernel-smp-unsupported-2.4.21-4.EL.i386.rpm | The SMP kernel with additional untested kernel modules for Intel CPUs. |
| kernel-source-2.4.21-4.EL.i386.rpm | Includes 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 http://www.redhat.com/docs/manuals/enterprise/.
The /boot PartitionThe 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 FilesystemThe /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 ForwardingMore 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 IPforwarding with the following command:
# echo 1 >> /proc/sys/net/ipv4/ip_forward
# cat /proc/sys/net/ipv4/ip_forward
1
Detected CPU information
Preventing the Ping of DeathThe 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.”
Managing /proc Graphically# echo 1 >> /proc/sys/net/ipv4/tcp_syncookies
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
|
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
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.
|
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.
|