Mastering Red Hat Linux 9 [Electronic resources] نسخه متنی

Making Source RPMs Work

A key feature of Linux is the easy accessibility to the source code. Since Red Hat Linux is built on RPM packages, that means access to the source RPMs (SRPMs). An SRPM includes the code and instructions needed to build abinary RPM, which you can then install on your Red Hat Linux computer.

Processing source code now requires the rpm-build RPM package. While the rpm command still provides legacy support for managing SRPMs, you’ll need to use the rpmbuild command for this purpose in the future.

To understand how to use a source RPM, you need to know the default directory structure and understand that .spec files are used to build a binary RPM.

Directories

By convention, SRPMs are easy to identify; they have the .src.rpm extension. SRPMs include specification and other files, which you can set up in various /usr/src/redhat subdirectories. Any SRPM that you build into a binary file is also set up in the same directory structure. The five key SRPM directories are shown in Table 10.2.

To break an SPRM down into these directories, you need to install it. For example, if you want to work with the anonftp package, you’ll need to install the associated .src.rpm file. For example, if you’ve mounted an SRPM Red Hat CD, you might use the following command:

# rpm -i /mnt/cdrom/RedHat/SRPMS/anaconda-*.src.rpm

The Spec File

The key to managing an SRPM is in its spec file. Once you’ve installed an SRPM, you should be able to find its spec file in the /usr/src/redhat/SPECS directory. This file controls how packages are built, and configures commands when an RPM is installed or deleted.

The key sections in a spec file are %prep, %build, and %install. They allow you to build source and binary RPMs. One important variable is Requires or BuildRequires, which lists other packages that you should install first. Other typical sections in a .spec file include:

%define Includes basic parameters such as the location of the top-level directory for that package. For example, you might see a ROOT /var/ftp line in this section. The section includes basic summary information for the RPM. When this RPM is installed, this is what a user will see in response to the rpm -qi packagename command.

%package Lists packages that depend on this particular RPM.

%description Provides more information for the rpm -qi packagename command.

%prep Includes preparation commands for archives and patches.

%setup Contains processing commands for unpacking archives.

%build Builds the code to be compiled.

%install Adds the commands that actually build the files and install the package in well-defined directories.

%clean Includes basic commands for deleting any intermediate files from your system.

%post Contains post-installation scripts, such as a script that modifies a user account.

%postun Contains scripts after you remove a package.

%pre Contains pre-installation scripts, such as a script that prepares a directory.

%preun Contains scripts before you remove a package.

%triggerin Contains parts of other packages you’ve copied.

%config Lists configuration files for /etc.

Spec files are not as difficult as they may look. For the most part, they include regular Linux commands and descriptions, which you can modify in a text editor.

Building Binaries from a Tarball

You can create an RPM from a tarball. But first, you need a spec file. As you’ve seen in the previous section, this can be a little difficult.

One way to learn more about this process is to read different spec files. For example, take the following excerpts from a dosemu.spec file:

%define vimver 5.8
%define vim vim58
Summary: A DOS emulator.
Name: dosemu
Version: 1.1.1
Release: 3
Exclusivearch: %{ix86}
License: distributable
Group: Applications/Emulators
Source0: ftp://ftp.dosemu.org/dosemu/dosemu-%{version}.tar.bz2
…
Patch0: dosemu-0.66.7-config.patch
…
%package -n xdosemu
Requires: dosemu = %{PACKAGE_VERSION}
Summary: A DOS emulator for the X Window System.
Group: Applications/Emulators

This file was taken from a dosemu-*.src.rpm package. The system is fairly straightforward; from the code, you can find the release version, the URL for the source and related patch(es), and the summary description. You can also see that the xdosemu package requires dosemu, which sets up an RPM dependency.

Building a Binary RPM

All you need to create a binary RPM is the source code (which you can get from a source RPM or a tarball) and a spec file. You can create a spec file from scratch, or modify an existing spec file from a source RPM.

There are two basic ways to build a binary RPM:

# rpmbuild -ba packagename.spec
# rpmbuild -bb packagename.spec

The first command (rpmbuild -ba) creates binary and source RPM packages. The second command (rpmbuild -bb) creates only the binary RPM package.

Once you’ve learned to use RPMs, it’s easy to become too dependent. A cracker might post a virus or a Trojan horse on an RPM posted online. The rpm command includes ways to check the integrity of an RPM, using the Pretty Good Privacy (PGP) system (see the next section). You can also verify the contents of a package, or even a specific file.

RPM and Pretty Good Privacy

The RPM system uses one of the security standards associated with e-mail security, known as Pretty Good Privacy (PGP). Developed by Phil Zimmerman, PGP provides a private- and public-key system. With Red Hat Linux, the GNU way of using PGP is known as the GNU Privacy Guard (GPG).

The key to all of this is the Red Hat GPG key. It should be installed by default as /usr/share/doc/rpm-version/RPM-GPG-KEY. If it isn’t there, you can get it from at least one of the following sources:

From the Red Hat Linux installation CDs, in the main directory. If you install CDs in the default location, the key will be in /mnt/cdrom/RPM-GPG-KEY.

From www.redhat.com. As of this writing, it is available at www.redhat.com/solutions/ security/news/publickeyl.

Next, import the GPG public key. For example, if you’re importing from the installation CD, you should import to the /var/lib/rpm/Pubkeys file with the following command:

# rpm --import /mnt/cdrom/RPM-GPG-KEY

Verifying a Package

Now you can verify any RPM package for a genuine Red Hat Linux signature. For example, it may be a good idea to verify the integrity of the kernel sources before recompiling. To perform this task on a kernel-sources RPM in the /tmp directory, run the following command:

# rpm -K /tmp/kernel-source-*.rpm
/tmp/kernel-sources-versionnumber.rpm: (sha1) dsa sha1 md5 gpg OK

This verifies the integrity of the kernel-source RPM to the noted encryption schemes, including GPG.

Verifying a File

It’s useful to check files against the original configuration. For example, if a cracker changes a file on your computer, you want to know about it. There are a number of standard things about every file you can check against the original. The data associated with every file installed through an RPM package is stored in the RPM database in the /var/lib/rpm directory.

If you suspect that a certain command isn’t working quite as it should, you can check it against the RPM database. Let’s take the mount command as an example. You can check the integrity of mount with the following command:

# rpm -Vf /bin/mount

If you don’t see any output, the command matches what was originally installed.

Alternatively, if someone tampered with the mount command, you might see output similar to the following:

# rpm -Vf /bin/mount
SM5....T    /bin/mount

This command checks nine different attributes of /bin/mount. If you see one of the letters shown in Table 10.3, the file differs from the original in some way. In this particular case, there are changes to the file size, permissions, the MD5 checksum, and the file modification time.

In some cases, a “failure” is not a problem. For example, if you’ve revised your /etc/inittab file, you’ll see what looks like a verification failure:

# rpm -Vf /etc/inittab
..5....T c /etc/inittab

However, this particular “failure” may not mean that a problem exists. For example, I got this result after modifying the initdefault variable in this configuration file. In other words, the checksum (5) changed because I changed the content of the file; and the file modification time (T) is different from when Red Hat Linux was installed on my computer.