|
|
Before you install RPM packages, you may want to run some checks to answer a few questions about those packages. For security purposes, you can make sure that the package was properly signed. You can also find out what dependencies the package has and information about what the package contains. The following sections explore these topics.
Whether you do it to a pile of RPM packages on your hard disk or to packages downloaded from an apt or yum repository, checking the signature of the packages you plan to install on your Linux system is a good idea. Using the rpm command, you can import public keys that are then used to verify the contents of your RPM packages.
The Fedora Core distribution comes with several GNU Privacy Guard (GPG) keys that it uses to verify the packages you install that come directly from the Fedora project. Many software repositories that let you download RPM packages outside of any official Red Hat or Fedora distribution will have their own GPG keys, which you can use to verify that their packages have not been tampered with.
| Cross-Reference |
For more information on the GNU Privacy Guard project, visit the project's home page at www.gnupg.org. |
If you install Fedora Core from the three install CDs, you can find the PGP public key signatures from Red Hat, Inc., in the top-level directory of each CD. After the install, the keys are stored in the /usr/share/doc/fedora-release-1 directory (for Fedora Core systems) or the /usr/share/doc/redhat-release-* (for Red Hat Linux systems). Files containing the two keys that are installed and used automatically on Fedora Core systems include the following:
RPM-GPG-KEY-This file contains the PGP public key used by Red Hat, Inc., to build its own software packages.
RPM-GPG-KEY-fedora-This file contains the PGP public key used to sign packages that are specific to the Fedora Project.
The two keys stored in these files are installed in the RPM database during Fedora Core installation so they can be used to check that the packages have been properly signed.
GPG keys are stored in your RPM database and can be manipulated using some of the same options you would use to work with regular RPM packages. To see the keys installed in your computer, type the following:
# rpm -qa gpg-pubkey* gpg-pubkey-4F2a6fd2-3f9d9d3b gpg-pubkey- db42a60e-37ea5438
The gpg-pubkey-db42a60e-37ea5438 represents the Red Hat, Inc., public key used to sign its packages. The gpg-pubkey-4f2a6fd2-3f9d9d3b represents the Fedora Core public key. To get information about any public key, you can use the rpm command as you would from any RPM package. For example, to see who owns the first public key type
# rpm -qi gpg-pubkey-4f2a6fd2-3f9d9d3b | less Name : gpg-pubkey Relocations: (not relocateable) Version : 4f2a6fd2 Vendor: (none) Release : 3f9d9d3b Build Date: Thu 05 Feb 2004 09:44:00 PM PST Install Date: Thu 05 Feb 2004 09:44:00 PM PST Build Host: localhost Group : Public Keys Source RPM: (none) Size : 0 License: pubkey Signature : (none) Summary : gpg(Fedora Project <fedora@redhat.com>) Description: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: rpm-4.2.1 (beecrypt-3.0.0) mQGiBD+dnTsRBACwnlz4Ahct0LlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBU0JD11NUCqH . . . -----END PGP PUBLIC KEY BLOCK-----
From this output, you can see how the key's name is divided into version and release numbers. In the Summary line, the key is identified as gpg for the Fedora Project. I pipe the output through less here (| less) so that you can page through the text. Press the space bar to page through and type q to quit at the end. I pipe output to less in several examples throughout the chapter.
If, for some reason, either of the keys (Fedora or Red Hat) is not installed, you can import each to your RPM database as follows:
# cd /usr/share/doc/fedora-release-* # rpm --import RPM-GPG-KEY-fedora # rpm --import RPM-GPG-KEY
When you install new or updated RPM packages from Fedora Project or Red Hat, Inc., the keys are automatically checked and you are notified if they don't match any package you try to install. If you ever want to remove a GPG key, you can do so using the -e option of rpm. This is the same command you would use to remove any regular RPM package as well. For example, the following would remove the Fedora public key:
# rpm -e gpg-pubkey-4f2a6fd2-3f9d9d3b
By adding packages to your Fedora or Red Hat Enterprise Linux systems that are not released as part of those distributions, you are assuming more risk for the quality and security of those packages. Getting and using GPG keys to check the signatures on packages you get from third-party software repositories can verify that they haven't been altered since they were created and help insure that the packages come from an identifiable place.
As described in Chapter 3, tools such as yum and apt can be used to download and install RPM packages from the Internet. Getting GPG keys from a download site before you use the software it offers is one way to help check that the software hasn't been compromised. The following procedure describes how to get and import GPG keys to check software you get from the freshrpms.net software repository (a well-known software repository for Fedora and Red Hat Linux software):
Get the freshrpms.net public key by typing the following (if the key file has moved, you might need to go to freshrpms.net and poke around for it):
With the RPM-GPG-KEY.txt file in your current directory, type the following to import the freshrpms.net public key into your RPM database:
#rpm --import RPM-GPG-KEY.txt
Check information for the public key you imported (the next command reflects the public key name currently being used with freshrpms packages).
#rpm -qi gpg-pubkey-e42d547b |less
The output should list Matthias Saou in the Summary.
At this point, you should be able to download packages from the freshrpms.net site (either from your web browser or using a download/install tool such as yum) without getting complaints about not having a key to validate them. You can repeat this procedure for any software repository you want to use.
To check a package before you install it, you can use the checksig option to rpm. Because an RPM package can contain multiple digests and signatures, the checksig option will check each digest and signature to make sure it is correct.
For example, let's say that you copied the fedora-logos RPM package into the current directory. You could check the signature on that package as follows:
# rpm --checksig fedora-logos-1.1.20-noarch.rpm fedora-logos-1.1.20-noarch.rpm: (sha1) dsa sha1 md5 gpg 0K
This output shows that the package uses the Secure Hash Algorithm, version 1 (sha1) header digest, which acts as a fingerprint of the contents of the RPM. It uses a DSA header signature and includes md5 digest and GPG signature. You can tell that this package is all right (was properly created with the given key) by noting the following:
Each digest and signature is shown in lower case.
There is the word OK at the end (as opposed to NOT OK).
If you want to see more information about the signature checking, you can add a -v or -vv option. Here is an example:
# rpm --checksig -vv fedora-logos-1.1.20-1.noarch.rpm
D: Expected size: 263841 = lead(96)+sigs(344)+pad(0)+data(263401)
D: Actual size: 263841
D: opening db environment /var/lib/rpm/Packages joinenv
D: read h# 1624 Header sanity check: OK
D: ========== DSA pubkey id b44269d04f2a6fd2
fedora-logos-1.1.20-1.noarch.rpm:
Header V3 DSA signature: 0K, key ID 4f2a6fd2
Header SHA1 digest: OK (b712be20fa0b6d3bf89f6a3d0c91f86efce24f0e)
MD5 digest: 0K (94d9d20ce0265cb1f36d5fb8fa0dfc30)
V3 DSA signature: 0K, key ID 4f2a6fd2
The output shows that the number of characters expected in the file (263,841) was actually found. You can see that the command connected to the RPM database environment (/var/lib/rpm/Packages joinenv). The header passed a sanity check (OK), and the DSA public key with id number b44269d04f2a6fd2 was found. After this each signature and digest was checked (DSA signature, SHA1 digest, MD5 digest, and DSA signature) and found to be correct (OK).
If the package checks out, and you trust the keys you are using, you can probably go ahead and safely install the package.
The following examples illustrate some cases where the package did not check out:
Missing key-If for some reason, the public key associated with the signed package was not installed in your database, you might see the following error message:
fedora-logos-1.1.20-1.noarch.rpm: (SHAD DSA sha1 md5
(GPG) NOT OK (MISSING KEYS: GPG#4f2a6fd2)
In this case, the key 4f2a6fd2 (for Fedora Project packages) is missing. Note that a missing key causes the SHA1, DSA, and GPG notations to display in upper case (indicating a failure). However, the fact that sh1 and md5 are in lower case indicates that the package itself is not corrupted, because the SH1 and MD5 digests were consistent with the contents of the package. Chances are if you install the proper key, the package will pass the check.
Corrupted RPM-If the contents of an RPM file have been badly corrupted, all digest and signature indications might appear in upper case or the package might not even be recognized as an RPM file. The following messages reflect these two results:
fedora-logos-1.1.20-1.noarch.rpm:(SHA1) DSA SHA1 MD5 GPG NOT OK error: fedora-logos-1.1.20-1.noarch.rpm: not an rpm package
You won't be able to install this package even if you wanted to. Get a new copy of the package.
Modified RPM content-It is possible that the content of an RPM file has been changed, but the headers appear to be valid. In that case, even though the dsa and sh1 appear to be all right, the MD5 and GPG will appear as BAD. Here's what verbose output looks like (rpm --checksig -vv) in that case:
fedora-logos-1.1.20-1.noarch.rpm:
Header V3 DSA signature: 0K, key ID 4f2a6fd2
Header SHA1 digest: 0K (b712be20fa0b6d3bf89f6a3d0c9lf86efce24f0e)
MD5 digest: BAD Expected(94d9d20ce0265cblf36d5fb8fa0dfc30) !=
(835891bb30ca96d73dc4bce78ddb36d7)
V3 DSA signature: BAD, key ID 4f2a6fd2
In this case, you should not use the RPM since it was probably tampered with.
Most RPM packages include built-in information about other components (such as libraries) that they require to work. If you try to install or upgrade a package, and components the package depends on are not already installed, package installation fails (by default). Likewise, if you try to remove a package on which other installed packages depend, it will also fail.
If you install a package from Fedora or Red Hat Linux installation CDs (or if you are installing from a well-maintained yum or apt repository), dependency checks are done automatically when you try to add or remove packages. When you install using yum or apt programs, they ask you if you want to install any dependent package(s) as well. If you say yes, yum or apt will go ahead and install the dependent package(s). Problem solved.
| Note |
Installing RPMs from a software repository using yum or apt is always preferred over installing individual packages from an FTP or HTTP server. Yum and apt can insure dependencies are met in a way that can't be done by downloading packages individually. |
This is a troubleshooting book; however, you might be interested in dealing with those times when there is not a package already installed to fulfill the requirements. In that case you can do the following:
Skip dependencies-The rpm command allows you to skip dependency checking using the --nodeps option. While this will get the package installed, it will most likely leave you with a package that doesn't work.
Look for the needed RPM package-You might need to do some digging around to find the package that contains the components you need. Then you can install the package that contains the required component so the package you want can be installed.
To find out what dependencies are not being met, you can just try to install or upgrade the package you want. The missing dependent components will be listed by default and the install will fail. Alternatively, you can ask to explicitly list the dependencies of the package. Once you know what is missing, you can do the following:
Search installed RPM packages for the component.
Search the full database of RPM packages that are on the full CD set representing Fedora Core, Red Hat Linux 9, or other operating system. (See the Using the RPM Universal Database sidebar for more information.)
Check the FTP or HTTP directory where you got the initial package, search the rpmfind.net site for the package you need, or just search the Internet.
 |
Each Red Hat Linux distribution (Fedora, Red Hat Linux 9, and Red Hat Enterprise Linux) includes a package containing a database of information that describes all the RPMs in that distribution. In Red Hat Linux install the rpmdb-redhat package; in Fedora install rpmdb-fedora package.
The entire database of RPM information is in the /usr/lib/rpmdb/i386-redhat-linux/redhat directory. You can query that database for dependencies using the rpm --redhat provides and rpm --redhatrequires command. When searching for how to resolve dependencies for a package you want to install, this "universal" database is a good place to look.
|
The following procedure takes you through the process of checking a package for dependencies, finding the package needed to fulfill the dependencies, and then getting and installing that package.
Get an RPM package you want to install. For this example, I downloaded the xmame-0.78.1-2.fr.i386 package for Fedora Core 1:
Run a test install on the package to see the dependency checking (among other things):
# rpm --test -Uhvv xmame-0.78.1-2.fr.i386
D: ============== xmame-0.78.1-2.fr.i386.rpm
D: Requires: /bin/sh YES (db files)
D: Requires: /usr/bin/tclsh YES (db files)
D: Requires: libc.so.6 YES (db provides)
D: Requires: libc.so.6(GLIBC_2.0) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.1) YES (db provides)
D: Requires; libc.so.6(GLIBC_2.3) YES (db provides)
D: Requires: libz.so.1 YES (db provides)
D: Requires: rpmlib(CompressedFileNames) <= 3.0.4-1 YES (rpmlib provides)
D: Requires: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 YES (rpmlib provides)
D: Requires: xmame-bin = 0.78.1 NO
D: package xmame-0.78.1-2.fr has unsatisfied Requires: xmame-bin = 0.78.1
error: Failed dependencies:
xmame-bin = 0.78.1. is needed by xmame-0.78.1-2.fr
As you can see from the output (which I edited down to include just required items), most of the required components needed by the xmame package are already provided by the packages that are already installed. The sh and tclsh files are there, as are several libc libraries and rpmlib features. What is missing is xmame-bin.
You can see if any installed package has the component you need using the query option -whatprovides. (Of course, we already know the component is not in an installed package, since the dependency failed. But we'll just go through the motions anyway.)
#rpm -q --whatprovides xmame-bin no package provides xmame-bin
Next, you can search the universal RPM database, which contains all the RPM packages in the entire Fedora Core or Red Hat Enterprise Linux CD set. This will tell us if the component is in any package from your CD set, whether or not the package is installed.
#rpm --redhatprovides xmame-bin no package provides xmame-bin
Next, I suggest opening the FTP site where you got the package in an FTP client and seeing if the package needed is there. In my case, I went to the freshrpms.net directory that contained the xmamb package and downloaded the xmame-x11 package to the current directory. I then checked to see what the package provided:
#rpm -q --provides -p xmame-x11-078.1-2.fr.i386.rpm xmame-bin = 0.78.1 xmame-SDL = 0.78.1-2.fr
This package seems to provide the xmame-bin component we need. So we can go ahead and try installing it. If this installs without a problem, we can install our original xmame package. Although in this case it worked, if you could not find a package to meet the dependency in the FTP directory of the original package, continue with the rest of this procedure.
| Note |
Instead of using the name of the package in the current directory to check for the needed component, you could have provided the full URL to the package in the FTP or HTTP directory. It makes you type a long URL, but adds an extra download step. |
If the package is still not found, try searching the rpmfind.net site. Go to www.rpmfind.net and search for the needed component. All RPM files that are found that include your search term are displayed. Click on one that is listed for Red Hat Linux 9 or other appropriate distribution.
If you still have not found the component, as a last resort go to www.google.com or other search engine and simply search the Internet for the component.
There may be some cases where you can't match the dependency exactly. For example, the package you want to install may be looking for an exact version of the component and you might only have access to a later version. The later version may well work. In that case, you might want to try the --nodeps option to force the package to install. Here are some of the types of dependent components you may run into:
Package-An exact package may be required. In that case, the dependency may specify only the package name or package name and version number. The requirement may also be that the package be less than, greater than, or equal to a certain version.
Component-A particular library or binary file may be required. Where that component comes from may not matter, as long as it is provided by some RPM package. In this example, an exact version of xmame-bin was required (xmame-bin = 0.78.1). This represents an xmame binary that can be available from several different RPM files. As long as one is installed, the dependency check will pass.
After your software packages are installed, the RPM database remains an excellent resource for cross-checking original information about a package against the actual installed components on your hard disk. In other words, you can tell if someone has been fooling around with your software.
Chapter 10 is a more complete reference to techniques for verifying if any of your software has been tampered with, including ways of using the rpm command to verify that someone hasn't planted a trojan horse in an executable. A simple way of checking a whole RPM package for files that have been tampered with is the rpm -V command. For example, to check the entire samba package, you could type
# rpm -V samba
Any files in the samba package that have been changed since they were installed will appear after the command. The next procedure can be used for checking whether a single file has been tampered with.
For the file or command you want to check, find out what package it is from. In this example, I'm checking the startup script for the Samba service:
#rpm -qf /etc/rc.d/init.d/smb samba-3.0.0-15
List the files (-ql) contained in the samba software package (from the RPM database of installed software) and dump (--clump) data out about each file. Then sort out (grep) everything except the smb script.
#rpm -ql --dump samba | grep /etc/rc.d/init.d/smb /etc/rc.d/init.d/smb 1928 1064589271 99d3f786f9dc199fe0221cce496c5795 0100755 root root 1 0 0 X
Interesting information associated with the dump includes the following:
The original number of characters in the file (1928).
The md5sum digest that reflects the contents of the smb file (99d3f786fgdc199fe0221cce496c5795).
Permission associated with the file (0755).
Ownership of the file (root owner and root group).
Next, check the actual file to see if the contents have been changed. Type the following:
#Is -1 /etc/rc.d/init.d/smb -rwxr-xr-x 1 root root 1928 Sep 26 08:14 /etc/rc.d/init.d/smb #md5sum /etc/rc.d/init.d/smb 99d3f786f9dcl99fe0221cce496c5795 /etc/rc.d/init.d/smb
The long list of the file (ls -l) shows that there are 1928 characters in the file, the owner and group are both root, and file permissions are 0775 (-rwx r - x r - x). All of that matches the dump output shown earlier. Likewise, the md5sum output (99d3f . . . c5795) also matches the dump output for the file.
In this case, information about the installed smb script seemed to match the information about the original script stored in the RPM database. If you believe that the RPM database might have been tampered with as well, you could check against the actual samba RPM file from the CD or other trusted source. For example, with the samba RPM in the current directory, I could type
# rpm -ql --dump -p samba-3.0.0-15.i386.rpm | grep /etc/rc.d/init.d/smb
Hopefully, you would get the same results as you got from the similar command line you ran against the RPM database.
| Cross-Reference |
For more information on using the rpm command to verify the contents of a command, library or configuration file, refer to Chapter 10. |
Many RPM packages include scripts that run when the package is installed or uninstalled. In particular, when you are upgrading from one version of a package to another and something messes up, you might want to see what those scripts did to your system.
The rpm command has a means of listing the contents of
scripts in an RPM package that run during the install or uninstall process and
trigger scripts that are kicked off when certain conditions are met.
The following sections describe how to list scripts and trigger scripts in an RPM file.
Use the --scripts query option to the rpm command to see scripts that are run before and after installs and uninstalls of a package are done. Here is an example:
# rpm -q --scripts samba postinstall scriptlet (using /bin/sh): /sbin/chkconfig --add smb preuninstall scriptlet (using /bin/sh): if [ $1=0 ]; then /sbin/chkconfig --del smb rm -rl/var/log/samba/* /var/cache/samba/* /sbin/service smb stop >/dev/null 2>&1 fi exit 0 postuninstall scriptlet (using /bin/sh): if [ "$1" -ge "1" ]; then /etc/rc.d/init.d/smb condrestart >/dev/null 2>&1 fi
This example shows the scripts that are included in the samba package. After the samba package is installed (postinstall), the chkconfig command is called to turn on the samba service (- -add smb). Before the package is uninstalled (preuninstall), the samba service is removed from starting again (chkconfig - -del smb) and all log files (/var/log/samba/*) and cache files (/var/cache/samba/*) are removed.
After the package is uninstalled (postuninstall), if the package still exists on the system, the service is restarted. (This is done in cases where you are removing an old version of the package and the new version has been installed and needs to be restarted.)
Scripts that have some level of complexity include those for packages that use the alternatives system and therefore may or may not be activated by default (including sendmail, postfix, and cups). Special scripts that are only used in particular conditions are referred to as trigger scripts.
Some packages have trigger scripts that are kicked off during installation if certain conditions are met. These are particularly useful in upgrades where the software packager wants different installation actions to take place, depending on the current package release you are upgrading from. Here's an example of how to display the trigger scripts included in the sendmail package:
# rpm -q --triggers sendmail triggerpostun scriptlet (using /bin/sh) -- sendmail<8.10.0 /sbin/chkconfig --add sendmail triggerpostun scriptlet (using /bin/sh) -- sendmail<8.11.6-11 /usr/sbin/alternatives - auto mta
Here you can see that upgrades from pre-8.10.0 versions of sendmail add the sendmail services to be turned on when the computer boots (chkconfig--add sendmail). Pre-8.11.6-11 sendmail versions have the alternatives command set the mail transfer agent (mta) to auto state (which makes the highest priority mail services used as the mta). By default, sendmail is chosen over postfix.
There have been some reports of trigger scripts breaking services. So if a service that was recently upgraded, such as sendmail or initscripts, is broken, you can check for triggers to see if there are trigger scripts that could have caused a problem.
|
|