|< Day Day Up >|| |
One of the major duties of a system administrator is software management. Applications are upgraded. Kernels are patched. Without the right tools, it can be difficult to figure out what software is on a system, what is the latest update, and what applications depend on other software. Worse, you may install a new software package only to find it has overwritten a crucial file from a currently installed package.
The Red Hat Package Manager (RPM) was designed to eliminate these problems. With RPM, software is managed in discrete 'packages.' An RPM package includes the software with instructions for adding, removing, and upgrading those files. When properly used, the RPM system can back up key configuration files before proceeding with upgrades and removals. It can also help you identify the currently installed version of any RPM-based application.
In the generic sense, an RPM package is a container of files. It includes the group of files associated with a specific program or application, which normally includes binary installation scripts, as well as configuration and documentation files. It also includes instructions on how and where these files should be installed and uninstalled.
An RPM package name usually includes the version, the release, and the architecture for which it was built. For example, the fictional penguin-3.4.5-26.i386.rpm package is version 3.4.5, build 26. The 'i386' indicates that it is suitable for computers built to the Intel architecture.
|On The Job|| |
Many RPM packages are CPU specific. You can identify the CPU type for your computer in the /proc/cpuinfo file. Some RPM packages, with the noarch label, can be installed on computers with all types of CPUs.
At the heart of this system 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 see if 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. You've already installed package X. If you then try to install package Y, RPM backs up the original /etc/someconfig file before installing package Y.
With the RPM system, you can even specify package locations just like an Internet address, in Uniform Resource Locator (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 -i 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 server 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. Based on the preceding example, if the username is mjang and the password is Ila451MS, you could install an RPM directly from a server with the following command:
rpm -i ftp://mjang:Ila451MS@ftp.rpmdownloads.com/pub/foo.rpm
The key to this system is the rpm command. We'll cover the four most common modes associated with this command: query, install, upgrade, and remove. But first, in this age of insecure downloads, you should know how to validate the signature associated with an RPM, as well as verifying the files in a specific package.
RPM uses two methods of 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 GPG public key for its RPM files; you can find it on each installation CD in the RPM-GPG-KEY file or in the /usr/share/rhn directory.
To authenticate your RPMs using the GPG system, import the key file using the following command (assuming it's a CD-based keyfile, mounted on the /mnt/cdrom directory):
# rpm --import /usr/share/rhn/RPM_GPG_KEY
Now if you wanted to check the integrity of some RPM such as pkg-1.2.3-4.noarch.rpm on a CD, run the following command:
# rpm --checksig /mnt/cdrom/RedHat/RPMS/pkg-1.2.3-4.noarch.rpm
This allows you to verify both the integrity and the authenticity of the RPM.
Verifying an installed package compares information about that package with information from the RPM database on your system. The --verify 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.
# rpm --verify -a
Verify all files within a package against an RPM file on a mounted CD-ROM.
# rpm --verify -p /mnt/cdrom/RedHat/RPMS/inn-2.3.5-5.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 are eight tests. If there's a change, the output is a string of 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 4-10 lists the failure codes and their meanings.
File modification time
Sometimes you need a file or a command, and just don't know what is the correct package to install. Red Hat provides a database that can associate the right RPM package with a specific file. Naturally, this database can be installed from the rpmdb-redhat-* RPM. It's installed by default on RHEL 3. It enables you to find the RPM associated with any available file from the Red Hat installation CDs. For example, if you're looking for the package associated with /etc/passwd, run the following command:
# rpm --redhatprovides /etc/passwd
If you're using Red Hat Linux 9 to study for the exam, you'll have to install the rpmdb-redhat RPM after installation.
The rpm command makes it easy to add and remove software packages to your system. It maintains a database regarding the proper way to add, upgrade, and remove packages. This makes it relatively simple to add and remove software with a single command.
The install mode, as its name suggests, is used to install RPM packages on your system. You can install an RPM package with the -i option. For example, the following command installs the hypothetical penguin RPM:
# rpm -i penguin-3.4.5-26.i386.rpm
If the package is available on a remote FTP server, you could install it directly from that server. For example, the following command installs it from a hypothetical ftp.rpmdownloads.com server in its /pub directory.
# rpm -i ftp://ftp.rpmdownloads.com/pub/penguin-3.4.5-26.i386.rpm
Before installing the package, RPM performs several checks. First, it makes sure the package you're trying to install isn't already installed-normally, RPM won't let you install a package on top of itself. It also checks to make sure you aren't installing an older version of the package. Next, RPM does a dependency check. Some programs won't work unless others are already installed. In this example, you've just downloaded the latest RPM version of the Penguin utilities, and you now want to install it.
# rpm -i penguin-3.4.5-26.i386.rpm failed dependencies: iceberg >>= 7.1 is needed by penguin-3.26.i386.rpm
This error tells you that rpm did not install the Penguin package because it requires the iceberg RPM package, version 7.1 or later. You'll have to find and install the iceberg package, and any packages iceberg may require.
Finally, RPM checks to see if it would overwrite any configuration files when it installs a package. RPM tries to make intelligent decisions about what to do in this situation. If RPM chooses to replace an existing configuration file, it gives you a warning like:
# rpm -i penguin-3.26.i386.rpm warning: /etc/someconfig saved as /etc/someconfig.rpmsave
It's up to you to look at both files and determine what, if any, modifications need to be made.
|On The Job|| |
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 in every way that package may be used in a production environment.
The -U switch is used to upgrade existing packages. For example, if Penguin utilities, version 3.25, is already installed, the following command:
# rpm -U penguin-3.26.i386.rpm
upgrades the old version of the package with the new one. In fact, if you've never installed this package before, the -U switch works just like -i. The package is simply installed for the first time.
The rpm -e command removes a package from your system. But before removing a package, RPM checks a few things first. 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 any of the configuration files, RPM makes a copy of the file, adds an .rpmsave extension to the end of the filename, 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.
|On The Job|| |
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 packages for /etc/passwd or the kernel, that would devastate your system.
Red Hat Enterprise Linux is constantly being updated. As bugs or security problems are found, they are collected on Red Hat's errata Web page, currently located at www.redhat.com/apps/support/errata/. Additional errata associated with Red Hat Enterprise Linux is available through the Red Hat Network. If you've purchased RHEL 3, it's part of your subscription.
|On The Job|| |
As of this writing, Red Hat has stated that it will discontinue errata for Red Hat Linux 9 in April of 2004. The people associated with the Fedora Legacy Project plan to continue support beyond that date. More information is available at www.fedoralegacy.org.
Exercise 4-4: Updating from the Red Hat Errata
The steps in this exercise assume that you're using Red Hat Enterprise Linux 3. If you are using Red Hat Linux 9 or earlier, you may not be able to do this exercise. Red Hat has stated that it will discontinue support for Red Hat Linux 9 after April 2004. However, you may be able to find errata through the Fedora project. If you find errata, here's a good checklist to follow whenever you review the errata page. The actual steps may vary widely for errata from the Fedora project:
Go to www.redhat.com/apps/support/errata. Find the Red Hat Errata link for your distribution.
The page you see includes links for security, bug fixes, and enhancements. The security alerts are especially important if your system is on a network. Click the security link. You may need to click the link associated with the alert. If you have a subscription to the Red Hat Network for RHEL 3, use your account. You may find additional errata here as well.
You may not have installed some of the affected packages. Use the rpm -qi packagename command to check. If you have installed an affected package on your system, consider the recommended upgrade.
Before replacing an affected package, consider the ramifications. You may need to bring the system down to single-user or perform a reboot, which can affect other users who are connected to your system. If a production computer is affected, you may want to test the changes on another computer first.
If you choose to make an upgrade, back up at least the relevant files on your current system. Upgrades do fail on occasion.
When performing the upgrade, watch for configuration file warnings. If your local configuration files are replaced with new files, you may need to change the new configuration files to reflect your current settings.
Thoroughly test the new package. Make sure you have it configured correctly.
If a package is listed in the errata but not installed on your system, chances are there's no reason to put it on your system now. Read the detailed errata entry for that package carefully, and only install it if needed.
Red Hat has included a Network Alert Notification Tool. You can use this to check for revised packages, new packages, errata, and other information. It comes as an entitlement with your purchase of Red Hat Enterprise Linux. There is no reference to this software in the syllabus for the RHCT (RH133) or RHCE (RH300) exams, or in the RHCE Exam Prep guide.
Without RPM, you'd need to search around your filesystems to figure out whether a particular software package is installed. RPM makes it easy for you to figure out what RPM packages are installed and get information about those packages.
The -q switch is used to query packages. When you use RPM's query mode, you can learn if a specific package is installed or identify the files associated with that package. The rpm -q packagename command will return the installed version of a specified package. For example, to find the version number of an installed mutt text e-mail reader, run the following command:
# rpm -q mutt lynx-1.4.1-3
If you want to see which installed package owns a file, use the -f modifier. Here we want to identify the package that owns /etc/passwd:
# rpm -qf /etc/passwd setup-2.5.27-1
Likewise, if you want to generate a list of files belonging to a certain package, use the -l modifier.
# rpm -ql setup /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/exports /etc/filesystems /etc/group /etc/gshadow /etc/host.conf /etc/hosts.allow /etc/hosts.deny /etc/inputrc /etc/motd /etc/passwd /etc/printcap /etc/profile /etc/profile.d /etc/protocols /etc/securetty /etc/services /etc/shells /usr/share/doc/setup-2.5.27 /usr/share/doc/setup-2.5.27/uidgid /var/log/lastlog
One of the most common modifiers to -q is -a, a query for all installed packages on your system. As configured, my RHEL 3 system includes 700 packages. Here's a truncated output:
# rpm -qa ghostscript-fonts-5.50-9 libmng-1.0.4-3 libtiff-3.5.7-13 ncurses-5.3-9.3 arts-1.1.3-2.2 ... commons-modeler-1.0-5 sendmail-cf-8.12.10-1
|On The Job|| |
It's common to use the rpm -qa command as a searchable database. All you need to do is pipe the output with a search term through grep. For example, the rpm -qa | grep kde command makes it easy to identify all installed packages related to the K Desktop Environment.
For even more information about a specific package, use the -i (information) modifier. Table 4-11 lists some of the most important entries from the package output. Run the rpm -qi packagename command on the RPM of your choice and see the result for yourself.
The name of the package.
The version of the package.
The number of times this package has been released using the same version of the software.
When this package was installed on your system.
Your RPM database is divided into groups, which describe the functionality of the software. Every time you install a package, it will be grouped accordingly.
The total size in bytes of all the files in the package.
The license under which the original software was released.
You can update packages with a graphical tool. The Red Hat Package Management utility includes several advantages. It includes an interface similar to the Anaconda Custom Installation screen. It allows you to install more than one package at a time. It automatically installs any other dependent packages that may be needed.
There are two ways to start the Package Management utility. In the GNOME or KDE desktop, click Main Menu | System Settings | Add/Remove Applications. Alternatively, in a GUI text command window, run the redhat-config-packages command. Either action opens the Package Management utility shown in Figure 4-6.
Figure 4-6: The Package Management utility
You can use it to add the package groups of your choice. The list shown is the same as what you saw during the installation process. Once you've selected a package group, you're allowed to customize the installation by clicking the associated Details link.
There's an important trick with the Package Management utility. With the right switch, you can connect it to a remote installation server, such as the one you created in Chapter 2. For example, if you've mounted the NFS installation source from Chapter 2 to the local /mnt/inst directory, you can link the Package Management utility to that source with the following command:
# redhat-config-packages --tree=/mnt/inst
For more information on mounting remote directories via Samba, see Chapter 8; to do the same via NFS, see Chapter 9.
|Exam Watch|| |
If you need to install a group of packages during the Red Hat exams, you may not have access to all of the installation CDs. In that case, the redhat-config-packages command can help. With the --tree switch, you can use the same network source that you used to install Red Hat Enterprise Linux.
|< Day Day Up >|| |