114 Technique 17: Installing Made Easy with RPM
• Figure 17-7: The YaST package manager.
Installing from your Konqueror browser
With the Konqueror (KDE) browser, you can install RPM packages with just a couple of clicks from the comfort of your browser window. You can use the Konqueror browser to install RPM packages downloaded from the Web, or from disk.
If you’re using Fedora, follow these steps:
1. Open your Konqueror browser and navigate to the directory holding the .rpm file.
2. Double-click the package filename.
In a snap, the Package Manager walks you through the installation.
Follow these steps if you’re running SuSE:
1. Open the Konqueror browser and surf to the file’s location.
2. Click the package’s icon to view a description of the package’s content.
Change to the Files tab to see a list of the files included in the RPM package.
3. Click the Install Package with YaST button.
Enter the superuser password if prompted.
YaST takes it from there, and installs your package!
If you’re a Mandrake user, follow these steps:
1. Open the Konqueror browser and move to the directory containing the RPM package.
2. Right-click on the package’s icon, and choose
Software Installer from the pop-up menu.
3. Enter your root password if prompted and click OK.
A message dialog opens, asking if you would like to install the software package on your computer or just save the file.
If you need additional files to satisfy the dependencies of the package, you’ll be prompted to accept their installation as well.
4. Click the Install It button.
A progress bar opens, and the package is installed. That’s all there is to it!
Be sure you’re getting RPM packages from a reputable source. A not-so-friendly but crafty programmer with an axe to grind could potentially infect an RPM package with a virus and do mega-harm to your system. Technique 18 shows you how to verify that a package comes from the person who claims to have built it. Be sure to perform backups on a regular basis if you’re doing a lot of downloading (see Techniques 49 and 50 for more information about backing up your system).
18 Getting Comfortable
with RPM
Technique
Save Time By
Updating rather than installing your software
Verifying your system integrity
Keeping an eye on file ownership
Determining whether a package has been tampered with
In Techniques 16 and 17, we show you the fast (and powerful) installation and query features of RPM (the Red Hat Package Manager). In this technique, we introduce you to some of the eclectic (but handy) fea-
tures that often go by the wayside — verify and update.
RPM just might be your system’s best friend. After all, it knows more about your system than anyone. RPM maintains a database of information about the packages installed on your system. By comparing that database to the current state of your system, RPM can tell you if a package has been altered after you installed it. The --verify feature can help you detect intruders, users trying to do things they shouldn’t be doing, or configuration problems just waiting to ruin your weekend.
RPM can also verify the digital signature (and integrity) of a package before you install it to see if the package has been tampered with. You can save yourself hours of misery by keeping your system safe from potential Trojan horses. If the key signature doesn’t match, you don’t install it.
In this technique, we walk you through some RPM features that you may not be familiar with. Some of these features are great timesavers — you just need to know about them.
Saving Time with --upgrade
When you add a new package to your system, you can use rpm --install to install or rpm --upgrade to upgrade. We recommend going the upgrade route rather than the install route. rpm --install fails if an older version of the package is already installed, but rpm --upgrade upgrades an existing package or installs a new one, whichever is appropriate.
To use any of the RPM features that modify the rpm database — including installing and updating — you need to hold superuser privileges. If the rpm command displays a cryptic message (such as cannot get exclusive lock or cannot open Packages index), check your privileges.
116 Technique 18: Getting Comfortable with RPM
When you use --install, rpm first looks at your system to see if the package is already installed. If it is, rpm complains about file conflicts. (And if you look very closely, you also see a message that states the package is already installed — a message that’s kind of hard to see among all the other complaints.)
When you use --upgrade, rpm checks to see if the package is installed and, if so, compares the installed package to the version you’re trying to install. If you’re installing a more recent version, rpm upgrades to the more recent version. If you’re trying to install an older version, it tells you that your currently installed software is more recent than the copy you’re trying to upgrade to, and quits. If the package is not currently installed on your system, rpm installs it.
Here’s our favorite command line for installing new software:
# rpm --upgrade -vh filename.rpm
You can use this command to do initial installs or to upgrade versions. bash doesn’t care which because it knows that your intention is to get the most recent copy of the program on your system as quickly as possible.
An easy timesaver is to use the shortcut version of the upgrade command to install RPM packages, # rpm -Uvh filename.rpm.
All the command line options that work with --install also work with --upgrade. Check out the man page (man rpm) for a complete list.
Verifying Your System
When you install a package, RPM records detailed information about the package content in a database. The database includes information such as expected file size, expected owner, and expected permissions. RPM also stores an MD5 checksum (effectively a fingerprint that uniquely identifies
the file content; see the sidebar, “What’s this MD5 stuff anyway?”) for each file in each package. At your request, RPM compares the information stored in the database with the installed version of a given package.
When you run the command rpm --verify packagename, rpm searches through the list of files owned by that package and compares the file as it exists on your hard drive with the information stored in the database. For each file, -verify compares the file’s size, permissions, group and owner, modification time, and MD5 checksum. RPM verifies that packages you’ve installed are still in good form and haven’t been tampered with.
You can verify a single package, a group of packages, or all the packages installed on your computer. If your packages are clean, rpm --verify completes without printing any messages. If rpm --verify finds a file that’s out of whack, it displays a cryptic looking string of characters that tells you what’s wrong. The failure codes are listed in Table 18-1.
TABLE 18-1: RPM --VERIFY FAILURE CODES
Code Meaning
SThe file’s size differs from the expected value.
MThe file’s permissions differ from the expected values.
5The MD5 checksum has changed — this one is important because it means someone has tampered with a file after you installed it.
DThis file is a device-interface file, and the major or minor device numbers differ from the expected values.
LThis file is a symbolic link but is pointing to the wrong place.
UThe file’s ownership has changed — watch this one. A change in ownership can alert you to an intruder who’s trying to gain extra privileges or to modify files he (or she) shouldn’t modify.
GThe file’s group ownership has changed.
TThe modification time has changed.
Reading the Tamper-Proof Seal 117
We’ve purposefully damaged one of the files on our computer just to see what --verify reports:
$ rpm --verify coreutils
S.5....T d /usr/share/man/man1/yes.1.gz
The failure codes tell us that the file has changed size (S), its MD5 checksum is wrong (5), and the modification time doesn’t match the value stored in the RPM database (T).
Check out any inconsistencies that --verify uncovers because they could indicate intruders or other problems waiting to bite you:
The MD5 checksum value is like a fingerprint of the data within a file. If the number changes, the content has changed.
If the user ownership changes, users might be getting in and giving themselves privileges they shouldn’t have.
Likewise, a change in group ownership could indicate an intruder.
If the MD5 checksum has changed, but the modification time has not changed, an intruder may be trying to cover his or her tracks.
To verify a single package, include the package name on the command line, like this:
$ rpm --verify bash
You can also verify all the packages within a group:
$ rpm --verify --group “Amusements/Games”
To verify all the packages installed on your computer, use the following command:
$ rpm --verify --all
Verifying your entire system takes quite some time, but when you’re done, you’ll have a very thorough understanding of the state of your system.
The --verify command can take awhile to complete. Start the command and let it run while you’re in a meeting or when you go home at night.
What’s this MD5 stuff anyway?
MD5 is a message-digest algorithm (in fact, MD5 is a rather uninspired acronym for message digest number 5). A message digest is like a fingerprint that belongs to a chunk of data. Two different chunks of data are highly unlikely to have the same fingerprint (that is, the same MD5 checksum). MD5 is cryptographically strong, meaning that it would take an incredibly fast computer (or an astonishingly brilliant mathematician) to come up with another chunk of data with the same fingerprint.
A digest algorithm generates two different digest values for two different files. A good digest program pays attention not only to the characters in the file, but also to the ordering of the characters in the file (so ab generates a different checksum than ba).
When an RPM package is first created, RPM computes the MD5 checksum of each file in the package. When you install the package, the MD5 checksums are copied into the RPM database. When you verify a package, RPM recomputes the checksum of each file in the package (it reads through the whole file and computes the checksum again from scratch) and compares that checksum to the value stored in the database. If the checksums are different, the file has been modified.
Reading the Tamper-Proof Seal
When you get a new RPM package, whether from a Web site or on a disc, you really have no guarantee that it hasn’t been tampered with — that is, unless you use RPM to verify its digital signature.
Just like the tamper-proof seal on a bottle of aspirin, the digital signature is there to protect you from potential headaches. After all, you would never use medicine from a bottle with a broken seal. A digital signature ensures that a package was created by the person (or organization) claiming to have produced the package.
118 Technique 18: Getting Comfortable with RPM
When you install Linux from a CD or DVD, the disc should include a public key from the packager. Every package included in your Linux distribution is (or at least can be) signed with the packager’s private key. You can use RPM (and the public key) to verify each package. When you download a package, look through the project’s Web site to see if it makes a public key available. If you find one, use it. (If you can’t find a public key, e-mail the maintainers asking them to sign their packages.)
In this section, we use the Fedora install DVD as an example of how to import a public key and then use that key to check the signature of a package — we assume most of you have installation media. Not all vendors include keys on their software, but it’s a really good idea to run an integrity check if they do.
To verify the integrity of your Fedora disc, follow these steps:
1. Open a terminal window and give yourself superuser privileges.
2. Insert and mount either the DVD or the first CD of the Fedora distribution, and move to the cdrom directory.
$cd /mnt/cdrom
3.Type the following command and press Enter:
$rpm --import RPM-GPG-KEY
The --import command installs the public key (RPM-GPG-KEY) into your RPM database. After it’s there, RPM will use the public key to verify any package you install that’s been signed with the corresponding private key. See Technique 28 for more information ahout how digital signatures, public keys, and private keys all fit together.
Depending on your distribution, one key or many keys may exist. If multiple keys exist, install them all before checking the package’s signature. The easy way to do this is to use rpm --import RPM-GPG*.
4. Move to the directory of the package you want to verify and press Enter. For our example, enter
$cd /mnt/cdrom/Fedora/RPMS
5.Enter the following command:
$rpm --checksig bash
6.Press Tab to autocomplete the package name and then press Enter.
rpm displays a message that looks something like this:
bash-2.05b-31.i386.rpm: (sha1) dsa sha1 md5 gpg OK
From this message, you know that your bash package is OK. If the result set returns a NOT OK or MISSING KEYS, you should at least question the integrity of the package. Some system administrators won’t install software that doesn’t come with proper digital signatures to avoid any potential problems.
Some open-source software that has integrity doesn’t have keys. We wish it did because the software is good, reputable, and worthy of downloading.
In our example, the key was distributed on the disc with the software. Often, the keys are available at the project’s Web site, as a separate download. If you have trouble finding the key, consider e-mailing the site administrator.