Certification Objective 5.02-More RPM Commands

The rpm command is rich with details, and learning to use this command can and does fill entire books, including the Red Hat RPM Guide, by Eric Foster-Johnson. All this book can do is cover some of the basic ways rpm can help you manage your systems. You've already read about how rpm can install and upgrade packages in various ways. Queries can help you identify what's installed, in detail. Validation tools can help you check the integrity of packages and individual files. You can use related tools to help you find the RPM that meets specific needs as well as a full list of what's already installed.

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.el5.2 

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

Table 5-1: rpm --query Options

rpm Query Command


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.

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 that 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 a GNU Privacy Guard (GPG) public key for its RPM files; 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-KEY-redhat-release 

On the Job 

There are six GPG keys associated with RHEL 5. The RPM-GPG-KEY-redhat-release and RPM-GPG-KEY-redhat-auxilliary 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 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. The following example shows /bin/vi with an incorrect group ID assignment:

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

Table 5-2 lists the failure codes and their meanings.

Table 5-2: rpm --verify Codes

Failure Code



MD5 checksum


File size


Symbolic link


File modification time









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 includes all packages installed when RHEL was installed on this system. It's not updated after installation.

Using RPM Sources

The RPMs described so far are already in binary format. In other words, they're compiled and ready to install just like "tarballs" or Microsoft-style installation packages. But Linux goes back to the source code. Courtesy of the GPL, the source code is readily available.

In fact, if you're studying for the Red Hat exams using Fedora Core 6 and don't have an RHN subscription, you still have access to the RHEL source code packages through ftp.redhat.com.

image from book
Exam Watch

You can also build RPM sources from a tar archive. However, as of this writing, no requirements in the RHCE and RHCT related course outlines are related to building source RPMs from tar archives. But an obsolete version of the RHCE Exam Prep guide suggests that you need to be "familiar with the basic elements of" source RPMs.

image from book

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 identifier as part of the file name, like so:


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

Before you continue with this section, make sure your system includes the rpm-build RPM package, for access to the rpmbuild command.

On the Job 

In RHEL, the rpmbuild command has superseded the older rpm commands associated with building RPM packages from source code.

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 various /usr/src/redhat subdirectories, which you can then use to create a binary RPM. For the purpose of this section, 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.

The /usr/src/redhat/ Directory Structure

There are five subdirectories located under the /usr/src/redhat directory, as described in Table 5-3.

Table 5-3: Build Directories from RPM Sources




Contains the original program source code.


Contains spec files, which control the RPM build process.


Source code is unpacked and built here.


Contains the output binary RPM.


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 previous section should have unpacked a kernel-2.6.spec file in the /usr/src/redhat/SPECS directory.

Changing Compile Options for a Source RPM

While most precompiled RPMs will serve your needs, at times you will want to modify the source code or compile options in the corresponding SRPMs. You can do so in the spec file that you get when you installed the source RPM.

To change the compile options in an SRPM, you must understand spec files. The spec file is stored in /usr/src/redhat/SPECS/packagename.spec. The spec file controls the way a package is built and what actions are performed when it is installed or removed from a system. A spec file has 10 different sections, as described in Table 5-4. Several of the sections include commands that can be run as individual shell scripts. You won't see all of these sections in every spec file. For more information, see the RPM HOWTO at www.rpm.org.

Table 5-4: Build Directories for Source RPM Files




Includes information shown with an rpm -qi command. This normally includes a summary, version, and group. It also includes a list of dependent packages.


A basic package description.


Adds a macro for preinstallation scripts.


Includes any preparatory commands required before building the source code, such as unpacking.


Commands to compile the spec file and build sources.


Commands to install the software on a system.

Install and uninstall scripts

Spec files usually contain scripts that will be run on the end user's system to install or remove the software. RPM can execute a script before the package is installed, after the package is installed, before the package is removed, and after the package is removed.


Although RPM takes care of most verification tasks, a script can be inserted here for any desired extra checks.


A script can be specified here to perform any necessary cleanup tasks.


Adds a macro that cleans up after installation.


Scripts that prepare for uninstallation.


Adds a macro that cleans up after uninstallation.


A list of files in the package.


A list of revisions.

You can change the compile-time options for a package in the build section of the spec file. Here's a sample %clean section from a different spec file (this is not from the vsftpd source RPM):

 %build rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/bin $RPM_BUILD_ROOT/etc ./configure --prefix=/usr --exec-prefix=/ make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s 

This section, a shell script, begins with some housekeeping, removing any files that may be left over from a previous build. A directory structure is created for the source files. Then the package is configured and compiled with the make command.

For a different package, you might modify the make command line to compile other components after LDFLAGS. The compile options from $RPM_OPT_ FLAGS are defaults, set by RPM. Alternatively, you could use this variable to set other compile-time options such as a different CPU.

On the Job 

Perhaps the essential reference guide to the RPM system is Red Hat's book Maximum RPM. An older version is available online from Red Hat at www.redhat.com/docs/books/max-rpm.

Building Custom Source and Binary RPMs

By now, you should understand where you should modify a source RPM spec file to change compile-time options in the %build section. However, there's much more to building customized RPMs. Once you have modified the spec file, you need to tell RPM to build a new binary and source RPM.

You can build an RPM using the rpmbuild command, with the build switch, -b. By itself, rpmbuild -b calls the scripts specified in the %prep, %build, and %install sections of the spec file. Normally, you'll modify the -b with a, which makes RPM go through the build process, step by step. The rpmbuild command is directed at a spec file. For example, this command

 # rpmbuild -ba vsftpd.spec 

directs RPM to create binary and source RPMs from this spec file. Alternatively, if you just want the binary RPM, use the following command:

 # rpmbuild -bb vsftpd.spec 

Naturally, the RPMs are created in the RPMS/ and SRPMS/ subdirectories.

Building Red Hat Enterprise RPMs

Red Hat makes source RPMs freely available at ftp.redhat.com. You can find the SRPMs for RHEL 5 Server in the /pub/redhat/linux/enterprise/5Server/en/os/SRPMS directory. If you're working with RHEL 5 Desktop, substitute 5Client for 5Server.

If you're studying for the Red Hat exams using a "rebuild," you don't have to buy RHEL. Alternatively, you can build Red Hat Enterprise RPMs from the source code. For example, you can learn more about the Samba server from the Samba source code. To do so, take the following steps. First navigate to ftp.redhat.com (or a mirror site) and navigate to the directory with RHEL 5 source RPMs. (The source code for the RHEL 5 Client and Server are identical, as of this writing.) Then you can

  1. Download the RHEL 5 version of the package that contains the Samba server, samba-*.src.rpm.

  2. Install the source RPM package. The rpm command described earlier sets up the source code in your /usr/src/redhat tree.

  3. Build the RPM from source. The rpmbuild commands use the code loaded in the /usr/src/redhat directories to create RPM packages in the /usr/src/redhat/ RPMS directory, in the subdirectory associated with your architecture.

RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302)
Linux Patch Management: Keeping Linux Systems Up To Date
ISBN: 0132366754
EAN: 2147483647
Year: 2004
Pages: 227
Authors: Michael Jang

Similar book on Amazon
Linux Quick Fix Notebook
Linux Quick Fix Notebook
Self-Service Linux: Mastering the Art of Problem Determination
Self-Service Linux: Mastering the Art of Problem Determination
RHCSA/RHCE Red Hat Linux Certification Study Guide (Exams EX200 & EX300), 6th Edition (Certification Press)
RHCSA/RHCE Red Hat Linux Certification Study Guide (Exams EX200 & EX300), 6th Edition (Certification Press)
Security Strategies in Linux Platforms and Applications (Information Systems Security & Assurance)
Security Strategies in Linux Platforms and Applications (Information Systems Security & Assurance)

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net