The /usr/src/redhat Directory Structure

There are five subdirectories located under the /usr/src/redhat directory, as described below

• /usr/src/redhat/SOURCES contains the original program source code
• /usr/src/redhat/SPECS contains spec files, which control the RPM build process
• /usr/src/redhat/BUILD, source code is unpacked and built here
• /usr/src/redhat/RPMS contains the output binary RPM
• /usr/src/redhat/SRPMS contains the SRPM created by the build process

When you build a source RPM, you build it within this structure. If you install a source RPM, it is extracted into this structure. The kernel source RPM that you installed in the "Installing Source RPMs" should have unpacked a kernel-2.6.spec file in the /usr/src/redhat/SPECS directory.

Installing Source RPMs

Like normal RPMs, a source RPM (SRPM) is installed with the rpm -i rpmname.src.rpm command. However, this command installs only the contents of the SRPM in the various /usr/src/redhat subdirectories, which you can then use to create a binary RPM. for the purpose of our discussion on SRPM, I've installed the source for the Linux kernel from the freely available RHEL source RPMs, which you can download for yourself from ftp.redhat.com.

Once downloaded from the source of your choice, proceed to install it as if it were a regular RPM, in this case with the following command:

# rpm -ivh kernel-*.src.rpm

As noted earlier, you can now use the source code and spec files in various /usr/src/redhat subdirectories to build and install the package.

Creating Custom RPMs from Source

A source RPM is, as the name indicates, a package of source code used to build architecture-specific packages. Properly labeled source RPMs include the src identifer as part of the file name, like so:

polarbear-2.07-2.src.rpm

Binary RPMs are built from source RPMs. The source RPM contains the source code and specifications necessary to create the binary RPM.

As I continue discussing source RPMs over the next several days, make sure your system includes the rpm-build package, for access to the rpmbuild command.

Listing Installed RPMs

There are two basic ways to list all installed RPMs. The basic list is stored in /var/log/rpmpkgs. However, this is updated only once a day. If you want the most current list, run the following command:

# rpm -qa

The /root/install.log file include all packages installed when RHEL was installed on this system. It's not updated after installation.

RPM Verification

Verifying an installed package compares information about that package with information from the RPM database on your system. The --verify (or -v) switch checks the size, MD5 checksum, permissions, type, owner, and group of each file in the package. Here are a few examples:

- Verify all files. Naturally, this may take a long time on your system. (Of course, the rpm -va command performs the same function.)

# rpm --verify -a

- Verify all files within a package against a downloaded RPM.

# rpm --verify -p /root/Desktop/inn-2.4.3-6.i386.rpm

- Verify a file associated with a particular package.

# rpm --verify --file /bin/ls

If the files or packages check out, you will see no output. Any output means that a file or package is different from the original. There's no need to panic if you see a few changes, after all, you do change configuration files. There are eight tests. If there's been a change, the output is a string of up to eight characters, each of which tells you what happened during each test.

If you see a dot (.), that test passed. Teh following example shows /bin/vi with an incorrect group ID assignment:

# rpm --verify --file /bin/vi
. . . . . . G . /bin/vi

Below is a list of failure codes and their meanings:

• 5 MD5 checksum
• S File size
• L Symbolic link
• T File modification time
• D Device
• U User
• G Group
• M Mode

Validating an RPM Package Signature

RPM uses two methods for checking the integrity of a package: the MD5 checksum and the GPG signature. You can use the MD5 checksum to verify tht the file is intact (no data was lost or corrupted while copying or downloading the file). You can then use the GPG signature to make sure the file is authentic. For example, you can use it to confirm that an RPM file is indeed an official Red Hat RPM. Red Hat provides GNU Privacy Guard (GPG) public key for its RPM file; you can find it on each installation CD in the appropriate RPM-GPG-KEY-* file or in the /etc/pki/rpm-gpg/ directory.

To authenticate your RPMs using the GPG system, assuming, it was released after November 2006, import the key file using the following command (assuming it's a CD-based keyfile, mounted on the /media/disk directory):

# rpm --import /media/disk/RPM-GPG-redhat-release

There are six GPG keys associated with RHEL 5. The RPM-GPG-KEY-redhat-release and RPM-GPG-KEY-redhat-auxiliary keys are used for packages released after November 2006; the RPM-GPG-KEY-redhat-former key is used for packages released before that date.

Now if you wanted to check the integrity of some RPM such as pkg-1.2.3-4.noarch.rpm on a CD, you'd run the following command:

# rpm --checksig /media/disk/Server/pkg-1.2.3-4.noarch.rpm

This allows you to verify both the integrity and the authenticity of the RPM.

RPM Queries

The simplest RPM query verifies whether a specific package is installed. The following command verifies the installation of the Samba package:

# rpm -q samba
samba-3.0.23c-2.e15.2

You can do more with RPM queries as described below. Note how queries are associated with -q or --query; full word switches such as --query are usually associated with a double-dash.

rpm -qa Lists all installed packages.

rpm -qf /path/to/file Identifies the package associated with /path/to/file

rpm -qc packagename Lists only configuration files from packagename

rpm -qi packagename Displays basic information for packagename

rpm -ql packagename Lists all files from packagename

rpm -qR packagename Notes all dependencies; you can't install packagename without them

Updating a Kernel RPM

Kernel updates incorporate new features, address security issues, and generally help your Linux system work better. However, kernel updates can also be a pain in the rear end, especially if you have specialized packages that depend on an existing version of a kernel.

In other words, don't upgrade a kernel if you're not ready to repeat everything you've done with the existing kernel, whether it's specialized drivers, recompiling to incorporate additional filesystems, or more.

If you're told to update a kernel RPM, the temptation is to run the rpm -U newkernel command. Don't do it! It overwrites your existing kernel, and if the new kernel doesn't work with your system, you're out of luck. (Well, not completely out of luck, but if you reboot and have problems, you'll have to use linux rescue mode to boot your system and reinstall the existing kernel, which might make or an interesting test scenario.)

The best option for upgrading to a new kernel is to install it, especiall with the command such as:

# rpm -ivh newkernel

If you're connected to an appropriate repository, the following command works just as well:

# yum install kernel

This installs the new kernel, side by side with the current working kernel. It adds options to boot the new kernel in the boot loader menu (through the GRUB configuration file), without erasing existing options. If you use the yum command, make sure you use yum install kernel to ensure the kernel is installed and the previous kernel (and associated configuration options) is not overwritten.

Installing RPMs from Remote Systems

With the RPM system, you can even specify package locations similar to an Internet address, in URL format. For example, if you want to apply the rpm command to the foo.rpm package on the /pub directory of the ftp.rpmdownloads.com FTP server, you can install this package with a command such as:

# rpm -ivh ftp://ftp.rpmdownloads.com/pub/foo.rpm

Assuming you're connected to the Internet, this particular rpm command logs onto the FTP server anonymously and downloads the file.

If the FTP servers requires a username and password, you can use the following format:

ftp://username:password@hostname:port/path/to/
remote/package/file.rpm

where username and password are the username and password you need to log on to this system, and port, if required, specifies a nonstandard port used on the remote FTP server. Naturally, transmitting passwords in clear text over a network is discouraged, so anonymous FTP servers may be preferred.

If the username is paul and the password is Ila451MS, you could install an RPM directly from a server with the following command:

# rpm -ivh ftp://paul:Ila451MS@ftp.rpmdownloads.com/pub/foo.rpm

The key to this system is the rpm command. Even over a network, it works with globbing; in other words, if you don't know the version number, you can replace it with a *:

# rpm -ivh ftp://paul:Ila451MS@ftp.rpmdownloads.com/pub/foo-*

Later, we'll see how to validate the signature associated with an RPM and verify the files in a specific package.

Removing RPMs

The rpm -e command removes a package from your system. But before removing a package, RPM checks out a few things. It does a dependency check to make sure no other packages need what you're trying to remove. If it finds dependent packages, rpm -e fails with an error message identifying these packages.

If you have modified most any of the configuration files, RPM makes a copy of the file, adds an .rpmsave extension to the end of the file name, and then erases the original. Finally, after removing all files from your system and the RPM database, it removes the package name from the database.

Be very careful about which packages you remove from your system. Like many other Linux utilities, RPM may silently let you shoot yourself in the foot. For example, if you were to remove the package that include /etc/passwd or the kernel, it would devastate your system.

Installing RPMs

There are three basic commands that may install an RPM. They won't work if there are dependencies (packages that need to be installed first). For example, if you haven't installed Samba and try to install the system-config-samba package, you'll get the following message (your version numbers may be different):

# rpm -i system-config-samba-*
error: Failed dependencies:
samba is needed by system-config-samba-1.2.39-1.1.noarch

Sure, you can use the --force option to make rpm ignore dependencies, but that can lead to other problems, unless you install those dependencies as soon as possible. The best option is to use an appropriate yum command. In this case, a yum install system-config-samba command would automatically install the Samba RPM as well.

If you're not stopped by dependencies, there are three basic commands that can install RPM packages:

# rpm -i packagename

# rpm -U packagename

# rpm -F packagename

The rpm -i option installs the package, if it isn't already installed. The rpm -U option upgrades any existing package or installs it if an earlier version isn't already installed. The rpm -F option upgrades only existing packages. It does not install a package if it wasn't previously installed.

I like to add the -vh options whenever I use the rpm command. These options add verbose mode and use hash marks to help you monitor the progress of the installation. So when I use rpm to install a package, I run

# rpm -ivh packagename

There's one more thing the rpm command does before installing a package: it checks to see whether it would overwrite any configuration files. The rpm command tries to make intelligent decisions about what to do in this situation. As suggested earlier, if the rpm command chooses to replace an existing configuration file, it gives you a warning (in most cases like:

# rpm -i penguin-3.26.i386.rpm
warning: /etc/someconfig.conf saved as /etc/someconfig.conf.rpmsave

It's up to you to look at both files and determine what, if any, modifications need to be made.

If you've already customized a package and upgraded it with rpm, go to the saved configuration file. Use it as a guide to change the settings in the new configuration file. Since you may need to make different changes to the new configuration file, you should test the result for every situation in which the package may be used in a production environment.

What Is an RPM?

At the heart of Red hat is the RPM database. Among other things, this database tracks the version and location of each file in each RPM. The RPM database also maintains an MD5 checksum of each file. With the checksum, you can use the rpm -V package command to determine whether any file from that RPM package has changed. The RPM database makes adding, removing, and upgrading packages easy, because RPM knows which files to handle and where to put them.

RPM also manages conflicts between packages. For example, assume you have two different packages that use configuration files with the same name. Call the original configuration file /etc/someconfig.conf. You've already installed package X. If you the try to install package Y, RPM packages are dsigned to back up the original /etc/someconfig.conf file (with a file name like /etc/someconfig.conf.rpmsave) before installing package Y.

While RPM upgrades are supposed to preserve or save existing configuration files, there are no guarantees. It's best to back up all applicable configuration files before upgrading any associated RPM package.