Chapter 5: Package Management | Linux Patch Management: Keeping Linux Systems Up To Date

After installation is complete, you still have administrative work to do. To customize the system to meet your needs, you may need to add or remove packages and more. To make sure you get the right updates, you need to know how to get your system working with the Red Hat Network (or the repository associated with your distribution). If you're satisfied with your configuration, you may want to use kickstart to automate future installations.

Certification Objective 5.01-The Red Hat Package Manager

One of the major duties of a system administrator is software management. New applications are installed. Services are updated. 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.

Inside the Exam

Administrative Skills

The management of RPM packages is a fundamental skill for Red Hat administrators, so it's reasonable to expect to use the rpm and related commands on both parts of the RHCT or RHCE exam. While the requirements are listed in the Installation and Configuration part of each exam, these skills may also help you during the Troubleshooting and System Maintenance part of each exam. The Red Hat Exam Prep guide includes two specific references to the rpm command:

Install and update packages using rpm.
Properly update the kernel package.

And there's a related reference, as update tools such as yum and Pup are essentially front-ends to the rpm command:

Configure the system to update/install packages from remote repositories using yum or Pup.

But whenever you install a new package, you need to know how to use the rpm command. You need to know how to use it to find the files you need. You need to know how the yum command helps manage dependencies, including any additional packages that might be required.

Finally, this chapter will also help you meet the Exam Prep guide requirement associated with Kickstart, which suggests that RHCEs must also be able to

Configure hands-free installation using Kickstart.

The Red Hat Package Manager (RPM) was designed to alleviate 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.

RPMs and the rpm command are far from perfect, which is why it has been supplemented with the yum command. With a connection to a repository such as that available from the Red Hat Network or third-party "rebuilds" such as CentOS, you'll be able to use yum to satisfy dependencies.

What Is a Package?

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, and the i386 indicates that it is suitable for computers built to the Intel 32-bit 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.

What Is an RPM?

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 determine whether 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.conf. You've already installed package X. If you then try to install package Y, RPM packages are designed to back up the original /etc/someconfig.conf file (with a file name like /etc/someconfig.conf.rpmsave) before installing package Y.

On the Job

While RPM upgrades are supposed to preserve or save existing configuration files, there are no guarantees. It's best to back up all applicable configuration files before upgrading any associated RPM package.

Installing RPMs

There are three basic commands that may install an RPM. They won't work if there are dependencies (packages that need to be installed first). For example, if you haven't installed Samba and try to install the system-config-samba package, you'll get the following message (your version numbers may be different):

 # rpm -i system-config-samba-* error: Failed dependencies:         samba is needed by system-config-samba-1.2.39-1.1.noarch

When dependency messages are shown, rpm does not install the given package.

On the Job

Sure, you can use the --force option to make rpm ignore dependencies, but that can lead to other problems, unless you install those dependencies as soon as possible. The best option is to use an appropriate yum command, described later in this chapter. In this case, a yum install system-config-samba command would automatically install the Samba RPM as well.

If you're not stopped by dependencies, there are three basic commands that can install RPM packages:

 # rpm -i packagename # rpm -U packagename # rpm -F packagename

The rpm -i option installs the package, if it isn't already installed. The rpm -U option upgrades any existing package or installs it if an earlier version isn't already installed. The rpm -F option upgrades only existing packages. It does not install a package if it wasn't previously installed.

I like to add the -vh options whenever I use the rpm command. These options add verbose mode and use hash marks to help you monitor the progress of the installation. So when I use rpm to install a package, I run

 # rpm -ivh packagename

There's one more thing the rpm command does before installing a package: it checks to see whether it would overwrite any configuration files. The rpm command tries to make intelligent decisions about what to do in this situation. As suggested earlier, if the rpm command chooses to replace an existing configuration file, it gives you a warning (in most cases) like:

 # rpm -i penguin-3.26.i386.rpm warning: /etc/someconfig.conf saved as /etc/someconfig.conf.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 for every situation in which the package may be used in a production environment.

Removing RPMs

The rpm -e command removes a package from your system. But before removing a package, RPM checks a few things. 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 most any of the configuration files, RPM makes a copy of the file, adds an .rpmsave extension to the end of the file name, 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 that include /etc/passwd or the kernel, it would devastate your system.

Installing RPMs from Remote Systems

With the RPM system, you can even specify package locations similar to an Internet address, in 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 -ivh 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. Naturally, transmitting passwords in clear text over a network is discouraged, so anonymous FTP servers may be preferred.

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 -ivh ftp://mjang:Ila451MS@ftp.rpmdownloads.com/pub/foo.rpm

The key to this system is the rpm command. Even over a network, it works with globbing; in other words, if you don't know the version number, you can replace it with a *:

 rpm -ivh ftp://mjang:Ila451MS@ftp.rpmdownloads.com/pub/foo-*

Later, in this age of insecure downloads, you'll see how to validate the signature associated with an RPM and verify the files in a specific package.

Updating a Kernel RPM

Kernel updates incorporate new features, address security issues, and generally help your Linux system work better. However, kernel updates can also be a pain in the rear end, especially if you have specialized packages that depend on an existing version of a kernel.

In other words, don't upgrade a kernel if you're not ready to repeat everything you've done with the existing kernel, whether it's specialized drivers, recompiling to incorporate additional filesystems, or more.

If you're told to update a kernel RPM, the temptation is to run the rpm -U newkernel command. Don't do it! It overwrites your existing kernel, and if the new kernel doesn't work with your system, you're out of luck. (Well, not completely out of luck, but if you reboot and have problems, you'll have to use linux rescue mode to boot your system and reinstall the existing kernel, which might make for an interesting test scenario.)

The best option for upgrading to a new kernel is to install it, specifically with a command such as:

 # rpm -ivh newkernel

If you're connected to an appropriate repository, the following command works just as well:

 # yum install kernel

This installs the new kernel, side by side with the current working kernel. It adds options to boot the new kernel in the boot loader menu (through the GRUB configuration file), without erasing existing options. If you use the yum command (described later in this chapter), make sure you use yum install kernel to ensure the kernel is installed and the previous kernel (and associated configuration options) is not overwritten.