Chapter 10
Getting and Managing Software
In Linux distributions such as Fedora and Ubuntu, you don't need to know much about how software is packaged and managed to get the software you want. Those distributions have excellent software installation tools that automatically point to huge software repositories. Just a few clicks and you're using the software in little more time than it takes to download it.
The fact that Linux software management is so easy these days is a credit to the Linux community, which has worked diligently to create packaging formats, complex installation tools, and high-quality software packages. Not only is it easy to get the software, but once it's installed, it's easy to manage, query, update, and remove it.
This chapter begins by describing how to install software packages in Fedora using the PackageKit graphical installation tool. If you are just installing a few software packages on your own desktop system, you may not need much more than that and occasional security updates.
To dig deeper into managing Linux software, I next describe what makes up Linux software packages (comparing deb and rpm formatted packaging), underlying software management components, and commands (yum and rpm) for managing software in Fedora and Red Hat Enterprise Linux. That's followed by a description of how to manage software packages in enterprise computing.
Managing Software with PackageKit
PackageKit is a set of programs that provide graphical windows, and other components, for installing, removing, and otherwise managing software in Fedora and Red Hat Enterprise Linux. Ubuntu uses components of PackageKit, but not the entire interface. To use PackageKit from a GNOME 3 desktop in Fedora, click the Add/Remove Software icon (look on the Applications menu).
Figure 10.1 shows an example of the PackageKit Add/Remove Software window being used to search for a package.
Figure 10.1 Install and manage software packages from PackageKit.
Enabling repositories and getting updates
Once you have installed Fedora, PackageKit is configured to handle software updates and connect to the Fedora software repositories as needed. To see information about how PackageKit is configured, from the PackageKit window, select System ⇒ Software Sources. You will see:
- Update Settings — From settings on this tab, you see that your system checks daily for software package updates and automatically installs only security updates.
- Software Sources — Entries on this tab show software repositories that are configured on your system. The ones with check marks next to them are enabled. By default, the Fedora main repository and Fedora updates repository are enabled.
If you have just installed Fedora, it's a good idea to immediately check for updates (especially if the Fedora release you have installed has been out for a while). All you need is an Internet connection to check for updates (no configuration or passwords are required).
To check for updated software packages, click the Check Now button at the bottom of the Software Sources tab. Figure 10.2 shows an example of the Software Updates window after a fresh Fedora Live CD install, with hundreds of packages available for update.
Figure 10.2 Keep software current from the Software Update window.
In this example, there are 428 packages (187.5 MB) ready to be updated. So the process can take a while. You can clear the boxes next to any packages you don't want to update. When you are satisfied with the list, click Install Updates.
The repositories listed come from entries in files from the /etc/yum.repos.d directory. The default entries make thousands of packages from the main Fedora repositories available to you. However, you can also add third-party repositories to get special software or non-free software that doesn't come with Fedora. The “Using third-party software repositories” section, later in this chapter, describes how to do this.
Searching for packages
To find packages from the Add/Remove Software window, you can use the search box (to find by a word in the package name or description), select the package from the software groups listed on the left, or sort packages from newest to oldest. Click the package name to see a description. The icons next to each package tell you the status of each package:
- Closed box — The package is available, but not yet installed.
- Open box — The package is installed.
- Open box with plus — The package is set to be installed. You must click Apply to install it.
To refine your package search, you can click the Filters button at the top of the window. Instead of displaying all packages from a category or search, I can select Installed ⇒ Only Available to see only packages that are not already installed. Or select Graphical ⇒ Only Graphical to display only graphical applications.
If you have enabled non-free repositories (packages that are either open source or may be patent-encumbered), you can see or exclude those packages under the Filters menu as well. Only the newest packages and those that match your computer's architecture are displayed, but you can change that as well.
Installing and removing packages
Just to see how it works, try installing a game or other software package that interests you. Here's how:
Going beyond PackageKit
If you are managing a single desktop system, you might be quite satisfied with the thousands of packages available with Fedora. Unless otherwise noted, all software packages used in this book are available from the massive Fedora repository (desktop, system administration, server, software development, and other types of packages).
However, here are some examples of why you might want to go beyond what you can do with the Add/Remove Software window:
- More repositories — Fedora and Red Hat Enterprise Linux distribute only open source, freely distributable software. You may want to install some commercial software (such as Adobe Flash player) or non-free software (available from repositories such as rpmfusion.org).
- More complex queries — Using commands such as yum and rpm, you can get detailed information about packages, package groups, and repositories.
- Software validation — Using rpm and other tools, you can check whether a signed package has been modified before you installed it or whether any of the components of a package have been tampered with since the package was installed.
- Managing software installation — Although PackageKit works well if you are installing software on a single system, it doesn't scale well for managing software on multiple systems. Other tools are built on top of the rpm facility for doing that.
Before I launch into some of the command-line tools for installing and managing software in Linux, the next section describes how the underlying packaging and package management systems in Linux work. In particular, I focus on RPM packaging as it is used in Fedora, Red Hat Enterprise Linux, and related distributions.
Understanding Linux RPM Software Packaging
On the first Linux systems, if you wanted to add additional software you would grab the source code from a project that produced it, compile it into runnable binaries, and drop it onto your computer. If you were lucky, someone would have already compiled it in a form that would run on your computer.
The form of the package could be a tarball, containing executable files (commands), documentation, configuration files, and libraries. (A tarball is a single file in which multiple files are gathered together for convenient storage or distribution.) When you install software from a tarball, the files from that tarball might be spread across your Linux system in appropriate directories (/usr/share/man, /etc, /bin, and /lib, to name a few).
While it is easy to create a tarball and just drop a set of software onto your Linux system, this method of installing software makes it difficult to:
- Get dependent software — You would need to know if the software you were installing depended on other software being installed for your software to work. Then you would have to track down that software and install that too (which might itself have some dependencies).
- List the software — Even if you knew the name of the command, you might not know where its documentation or configuration files were located when you looked for it later.
- Remove the software — Unless you kept the original tarball or a list of files, you wouldn't know where all the files were when it came time to remove them. Even if you knew, you would have to remove each one individually.
- Update the software — Tarballs are not designed to hold metadata about the contents they contain. Once the contents of a tarball are installed, you may not have a way to tell what version of the software you are using, making it difficult to track down bugs and get new versions of your software.
To deal with these problems, packages progressed from simple tarballs to more complex packaging. With only a few notable exceptions (such as Gentoo, Slackware, and a few others), most Linux distributions went to one of two different packaging formats — DEB and RPM:
- DEB (.deb) packaging — The Debian GNU/Linux project created .deb packaging, which is used by Debian and other distributions based on Debian (Ubuntu, Linux Mint, KNOPPIX, and so on). Using tools such as apt-get and dpkg, Linux distributions could install, manage, upgrade, and remove software.
- RPM (.rpm) packaging — Originally named Red Hat Package Manager but later recursively renamed RPM Package Manager, RPM is the preferred package format for SUSE, Red Hat distributions (RHEL and Fedora), and those based on Red Hat distributions (CentOS, Oracle Linux, and so on). The rpm command was the first tool to manage RPMs, but later yum was added to enhance the RPM facility.
For managing software on individual systems, there are proponents on both sides of the RPM vs. DEB debate with valid points. However, RPM is the preferred format for managing enterprise-quality software installation, updates, and maintenance. This chapter focuses on RPM (Fedora and Red Hat Enterprise Linux) packaging and software management.
Understanding RPM packaging
An RPM package is a consolidation of files needed to provide a feature, such as a word processor, a photo viewer, or a file server. Inside an RPM can be the commands, configuration files, and documentation that make up the software feature. However, an RPM file also contains metadata that stores information about the contents of that package, where the package came from, what it needs to run, and other information.
What is in an RPM?
Before you even look inside an RPM, you can tell a lot about it by the name of the RPM package itself. To find out the name of an RPM package currently installed on your system (such as the Firefox web browser), you could type the following from the shell in Fedora or Red Hat Enterprise Linux:
# rpm -q firefox firefox-10.0.3-1.el6_2.x86_64
From this, you can tell that the basename of the package is firefox. The release number is 10.0.3 (assigned by the upstream producer of Firefox, the Mozilla Project). The version number (assigned by the packager, Red Hat, each time the package is rebuilt at the same release number) is 1. The firefox package was built for Red Hat Enterprise Linux 6.2 (el6_2) and is compiled for the X86 64-bit architecture (x86_64).
When the firefox package was installed, it was probably copied from the installation medium (such as a CD or DVD) or downloaded from a YUM repository (more on that later). If you had been given the RPM file and it was sitting in a local directory, the name would appear as firefox-10.0.3-1.el6_2.x86_64.rpm and you could install it from there. Regardless of where it came from, once installed, the name and other information about the package are stored in an RPM database on the local machine.
To find out more about what is inside an RPM package, you can use options other than the rpm command to query that local RPM database. For example:
# rpm -qi firefox Name: firefox Relocations: (not relocatable) Version: 10.0.3 Vendor: Red Hat, Inc. Release: 1.el6_2 Build Date: Tue 06 Mar 2012 04:41:17 AM EST Install Date: Thu 22 Mar 2012 01:54:02 PM EDT Build Host: x86-003.build.bos.redhat.com Group: Applications/Internet Src RPM: firefox-10.0.3-1.el6_2.src.rpm Size: 24510223 License: MPLv1.1 or GPLv2+ or LGPLv2+ Signature: RSA/8, Tue 13 Mar 2012 08:14:35 AM, Key ID 199e2f91fd431d51 Packager: Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL: http://www.mozilla.org/projects/firefox/ Summary: Mozilla Firefox Web browser Description: Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability.
Besides the information you got from the package name itself, the -qi (query information) option lets you see who built the package (Red Hat, Inc.), when it was built, and when it was installed. The group the package is in (Applications/Internet), its size, and the licensing are listed. To find out more about the package, the URL points to the project page on the Internet and the Summary and Description tell you what the package is used for.
Where do RPMs come from?
The software included with Linux distributions, or built to work with those distributions, comes from thousands of open source projects all over the world. These projects, referred to as upstream software providers, usually make the software available to anyone who wants it, under certain licensing conditions.
A Linux distribution takes the source code and builds it into binaries. Then it gathers those binaries together with documentation, configuration files, and other components available from the upstream provider.
After gathering all those components into the RPM, the RPM package is signed (so users can test the package for validity) and placed in a repository of RPMs for the specific distribution and architecture (32-bit x86, 64-bit x86, and so on). The repository is placed on an installation CD or DVD or in a directory that is made available as an FTP, web, or NFS server.
Installing RPMs
When you initially install a Fedora or Red Hat Enterprise Linux system, many individual RPM packages make up that installation. After Linux is installed, you can add more packages using the PackageKit GUI (as described earlier). Refer to Chapter 9 for information on installing Linux.
The first tool to be developed for installing RPM packages, however, was the rpm command. Using rpm, you can install, update, query, validate, and remove RPM packages. The command, however, has a few major drawbacks:
- Dependencies — Most RPM packages are dependent on some other software (library, executables, and so on) being installed on the system for that package to work. When you try to install a package with rpm, if a dependent package is not installed, the package installation will fail, telling you which components were needed. At that point you would have to dig around to find what package contained that component. When you did, and went to install it, that dependent package might itself have dependencies you would need to install to get it to work. This situation was lovingly referred to as “dependency hell” and was often used as an example of why DEB packages were better than RPMs. DEB packaging tools were made to automatically resolve package dependencies well before RPM-related packaging tools could do that.
- Location of RPMs — The rpm command expects you to provide the exact location of the RPM file when you try to install it. In other words, you would have to give firefox-10.0.3-1.el6_2.x86_64.rpm as an option if the RPM were in the current directory or http://example.com/firefox-10.0.3-1.el6_2.x86_64.rpm if it were on a server.
As Red Hat Linux and other RPM-based applications grew in popularity, it became apparent that something had to be done to make package installation more convenient. The answer was the YUM facility.
Managing RPM Packages with YUM
The YellowDog Updater Modified (YUM) project set out to solve the headache of managing dependencies with RPM packages. Its major contribution was to stop thinking about RPM packages as individual components and think of them as parts of larger software repositories.
With repositories, the problem of dealing with dependencies fell not to the person who installed the software, but to the Linux distribution or third-party software distributor that makes the software available. So, for example, it would be up to the Fedora project to make sure that every component needed by every package in its Linux distribution could be resolved by some other package in the repository.
Repositories could also build on each other. So, for example, the rpmfusion.org repository could assume that a user already had access to the main Fedora repository. So if a package being installed from rpmfusion.org needed a library or command from the main Fedora repository, the Fedora package could be downloaded and installed at the same time you install the rpmfusion.org package.
The yum repositories could be put in a directory on a web server (http://), FTP server (ftp://), or local medium such as a CD, DVD, or local directory (file://). The locations of these repositories would then be stored on the user's system in the /etc/yum.conf file or, more typically, in separate configuration files in the /etc/yum.repos.d directory.
Understanding how yum works
The basic syntax of the yum command is:
# yum [options] command
Using that syntax, you can find packages, see package information, find out about package groups, update packages, or delete packages, to name a few features. With the YUM repository and configuration in place, a user can install a package by simply typing something like this:
# yum install firefox
The user only needs to know the package name (which could be queried in different ways, as described in the “Searching for packages” section later in this chapter). The YUM facility finds the latest version of that package available from the repository, downloads it to the local system, and installs it. Figure 10.3 shows what happens when someone installs a package using the yum command.
The result of a yum install package command is that the package requested is copied from the yum repository to the local system. The files in the package are put in the filesystem where needed (/etc, /bin, /usr/share/man, and so on). Information about the package is stored in the local RPM database, where it can be queried.
Figure 10.3 Local and remote activities when installing an RPM with YUM
To gain more experience with the YUM facility, and see where there are opportunities for you to customize how YUM works on your system, follow the descriptions of each phase of the yum install process illustrated in Figure 10.3 and defined here.
Checking /etc/yum.conf
When any yum command starts, it checks the file /etc/yum.conf for default settings. The /etc/yum.conf file is the basic YUM configuration file. You can also identify the location of repositories here, although the /etc/yum.repos.d directory is the more typical location for identifying repositories. Here's an example of /etc/yum.conf on an RHEL 6.2 system:
[main] cachedir=/var/cache/yum/$basearch/$releasever keepcache=0 debuglevel=2 logfile=/var/log/yum.log exactarch=1 plugins=1 gpgcheck=1
Settings in yum.conf tell YUM where to keep cache files (/var/cache/yum) and log entries (/var/log/yum.log), and whether or not to keep cache files around after a package is installed (0 means no). You can raise the debuglevel value in the yum.conf file to above 2 if you want to see more details in your log files.
Next, you can see if the exact architecture (x86, x86_64, and so on) should be matched when choosing packages to install (1 means yes) and whether or not to use plugins (1 means yes) to allow for things such as blacklists, white lists, or connecting to Red Hat Network for packages.
Finally, gpgcheck says whether or not to validate each package against a key you receive from those who built the RPM. For packages that come with Fedora or RHEL, the key is included with the distribution to check all packages. However, if you try to install packages that are not from your distribution, you need to either import the key needed to sign those packages or turn off that feature (gpgcheck=0).
To find other features you can set in the yum.conf file, type man yum.conf.
Checking /etc/sysconfig/rhn/up2date (RHEL only)
For Red Hat Enterprise Linux systems, instead of pointing to a single public software repository (as Fedora does), you register your system with Red Hat Network and purchase entitlements to download software from different channels.
When your system is registered with Red Hat Network, information is added to the /etc/sysconfig/rhn/up2date file to tell yum where to find Red Hat Enterprise Linux packages (either from a hosted Red Hat Network or from an RHN Satellite server).
Checking /etc/yum.repos.d/*.repo files
Software repositories can be enabled by dropping files ending in .repo into the /etc/yum.repos.d/ directory that point to the location of one or more repositories. In Fedora, even your basic Fedora repositories are enabled from .repo files in this directory.
The following is an example of a simple yum configuration file named /etc/yum.repos.d/myrepo.repo:
[myrepo] name=My repository of software packages baseurl=http://myrepo.example.com/pub/myrepo enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/MYOWNKEY
Each repository entry begins with the name of the repository enclosed in square brackets. The name line contains a human-readable description of the repository. The baseurl line identifies the directory containing the RPM files, which can be an httpd://, ftp://, or file:// entry.
The enabled line indicates whether or not the entry is active. A 1 is active; 0 is inactive. If there is no enabled line, the entry is active. The last two lines in the preceding code indicate whether or not to check the signatures on packages in this repository. The gpgkey line shows the location of the key that is used to check the packages in this repository.
You can have as many repositories enabled as you like. However, keep in mind that when you use yum commands, every repository is checked and metadata about all packages is downloaded to the local system running the yum command. So to be more efficient, don't enable repositories you don't need.
Downloading RPM packages and metadata from a YUM repository
After yum knows the locations of the repositories, metadata from the repodata directory of each repository is downloaded to the local system. In fact, it is the existence of a repodata directory in a directory of RPMs that indicates that it is a yum repository.
Metadata information is stored on the local system in the /var/cache/yum directory. Any further queries about packages, package groups, or other information from the repository are gathered from the cached metadata until a timeout period is reached.
After the timeout period is reached, yum retrieves fresh metadata if the yum command is run. By default, the timeout is 90 minutes. You can change that period by setting metadata_expire in the /etc/yum.conf file. Uncomment that line and change the number of minutes.
Next, yum looks at the packages you requested to install and checks if there are any dependent packages needed by those packages. With the package list gathered, yum asks you if it is all right to download all those packages. If you choose yes, the packages are downloaded to the cache directories and installed.
RPM packages installed to Linux file system
Once all the necessary packages are downloaded to the cache directories, yum runs rpm commands to install each package. If a package contains preinstall scripts (which might create a special user account or make directories), those scripts are run. The contents of the packages are copied to the filesystem (commands, config files, docs, and so on). Then, any post install scripts are run. (Post install scripts run additional commands needed to configure the system after each package is installed.)
Store YUM repository metadata to local RPM database
The metadata contained in each RPM package that is installed is ultimately copied into the local RPM database. The RPM database is contained in files that are stored in the /var/lib/rpm directory.
Once information about installed packages is in the local RPM database, there are all sorts of queries you can do of that database. You can see what packages are installed, list components of those packages, and see scripts or change logs associated with each package. You can even validate installed packages against the RPM database to see if anyone has tampered with installed components.
The rpm command (described in the “Installing, Querying, and Verifying Software with the rpm Command” section later in this chapter) is the best tool for querying the RPM database. You can run individual queries with rpm or use it in scripts to produce reports or run common queries over and over again.
Now that you understand the basic functioning of the yum command, your Fedora system should be automatically configured to connect to the main Fedora repository and the Fedora Updates repository. You can go ahead and try some yum command lines to install packages right now. Or you can enable other third-party YUM repositories to draw software from.
Using YUM with third-party software repositories
The Fedora and Red Hat Enterprise Linux software repositories have been screened to contain only software that meets criteria that make it open and redistributable. In some instances, however, you may want to go beyond those repositories. Before you do, you should understand that some third-party repositories
- Have less stringent requirements for redistribution and freedom from patent constraints than the Fedora and RHEL repositories have
- May introduce some software conflicts
- May include software that is not open source and, although it may be free for personal use, may not be redistributable
- May slow down the process of installing all of your packages (because metadata is downloaded for every repository you have enabled)
For those reasons, I recommend that you either don't enable any extra software repositories, or enable only the RPM Fusion repository (http://rpmfusion.org) at first for Fedora and the EPEL repository (http://fedoraproject.org/wiki/EPEL) for Red Hat Enterprise Linux. RPM Fusion represents a fusion of several popular third-party Fedora repositories (Freshrpms, Livna.org, and Dribble). See the repository's FAQ for details (http://rpmfusion.org/FAQ). To enable the free RPM Fusion repository in Fedora, do the following:
# rpm -Uvh http://download1.rpmfusion.org/free/fedora/ rpmfusion-free-release-stable.noarch.rpm
The RPM Fusion non-free repository contains such things as codecs needed to play many popular multimedia formats. To enable the non-free repository in Fedora, type the following (again, type the following two lines on a single line, with no space between the two):
# rpm -Uhv http://download1.rpmfusion.org/nonfree/fedora/ rpmfusion-nonfree-release-stable.noarch.rpm
Most of the other third-party repositories that might interest you contain software that is not open source. For example, if you want to install the Adobe Flash plug-in for Linux, download the YUM repository package from Adobe and you can use the yum command to install the Flash plug-in, and get updates later by running the yum update command, when updates are available.
Managing software with the YUM command
The yum command has dozens of subcommands you can use to work with RPM packages on your system. The following sections provide some examples of useful yum command lines to search for, install, query, and update packages associated with your YUM repositories. There is also a section describing how to remove installed packages with the yum command.
Searching for packages
Using different searching subcommands, you can find packages based on key words, package contents, or other attributes.
Let's say you want to try out a different text editor, but you can't remember the name of the one you wanted. You could start by using the search subcommand to look for the term “editor” in the name or description:
# yum search editor ... eclipse-veditor.noarch : Eclipse-based Verilog/VHDL plugin ed.x86_64 : The GNU line editor emacs.x86_64 : GNU Emacs text editor
The search uncovered a long list of packages containing “editor” in the name or description. The one I was looking for is named emacs. To get information about that package, I can use the info subcommand:
# yum info emacs
Name : emacs
Arch : x86_64
Epoch : 1
Version : 23.1
Release : 21.el6_2.3
Size : 2.2 M
Repo : production-rhel-x86_64-workstation-6
Summary : GNU Emacs text editor
License : GPLv3+
Description : Emacs is a powerful, customizable, self-documenting,
: modeless text editor. Emacs contains special code
: editing features, a scripting language (elisp), and ...
If you know the command, configuration file, or library name you want, but don't know what package it is in, use the provides subcommand to search for the package. Here you can see that the dvdrecord command is part of the wodim package:
# yum provides dvdrecord wodim-1.1.9-11.el6.x86_64 : A command line CD/DVD recording program Repo : production-rhel-x86_64-workstation-6 Matched from: Other : dvdrecord
The list subcommand can be used to list package names in different ways. Use it with a package base name to find the version and repository for a package. You can list just packages that are available or installed, or you can list all packages.
# yum list emacs emacs.i686 1:23.3-9.fc16 updates # yum list available 389-admin.i686 1.1.23-1.fc16 fedora 389-admin-console.noarch 1.1.8-2.fc16 updates 389-admin-console-doc.noarch 1.1.8-2.fc16 updates ... # yum list installed Installed Packages ConsoleKit.i686 0.4.5-1.fc15 @koji-override-0/$releasever ConsoleKit-libs.i686 0.4.5-1.fc15 @koji-override-0/$releasever ConsoleKit-x11.i686 0.4.5-1.fc15 @koji-override-0/$releasever # yum list all ...
If you find a package, but want to see what components that package is dependent on, you can use the deplist subcommand. With deplist, you can see the components (dependency) but also the package that component comes in (provider). Using deplist can help if no package is available to provide a dependency, but you want to know what the component is so you can search other repositories for it. Consider the following example:
# yum deplist emacs | less Finding dependencies: package: emacs.x86_64 1:23.1-21.el6_2.3 dependency: libc.so.6(GLIBC_2.3.4)(64bit) provider: glibc.x86_64 2.12-1.7.el6 dependency: libasound.so.2(ALSA_0.9.0rc4)(64bit)
Installing and removing packages
The install subcommand lets you install one or more packages, along with any dependent packages needed. With yum install, multiple repositories can be searched to fulfill needed dependencies. Consider the following example of yum install:
# yum install emacs ... ====================================================================== Package Arch Version Repository Size ====================================================================== Installing: emacs x86_64 1:23.1-21.el6_2.3 rhel-x86_64-workstation-6 2.2 M Installing for dependencies: emacs-common x86_64 1:23.1-21.el6_2.3 rhel-x86_64-ws-6 18 M Transaction Summary ======================================================================= Install 2 Package(s) Total download size: 20 M Installed size: 0 Is this ok [y/N]: y
You can see here that emacs requires that emacs-common be installed so both are queued up for installation. The two packages together are 20M. Pressing y installs them. You can put a -y on the command line (just after the yum command) to avoid having to press y to install the packages, but, personally, I want to see all the packages about to be installed before I agree to the installation.
You can reinstall a package if you mistakenly delete components of an installed package. If you attempt a regular install, the system will respond with “nothing to do.” You must, instead, use the reinstall subcommand. For example, say you installed the zsh package and then deleted /bin/zsh by mistake. You could restore the missing components by typing the following:
# yum reinstall zsh
You can remove a single package with the erase subcommand. For example, to erase the emacs package, you could type the following:
# yum erase emacs Dependencies Resolved ================================================================= Package Arch Version Repository Size ================================================================= Removing: emacs x86_64 1:23.1-21.el6_2.3 @rhel-x86_64-workstation-6 11 M Transaction Summary ================================================================= Remove 1 Package(s) Installed size: 11 M Is this ok [y/N]: y
Notice that even though two packages were installed when emacs was installed, only the emacs package itself was removed with the erase subcommand. While emacs required that emacs-common be installed, emacs-common did not depend on emacs and could therefore stay on the system without breaking dependencies. Running yum remove emacs-common would have removed both packages.
An alternative method to remove a set of packages you have installed is to use the history subcommand. Using history, you can see your yum activities and undo an entire transaction. In other words, all the packages you installed can be uninstalled using the undo option to the history subcommand. For example:
# yum history ID | Login user | Date and time | Action(s) | Altered --------------------------------------------------------------------- 96 | Chris Negus <cnegus> | 2012-04-10 06:25 | Install | 2 ... # yum history info 96 Transaction ID : 96 ... Command Line : install emacs ... # yum history undo 96 Undoing transaction 96, from Tue Apr 10 06:25:41 2012 Install emacs-1:23.1-21.el6_2.3.x86_64 @rhel-x86_64-workstation-6 Dep-Install emacs-common-1:23.1-21.el6_2.3.x86_64 @rhel-workstation-6 Resolving Dependencies ...
Before you undo the transaction, you can view the transaction to see exactly which packages were involved. Viewing the transaction can save you from mistakenly deleting packages you want to keep. By undoing transaction 96, you can remove both packages that were installed during that transaction. If you are trying to undo an install that included dozens or even hundreds of packages, undo can be a very useful option.
Updating packages
As new releases of a package become available, they are sometimes put in separate update repositories or simply added to the original repository. If multiple versions of a package are available (whether in the same repository or another enabled repository), yum provides the latest version when you install a package. If a new version shows up later, you can download and install the new version of the package by using the update subcommand.
The check-update subcommand can check for updates. The update subcommand can be used to update a single package or to get updates to all packages that are currently installed and have an update available. For example:
# yum check-update ... freetype.x86_64 2.3.11-6.el6_2.9 rhel-x86_server-6 libtiff.x86_64 3.9.4-5.el6_2 rhel-x86_server-6 # yum update ... tzdata noarch 2012b-3.el6 rhel-x86_64-workstation-6 441 k tzdata-java noarch 2012b-3.el6 rhel-x86_64-workstation-6 154 k Transaction Summary ===================================================================== Upgrade 38 Package(s) Total download size: 50 M Is this ok [y/N]: y # yum update cups
The preceding code requested to update the cups package. If other dependent packages need to be updated to update cups, those packages would be downloaded and installed as well.
Updating groups of packages
To make it easier to manage a whole set of packages at once, YUM supports package groups. For example, you could install GNOME Desktop Environment (to get a whole desktop) or Virtualization (to get packages needed to set up the computer as a virtual host). You can start by running the grouplist subcommand to see a list of group names:
# yum grouplist | less Installed Groups: Administration Tools Design Suite Dial-up Networking Support ... Available Groups: Authoring and Publishing Base Books and Guides ...
Let's say you wanted to try out a different desktop environment. You see LXDE and you want to know what is in that group. To find out, use the groupinfo subcommand:
# yum groupinfo LXDE Group: LXDE Description: LXDE is a lightweight X11 desktop environment... Mandatory Packages: lxde-common lxmenu-data ...
In addition to showing a description of the group, groupinfo shows Mandatory Packages (those that are always installed with the group), Default Packages (those that are installed by default, but can be excluded), and Optional Packages (which are part of the group, but not installed by default). When you use graphical tools to install package groups, you can uncheck default packages or check optional packages to change whether or not they are installed with the group.
If you decide you want to install a package group, use the groupinstall subcommand:
# yum groupinstall LXDE
This groupinstall resulted in 23 packages from the group and 9 extra packages being installed. If you decide you don't like the group of packages, you can remove the entire group at once using the groupremove subcommand:
# yum groupremove LXDE
Maintaining your RPM package database and cache
There are several subcommands to yum that can help you do maintenance tasks, such as check for problems with your RPM database or clear out cache. The YUM facility has tools for maintaining your RPM packages and keeping your system's software efficient and secure.
Clearing out the cache is something you want to do from time to time. If you decide to keep downloaded packages after they are installed (they are removed by default, based on the keepcache=0 setting in the /etc/yum.conf file), your cache directories (under /var/cache/yum) can fill up. Metadata stored in cache directories can be cleared, causing fresh metadata to be downloaded from all enabled YUM repositories the next time yum is run. Here are ways to clear that information:
# yum clean packages Cleaning repos: rhel-x86_64-server-6 7 package files removed # yum clean metadata 43 metadata files removed 13 sqlite files removed # yum clean all Cleaning repos: rhel-x86_64-server-6 Cleaning up Everything
Although unlikely, it's possible that the RPM database can become corrupted. This can happen if something unexpected occurs, such as pulling out the power cord when a package is partially installed. You can check the RPM database to look for errors (yum check) or just rebuild the RPM database files, as follows:
# yum check check all # yum clean rpmdb Cleaning repos: rhel-x86_64-server-6 4 rpmdb files removed
Of the yum clean examples in the preceding three command lines, all remove cached data from the /var/cache/yum subdirectories, except for the rpmdb example. That command removed db* files from the /var/lib/rpm directory (regenerating those database files to clean up any problems).
The rpmdb option is one of the few options to yum that is used to work with the RPM database directly. In general, yum is used for manipulating yum repositories. The command best suited for working with the local RPM database is the rpm command.
Downloading RPMs from a yum repository
If you just want to examine a package without actually installing it, you can use the yumdownloader command. Running that command causes the package you name to be downloaded from the YUM repository and copied to your current directory.
For example, to download the latest version of the Firefox web browser package from the YUM repository to your current directory, type the following:
# yumdownloader firefox ... firefox-10.0.5.1.el6.2.x86_64.rpm
With the RPM package now sitting in your current directory, you can use a variety of rpm commands to query or use that package in different ways (as described in the next section).
Installing, Querying, and Verifying Software with the rpm Command
There is a wealth of information about installed packages in the local RPM database. The rpm command contains dozens of options to enable you to find information about each package, such as the files it contains, who created it, when it was installed, how large it is, and many other attributes. Because the database contains fingerprints (md5sums) of every file in every package, it can be queried with RPM to find out if files from any package have been tampered with.
The rpm command can still do basic install and upgrade activities, although most people only use rpm in that way when there is a package sitting in the local directory, ready to be installed. So let's get one in our local directory to work with. Type the following to download the latest version of the zsh package:
# yumdownloader zsh zsh-4.3.17-1.1.31-2.fc16.noarch | 2.3 MB 00:03
With the zsh package downloaded to your current directory, try some rpm commands on it.
Installing and removing packages with rpm
To install a package with the rpm command, type:
# rpm -i zsh-4.3.17-1.1.31-2.fc16.noarch.rpm
Notice that the entire package name is given to install with rpm, not just the package base name. If an earlier version of zsh were installed, you could upgrade the package using -U. Often, people use -h and -v options to get hash signs printed and more verbose output during the upgrade:
# rpm -Uhv zsh-4.3.17-1.1.31-2.fc16.noarch.rpm Preparing... ######################### [100%] 1:zsh ######################### [100%]
While an install (-i) will only install a package if the package is not already installed, an upgrade (-U) will install the package whether it is already installed or not. A third type of install called freshen (-F) installs a package only if there is an existing, earlier version of a package installed on the computer. For example:
# rpm -Fhv *.rpm
You could use the previous freshen command if you were in a directory containing thousands of RPMs but only wanted to update those that were already installed (in an earlier version) on your system and skip those that were not yet installed.
There are a few interesting options you can add to any of your install options. The --replacepkgs option enables you to reinstall an existing version of a package (if, for example, you had mistakenly deleted some components) and the --oldpackage enables you to install an earlier version of a package.
# rpm -Uhv --replacepkgs emacs-common-23.3-9.fc16i686.rpm # rpm -Uhv --oldpackage zsh-4.1.0-2.fc16.noarch.rpm
You can remove a package with the -e option. You only need the base name of a package to remove it. For example:
# rpm -e emacs
The rpm -e emacs command would be successful because no other packages are dependent on emacs. However, it would leave behind emacs-common, which was installed as a dependency to emacs. If you had tried to remove emacs-common first, that command would fail with a “Failed dependencies” message.
Querying rpm information
Once the package is installed, you can query for information about the package. Using the -q option, you can see information about the package, including a description (-qi), list of files (-ql), documentation (-qd), and configuration files (-qc).
# rpm -qi zsh Name : zsh Version : 4.3.17 Release : 1.fc16 ... # rpm -ql zsh /bin/zsh /etc/skel/.zshrc /etc/zlogin /etc/zlogout ... # rpm -qd zsh /usr/share/doc/zsh-4.3.17/FAQ /usr/share/doc/zsh-4.3.17/FEATURES /usr/share/doc/zsh-4.3.17/README # rpm -qc zsh /etc/skel/.zshrc /etc/zlogin /etc/zlogout
There are options to query any piece of information contained in an RPM. You can find what an RPM needs for it to be installed (--requires), what version of software a package provides (--provides), what scripts are run before and after an RPM is installed or removed (--scripts), and what changes have been made to an RPM (--changelog).
# rpm -q --requires emacs-common
/bin/sh
/sbin/install-info
/usr/bin/perl
...
# rpm -q --provides emacs-common
config(emacs-common) = 1:23.3-9.fc16
emacs-common = 1:23.3-9.fc16
# rpm -q --scripts httpd
# Add the "apache" user
/usr/sbin/useradd -c "Apache" -u 48
-s /sbin/nologin -r -d /var/www apache 2> /dev/null || :
postinstall scriptlet (using /bin/sh):
# Register the httpd service
/sbin/chkconfig --add httpd
...
# rpm -q --changelog httpd | less
* Mon Mar 05 2012 Jan Kaluza <[email protected]> - 2.2.22-2
- fix #751591 - start httpd after network filesystems
...
In the previous two examples, you can see that scripts inside the httpd package add an apache user at installation time and turn on the httpd service with chkconfig. The --changelog option enables you to see why changes have been made to each version of the package. The fix # represents a fixed bug that you can look up in http://bugzilla.redhat.com.
Using a feature called --queryformat, you can query different tags of information and output them in any form you like. Run the --querytags option to be able to see all the tags that are available:
# rpm --querytags | less
ARCH
ARCHIVESIZE
BASENAMES
BUGURL
...
# rpm -q binutils --queryformat "The package is %{NAME}
and the release is %{RELEASE}
"
The package is binutils and the release is 6.fc16
All the queries you have done so far have been to the local RPM database. By adding a -p to those query options, you can query an RPM file sitting in your local directory instead. The -p option is a great way to look inside a package that someone gives you to investigate what it is before you install it on your system.
If you haven't already, get the zsh package and put it in your local directory (yumdownloader zsh). Then run some query commands on it.
# rpm -qip zsh-4.3.17-1.fc16.i686.rpm # rpm -qlp zsh-4.3.17-1.fc16.i686.rpm # rpm -qdp zsh-4.3.17-1.fc16.i686.rpm # rpm -qcp zsh-4.3.17-1.fc16.i686.rpm
Verifying RPM packages
Using the -V option, you can check the packages installed on your system to see if the components have been changed since the packages were first installed. While it is normal for configuration files to change over time, it is not normal for binaries (the commands in /bin, /sbin, and so on) to change after installation. Binaries that are changed are probably an indication that your system has been cracked.
In this example, I'm going to install the zsh package and mess it up. If you want to try along with the examples, be sure to remove or reinstall the package when you are done.
# rpm -i zsh-4.3.17-1.fc16.i686.rpm # echo hello > /bin/zsh # rm /etc/zshrc # rpm -V zsh S.5....T. /bin/zsh missing c /etc/zshrc
In this output, you can see that the /bin/zsh file has been tampered with and /etc/zshrc has been removed. Each time you see a letter or a number instead of a dot from the rpm -V output, it is an indication of what has changed. Letters that can replace the dots (in order) include the following:
S file Size differs M Mode differs (includes permissions and file type) 5 MD5 sum differs D Device major/minor number mismatch L readLink(2) path mismatch U User ownership differs G Group ownership differs T mTime differs P caPabilities differ
Those indicators are from the Verify section of the rpm man page. In my example, you can see the file size has changed (S), the md5sum checked against the file's fingerprint has changed (5), and the modification time (T) on the file differs.
To restore the package to its original state, use rpm with the --replacepkgs option, as shown next. (The yum reinstall zsh command would work as well). Then check it with -V again. No output from -V means that every file is back to its original state.
# rpm -i --replacepkgs zsh-4.3.17-1.fc16.i686.rpm # rpm -V zsh
Good practice is to back up your RPM database (from /var/lib/rpm) and copy it to some read-only medium (such as a CD). Then, when you go to verify packages that you suspect were cracked, you know you aren't checking it against a database that has also been cracked.
Managing Software in the Enterprise
At this point you should have a good working knowledge of how to install, query, remove, and otherwise manipulate packages with graphical tools, the yum command, and the rpm command. When you start working with RPM files in a large enterprise, you will need to extend that knowledge.
Features used to manage RPM packages in the enterprise with Red Hat Enterprise Linux offer a bit more complexity and a lot more power. Instead of having one big software repository, as Fedora does, RHEL provides deployment through Red Hat Network, which requires a paid subscription and entitlements to a variety of software channels (RHEL, Red Hat Enterprise Virtualization, Red Hat Cluster Suite, and so on).
In terms of enterprise computing, one of the great benefits of the design of RPM packages is that their management can be automated. Other Linux packaging schemes allow packages to stop and prompt you for information when they are being installed (such as asking for a directory location or a username). RPM packages install without interruption, offering some of the following advantages:
- Kickstart files — All the questions you answer during a manual install and all the packages you select can be added into a file called a kickstart file. When you start a Fedora or Red Hat Enterprise Linux installer, you can provide a kickstart file at the boot prompt. From that point on, the entire installation process completes on its own.
- PXE boot — You can configure a PXE server to allow client computers to boot an anaconda (installer) kernel and a select kickstart file. A completely blank computer with a network interface card (NIC) that supports PXE booting can simply boot from its NIC to launch a fresh installation. In other words, turn on the computer, and if it hits the NIC in its boot order, a few minutes later you can have a freshly installed system, configured to your exact specifications without intervention.
- Satellite server (Spacewalk) — Red Hat Enterprise Linux systems can be deployed using what is referred to as Satellite Server (the open source project is called Spacewalk). Built into Satellite Server are the same features you have from Red Hat Network to manage and deploy new systems and updates. Without logging in directly, RHEL systems can be configured to get software updates at times set from the satellite server. Sets of packages called Errata that fix specific problems can be quickly and automatically deployed to the systems that need them.
Descriptions of how to use kickstart files, satellite servers, and other enterprise-ready installation features are beyond the scope of this book. But the understanding you have gained from learning about YUM and RPM will serve as a solid foundation for any RHEL software installation work you do in the future.
Summary
Software packaging in Fedora, Red Hat Enterprise Linux, and related systems is provided using software packages based on the RPM Package Manager (RPM) tools. There are easy-to-use graphical tools such as the PackageKit Add/Remove Software window for finding and installing packages. The primary command-line tools include the yum and rpm commands.
Using any of these software management tools, you can install, query, verify, update, and remove packages. You can also do maintenance tasks, such as clean out cache files and rebuild the RPM database. This chapter describes many of the features of PackageKit, YUM, and RPM.
With your system installed and the software packages that you need added, it is time to further configure your Fedora or RHEL system. If you expect to have multiple people using your system, your next task could be to add and otherwise manage user accounts on your system. Chapter 11 describes user management in Fedora, RHEL, and other Linux systems.
Exercises
These exercises test your knowledge of working with RPM software packages in Fedora or Red Hat Enterprise Linux. To do the exercises, I recommend you have a Fedora system in front of you that has an Internet connection. (Most of the procedures will work equally well on a registered RHEL system.)
You need to be able to reach the Fedora repositories (which should be set up automatically). If you are stuck, solutions to the tasks are shown in Appendix B (although in Linux, there are often multiple ways to complete a task).