Part I. Package Management
All software on a Red Hat Enterprise Linux system is divided into
RPM packages, which can be installed, upgraded, or removed. This part
describes how to manage packages on Red Hat Enterprise Linux using the Yum and RPM package managers and the PackageKit suite of graphical package management tools.
Table of Contents
- 1. Yum
- 2. PackageKit
- 3. RPM
Chapter 1. Yum
Yum is the Red Hat
package manager that is able to query for information about packages,
fetch packages from repositories, install and uninstall packages using
automatic dependency resolution, and update an entire system to the
latest available packages. Yum
performs automatic dependency resolution on packages you are updating,
installing or removing, and thus is able to automatically determine,
fetch and install all available dependent packages. Yum can be configured with new, additional repositories, or package sources, and also provides many plugins which enhance and extend its capabilities. Yum is able to perform many of the same tasks that RPM can; additionally, many of the command line options are similar. Yum enables easy and simple package management on a single machine or on groups of them.
Secure Package Management with GPG-Signed Packages
Yum provides secure
package management by enabling GPG (Gnu Privacy Guard; also known as
GnuPG) signature verification on GPG-signed packages to be turned on for
all package repositories (i.e. package sources), or for individual
repositories. When signature verification is enabled, Yum
will refuse to install any packages not GPG-signed with the correct key
for that repository. This means that you can trust that the RPM
packages you download and install on your system are from a trusted
source, such as Red Hat, and were not modified during transfer. Refer to
Section 1.3, “Configuring Yum and Yum Repositories” for details on enabling signature-checking with Yum, or Section 3.3, “Checking a Package's Signature” for information on working with and verifying GPG-signed RPM packages in general.
Yum also enables you to easily set up your own repositories of RPM packages for download and installation on other machines.
Learning Yum is a
worthwhile investment because it is often the fastest way to perform
system administration tasks, and it provides capabilities beyond those
provided by the PackageKit graphical package management tools. Refer to Chapter 2, PackageKit for details on using PackageKit.
1.1. Checking For and Updating Packages
1.1.1. Checking For Updates
You can use the
yum check-update command to see which installed packages on your system have updates available.
Note: Yum and Superuser Privileges
You must have superuser privileges in order to use
yum
to install, update or remove packages on your system. All examples in
this chapter assume that you have already obtained superuser privileges
by using either the su or sudo command.
~]# yum check-update
Loaded plugins: presto, refresh-packagekit, security
PackageKit.x86_64 0.5.8-2.el6 rhel
PackageKit-glib.x86_64 0.5.8-2.el6 rhel
PackageKit-yum.x86_64 0.5.8-2.el6 rhel
PackageKit-yum-plugin.x86_64 0.5.8-2.el6 rhel
glibc.x86_64 2.11.90-20.el6 rhel
glibc-common.x86_64 2.10.90-22 rhel
kernel.x86_64 2.6.31-14.el6 rhel
kernel-firmware.noarch 2.6.31-14.el6 rhel
rpm.x86_64 4.7.1-5.el6 rhel
rpm-libs.x86_64 4.7.1-5.el6 rhel
rpm-python.x86_64 4.7.1-5.el6 rhel
udev.x86_64 147-2.15.el6 rhel
yum.noarch 3.2.24-4.el6 rhel
These packages are listed as having updates available. The first package in the list is PackageKit, the graphical package manager. The first line of the above output tells us:
PackageKit— the name of the packagex86_64— the CPU architecture the package was built for0.5.8— the version of the updated package to be installedrhel— the repository in which the updated package is located
The output also shows us that we can update the kernel (the kernel package), Yum and RPM themselves (the
yum and rpm packages), as well as their dependencies (such as the kernel-firmware, rpm-libs and rpm-python packages), all using yum.
1.1.2. Updating Packages
You can choose to update a single package, multiple packages, or all
packages at once. If any dependencies of the package (or packages) you
update have updates available themselves, then they are updated too. To
update a single package
, enter
yum update <package_name>:
~]# yum update udev
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package udev.x86_64 0:147-2.15.el6 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
===========================================================================
Package Arch Version Repository Size
===========================================================================
Updating:
udev x86_64 147-2.15.el6 rhel 337 k
Transaction Summary
===========================================================================
Install 0 Package(s)
Upgrade 1 Package(s)
Total download size: 337 k
Is this ok [y/N]:
This output contains several items of interest:
Loaded plugins: presto, refresh-packagekit, security—yumalways informs you which Yum plugins are installed and enabled. Here,yumis using the presto, refresh-packagekit and security plugins. Refer to Section 1.4, “Yum Plugins” for general information on Yum plugins, or to Section 1.4.3, “Plugin Descriptions” for descriptions of specific plugins.kernel.x86_64— you can download and install new kernels safely withyum.Important: Updating and Installing Kernels with Yum
yumalways installs a new kernel in the same sense that RPM installs a new kernel when you use the commandrpm -i kernel. Therefore, you do not need to worry about the distinction between installing and upgrading a kernel package when you useyum: it will do the right thing, regardless of whether you are using theyum updateoryum installcommand.When using RPM, on the other hand, it is important to use therpm -i kernelcommand (which installs a new kernel) instead ofrpm -u kernel(which replaces the current kernel). Refer to Section 3.2.2, “Installing and Upgrading” for more information on installing/updating kernels with RPM.yumpresents the update information and then prompts you as to whether you want it to perform the update;yumruns interactively by default. If you already know which transactionsyumplans to perform, you can use the-yoption to automatically answeryesto any questionsyummay ask (in which case it runs non-interactively). However, you should always examine which changesyumplans to make to the system so that you can easily troubleshoot any problems that might arise.If a transaction does go awry, you can view Yum's log of transactions by enteringcat /var/log/yum.logat the shell prompt. The most recent transactions are listed at the end of the log file.
Updating All Packages and Their Dependencies
To update all packages and their dependencies, simply enter
yum update (without any arguments):
Example 1.1. Updating all packages at once
~]# yum update1.1.3. Updating Security-Related Packages
Discovering which packages have security updates available and then
updating those packages quickly and easily is important. Yum provides the
plugin for this purpose. The security plugin extends the
yum command with a set of highly-useful security-centric commands, subcommands and options. Refer to Section 1.4.3, “security (yum-plugin-security)” for specific information.
1.1.4. Preserving Configuration File Changes
You will inevitably make changes to the configuration files
installed by packages as you use your Red Hat Enterprise Linux system. RPM, which Yum uses to perform changes to the system, provides a mechanism for ensuring their integrity. Refer to Section 3.2.2, “Installing and Upgrading” for details on how to manage changes to configuration files across package upgrades.
1.2. Packages and Package Groups
1.2.1. Searching, Listing and Displaying Package Information
You can search all RPM package names, descriptions and summaries by using the
yum search <term> [more_terms] command. yum displays the list of matches for each term:
~]# yum search meld kompare
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
============================ Matched: kompare =============================
kdesdk.x86_64 : The KDE Software Development Kit (SDK)
Warning: No matches found for: meld
yum search is useful for searching for packages you do not know the name of, but for which you know a related term.
Listing Packages
Tip: Filtering Results with Glob Expressions
All of Yum's various list commands allow you to filter the results by appending one or more glob expressions as arguments. Glob expressions are normal strings of characters which contain one or more of the wildcard characters
* (which expands to match any character multiple times) and ?
(which expands to match any one character). Be careful to escape both
of these glob characters when passing them as arguments to a yum command. If you do not, the bash shell will interpret the glob expressions as pathname expansions, and potentially pass all files in the current directory that match the globs to yum, which is not what you want. Instead, you want to pass the glob expressions themselves to yum, which you can do by either:
- escaping the wildcard characters
- double-quoting or single-quoting the entire glob expression.
The following examples show both methods:
Example 1.2. Filtering results using a single glob expression with two escaped wildcard characters
~]# yum list available gstreamer\*plugin\*
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
Available Packages
gstreamer-plugins-bad-free.i686 0.10.17-4.el6 rhel
gstreamer-plugins-base.i686 0.10.26-1.el6 rhel
gstreamer-plugins-base-devel.i686 0.10.26-1.el6 rhel
gstreamer-plugins-base-devel.x86_64 0.10.26-1.el6 rhel
gstreamer-plugins-good.i686 0.10.18-1.el6 rhel
Example 1.3. Filtering results using a double-quoted glob expression
~]# yum list installed "krb?-*"
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
Installed Packages
krb5-libs.x86_64 1.8.1-3.el6 @rhel
krb5-workstation.x86_64 1.8.1-3.el6 @rhel
yum list— List information on installed and available packages matching all glob expressions.<glob_expr>[more_glob_exprs]Example 1.4. Listing all ABRT addons and plugins using glob expressions
~]#
yum list abrt-addon\* abrt-plugin\*Loaded plugins: presto, refresh-packagekit, rhnplugin, security Installed Packages abrt-addon-ccpp.x86_64 1.0.7-5.el6 @rhel abrt-addon-kerneloops.x86_64 1.0.7-5.el6 @rhel abrt-addon-python.x86_64 1.0.7-5.el6 @rhel abrt-plugin-bugzilla.x86_64 1.0.7-5.el6 @rhel abrt-plugin-logger.x86_64 1.0.7-5.el6 @rhel abrt-plugin-sosreport.x86_64 1.0.7-5.el6 @rhel abrt-plugin-ticketuploader.x86_64 1.0.7-5.el6 @rhel
Displaying Package Info
yum info <package_name> [more_names]
displays information about one or more packages (glob expressions are valid here as well):
~]# yum info abrt
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
Installed Packages
Name : abrt
Arch : x86_64
Version : 1.0.7
Release : 5.el6
Size : 578 k
Repo : installed
From repo : rhel
Summary : Automatic bug detection and reporting tool
URL : https://fedorahosted.org/abrt/
License : GPLv2+
Description: abrt is a tool to help users to detect defects in applications
: and to create a bug report with all informations needed by
: maintainer to fix it. It uses plugin system to extend its
: functionality.
yum info <package_name> is similar to the rpm -q --info <package_name> command, but provides as additional information the ID of the Yum repository the RPM package is found in (look for the From repo: line in the output).
yumdb info <package_name> [more_names] can be used to query the Yum
database for alternative and useful information about a package,
including the checksum of the package (and algorithm used to produce it,
such as SHA-256), the command given on the command line that was
invoked to install the package (if any), and the reason that the package
is installed on the system (where user indicates it was installed by the user, and dep means it was brought in as a dependency):
~]# yumdb info yum
yum-3.2.27-4.el6.noarch
checksum_data = 15c8eaf583fabad6974a35b9f6c6527e49362fe4e23baec1682ef51a598e4abb
checksum_type = sha256
command_line = update
from_repo = rhel
from_repo_revision = 1271991599
from_repo_timestamp = 1271991721
reason = user
releasever = 6
See
man yumdb for more information on the yumdb command.
Finally, the
yum history command, which is new in Red Hat Enterprise Linux 6, can be used to show a timeline of Yum
transactions, the dates and times on when they occurred, the number of
packages affected, whether transactions succeeded or were aborted, and
if the RPM database was changed between transactions. Refer to the history section of man yum for details.
1.2.2. Installing
You can install a package and all of its non-installed dependencies by entering:
~]# yum install <package_name>
You can install multiple packages simultaneously by appending their names as arguments:
yum install <package_name> [more_names] .
If you are installing packages on a multilib
system, such as an AMD64 or Intel64 machine, you can specify the
architecture of the package (as long as it's available in an enabled
repository) by appending
.arch to the package name:
~]# yum install sqlite2.i586
You can use glob expressions to quickly install multiple similarly-named packages:
~]# yum install audacious-plugins-\*
In addition to package names and glob expressions, you can also provide file names to
yum install. If you know the name of the binary you want to install, but not its package name, you can give yum install the path name:
~]# yum install /usr/sbin/namedyum then searches through its package
lists, finds the package which provides /usr/sbin/named, if any, and
prompts you as to whether you want to install it.
What if you know you want to install the package that contains the
named binary, but don't know in which bin or sbin directory that file lives? In that situation, you can give yum provides a glob expression:
Example 1.5. Finding which package owns a file and installing it
~]#yum provides "*bin/named"Loaded plugins: presto, refresh-packagekit, rhnplugin, security 32:bind-9.7.0-4.P1.el6.x86_64 : The Berkeley Internet Name Domain (BIND) : DNS (Domain Name System) server Repo : rhel Matched from: Filename : /usr/sbin/named ~]#yum install bind
Note
yum provides is the same as yum whatprovides.
Tip: yum provides/whatprovides and Glob Expressions
yum provides "*/<file_name>" is a common and useful trick to quickly find the package(s) that contain <file_name>.
Installing a Package Group
A package group is similar to a package: it is not useful by itself,
but installing one pulls a group of dependent packages that serve a
common purpose. A package group has a name and a groupid. The
yum grouplist -v command lists the names of all package groups, and, next to each of them, their groupid in parentheses. The groupid is always the term in the last pair of parentheses, such as kde-desktop and kde-software-development in this example:
Not all packages used in examples may be available on RHN
Some of the software packages—or package groups—queried for and installed with Yum in this chapter may not be available from Red Hat Network. Their use in examples is purely to demonstrate Yum's command usage.
Note that obtaining and installing software packages from
unverified or untrusted software sources other than Red Hat Network
constitutes a potential security risk, and could lead to security,
stability, compatibility maintainability issues.
~]# yum -v grouplist kde\*
KDE (K Desktop Environment) (kde-desktop)
KDE Software Development (kde-software-development)
You can install a package group by passing its full group name (without the groupid part) to
groupinstall:
~]# yum groupinstall "KDE (K Desktop Environment)"
You can also install by groupid:
~]# yum groupinstall kde-desktop
You can even pass the groupid (or quoted name) to the
install command if you prepend it with an @-symbol (which tells yum that you want to perform a groupinstall):
~]# yum install @kde-desktop1.2.3. Removing
yum remove <package_name>
uninstalls (removes in RPM and Yum
terminology) the package, as well as any packages that depend on it. As
when you install multiple packages, you can remove several at once by
adding more package names to the command:
yum remove foo bar baz
Similar to
install, remove can take these arguments:
- package names
- glob expressions
- file lists
- package provides
Warning: Removing a Package when Other Packages Depend On It
Yum is not able
to remove a package without also removing packages which depend on it.
This type of operation can only be performed by RPM,
is not advised, and can potentially leave your system in a
non-functioning state or cause applications to misbehave and/or crash.
For further information, refer to Section 3.2.4, “Uninstalling” in the RPM chapter.
Removing a Package Group
You can remove a package group using syntax congruent with the
install syntax.
Example 1.6. Alternative but equivalent ways of removing a package group
~]#yum groupremove "KDE (K Desktop Environment)"~]#yum groupremove kde-desktop~]#yum remove @kde-desktop
Smart package group removal
When you tell yum
to remove a package group, it will remove every package in that group,
even if those packages are members of other package groups or
dependencies of other installed packages. However, you can instruct
yum to remove only those packages which are not required by any other packages or groups by adding the groupremove_leaf_only=1 directive to the [main] section of the /etc/yum.conf configuration file. For more information on this directive, refer to Section 1.3.1, “Setting [main] Options”.
1.3. Configuring Yum and Yum Repositories
This section shows you how to:
- set global Yum options by editing the
[main]section of the/etc/yum.confconfiguration file; - set options for individual repositories by editing the [
repository] sections in/etc/yum.confand.repofiles in the/etc/yum.repos.d/directory; - use Yum variables in
/etc/yum.confand files in/etc/yum.repos.d/so that dynamic version and architecture values are handled correctly; and, - set up your own custom Yum repository.
The
/etc/yum.conf configuration file contains one mandatory [main] section under which you can set Yum options. The values that you define in the [main] section of yum.conf have global effect, and may override values set any individual [repository] sections. You can also add [repository] sections to /etc/yum.conf; however, best practice is to define individual repositories in new or existing .repo files in the /etc/yum.repos.d/directory. Refer to Section 1.3.2, “Setting [repository] Options” if you need to add or edit repository-specific information.
1.3.1. Setting [main] Options
The
/etc/yum.conf configuration file contains exactly one [main] section. You can add many additional options under the [main] section heading in /etc/yum.conf. Some of the key-value pairs in the [main] section affect how yum operates; others affect how Yum treats repositories. The best source of information for all Yum options is in the [main] OPTIONS and [repository] OPTIONS sections of man yum.conf.
Here is a sample
/etc/yum.conf configuration file:
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
[comments abridged]
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
Here is a list of the most commonly-used options in the
[main] section, and descriptions for each:
- assumeyes=
<value> - ...where
<value>is one of:0—yumshould prompt for confirmation of critical actions it performs. This is the default.1— Do not prompt for confirmation of criticalyumactions. Ifassumeyes=1is set,yumbehaves in the same way that the command line option-ydoes. - cachedir=
/var/cache/yum/$basearch/$releasever - This option specifies the directory where Yum should store its cache and database files. By default, Yum's cache directory is
/var/cache/yum/$basearch/$releasever. See Section 1.3.3, “Using Yum Variables” for descriptions of the$basearchand$releaseverYum variables. - debuglevel=
value - ...where
<value>is an integer between1and10. Setting a higherdebuglevelvalue causesyumto display more detailed debugging output.debuglevel=0disables debugging output, whiledebuglevel=2is the default. - exactarch=
<value> - ...where
<value>is one of:0— Do not take into account the exact architecture when updating packages.1— Consider the exact architecture when updating packages. With this setting,yumwill not install an i686 package to update an i386 package already installed on the system. This is the default. - exclude=
<package_name>[more_package_names] - This option allows you to exclude packages by keyword during installation/updates. Listing multiple packages for exclusion can be accomplished by quoting a space-delimited list of packages. Shell globs using wildcards (for example,
*and?) are allowed. - gpgcheck=
<value> - ...where
<value>is one of:0— Disable GPG signature-checking on packages in all repositories, including local package installation.1— Enable GPG signature-checking on all packages in all repositories, including local package installation.gpgcheck=1is the default, and thus all packages' signatures are checked.If this option is set in the[main]section of the/etc/yum.conffile, it sets the GPG-checking rule for all repositories. However, you can also setgpgcheck=<value>for individual repositories instead; i.e., you can enable GPG-checking on one repository while disabling it on another. Settinggpgcheck=for an individual repository in its correpsonding<value>.repofile overrides the default if it is present in/etc/yum.conf. Refer to Section 3.3, “Checking a Package's Signature” for further information on GPG signature-checking. - groupremove_leaf_only=
<value> - ...where
<value>is one of:0—yumshould not check the dependencies of each package when removing a package group. With this setting,yumremoves all packages in a package group, regardless of whether those packages are required by other packages or groups.groupremove_leaf_only=0is the default.1—yumshould check the dependencies of each package when removing a package group, and remove only those packages which are not not required by any other package or group.For more information on removing packages, refer to Smart package group removal. - installonlypkgs=
<space><separated><list><of><packages> - Here you can provide a space-separated list of packages which
yumcan install, but will never update. Refer toman yum.conffor the list of packages which are install-only by default. If you add theinstallonlypkgsdirective to/etc/yum.conf, you should ensure that you list all of the packages that should be install-only, including any of those listed under theinstallonlypkgssection ofman yum.conf. In particular, kernel packages should always be listed ininstallonlypkgs(as they are by default), andinstallonly_limitshould always be set to a value greater than2so that a backup kernel is always available in case the default one fails to boot. Refer to installonly_limit=<value>for details on theinstallonly_limitdirective. - installonly_limit=
<value> - ...where
<value>is an integer representing the maximum number of versions that can be installed simultaneously for any single package listed in theinstallonlypkgsdirective. The defaults for theinstallonlypkgsdirective include several different kernel packages, so be aware that changing the value ofinstallonly_limitwill also affect the maximum number of installed versions of any single kernel package. The default value listed in/etc/yum.confisinstallonly_limit=3, and it is not recommended to decrease this value, particularly below2. - keepcache=
<value> - ...where value is one of:
0— Do not retain the cache of headers and packages after a successful installation. This is the default.1— Retain the cache after a successful installation. - logfile=
/var/log/yum.log - This option specifies where
yumshould send its logging output. By default,yumlogs to/var/log/yum.log. - multilib_policy=
<value> - ...where
<value>is one of:best— install the best-choice architecture for this system. For example, settingmultilib_policy=beston an AMD64 system causesyumto install 64-bit versions of all packages.all— always install every possible architecture for every package. For example, withmultilib_policyset toallon an AMD64 system,yumwould install both the i586 and AMD64 versions of a package, if both were available. - obsoletes=
<value> - ...where
<value>is one of:0— Disableyum's obsoletes processing logic when performing updates.1— Enableyum's obsoletes processing logic when performing updates. When one package declares in its spec file that it obsoletes another package, the latter package will be replaced by the former package when the former package is installed. Obsoletes are declared, for example, when a package is renamed.obsoletes=1the default. - plugins=
<value> - ...where
<value>is one of:0— Disable all Yum plugins globally.Disabling plugins is not advised
Disabling all plugins is not advised because certain plugins provide importantYumservices. In particular, rhnplugin enables connecting toRed Hat Network, and the security plugin allows system administrators to easily update the system with (sometimes critical) security updates. Disabling plugins globally is provided as a convenience option, and is generally only recommended when diagnosing a potential problem withYum.1— Enable all Yum plugins globally. Withplugins=1, you can still disable a specific Yum plugin by settingenabled=0in that plugin's configuration file. Refer to Section 1.4, “Yum Plugins” for more information about various Yum plugins, or to Section 1.4.1, “Enabling, Configuring and Disabling Yum Plugins” for further information on controlling plugins. - reposdir=
</absolute/path/to/directory/containing/repo/files> - This option allows you to specify a directory where
.repofiles are located. All.repofiles contain repository information (similar to the [repository] section(s) of/etc/yum.conf).yumcollects all repository information from.repofiles and the [repository] section of the/etc/yum.conffile to create a master list of repositories to use for transactions. Refer to Section 1.3.2, “Setting [repository] Options” for more information about options you can use for both the [repository] section and.repofiles. Ifreposdiris not set,yumuses the default directory/etc/yum.repos.d/. - retries=
<value> - ...where
<value>is an integer0or greater. This value sets the number of timesyumshould attempt to retrieve a file before returning an error. Setting this to0makesyumretry forever. The default value is10.
1.3.2. Setting [repository] Options
You can define individual Yum repositories by adding [
repository] sections (where repository is a unique repository ID, such as [my_personal_repo]) to /etc/yum.conf or to .repo files in the /etc/yum.repos.d/directory. All .repo files in /etc/yum.repos.d/are read by yum; best practice is to define your repositories here instead of in /etc/yum.conf. You can create new, custom .repo files in this directory, add [repository] sections to those files, and the next time you run a yum command, it will take all newly-added repositories into account.
Here is a (bare-minimum) example of the form a
.repo file should take:
[repository_ID] name=A Repository Name baseurl=http://path/to/repo or ftp://path/to/repo or file://path/to/local/repo
Every [
repository] section must contain the following minimum parts:
- [
repository_ID] - The repository ID is a unique, one-word (no spaces; underscores are allowed) string of characters (enclosed by brackets) that serves as a repository identifier.
- name=
<My Repository Name> - This is a human-readable string describing the repository.
- baseurl=http://path/to/repo, ftp://path/to/repo, file://path/to/local/repo
- This is a URL to the directory where the repodata directory of a repository is located. Usually this URL is an HTTP link, such as:
baseurl=http://path/to/repo/releases/$releasever/server/$basearch/os/
Yum always expands the$releasever,$archand$basearchvariables in URLs. See the following section for explanations of all Yum variables: Section 1.3.3, “Using Yum Variables”.- If the repository is available over FTP, use: ftp://path/to/repo
- If the repository is local to the machine, use file://path/to/local/repo
- If a specific online repository requires basic HTTP authentication, you can specify your username and password in the
http://path/to/repoby prepending it asusername:password@link. For example, if a repository on http://www.example.com/repo/ requires a username of "user" and a password of "password", then thebaseurllink could be specified as:baseurl=http://
user:password@www.example.com/repo/
The following is another useful [
repository] directive:
- enabled=
<value> - ...where
<value>is one of:0— do not include this repository as a package source when performing updates and installs. This is an easy way of quickly turning repositories on and off, which is useful when you desire a single package from a repository that you do not want to enable for updates or installs.1— include this repository as a package source.Turning repositories on and off can also be performed quickly by passing either the--enablerepo=<orrepo_name>--disablerepo=<option torepo_name>yum, or easily through PackageKit's Add/Remove Software window.
Many more [
repository] options exist. Refer to the [repository] OPTIONS section of man yum.conf for the exhaustive list and descriptions for each.
1.3.3. Using Yum Variables
You can use and reference the following variables in
yum commands and in all Yum configuration files (/etc/yum.conf and all .repo files in /etc/yum.repos.d/.
-
$releasever - You can use this variable to reference the release version of Red Hat Enterprise Linux. Yum obtains the value of
$releaseverfrom thedistroverpkg=<value>line in the/etc/yum.confconfiguration file. If there is no such line in/etc/yum.conf, thenyuminfers the correct value by deriving the version number from theredhat-releasepackage. -
$arch - You can use this variable to refer to the system's CPU architecture as returned when calling Python's
os.uname()function. Valid values for$archinclude:i586,i686andx86_64. -
$basearch - You can use
$basearchto reference the base architecture of the system. For example, i686 and i586 machines both have a base architecture ofi386, and AMD64 and Intel64 machines have a base architecture ofx86_64. -
$YUM0-9 - These ten variables are each replaced with the value of any shell environment variables with the same name. If one of these variables is referenced (in
/etc/yum.conffor example) and a shell environment variable with the same name does not exist, then the configuration file variable is not replaced.
1.3.4. Creating a Yum Repository
To set up a Yum repository, follow these steps:
Procedure 1.1. Setting Up a Yum repository
- Install the
createrepopackage:~]#
yum install createrepo - Copy all of the packages into one directory, such as
/mnt/local_repo/. - Run the
createrepo --databasecommand on that directory:~]#
createrepo --database /mnt/local_repoImportant
Because RPM packages for Red Hat Enterprise Linux 6 are compressed using the XZ lossless data compression format, and may also be signed using alternative (and stronger) hash algorithms such as SHA-256, it is not possible to runcreaterepoon Red Hat Enterprise Linux 5 to create the package metadata for Red Hat Enterprise Linux 6 packages. Thecreaterepocommand relies onrpmto open and inspect the packages, andrpmon Red Hat Enterprise Linux 5 is not able to open the improved Red Hat Enterprise Linux 6 RPM package format.
This will create the necessary metadata for your Yum repository, as well as the sqlite database for speeding up
yum operations.
1.4. Yum Plugins
Yum provides plugins that extend and enhance its operations. Certain plugins are installed by default. Yum always informs you which plugins, if any, are loaded and active whenever you call any
yum command:
~]# yum info yum
Loaded plugins: presto, refresh-packagekit, security
[output truncated]
Note that the plugin names which follow
Loaded plugins are the names you can provide to the --disableplugins=<plugin_name> option.
1.4.1. Enabling, Configuring and Disabling Yum Plugins
To enable Yum plugins, ensure that a line beginning with
plugins= is present in the [main] section of /etc/yum.conf, and that its value is set to 1:
plugins=1
You can disable all plugins by changing this line to
plugins=0.
Disabling plugins is not advised
Disabling all plugins is not advised because certain plugins provide important
Yum services. In particular, rhnplugin enables connecting to Red Hat Network,
and the security plugin allows system administrators to easily update
the system with (sometimes critical) security updates. Disabling plugins
globally is provided as a convenience option, and is generally only
recommended when diagnosing a potential problem with Yum.
Every installed plugin has its own configuration file in the
/etc/yum/pluginconf.d/ directory. You can set plugin-specific options in these files. For example, here is the security plugin's security.conf configuration file:
Example 1.7. A minimal Yum plugin configuration file
[main] enabled=1
Plugin configuration files always contain a
[main] section (similar to Yum's /etc/yum.conf file) in which there is (or you can place if it is missing) an enabled= option that controls whether the plugin is enabled when you run yum commands.
If you disable all plugins by setting
enabled=0 in /etc/yum.conf, then all plugins are disabled regardless of whether they are enabled in their individual configuration files.
If you merely want to disable all Yum plugins for a single
yum command, use the --noplugins option.
If you simply want to disable one or more Yum plugins for a single
yum command, then you can add the --disableplugin=<plugin_name> option to the command:
Example 1.8. Disabling the presto plugin while running yum update
~]# yum update --disableplugin=presto
The plugin names you provide to the
--disableplugin= option are the same names listed after the Loaded plugins: line in the output of any yum
command. You can disable multiple plugins by separating their names
with commas. In addition, you can match multiple similarly-named plugin
names or simply shorten long ones by using glob expressions: --disableplugin=presto,refresh-pack*.
1.4.2. Installing More Yum Plugins
Yum plugins usually adhere to the
yum-plugin-<plugin_name> package-naming convention, but not always: the package which provides the presto plugin is named yum-presto, for example. You can install a Yum plugin in the same way you install other packages:
~]# yum install yum-plugin-security1.4.3. Plugin Descriptions
Here are descriptions of a few useful Yum plugins:
presto (yum-presto)
The presto plugin adds support to Yum for downloading delta RPM packages, during updates, from repositories which have presto
metadata enabled. Delta RPMs contain only the differences between the
version of the package installed on the client requesting the RPM
package and the updated version in the repository. Downloading a delta
RPM is much quicker than downloading the entire updated package, and can
speed up updates considerably. Once the delta RPMs are downloaded, they
must be rebuilt (the difference applied to the currently-installed
package to create the full updated package) on the installing machine,
which takes CPU time. Using delta RPMs is therefore a tradeoff between
time-to-download, which depends on the network connection, and
time-to-rebuild, which is CPU-bound. Using the presto
plugin is recommended for fast machines and systems with slower network
connections, while slower machines on very fast connections may benefit more from downloading normal RPM packages, i.e. by disabling presto. The presto plugin is enabled by default.
protect-packages (yum-plugin-protect-packages)
The protect-packages plugin prevents the
yum
package and all packages it depends on from being purposefully or
accidentally removed. This simple scheme prevents many of the most
important packages necessary for your system to run from being removed.
In addition, you can list more packages, one per line, in the /etc/sysconfig/protected-packages file[1] (which you should create if it does not exist), and protect-packages will extend protection-from-removal to those packages as well. To temporarily override package protection, use the --override-protection option with an applicable yum command.
rhnplugin (yum-rhn-plugin)
The rhnplugin for Yum provides support for connecting to
Red Hat Network (RHN). Systems registered with RHN are able to update and install packages from Red Hat Network.
Refer to
man rhnplugin for more information.
refresh-packagekit (PackageKit-yum-plugin)
This plugin updates metadata for PackageKit whenever yum is run. The refresh-packagekit plugin is installed by default.
security (yum-plugin-security)
Discovering information about and applying security updates easily
and often is important to all system administrators. For this reason Yum provides the security plugin, which extends
yum with a set of highly-useful security-related commands, subcommands and options.
You can check for all security-related updates as follows:
~]# yum check-update --security
Loaded plugins: presto, refresh-packagekit, security
Limiting package lists to security relevant ones
Needed 3 of 7 packages, for security
elinks.x86_64 0.12-0.13.el6 rhel
kernel.x86_64 2.6.30.8-64.el6 rhel
kernel-headers.x86_64 2.6.30.8-64.el6 rhel
You can then use either
yum update --security or yum update-minimal --security
to update those packages which are affected by security advisories.
Both of these commands update all packages on the system for which a
security advisiory has been issued. yum update-minimal --security updates them to the latest packages which were released as part of a security advisory, while yum update --security will update all packages affected by a security advisory to the latest version of that package available.
In other words, if:
- the kernel-2.6.30.8-16 package is installed on your system;
- the kernel-2.6.30.8-32 package was released as a security update;
- then kernel-2.6.30.8-64 was released as a bug fix update,
...then
yum update-minimal --security will update you to kernel-2.6.30.8-32, and yum update --security will update you to kernel-2.6.30.8-64. Conservative system administrators may want to use update-minimal to reduce the risk incurred by updating packages as much as possible.
Refer to
man yum-security for usage details and further explanation of the enhancements the security plugin adds to yum.
1.5. Additional Resources
- The Yum home page and wiki — http://yum.baseurl.org/wiki/Guides
- The
Yum Guidessection of the wiki contains more Yum documentation. - Managing Software with Yum — http://docs.fedoraproject.org/en-US/Fedora_Core/5/html-single/Software_Management_Guide/
- A useful resource that provides additional information about using the Yum package manager.
[1]
You can also place files with the extension .list in the /etc/sysconfig/protected-packages.d/ directory (which you should create if it does not exist), and list packages—one per line—in these files. protect-packages will protect these too.
Chapter 2. PackageKit
Red Hat provides PackageKit for viewing, managing, updating, installing and uninstalling packages
compatible with your system. PackageKit consists of several graphical interfaces that can be opened from the GNOME panel menu, or from the Notification Area when PackageKit alerts you that updates are available. For more information on PackageKit's architecture and available front ends, refer to Section 2.3, “PackageKit Architecture”.
2.1. Updating Packages with Software Update
PackageKit displays a starburst icon in the Notification Area whenever updates are available to be installed on your system.
Clicking on the notification icon opens the Software Update
window. Alternatively, you can open Software Updates by clicking → → from the GNOME panel, or running the
gpk-update-viewer command at the shell prompt. In the Software Updates window, all available updates are listed along with the names of the packages being updated (minus the .rpm
suffix, but including the CPU architecture), a short summary of the
package, and, usually, short descriptions of the changes the update
provides. Any updates you do not wish to install can be de-selected here
by unchecking the checkbox corresponding to the update.
installing 12 updates with packagekit's software update window
Figure 2.1. Installing updates with Software Update
The updates presented in the Software Updates window only represent the currently-installed packages on your system for which updates are available;
dependencies of those packages, whether they are existing packages
on your system or new ones, are not shown until you click .
PackageKit
utilizes the fine-grained user authentication
capabilities provided by the PolicyKit toolkit whenever you request it to make changes to the system. Whenever you instruct PackageKit
to update, install or remove packages, you will be prompted to enter
the superuser password before changes are made to the system.
packagekit defers to policykit to provide authentication in order to make changes to the system
Figure 2.2. PackageKit uses PolicyKit to authenticate
If you instruct PackageKit to update the
kernel
package, then it will prompt you after installation, asking you whether
you want to reboot the system and thereby boot into the newly-installed
kernel.
Setting the Update-Checking Interval
Right-clicking on PackageKit's Notification Area icon and clicking opens the Software Update Preferences window, where you can define the interval at which PackageKit
checks for package updates, as well as whether or not to automatically
install all updates or only security updates, and how often to check for
major upgrades. Leaving the Check for updates when using mobile broadband
box unchecked is handy for avoiding extraneous bandwidth usage when
using a wireless connection on which you are charged for the amount of
data you download.
Setting the update-checking interval for packagekit by right-clicking on the notification area applet
Figure 2.3. Setting PackageKit's update-checking interval
2.2. Using Add/Remove Software
PackageKit's Software Update GUI window is a separate application from its Add/Remove Software
application, although the two have intuitively similar interfaces. To
find and install a new package, on the GNOME panel click on → → , or run the
gpk-application command at the shell prompt.
viewing packagekit's add/remove softvware window
Figure 2.4. PackageKit's Add/Remove Software window
2.2.1. Refreshing Software Sources (Yum Repositories)
PackageKit refers to Yum repositories as
software sources. It obtains all packages from enabled software sources. You can view the list of all configured and unfiltered (see below) Yum repositories by opening Add/Remove Software and clicking → . The Software Sources dialog shows the repository name, as written on the
name=<My Repository Name> field of all [repository] sections in the /etc/yum.conf configuration file, and in all repository.repo/etc/yum.repos.d/ directory.
Entries which are checked in the Enabled
column indicate that the corresponding repository will be used to
locate packages to satisfy all update and installation requests
(including dependency resolution). The Enabled column corresponds to the
enabled=<1 or 0> field in [repository]
sections. Checking an unchecked box enables the Yum repository, and
unchecking it disables it. Performing either function causes PolicyKit to prompt for superuser authentication to enable or disable the repository. PackageKit actually inserts the enabled=<1 or 0> line into the correct [repository] section if it does not exist, or changes the value if it does. This means that enabling or disabling a repository through the Software Sources
window causes that change to persist after closing the window or
rebooting the system. The ability to quickly enable and disable
repositories based on our needs is a highly-convenient feature of PackageKit.
Note that it is not possible to add or remove Yum repositories through PackageKit.
Showing Source RPM, Test and Debuginfo Repositories
Checking the box at the bottom of the Software Sources window causes PackageKit to display source RPM, testing and debuginfo repositories as well. This box is unchecked by defaut.
After enabling and/or disabling the correct Yum repositories, ensure that you have the latest list of available packages. Click on → and PackageKit will obtain the latest lists of packages from all enabled software sources, i.e. Yum repositories.
2.2.2. Finding Packages with Filters
Once the software sources have been updated, it is often beneficial to apply some filters so that PackageKit retrieves the results of our Find queries faster. This is especially helpful when performing many package searches. Four of the filters in the drop-down menu are used to split results by matching or not matching a single criterion. By default when PackageKit starts, these filters are all unapplied (), but once you do filter by one of them, that filter remains set until you either change it or close PackageKit.
Because you are usually searching for available packages that are not installed on the system, click → and select the radio button.
filtering out packages which are already installed
Figure 2.5. Filtering out already-installed packages
Also, unless we require development files such as C header files, we can filter for and, in doing so, filter out all of the
<package_name>-devel
filtering out development packages from our results
Figure 2.6. Filtering out development packages from the list of Find results
The two remaining filters with submenus are:
- Narrows the search to either applications which provide a GUI interface or those that do not (). This filter is useful when browsing for GUI applications that perform a specific function.
- Search for packages which are considered to be free software Refer to the Fedora Licensing List for details on approved licenses.
The remaining checkbox filters are always either checked or unchecked. They are:
- Checking the checkbox filters out generally-uninteresting packages that are typically only dependencies of other packages that we want. For example, checking and searching for
<package><package>-devel<package>-libs<package>-libs-devel<package>-debuginfo
- Checking filters out all older versions of the same package from the list of results, which is generally what we want.
Important: Using the Only newest items filter
Checking filters out all but the most recent version of any package from the results list. This filter is often combined with the filter to search for the latest available versions of new (not installed) packages. - Only native packages
- Checking the box on a multilib system causes PackageKit to omit listing results for packages compiled for the architecture that runs in compatibility mode. For example, enabling this filter on a 64-bit system with an AMD64 CPU would cause all packages built for the 32-bit x86 CPU architecture not to be shown in the list of results, even though those packages are able to run on an AMD64 machine. Packages which are architecture-agnostic (i.e. noarch packages such as
crontabs-1.10-32.1.el6.noarch.rpm) are never filtered out by checking . This filter has no affect on non-multilib systems, such as x86 machines.
2.2.3. Installing and Removing Packages (and Dependencies)
With the two filters selected, and , search for the htop
interactive process viewer and highlight the package. You now have
access to some very useful information about it, including: a clickable
link to the project homepage; the Yum
package group it is found in, if any; the license of the package; a
pointer to the GNOME menu location from where the application can be
opened, if applicable ( → → in our case); and the size of the package, which is relevant when we download and install it.
Viewing and installing a package with PackageKit's Add/Remove Software window
Figure 2.7. Viewing and installing a package with PackageKit's Add/Remove Software window
When the checkbox next to a package or group is checked, then that
item is already installed on the system. Checking an unchecked box
causes it to be marked for installation, which only occurs when the
button is clicked. In this way, you can search for and select multiple
packages or package groups before performing the actual installation
transactions. Additionally, you can remove installed packages by
unchecking the checked box, and the removal will occur along with any
pending installations when is pressed. Dependency resolution
, which may add additional packages to be installed or removed, is performed after pressing . PackageKit will then display a window listing those additional packages to install or remove, and ask for confirmation to proceed.
Check htop and click the button. You will then be prompted for the superuser password; enter it, and PackageKit will install htop. One nice feature of PackageKit
is that, following installation, it sometimes presents you with a list
of your newly-installed applications and offer you the choice of running
them immediately. Alternatively, you will remember that finding a
package and selecting it in the Add/Remove Software window shows you the Location of where in the GNOME menus its application shortcut is located, which is helpful when you want to run it.
Once it is installed, you can run
htop, an colorful and enhanced version of the top process viewer, by opening a shell prompt and entering:
~]$ htop
Viewing processes with htop!
htop is nifty, but we decide that
top is good enough for us and we want to uninstall it. Remembering that we need to change the filter we recently used to install it to in → , we search for htop
again and uncheck it. The program did not install any dependencies of
its own; if it had, those would be automatically removed as well, as
long as they were not also dependencies of any other packages still
installed on our system.
Warning: Removing a Package when Other Packages Depend On It
Although PackageKit
automatically resolves dependencies during package installation and
removal, it is unable to remove a package without also removing packages
which depend on it. This type of operation can only be performed by RPM,
is not advised, and can potentially leave your system in a
non-functioning state or cause applications to misbehave and/or crash.
removing the htop package with packagekit's add/remove software window
Figure 2.8. Removing a package with PackageKit's Add/Remove Software window
2.2.4. Installing and Removing Package Groups
PackageKit also has the ability to install Yum package groups, which it calls Package collections. Clicking on Package collections in the top-left list of categories in the Software Updates
window allows us to scroll through and find the package group we want
to install. In this case, we want to install Czech language support (the
Czech Support group). Checking the box and clicking informs us how many additional packages must be installed in order to fulfill the dependencies of the package group.
using PackageKit to install czech language support with PackageKit's add/remove software window
Figure 2.9. Installing the Czech Support package group
Similarly, installed package groups can be uninstalled by selecting Package collections, unchecking the appropriate checkbox, and applying.
2.2.5. Viewing the Transaction Log
PackageKit maintains a log of the transactions
that it performs. To view the log, from the Add/Remove Software window, click → , or run the
gpk-log command at the shell prompt.
The Software Log Viewer shows the Action, such as
Updated System or Installed Packages, the Date on which that action was performed, the Username of the user who performed the action, and the front end Application the user used (such as Update Icon, or kpackagekit). The Details column provides the types of the transactions, such as Updated, Installed or Removed, as well as the list of packages the transactions were performed on.
viewing the log of package management transactions with packagekit's loftware log viewer window
Figure 2.10. Viewing the log of package management transactions with the Software Log Viewer
Typing the name of a package in the top text entry field filters the
list of transactions to those which affected that package.
2.3. PackageKit Architecture
Red Hat provides the PackageKit
suite of applications for viewing, updating, installing and
uninstalling packages and package groups compatible with your system.
Architecturally, PackageKit consists of several graphical front ends that communicate with the
packagekitd daemon back end, which communicates with a package manager-specific back end that utilizes Yum to perform the actual transactions, such as installing and removing packages, etc.
Table 2.1, “PackageKit GUI Windows, Menu Locations, and Shell Prompt Commands” shows the name of the GUI window, how to start the window from the GNOME desktop or from the Add/Remove Software window, and the name of the command line application that opens that window.
Table 2.1. PackageKit GUI Windows, Menu Locations, and Shell Prompt Commands
| Window Title | Function | How to Open | Shell Command |
|---|---|---|---|
| Add/Remove Software | Install, remove or view package info |
From the GNOME panel: → →
| gpk-application |
| Software Update | Perform package updates |
From the GNOME panel: → →
| gpk-update-viewer |
| Software Sources | Enable and disable Yum repositories |
From Add/Remove Software: →
| gpk-repo |
| Software Log Viewer | View the transaction log |
From Add/Remove Software: →
| gpk-log |
| Software Update Preferences | Set PackageKit preferences | gpk-prefs | |
| (Notification Area Alert) | Alerts you when updates are available |
From the GNOME panel: → → , Startup Programs tab
| gpk-update-icon |
The
packagekitd daemon runs outside the user session and communicates with the various graphical front ends. The packagekitd daemon[2] communicates via the DBus system message bus with another back end, which utilizes Yum's Python API to perform queries and make changes to the sytem. On Linux systems other than Red Hat and Fedora, packagekitd
can communicate with other back ends that are able to utilize the
native package manager for that system. This modular architecture
provides the abstraction necessary for the graphical interfaces to work
with many different package managers to perform essentially the same
types of package management tasks. Learning how to use the PackageKit
front ends means that you can use the same familiar graphical interface
across many different Linux distributions, even when they utilize a
native package manager other than Yum.
In addition, PackageKit's
separation of concerns provides reliability in that a crash of one of
the GUI windows—or even the user's X Window session—will not affect any
package management tasks being supervised by the
packagekitd daemon, which runs outside of the user session.
All of the front end graphical applications discussed in this chapter are provided by the
gnome-packagekit package instead of by PackageKit and its dependencies. Users working in a KDE environment may prefer to install the kpackagekit package, which provides a KDE interface for PackageKit.
Finally, PackageKit also comes with a console-based frontend called
pkcon.
2.4. Additional Resources
- PackageKit home page — http://www.packagekit.org/index.html
- Information about and mailing lists for PackageKit.
- PackageKit FAQ — http://www.packagekit.org/pk-faq.html
- An informative list of Frequently Asked Questions for the PackageKit software suite.
- PackageKit Feature Matrix — http://www.packagekit.org/pk-matrix.html
- Cross-reference PackageKit-provided features with the long list of package manager back ends.
[2]
System daemons are typically long-running processes that provide
services to the user or to other programs, and which are started, often
at boot time, by special initialization scripts (often shortened to init scripts). Daemons respond to the service command and can be turned on or off permanently by using the chkconfig on or chkconfig offcommands. They can typically be recognized by a “d ” appended to their name, such as the packagekitd daemon. Refer to Chapter 7, Controlling Access to Services for information about system services.
Chapter 3. RPM
The RPM Package Manager (RPM) is an open packaging system
, which runs on Red Hat Enterprise Linux as well as other Linux and
UNIX systems. Red Hat, Inc. and the Fedora Project encourage other
vendors to use RPM for their own products. RPM is distributed under the
terms of the GPL (GNU General Public License).
The RPM Package Manager only works with packages built to work with the RPM format. RPM is itself provided as a pre-installed rpm
package. For the end user, RPM makes system updates easy. Installing,
uninstalling and upgrading RPM packages can be accomplished with short
commands. RPM maintains a database of installed packages and their
files, so you can invoke powerful queries and verifications on your
system.
The RPM package format has been improved for Red Hat Enterprise Linux
6. RPM packages are now compressed using the XZ lossless data
compression format, which has the benefit of greater compression and
less CPU usage during decompression, and support multiple strong hash
algorithms, such as SHA-256, for package signing and verification.
Use Yum Instead of RPM Whenever Possible
For most package management tasks, the Yum package manager offers equal and often greater capabilities and utility than RPM
. Yum also
performs and tracks complicated system dependency resolution, and will
complain and force system integrity checks if you use RPM as well to
install and remove packages. For these reasons, it is highly recommended
that you use Yum instead of RPM whenever possible to perform package management tasks. Refer to Chapter 1, Yum.
If you prefer a graphical interface, you can use the PackageKit GUI application, which uses Yum as its back end, to manage your system's packages. Refer to Chapter 2, PackageKit for details.
Important
When installing a package, ensure it is compatible with your
operating system and processor architecture. This can usually be
determined by checking the package name. Many of the following examples
show RPM packages compiled for the AMD64/Intel 64 computer
architectures; thus, the RPM file name ends in
x86_64.rpm.
During upgrades, RPM handles configuration files carefully, so that
you never lose your customizations—something that you cannot accomplish
with regular
.tar.gz files.
For the developer, RPM allows you to take software source code and package it into source and binary packages for end users.
This process is quite simple and is driven from a single file and
optional patches that you create. This clear delineation between pristine
sources and your patches along with build instructions eases the
maintenance of the package as new versions of the software are released.
Note
Because RPM makes changes to your system, you must be logged in as root to install, remove, or upgrade an RPM package.
3.1. RPM Design Goals
To understand how to use RPM, it can be helpful to understand the design goals of RPM:
- Upgradability
- With RPM, you can upgrade individual components of your system without completely reinstalling. When you get a new release of an operating system based on RPM, such as Red Hat Enterprise Linux, you do not need to reinstall a fresh copy of the operating system your machine (as you might need to with operating systems based on other packaging systems). RPM allows intelligent, fully-automated, in-place upgrades of your system. In addition, configuration files in packages are preserved across upgrades, so you do not lose your customizations. There are no special upgrade files needed to upgrade a package because the same RPM file is used to both install and upgrade the package on your system.
- Powerful Querying
- RPM is designed to provide powerful querying options. You can perform searches on your entire database for packages or even just certain files. You can also easily find out what package a file belongs to and from where the package came. The files an RPM package contains are in a compressed archive, with a custom binary header containing useful information about the package and its contents, allowing you to query individual packages quickly and easily.
- System Verification
- Another powerful RPM feature is the ability to verify packages. If you are worried that you deleted an important file for some package, you can verify the package. You are then notified of anomalies, if any—at which point you can reinstall the package, if necessary. Any configuration files that you modified are preserved during reinstallation.
- Pristine Sources
- A crucial design goal was to allow the use of pristine software sources, as distributed by the original authors of the software. With RPM, you have the pristine sources along with any patches that were used, plus complete build instructions. This is an important advantage for several reasons. For instance, if a new version of a program is released, you do not necessarily have to start from scratch to get it to compile. You can look at the patch to see what you might need to do. All the compiled-in defaults, and all of the changes that were made to get the software to build properly, are easily visible using this technique.The goal of keeping sources pristine may seem important only for developers, but it results in higher quality software for end users, too.
3.2. Using RPM
RPM has five basic modes of operation
(not counting package building): installing, uninstalling,
upgrading, querying, and verifying. This section contains an overview of
each mode. For complete details and options, try
rpm --help or man rpm. You can also refer to Section 3.5, “Additional Resources” for more information on RPM.
3.2.1. Finding RPM Packages
Before using any RPM packages, you must know where to find them. An
Internet search returns many RPM repositories, but if you are looking
for Red Hat RPM packages, they can be found at the following locations:
- The initial RPM repositories provided with the YUM package manager . Refer to Chapter 1, Yum for details on how to use the official Red Hat Enterprise Linux package repositories.
- The Extra Packages for Enterprise Linux (EPEL) is a community effort to provide high-quality add-on packages for Red Hat Enterprise Linux . Refer to http://fedoraproject.org/wiki/EPEL for details on EPEL RPM packages.
- Unofficial, third-party repositories not ahffiliated Red Hat also provide RPM packages.
Important
When considering third-party repositories for use with your Red Hat Enterprise Linux system, pay close attention to the repository's web site with regard to package compatibility before adding the repository as a package source. Alternate package repositories may offer different, incompatible versions of the same software, including packages already included in the Red Hat Enterprise Linux repositories. - The Red Hat Errata Page, available at http://www.redhat.com/apps/support/errata/
3.2.2. Installing and Upgrading
RPM packages typically have file names
like
tree-1.5.3-2.el6.x86_64.rpm. The file name includes the package name (tree), version (1.5.3), release (2), operating system major version (el6) and CPU architecture (x86_64).
You can use
rpm's -U option to:
- upgrade an existing but older package on the system to a newer version, or
- install the package even if an older version is not already installed.
That is,
rpm -U <rpm_file> is able to perform the function of either upgrading or installing as is appropriate for the package.
Assuming the
tree-1.5.3-2.el6.x86_64.rpm
package is in the current directory, log in as root and type the
following command at a shell prompt to either upgrade or install the tree package as determined by rpm:
rpm -Uvh tree-1.5.3-2.el6.x86_64.rpmUse -Uvh for nicely-formatted RPM installs
The
-v and -h options (which are combined with -U) cause rpm to print more verbose output and display a progress meter using hash signs.
If the upgrade/installation is successful, the following output is displayed:
Preparing... ########################################### [100%] 1:tree ########################################### [100%]
Always use the -i (install) option to install new kernel packages!
rpm provides two different options for installing packages: the aforementioned -U option (which historically stands for upgrade), and the -i option, historically standing for install. Because the -U option subsumes both install and upgrade functions, we recommend to use rpm -Uvh with all packages except kernel packages.
You should always use the
-i option to simply install a new kernel package instead of upgrading it. This is because using the -U
option to upgrade a kernel package removes the previous (older) kernel
package, which could render the system unable to boot if there is a
problem with the new kernel. Therefore, use the rpm -i <kernel_package> command to install a new kernel without replacing any older kernel packages. For more information on installing kernel packages, refer to Chapter 23, Manually Upgrading the Kernel.
The signature of a package is checked automatically when installing
or upgrading a package. The signature confirms that the package was
signed by an authorized party. For example, if the verification of the
signature fails, an error message such as the following is displayed:
error: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: BAD, key ID d22e77f2
If it is a new, header-only, signature, an error message such as the following is displayed:
error: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: BAD, key ID d22e77f2
If you do not have the appropriate key installed to verify the signature, the message contains the word
NOKEY:
warning: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA1 signature: NOKEY, key ID 57bbccba
Refer to Section 3.3, “Checking a Package's Signature” for more information on checking a package's signature.
3.2.2.1. Package Already Installed
Preparing... ########################################### [100%] package tree-1.5.3-2.el6.x86_64 is already installed
However, if you want to install the package anyway, you can use the
--replacepkgs option, which tells RPM to ignore the error:
rpm -Uvh --replacepkgs tree-1.5.3-2.el6.x86_64.rpm
This option is helpful if files installed from the RPM were deleted
or if you want the original configuration files from the RPM to be
installed.
3.2.2.2. Conflicting Files
If you attempt to install a package that contains a file which has already been installed by another package
, the following is displayed:
Preparing... ################################################## file /usr/bin/foobar from install of foo-1.0-1.el6.x86_64 conflicts with file from package bar-3.1.1.el6.x86_64
To make RPM ignore this error, use the
--replacefiles option:
rpm -Uvh --replacefiles foo-1.0-1.el6.x86_64.rpm3.2.2.3. Unresolved Dependency
RPM packages may sometimes depend on other packages
, which means that they require other packages to be installed to
run properly. If you try to install a package which has an unresolved
dependency, output similar to the following is displayed:
error: Failed dependencies: bar.so.3()(64bit) is needed by foo-1.0-1.el6.x86_64
If you are installing a package from the Red Hat Enterprise Linux
installation media, such as from a CD-ROM or DVD, the dependencies may
be available. Find the suggested package(s) on the Red Hat Enterprise
Linux installation media or on one of the active Red Hat Enterprise
Linux mirrors and add it to the command:
rpm -Uvh foo-1.0-1.el6.x86_64.rpm bar-3.1.1.el6.x86_64.rpm
If installation of both packages is successful, output similar to the following is displayed:
Preparing... ########################################### [100%] 1:foo ########################################### [ 50%] 2:bar ########################################### [100%]
You can try the
--whatprovides option to determine which package contains the required file.
rpm -q --whatprovides "bar.so.3"
If the package that contains
bar.so.3 is in the RPM database, the name of the package is displayed:
bar-3.1.1.el6.i586.rpm
Warning: Forcing Package Installation
Although we can force
rpm to install a package that gives us a Failed dependencies error (using the --nodeps option), this is not recommended, and will usually result in the installed package failing to run. Installing or removing packages with rpm --nodeps
can cause applications to misbehave and/or crash, and can cause serious
package management problems or, possibly, system failure. For these
reasons, it is best to heed such warnings; the package manager—whether RPM, Yum or PackageKit—shows us these warnings and suggests possible fixes because accounting for dependencies is critical. The Yum
package manager can perform dependency resolution and fetch
dependencies from online repositories, making it safer, easier and
smarter than forcing rpm to carry out actions without regard to resolving dependencies.
3.2.3. Configuration File Changes
Because RPM performs intelligent upgrading of packages with configuration files
, you may see one or the other of the following messages:
saving /etc/foo.conf as /etc/foo.conf.rpmsave
This message means that changes you made to the configuration file may not be forward-compatible
with the new configuration file in the package, so RPM saved your
original file and installed a new one. You should investigate the
differences between the two configuration files and resolve them as soon
as possible, to ensure that your system continues to function properly.
Alternatively, RPM may save the package's new configuration file as, for example,
foo.conf.rpmnew,
and leave the configuration file you modified untouched. You should
still resolve any conflicts between your modified configuration file and
the new one, usually by merging changes from the old one to the new one
with a diff program.
If you attempt to upgrade to a package with an older version number (that is, if a higher version of the package is already installed), the output is similar to the following:
package foo-2.0-1.el6.x86_64.rpm (which is newer than foo-1.0-1) is already installed
To force RPM to upgrade anyway, use the
--oldpackage option:
rpm -Uvh --oldpackage foo-1.0-1.el6.x86_64.rpm3.2.4. Uninstalling
Uninstalling a package is just as simple as installing one. Type the following command at a shell prompt:
rpm -e foo
Note
Notice that we used the package name
foo, not the name of the original package file, foo-1.0-1.el6.x86_64. If you attempt to uninstall a package using the rpm -e command and the original full file name, you will receive a package name error.
You can encounter dependency errors when uninstalling a package if
another installed package depends on the one you are trying to remove.
For example:
rpm -e ghostscript
error: Failed dependencies:
libgs.so.8()(64bit) is needed by (installed) libspectre-0.2.2-3.el6.x86_64
libgs.so.8()(64bit) is needed by (installed) foomatic-4.0.3-1.el6.x86_64
libijs-0.35.so()(64bit) is needed by (installed) gutenprint-5.2.4-5.el6.x86_64
ghostscript is needed by (installed) printer-filters-1.1-4.el6.noarch
Similar to how we searched for a shared object library (i.e. a
<library_name>.so.<number> ~]# rpm -q --whatprovides "libgs.so.8()(64bit)"
ghostscript-8.70-1.el6.x86_64Warning: Forcing Package Installation
Although we can force
rpm to remove a package that gives us a Failed dependencies error (using the --nodeps option), this is not recommended, and may cause harm to other installed applications. Installing or removing packages with rpm --nodeps
can cause applications to misbehave and/or crash, and can cause serious
package management problems or, possibly, system failure. For these
reasons, it is best to heed such warnings; the package manager—whether RPM, Yum or PackageKit—shows us these warnings and suggests possible fixes because accounting for dependencies is critical. The Yum
package manager can perform dependency resolution and fetch
dependencies from online repositories, making it safer, easier and
smarter than forcing rpm to carry out actions without regard to resolving dependencies.
3.2.5. Freshening
Freshening is similar to upgrading, except that only existent
packages are upgraded. Type the following command at a shell prompt:
rpm -Fvh foo-2.0-1.el6.x86_64.rpm
RPM's freshen option checks the versions of the packages specified
on the command line against the versions of packages that have already
been installed on your system. When a newer version of an
already-installed package is processed by RPM's freshen option, it is
upgraded to the newer version. However, RPM's freshen option does not
install a package if no previously-installed package of the same name
exists. This differs from RPM's upgrade option, as an upgrade does install packages whether or not an older version of the package was already installed.
Freshening works for single packages or package groups. If you have
just downloaded a large number of different packages, and you only want
to upgrade those packages that are already installed on your system,
freshening does the job. Thus, you do not have to delete any unwanted
packages from the group that you downloaded before using RPM.
In this case, issue the following with the
*.rpm glob:
rpm -Fvh *.rpm
RPM then automatically upgrades only those packages that are already installed.
3.2.6. Querying
The RPM database stores information about all RPM packages installed in your system. It is stored in the directory
/var/lib/rpm/,
and is used to query what packages are installed, what versions each
package is, and to calculate any changes to any files in the package
since installation, among other use cases.
To query this database, use the
-q option. The rpm -q package name command displays the package name, version, and release number of the installed package <package_name>. For example, using rpm -q tree to query installed package tree might generate the following output:
tree-1.5.2.2-4.el6.x86_64
You can also use the following Package Selection Options (which is a subheading in the RPM man page: see
man rpm for details) to further refine or qualify your query:
-a— queries all currently installed packages.-f— queries the RPM database for which package owns<file_name><file_name>rpm -qfinstead of/bin/lsrpm -qf ls).-p— queries the uninstalled package<package_file><package_file>
There are a number of ways to specify what information to display
about queried packages. The following options are used to select the
type of information for which you are searching. These are called the Package Query Options.
-idisplays package information including name, description, release, size, build date, install date, vendor, and other miscellaneous information.-ldisplays the list of files that the package contains.-sdisplays the state of all the files in the package.-ddisplays a list of files marked as documentation (man pages, info pages, READMEs, etc.) in the package.-cdisplays a list of files marked as configuration files. These are the files you edit after installation to adapt and customize the package to your system (for example,sendmail.cf,passwd,inittab, etc.).
For options that display lists of files, add
-v to the command to display the lists in a familiar ls -l format.
3.2.7. Verifying
Verifying a package compares information about files installed from a
package with the same information from the original package. Among
other things, verifying compares the file size, MD5 sum, permissions,
type, owner, and group of each file.
The command
rpm -V verifies a package. You can use any of the Verify Options listed for querying to specify the packages you wish to verify. A simple use of verifying is rpm -V tree, which verifies that all the files in the tree package are as they were when they were originally installed. For example:
- To verify a package containing a particular file:
rpm -Vf /usr/bin/treeIn this example,/usr/bin/treeis the absolute path to the file used to query a package. - To verify ALL installed packages throughout the system (which will take some time):
rpm -Va - To verify an installed package against an RPM package file:
rpm -Vp tree-1.5.3-2.el6.x86_64.rpmThis command can be useful if you suspect that your RPM database is corrupt.
If everything verified properly, there is no output. If there are
any discrepancies, they are displayed. The format of the output is a
string of eight characters (a "
c"
denotes a configuration file) and then the file name. Each of the eight
characters denotes the result of a comparison of one attribute of the
file to the value of that attribute recorded in the RPM database. A
single period (.) means the test passed. The following characters denote specific discrepancies:
5— MD5 checksumS— file sizeL— symbolic linkT— file modification timeD— deviceU— userG— groupM— mode (includes permissions and file type)?— unreadable file (file permission errors, for example)
If you see any output, use your best judgment to determine if you
should remove the package, reinstall it, or fix the problem in another
way.
3.3. Checking a Package's Signature
If you wish to verify that a package has not been corrupted or
tampered with, examine only the md5sum by typing the following command
at a shell prompt (where
<rpm_file> is the file name of the RPM package):
rpm -K --nosignature <rpm_file>
The message
<rpm_file>: rsa sha1 (md5) pgp md5 OK-K with -Kvv in the command.
On the other hand, how trustworthy is the developer who created the package? If the package is signed with the developer's GnuPG key, you know that the developer really is who they say they are.
An RPM package can be signed using Gnu Privacy Guard (or GnuPG), to help you make certain your downloaded package is trustworthy.
GnuPG is a tool for secure communication; it is a complete and free
replacement for the encryption technology of PGP, an electronic privacy
program. With GnuPG, you can authenticate the validity of documents and
encrypt/decrypt data to and from other recipients. GnuPG is capable of
decrypting and verifying PGP 5.
x files as well.
During installation, GnuPG is installed by default. That way you can
immediately start using GnuPG to verify any packages that you receive
from Red Hat. Before doing so, you must first import Red Hat's public
key.
3.3.1. Importing Keys
To verify Red Hat packages, you must import the Red Hat GPG key. To do so, execute the following command at a shell prompt:
rpm --import /usr/share/rhn/RPM-GPG-KEY
To display a list of all keys installed for RPM verification, execute the command:
rpm -qa gpg-pubkey*
For the Red Hat key, the output includes:
gpg-pubkey-db42a60e-37ea5438
To display details about a specific key, use
rpm -qi followed by the output from the previous command:
rpm -qi gpg-pubkey-db42a60e-37ea54383.3.2. Verifying Signature of Packages
To check the GnuPG signature of an RPM file after importing the builder's GnuPG key, use the following command (replace
<rpm-file> with the filename of the RPM package):
rpm -K <rpm-file>
If all goes well, the following message is displayed:
md5 gpg OK.
This means that the signature of the package has been verified, that it
is not corrupt, and therefore is safe to install and use.
3.4. Practical and Common Examples of RPM Usage
RPM is a useful tool for both managing your system and diagnosing and
fixing problems. The best way to make sense of all its options is to
look at some examples.
- Perhaps you have deleted some files by accident, but you are not sure what you deleted. To verify your entire system and see what might be missing, you could try the following command:
rpm -VaIf some files are missing or appear to have been corrupted, you should probably either re-install the package or uninstall and then re-install the package. - At some point, you might see a file that you do not recognize. To find out which package owns it, enter:
rpm -qf /usr/bin/ghostscriptThe output would look like the following:ghostscript-8.70-1.el6.x86_64
- We can combine the above two examples in the following scenario. Say you are having problems with
/usr/bin/paste. You would like to verify the package that owns that program, but you do not know which package ownspaste. Enter the following command,rpm -Vf /usr/bin/pasteand the appropriate package is verified. - Do you want to find out more information about a particular program? You can try the following command to locate the documentation which came with the package that owns that program:
rpm -qdf /usr/bin/freeThe output would be similar to the following:/usr/share/doc/procps-3.2.8/BUGS /usr/share/doc/procps-3.2.8/FAQ /usr/share/doc/procps-3.2.8/NEWS /usr/share/doc/procps-3.2.8/TODO /usr/share/man/man1/free.1.gz /usr/share/man/man1/pgrep.1.gz /usr/share/man/man1/pkill.1.gz /usr/share/man/man1/pmap.1.gz /usr/share/man/man1/ps.1.gz /usr/share/man/man1/pwdx.1.gz /usr/share/man/man1/skill.1.gz /usr/share/man/man1/slabtop.1.gz /usr/share/man/man1/snice.1.gz /usr/share/man/man1/tload.1.gz /usr/share/man/man1/top.1.gz /usr/share/man/man1/uptime.1.gz /usr/share/man/man1/w.1.gz /usr/share/man/man1/watch.1.gz /usr/share/man/man5/sysctl.conf.5.gz /usr/share/man/man8/sysctl.8.gz /usr/share/man/man8/vmstat.8.gz
- You may find a new RPM, but you do not know what it does. To find information about it, use the following command:
rpm -qip crontabs-1.10-32.1.el6.noarch.rpmThe output would be similar to the following:Name : crontabs Relocations: (not relocatable) Version : 1.10 Vendor: Red Hat, Inc. Release : 32.1.el6 Build Date: Thu 03 Dec 2009 02:17:44 AM CET Install Date: (not installed) Build Host: js20-bc1-11.build.redhat.com Group : System Environment/Base Source RPM: crontabs-1.10-32.1.el6.src.rpm Size : 2486 License: Public Domain and GPLv2 Signature : RSA/8, Wed 24 Feb 2010 08:46:13 PM CET, Key ID 938a80caf21541eb Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Summary : Root crontab files used to schedule the execution of programs Description : The crontabs package contains root crontab files and directories. You will need to install cron daemon to run the jobs from the crontabs. The cron daemon such as cronie or fcron checks the crontab files to see when particular commands are scheduled to be executed. If commands are scheduled, it executes them. Crontabs handles a basic system function, so it should be installed on your system.
- Perhaps you now want to see what files the
crontabsRPM package installs. You would enter the following:rpm -qlp crontabs-1.10-32.1.el6.noarch.rpmThe output is similar to the following:/etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /etc/crontab /usr/bin/run-parts /usr/share/man/man4/crontabs.4.gz
These are just a few examples. As you use RPM, you may find more uses for it.
3.5. Additional Resources
RPM is an extremely complex utility with many options and methods for
querying, installing, upgrading, and removing packages. Refer to the
following resources to learn more about RPM.
3.5.1. Installed Documentation
rpm --help— This command displays a quick reference of RPM parameters.man rpm— The RPM man page gives more detail about RPM parameters than therpm --helpcommand.
3.5.2. Useful Websites
- The RPM website — http://www.rpm.org/
- The RPM mailing list can be subscribed to, and its archives read from, here — https://lists.rpm.org/mailman/listinfo/rpm-list
