rpm

Document Sample
rpm Powered By Docstoc
					                                   [Red Hat Package Manager Notes]



                                                                     CPIT School of Computing

                          Diploma in Information and Communication Technologies

                      Red Hat Package Manager Notes
Contents
RPM: Installing and Removing Software ................................................. 2
  Introducing RPM ..................................................................... 2
  The RPM database .................................................................... 2
  Package Files ....................................................................... 2
  The rpm Executable .................................................................. 3
  Installing RPM packages: rpm -i packagefilename ...................................... 3
  Removing Packages: rpm -e packagename................................................ 4
  Referring to Package Files by URL ................................................... 5
  Using rpm to Update RPMS ............................................................ 5
  Updating Packages: rpm -U packagefilename ............................................ 5
  Freshening Packages: rpm -F packagefilename .......................................... 6
  Updating RPMS and Configuration Files................................................ 6
  "Updating" (Installing) Versioned Packages ........................................... 6
  Updating Kernels .................................................................... 7
RPM Queries and Verification .......................................................... 8
  RPM Queries: rpm -q ................................................................. 8
  Querying RPM Prerequisites: --requires and --provides ................................ 8
  Querying RPM Scripts: --scripts ..................................................... 9
  Listing RPM Packages by Timestamp: --last........................................... 10
  Package Verification: rpm -V packagename............................................ 10
Misc RPM Utilities ................................................................... 11
  RPM Package File Signatures ........................................................ 11
  Obtaining the Red Hat Public Key ................................................... 11
  Registering a Public Key with RPM: --import ......................................... 11
  Manually Checking a Package's Signature: --checksig ................................. 12
  Converting an RPM Package Into a cpio Stream ........................................ 12
  RPM Warts: database locking ........................................................ 13
  Red Hat Network .................................................................... 13
  Source RPMs ........................................................................ 14
  Installing Source RPMS ............................................................. 14
Yellowdog Updater Modified (YUM) ..................................................... 16
  The Dependency Problem ............................................................. 16
  Introducing yum .................................................................... 16
  yum Subcommands .................................................................... 17
  Configuring yum .................................................................... 19
  YUM Repository Configuration Directives ............................................. 19
  Simplifying Updates with yum update ................................................ 20
  YUM Examples ....................................................................... 20




                                            Page 1 of 22
                                              [Red Hat Package Manager Notes]




RPM: Installing and Removing Software

Key Concepts

      The Red Hat Package Manager (RPM) consists of three components: (1) the RPM database, (2) package
       files, and (3) the rpm command.
      The RPM database is found in the /var/lib/rpm/ directory.
      RPM package files are essentially archives which contain files to be installed and RPM header
       information.
      Conventional package file naming includes a package name, a version, a release number, and an
       architecture.
      RPM package files can be installed with rpm -i.
      RPM packages are removed with rpm -e
      RPM packages can are updated with either rpm -U or rpm -F.
      The rpm command can reference package files using FTP or HTTP Url’s.

Introducing RPM
Red Hat distributes software using the Red Hat Package Manager (more commonly known as RPM). With
RPM, administrators can easily install, upgrade, remove, and manage software.
When people speak of RPM, they are generally referring to the following three components collectively.
      The RPM database
      RPM Package Files
      The rpm Executable
We will look at each of these components in turn.

The RPM database
Every Red Hat Enterprise Linux system maintains a database of currently installed software, which resides in
the /var/lib/rpm/ directory. Examining the directory's contents with the file command, we discover that the
directory contains almost exclusively binary hashed database files.
[root@station root]# file /var/lib/rpm/*
/var/lib/rpm/Basenames:      Berkeley DB   (Hash, version 8, native byte-order)
/var/lib/rpm/Conflictname:   Berkeley DB   (Hash, version 8, native byte-order)
/var/lib/rpm/Dirnames:       Berkeley DB   (Btree, version 9, native byte-order)
/var/lib/rpm/Filemd5s:       Berkeley DB   (Hash, version 8, native byte-order)
/var/lib/rpm/Group:          Berkeley DB   (Hash, version 8, native byte-order)
/var/lib/rpm/Installtid:     Berkeley DB   (Btree, version 9, native byte-order)
/var/lib/rpm/Name:           Berkeley DB   (Hash, version 8, native byte-order)
/var/lib/rpm/Packages:       Berkeley DB   (Hash, version 8, native byte-order)
...

There are no "user serviceable parts" in the directory. Other than knowing that every Red Hat Enterprise Linux
machine has one, and that the database can take up a significant amount of disk space (on the order of 50
Megabytes), an administrator should not need to meddle with the database directly.

Package Files
Red Hat distributes software using package files. If you are new to package files, you can think of them as
similar to tar archives: they contain files to be installed on a system. But package files contain more. They also
contain an RPM header, which provides information about the packages, such as it's name, it's installed size,
and a short text description of its contents. More importantly, package file headers contain dependency
information about what other packages, executables, or libraries must be installed on a system for the package
to be useful.




                                                       Page 2 of 22
                                                               [Red Hat Package Manager Notes]
When examining Red Hat Enterprise Linux 5 media, either on a CD, or on a network mirror, package files for
the base distribution reside in the toplevel Server directory. After inserting and mounting a Red Hat Enterprise
Linux 5 CD-ROM, for example, one could find the following.
[root@station ~]# ls /mnt/cdrom/Server/
a2ps-4.13b-57.1.el5.i386.rpm
acl-2.2.39-1.1.i386.rpm
acpid-1.0.4-5.i386.rpm
adaptx-0.9.13-3jpp.1.i386.rpm
...

Of course, there are many package files.
[root@station ~]$ ls /var/ftp/pub/os/rhel5/Server | wc –l
2115
A package file name is structured with the following pieces of information.
name-version-release.architecture.rpm
In the following table, we discuss the naming of the amanda-2.4.4p1-0.3E.i386.rpm package file, and the
meaning of each of these components.
Table 1. Dissecting the Package File Name amanda-2.4.4p1-0.3E.i386.rpm
Component Example                                                                           Comments

Package
             amanda     The name of the package. When the package file is installed on a machine, this name will be the database entry which identifies the package.
Name

                     The open-source version of the product. The vast majority of software Red Hat distributes, Red Hat employees did not write. Instead, the
Version      2.4.4p1 software was written and is maintained by members of the open source community. Red Hat believes in preserving ties to the open source
                     product on which Red Hat products are based, and respects the open source community's version number for a given product.

                        While Red Hat often starts with a product maintained by the open source community, Red Hat does modify open source software.
                        Sometimes our modifications are minor, such as rearranging where files are installed. Sometimes the changes are more significant. If Red
Release
             0.3E       Hat engineers believe that a certain feature should be added to a product, but cannot convince the open source community to include them,
Number
                        they will include them in the Red Hat version. Any modifications made by Red Hat are made public, and are free for anyone in the open
                        source community to incorporate. Modifications to a given version of an open source product are tracked by the release number.

                        The architecture specifies for which type of CPU the software was built. Architectures supported by Red Hat Enterprise Linux include i386,
                        ia64, s390, and others. Some package files use the the architecture label noarch, which implies the package does not contain compiled
                        binaries, but architecture independent files such as scripts, images, or data files.
Architecture i386       Additionally, Red Hat distributes source RPM's, which are package files that do not contain compiled ("ready to use") binary applications,
                        but the source code from which the applications were compiled. Source RPM's are identified with a src "architecture". Most users have no
                        need to use source RPM's, but they are provided for the innovators and the curious. With a small exception found in a later Lesson, this
                        course deals exclusively with binary RPM's.


The rpm Executable
The rpm executable is an administrator's front end to the RPM database. The executable can perform an variety
of different function, distinguished by one of the following leading command line switches.
Table 1. Uses of the rpm Command
          Invocation                                Use

rpm -i, rpm -U, rpm -F Install or upgrade software from package files.

rpm -e                         Remove packages.

rpm -q                         Query the RPM database.

rpm -V                         Verify an installed package.

rpm --checksig                 Verify the integrity of a RPM package file.

The remainder of this Lesson discusses installing and removing packages files. The next two Lessons focus on
performing RPM queries and other miscellaneous RPM related topics.

Installing RPM packages: rpm -i packagefilename
Software is installed using the rpm -i command. As an example, an administrator wants to install publishing
software on a Red Hat Enterprise Linux machine, and chooses to explore TeTeX. From within a RPMS directory,
he first lists all packages with tetex in their names.
                                                                             Page 3 of 22
                                             [Red Hat Package Manager Notes]
[root@station Server]# ls *tetex*
tetex-afm-3.0-32.fc6.i386.rpm    tetex-latex-3.0-32.fc6.i386.rpm
tetex-doc-3.0-32.fc6.i386.rpm    tetex-xdvi-3.0-32.fc6.i386.rpm
tetex-dvips-3.0-32.fc6.i386.rpm

He next attempts to install the tetex-dvips-3.0-32.fc6.i386.rpm package file with rpm -i. When rpm
attempts to install a package, it will make several checks, including the following.
           Is there enough unused space in the filesystem?
           Is the RPM package dependent on another package, and if so, is the other package already installed?
           Will installing the package overwrite ("clobber") any existing files on the filesystem?
If any of these conditions are not satisfied, rpm will refuse to install the package.
[root@station Server]# rpm -ihv tetex-dvips-3.0-32.fc6.i386.rpm
warning: tetex-dvips-3.0-32.fc6.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
error: Failed dependencies:
        tetex-fonts = 3.0 is needed by tetex-dvips-3.0-32.fc6.i386

From the first warning line, he finds that RPM could not verify the integrity of the package file, because no
"key" was available. More on this in a later lesson. For now, we'll safely ignore these warnings.
More problematically, this package has dependencies. In order for the software contained in the tetex-dvips
package to be useful, the tetex-fonts package has to be installed. Our administrator now attempts to resolve the
dependency by installing the package file tetex-fonts-3.0-32.fc6.i386.rpm. This time, he includes the -h
and -v command line switches, which decorate the output with names and hash marks.
[root@station Server]# rpm -ihv tetex-fonts-3.0-32.fc6.i386.rpm
warning: tetex-fonts-3.0-32.fc6.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...                ########################################### [100%]
   1:tetex-fonts            ########################################### [100%]

This time, the package happily installed. Using the up arrow twice to quickly recover his previous line, he tries
again to install the tetex-dvips-3.0-32.fc6.i386.rpm package file.
[root@station Server]# rpm -i tetex-dvips-3.0-32.fc6.i386.rpm
warning: tetex-dvips-3.0-32.fc6.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186

Now that the dependency is satisfied, the tetex-dvips package installs. Because the -h and -v switches were not
specified, the package installed silently (with the exception of the NOKEY warning, which we have already
decided to ignore).
Once a package has been installed, the files contained in the package file are installed on the system, and the
package file is no longer needed (just as the box that a new television came in is not needed once the television
is set up).
The following table specifies command line switches that are sometimes used with the rpm -i command.
Table 1. Command Line Switches Used with rpm -i
         Switch                                                         Effect

-h, --hash           Print hash marks while installing.

-v, --verbose        Print "verbose" output. One -v prints the package name. Multiple -v's provide more detailed output.

--nodeps             Install even if prerequisites are missing.

--replace-files Install even if files will be overwritten

--force              Install even if the package is already installed

--test               Don't perform any actions, just print the output.

--noscripts          Don't perform any scripts associated with the RPM installation.

More options are available. Consult the rpm(8) man page for a complete list.

Removing Packages: rpm -e packagename
Once a package has been installed, the package file is irrelevant, and the package is now a database entry on the
local machine. Therefore, the package is no longer referred to using the package file name (such as tetex-
dvips-3.0-32.fc6.i386.rpm), but instead by just the package name (such as tetex-dvips).

                                                                                 Page 4 of 22
                                                                [Red Hat Package Manager Notes]
Packages are removed using rpm -e packagename, where -e stands for "erase".
Our administrator now attempts to remove the packages he installed in the previous section.
[root@station Server]# rpm -e tetex-fonts-3.0-32.fc6.i386.rpm
error: package tetex-fonts-3.0-32.fc6.i386.rpm is not installed

Realizing he fell into a common trap, he tries again, remembering to refer to the package by packagename,
instead of packagefilename.
[root@station Server]# rpm -e tetex-fonts
error: Failed dependencies:
        tetex-fonts = 3.0 is needed by (installed) tetex-dvips-3.0-32.fc6.i386

Again, our administrator has encountered dependency problems. Because the package tetex-dvips depends on
tetex-fonts, tetex-fonts cannot be removed while tetex-dvips is still installed. By reversing the order, the
packages can be removed.
[root@station root]# rpm -e tetex-dvips
[root@station root]# rpm -e tetex

The following table specifies command line switches that are sometimes used with the rpm -e command.
Table 1. Command Line Switches Used with rpm -e
  Switch                                 Effect

--nodeps Remove the package, even if dependent packages are installed.

--test      Don't perform any actions, just print the output.

Again, the rpm(8) man page provides a complete list of options.

Referring to Package Files by URL
When using the rpm executable, package files can be specified using a HTTP or FTP URL. The rpm command
will automatically download the specified package file, and treat the file as if it were specified locally.
When specifying a file using a HTTP protocol URL, as in the following, the typing can get tedious, as all of the
version and release number details must be specified (and there is no TAB completion to help).
[root@station ~]# rpm -ihv http://rha-server/pub/os/rhel5/Server/gnome-keyring-manager-2.16.0-3.el5.i386.rpm
Retrieving http://rha-server/pub/os/rhel5/Server/gnome-keyring-manager-2.16.0-3.el5.i386.rpm
warning: /var/tmp/rpm-xfer.ImYuXG: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...                ########################################### [100%]
   1:gnome-keyring-manager ########################################### [100%]

When using a FTP protocol URL, however, file globbing can be used to match files, and the glob will be
resolved on the FTP server. (Officially, the glob should be quoted, but bash allows users to get sloppy.)
[root@station ~]# rpm -ihv ftp://rha-server/pub/os/rhel5/Server/gnome-keyring-manager-*.rpm
Retrieving ftp://rha-server/pub/os/rhel5/Server/gnome-keyring-manager-2.16.0-3.el5.i386.rpm
warning: /var/tmp/rpm-xfer.puloX3: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...                ########################################### [100%]
   1:gnome-keyring-manager ########################################### [100%]


Using rpm to Update RPMS
Arguable the best advantage of using RPM to manage software is the ease with which RPM handles updates.

Updating Packages: rpm -U packagefilename
In the following, an administrator has downloaded an errata RPM for the gaim package from Red Hat Network.
He first observes his current package version, and compares the version to the downloaded package file.
[root@station ~]# rpm -q tar
tar-1.15.1-23.el5
[root@station ~]# ls *.rpm
tar-1.15.1-23.0.1.el5.i386.rpm

He naively attempts to install the more recent version of tar.
[root@station ~]# rpm -i tar-1.15.1-23.0.1.el5.i386.rpm
warning: tar-1.15.1-23.0.1.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
        file /bin/tar from install of tar-1.15.1-23.0.1.el5 conflicts with file from package tar-1.15.1-23.el5




                                                                         Page 5 of 22
                                              [Red Hat Package Manager Notes]
While RPM, in theory, allows multiple versions of an RPM to be installed simultaneously, the two versions of
the RPM must not contain the same files. Precious few RPM packages are designed that way (the kernel
package being a notable exception). Therefore, attempting to update a package with rpm -i usually fails.
The appropriate command is rpm -U, where "-U" stands for "Update". When updating, any previous version is
completely removed, and the new version is completely installed. (There is no such thing as a "patch" in RPM.
An updated package always stands alone, without need of the previous package).
[root@station ~]# rpm -U tar-1.15.1-23.0.1.el5.i386.rpm
warning: tar-1.15.1-23.0.1.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...                ########################################### [100%]
   1:tar                    ########################################### [100%]
[root@station ~]# rpm -q tar
tar-1.15.1-23.0.1.el5

With that single command, the tar package has been completely updated. RPM package updating can be
qualified with the same command line switches as package installation.

Freshening Packages: rpm -F packagefilename
As a slight variation on updating, a system can be "freshened" with the rpm -F packagefilename command.
The only difference between updating (with rpm -U) and freshening (with rpm -F) occurs when no version of
the specified package is already installed on the system. When updating, the specified package file is installed
anyway. When freshening, the specified package file is ignored.
Freshening is designed to work with collections of errata. For example, and administrator could download and
collect errata published from Red Hat on a server directory which could be accessed with the URL
ftp://server/pub/errata. Then, occasionally, an administrator could freshen another machine on the local
network using a command like the following.
[root@station root]# rpm -Fvh ftp://server/pub/errata/*.rpm

The packages in the errata directory which are relevant to the local machine would be updated, but those which
are not relevant would be ignored.

Updating RPMS and Configuration Files
When performing an RPM update, rpm replaces files from the older version with files from the newer version.
The exception is configuration files, which are handled specially.
The fate of a configuration file is complicated, and depends on the state of the configuration file in the original
RPM package, the newer RPM package, and as it exists on the filesystem. Depending on these factors, one of
the following actions will occur.
      If the file has not been edited, rpm assumes the "default" configuration is appropriate, and silently
       replaces the old (unedited) file with the new.
      If the file has been edited, but the configuration files do not differ in the two RPM packages, rpm
       assumes syntax has not changed, and leaves the edited configuration file in place. A copy of the new
       configuration file is installed, with the extension .rpmnew.
      If the file has been edited, and the configuration files differ in the two RPM packages, rpm assumes the
       configuration file syntax has changed between the two versions. The edited configuration file is moved
       aside with the .rpmsave extension, and the new (default) configuration file is installed. It is the
       administrator's responsibility to migrate the old configuration back in place manually.
For the latter two actions, rpm will announce the fate of the configuration file on standard out. When
performing a "mass update", it's a good idea to save standard out for later observation. In no case, however, will
rpm remove an edited configuration file from the filesystem entirely.

"Updating" (Installing) Versioned Packages
We saw above that, when attempting to install a newer version of a package that has already been installed,
rpm complains that a file from the newer package conflicts with a file from the already installed package. But
what if there aren't any conflicting files? Certain packages, notably the kernel, are designed so that for every
file, either the filename or a directory name contains the package version. Since installing a new version of the
package won't clobber any files, rpm is willing to have multiple copies of the package installed.

                                                       Page 6 of 22
                                             [Red Hat Package Manager Notes]
[root@station ~]# rpm -q kernel
kernel-2.6.18-8.el5
[root@station ~]# rpm -ihv kernel-2.6.18-8.1.1.el5.i686.rpm
Preparing...                ########################################### [100%]
   1:kernel                 ########################################### [100%]

How does a query report the presence of multiple versions of the same package?
[root@station ~]# rpm -q kernel
kernel-2.6.18-8.el5
kernel-2.6.18-8.1.1.el5

What happens if you ask to remove the package?
[root@station ~]# rpm -e kernel
error: "kernel" specifies multiple packages

The solution is to specify the version (as well as the package) you intend to remove.
[root@station ~]# rpm -e kernel-2.6.18-8.1.1.el5

In theory, any package for which every file is versioned can be treated this way. In practice, in Red Hat
Enterprise Linux, only the kernel package (and its variants) are designed this way.

Updating Kernels
The technique for updating kernels differs from that for other packages, and follows directly from our previous
discussion. Namely, when you've obtained an updated kernel package file, install the updated kernel, do not
update it. The reasons follow.
      Though unlikely, something can go wrong with the installation of your new kernel. If you do not have
       your original kernel, you are left with an unbootable machine.
      If you updated the kernel package, the first action would be to remove the current kernel package,
       leaving you in the uncomfortable position of running a kernel which could no longer load any modules.
Once you have rebooted your machine to the new kernel, and are satisfied that all works properly, you can
safely remove the old kernel package.




                                                    Page 7 of 22
                                                                [Red Hat Package Manager Notes]
RPM Queries and Verification

Key Concepts

            RPM package prerequisites can be queried using rpm -q --requires.
            The RPM prerequisites which a RPM package can fulfill can be queried using rpm -q --provides.
            RPM packages may contain scripts which are executed when the package is installed or removed. These
             scripts can be observed using rpm -q --scripts.
            A sorted list of packages and the time when they were installed can be generated using rpm -qa --last.
            Installed RPM packages can be verified using rpm -V, which reports files which have been modified
             since they have been installed.

RPM Queries: rpm -q
In the RHA030 course, the topic of querying the RPM database and querying RPM package files for
information was discussed in detail. As a quick review, every query is composed of two questions: what
packages do you want to query, and what information about them do you want to see?
The following two tables provide a quick review of the various command line switches which are used to
specify these two aspects of a query, as they were presented in RHA030.
Table 1. RPM Query Options for Specifying Packages
            Option                                                                        Specification
-a                         all installed packages
package-name               the package package-name
-f filename                the package that owns the file filename
-p package-file-           query the package file package-file-name directly. This option is fundamentally different, as all other options query the RPM
name                       database of installed packages.

Table 2. RPM Query Options for Specifying Information
      Option                         Specification
(default)            package name and version
-i                   package information header
-l                   list of files owned by the package
--queryformat str list information specified in format string str

In this Lesson, we extend our discussion with some advanced aspects of RPM package design and RPM
queries, focusing on RPM prerequisites and RPM scripts.

Querying RPM Prerequisites: --requires and --provides
RPM package prerequisites can be examined directly with the --requires and --provides command line
switches.
Examining the requirements of the samba package directly, we see that requirements can fall into one of several
broad categories.
[root@station root]# rpm -q --requires samba
/bin/mktemp
/bin/sh
...
/etc/pam.d/system-auth
/sbin/chkconfig
...
libacl.so.1
libacl.so.1(ACL_1.0)
libattr.so.1
libattr.so.1(ATTR_1.0)
libc.so.6
libc.so.6(GLIBC_2.0)
...
logrotate >= 0:3.4
pam >= 0:0.64
perl(Exporter)
rtld(GNU_HASH)
samba-common = 0:3.0.23c-2
sed

                                                                           Page 8 of 22
                                                       [Red Hat Package Manager Notes]
Table 1. Types of RPM Package Requirements
         Type               Example                                                             Comments
                  /bin/sh,                   The list of specific files is usually automatically generated, as can be deduced from the often repeated file
Specific Files
                  /etc/pam.d/system-auth     names.
                                             The ldd command can be used to examine what dynamic libraries must exist on a system in order to run a
Dynamic Libraries libacl.so.1, libc.so.6     specific command (try, for example, ldd /bin/ls). When creating an RPM package, the list of all required
                                             libraries is included as a prerequisite.
                                             When packaging an RPM, a developer should explicitly list all RPM package dependencies. Packages may
                  sed, samba-common =        either be tightly bound with another package, requiring a specific version (as is here the case for samba-
Other Packages
                  3.0.2, pam >= 0.64         common), or loosely bound to another package, requiring only some version greater than a listed version (as is
                                             here the case for the pam package).
                                             Some RPM packages require that a package that provides some abstract functionality be installed, such as a
Abstract
                                             web client. Other packages, such as mozilla or elinks, should specify that they provide that functionality. This
Functional        webclient
                                             type of requirement is listed by very few packages in Red Hat Enterprise Linux, and is not here used by the
Requirements
                                             samba package.

Similarly, the --provides command line switch can be used to list what a package explicitly provides.
[root@server1 ~]# rpm -q --provides firefox
webclient
...
libxpistub.so
gecko-libs = 1.8.0.9
firefox = 1.5.0.9-10.el5


Querying RPM Scripts: --scripts
When packaging an RPM package, developers can specify that shell scripts should execute as a side effect of
installing or removing a package. RPM scripts fall into one of the following four classes.
           Pre-install Scripts
           Post-install Scripts
           Pre-uninstall Scripts
           Post-uninstall Scripts
The scripts (or "scriptlets", as they are sometimes called) can be examined with the with the --scripts query
switch. Consider the following scripts which are associated with the httpd web server package.
[root@server1 root]# rpm -q httpd –scripts


preinstall scriptlet (using /bin/sh):
# 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


preuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ]; then
        /sbin/service httpd stop > /dev/null 2>&1
        /sbin/chkconfig --del httpd
fi


          In the pre-install script, the user apache is added to the system. The httpd daemon runs as the user
          apache, and many of the files installed by the httpd package are have their user owner set appropriately.

          In the post-install script, the runlevel specific links are initialized for the httpd service script.


          In the pre-uninstall script, just before the package is removed, any running httpd daemon is stopped, and
          the runlevel specific symbolic links for the httpd service script are removed.




                                                                  Page 9 of 22
                                              [Red Hat Package Manager Notes]
Listing RPM Packages by Timestamp: --last
As a special type of query, --last can be used to order RPM packages by when they were installed on the
system. The command is useful when searching for recent changes that might have occurred to a system.
[root@station ~]# rpm -qa --last | head -5
tar-1.15.1-23.0.1.el5                           Fri   15   Jun   2007   09:52:47   AM   EDT
gnome-keyring-manager-2.16.0-3.el5              Fri   15   Jun   2007   09:46:38   AM   EDT
net-snmp-utils-5.3.1-14.el5                     Wed   13   Jun   2007   12:32:37   PM   EDT
strace-4.5.15-1.el5                             Wed   13   Jun   2007   10:09:55   AM   EDT
openvpn-2.1-0.17.rc2.el5.1                      Wed   13   Jun   2007   06:29:04   AM   EDT


Package Verification: rpm -V packagename
The previous sections in this Lesson have all introduced variations on RPM queries. In this section, we
introduce a new topic: RPM package verification.
Obviously, the a system's RPM database stores every file which is associated with an installed package. In
addition to the name of the file, however, many of a file's attributes are stored as well, such as the file's user and
group owners, the files mode (permissions), the files length, and an MD5 fingerprint of the file's contents.
At any point after a package has been installed, a the -V switch can be used to "verify" the package. Every file
owned by a package will be compared against the attributes stored in the RPM database which were entered
when the package was installed, and any deviations will be reported.
In the following example, an administrator confirms that all of the files owned by the bash package are
unchanged, while for two of the files owned by the pam package, the files' size, MD5 fingerprint, and modify
time have changed since the package was installed (i.e, the files have been somehow modified).
[root@server1 root]# rpm -V bash
[root@server1 root]# rpm -V pam
[root@station ~]# rpm -V pam
....L... c /etc/pam.d/system-auth
S.5....T. c /etc/security/limits.conf

The following table summarizes the more common flags which are reported by rpm package verification.
Table 1. RPM Verification Flags
Flag Associated Attribute
S    Size
M    Mode (permissions)
5    MD5 sum
L    symbolic Link status
U    User owner
G    Group owner
T    Modify time
C    SELinux Context

A complete listing can be found in the VERIFY section of the rpm(8) man page.
RPM verification is commonly used in two scenarios. The first is debugging. The package worked when I
installed it, but doesn't work now. What have I changed? The second scenario is security. Periodically, all
packaged can be verified with the rpm -Va command. If the files /usr/bin/passwd or /usr/sbin/sshd have
been modified, you can suspect trouble.




                                                       Page 10 of 22
                                             [Red Hat Package Manager Notes]
Misc RPM Utilities

Key Concepts

      All Red Hat Enterprise Linux package files are cryptographically signed by Red Hat, Inc.
      The GPG public key which is used to confirm package integrity is distributed from the www.redhat.com
       website, in the root directory of every Red Hat Enterprise Linux CD-ROM, and in the file
       /usr/share/rhn/RPM-GPG-KEY.
      GPG public keys may be imported into the RPM database using rpm --import.
      RPM package file integrity can be confirmed using rpm --checksig.
      RPM package files can be converted into a cpio stream using rpm2cpio.
      Red Hat Enterprise Linux systems can be registered with Red Hat network using the rhn_register
       command.
      Red Hat Enterprise Linux systems registered with Red Hat Network may use the yum command to
       download and install RPM packages.
      Source RPM package files contain the source code from which binary RPM packages are built. They
       may be installed using rpm -i.

RPM Package File Signatures

In our first Lesson, upon installing a package file, rpm issued several warnings concerning a signature, which
we chose to ignore. We now focus our attention on the signature warnings. To refresh our memories, here is the
warning which occurred as the tetex-dvips RPM package was installed.

[root@station RPMS]# rpm -i tetex-dvips-1.0.7-66.i386.rpm
warning: tetex-dvips-1.0.7-66.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e


Red Hat cryptographically signs every RPM package file which it distributes with a GPG (Gnu Privacy Guard)
private key. By cryptographically verifying the signature, users can ensure that a RPM package file that has
been downloaded from the Internet has not been modified since the package file was signed by Red Hat. The
rpm command automatically attempts to verify a signature upon installation. In order to perform the signature
verification, however, the complementary GPG public key must be obtained. The warning occurred because the
package cannot be verified, as the necessary public key (key ID db42a60e) is not available.

Obtaining the Red Hat Public Key

Because the security of the signature verification depends on the integrity of the public key, Red Hat distributes
the public key a variety of ways. The Red Hat GPG public key can be found in any of the following locations.

      From the www.redhat.com web site.
      From the root directory of any Red Hat CD-ROM, in a file named RPM-GPG-KEY.
      In the Red Hat Enterprise Linux distribution, as the file /usr/share/rhn/RPM-GPG-KEY.

Registering a Public Key with RPM: --import

Once a public key has been obtained, the key can be registered with a system's RPM database using rpm --
import keyfile. In the following, the public key is installed from the root directory of a mounted Red Hat
Enterprise Linux CD-ROM.

[root@station root]# rpm --import /mnt/cdrom/RPM-GPG-KEY

Multiple keys may be imported. A list of public keys registered with a system's RPM database can be obtained
by listing all packages which start gpg-pubkey.
[root@station root]# rpm -qa | grep gpg-pubkey
gpg-pubkey-db42a60e-37ea5438

                                                      Page 11 of 22
                                             [Red Hat Package Manager Notes]
The details of a particular public key can be obtained by performing a -i query.

[root@station root]# rpm -q gpg-pubkey-db42a60e-37ea5438 -i
Name        : gpg-pubkey                   Relocations: (not relocateable)
Version     : db42a60e                          Vendor: (none)
Release     : 37ea5438                      Build Date: Mon 05 Jan 2004 02:00:13 PM EST
Install Date: Mon 05 Jan 2004 02:00:13 PM EST      Build Host: localhost
Group       : Public Keys                   Source RPM: (none)
Size        : 0                                License: pubkey
Signature   : (none)
Summary     : gpg(Red Hat, Inc <security@redhat.com>)
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.2.1 (beecrypt-3.0.0)

mQGiBDfqVDgRBADBKr3Bl6PO8BQ0H8sJoD6p9U7Yyl7pjtZqioviPwXP+DCWd4u8HQzcxAZ5
7m8ssA1LK1Fx93coJhDzM130+p5BG9mYSWShLabR3N1KXdXQYYcowTOMGxdwYRGr1Spw8Qyd
...


Manually Checking a Package's Signature: --checksig

A package's digital signature can be manually confirmed with rpm --checksig packagefilename.

[root@station root]# rpm --checksig /mnt/cdrom/RedHat/RPMS/pxe-0.1-36.i386.rpm
/mnt/cdrom/RedHat/RPMS/pxe-0.1-36.i386.rpm: (sha1) dsa sha1 md5 gpg OK

As the output implies, several internal checksums and the GPG signature were all "OK".

Converting an RPM Package Into a cpio Stream

When first introducing RPM package files, we stated that an RPM package can be thought of as a tar archive.
While the concept is correct, the protocol is wrong. In reality, RPM package files are formatted using a similar
archiving command called cpio. While the tar archive command focuses on argument lists of file names, the
cpio command focuses on "streams" of filenames flowing from standard in or standard out.

A RPM package file can be converted to a cpio stream using the rpm2cpio command. While knowledge of
cpio is required to fully appreciate the implications, a cursory look at the cpio(1) man page and the following
examples will demonstrate that rpm2cpio allows individual files to be extracted from an RPM package file,
without installing the package.

In the following, the vsftpd package file is converted into a cpio stream which is the piped to the cpio
command. The cpio command then lists every file in the cpio stream.

[root@station root]# rpm2cpio /mnt/cdrom/RedHat/RPMS/vsftpd-2.0.5-10.el5.i386.rpm    |
 cpio --extract --list
361 blocks
./etc/logrotate.d/vsftpd.log
./etc/pam.d/vsftpd
./etc/rc.d/init.d/vsftpd
./etc/vsftpd
...


With some rearrangement of the cpio command, individual files from the RPM package can be extracted into
the local filesystem. In the following example, the file ./etc/vsftpusers is created in the local directory,
creating any necessary directories along the way.

[root@station root]# rpm2cpio /mnt/cdrom/RedHat/RPMS/vsftpd-2.0.5-10.el5.i386.rpm    |
 cpio --extract --make-directories ./etc/vsftpd.ftpusers
361 blocks
[root@station root]# head -5 ./etc/vsftpd.ftpusers
# Users that are not allowed to login via ftp
root
bin
daemon
adm




                                                      Page 12 of 22
                                              [Red Hat Package Manager Notes]
While the details of the cpio command are beyond the scope of this course, administrators are still able to easily
benefit from a package file's close relationship to a cpio archive. Try examining the contents of a package file
directly with cat, and you are rewarded with the binary mess that you would expect. (Recall the reset command
will reset a terminal, if necessary.)

What happens if a package file is browsed with less? The less pager doesn't display the actual binary contents
of the file, but instead silently extracts the package file as a cpio archive, and displays the packages header,
changelog, and a detailed list of files!

RPM Warts: database locking

Often, databases are designed to allow only one pending transaction at a time, where access to the database is
granted by acquiring a database lock. The lock can only be held by one process at a time. The RPM database is
no exception.

In older versions of RPM, RPM database locking was coarse grained: only one instance of the rpm executable
could access the database at a time. If someone was installing a RPM package file, no one could perform a
query until the installation was complete. While database integrity was ensured, users were often frustrated
because of the delay.

At some point, rpm adopted more fine grained database locking. Processes need to acquire a lock for only the
portion of the database they are modifying, not the database as a whole. The fine grained locking strategy
means that locks are not held as long. The downside? Fine grained locking is more complicated to design.

With the initial conversion to fine grained locking, the rpm database locking mechanism occasionally became
stuck, usually as a result of a previously canceled rpm command. The symptom is an rpm command (such as
rpm -qa) which simply hangs (trying to acquire a lock it will never get). Any other rpm commands which are
started after that point hang as well. Although Red Hat Enterprise Linux 5 is much better, sometimes the
problem does reappear.

Fortunately, the solution is fairly simple, though obscure.

   1. Kill all currently running (or more to the point, hanging) rpm processes, with a command such as
       killall -9 rpm
   2. Remove all of the files which begin __db from the RPM database directory (/var/lib/rpm/).

You will have to have root access to the machine to perform the last step (and possibly the first step as well). If
root access is not available, a user can simply reboot the machine. In the Red Hat Enterprise Linux
/etc/rc.d/rc.sysinit startup script, the following subtle line is found without comment.

rm -f /var/lib/rpm/__db*

As a result, any "stuck" locks will be cleaned up every time the system reboots.

Red Hat Network

Red Hat distributes software primarily through Red Hat Network, which can be found at http://rhn.redhat.com.
When you purchase a Red Hat Network entitlement, you gain access to the web application. Through an active
Red Hat Network account, you can perform the following actions.

      Download ISO images of the Red Hat Enterprise Linux distribution media.
      Download errata published after a particular Red Hat Enterprise Linux release.
      Manage a machine's (or group of machine's) software configuration remotely through the web interface.



                                                       Page 13 of 22
                                            [Red Hat Package Manager Notes]
Once a system has been installed with Red Hat Enterprise Linux, it can register with a Red Hat Network
account using the rhn_register command. Once registered, the yum command (discussed in a following
lesson) can be used to automatically download and install errata and otherwise uninstalled packages from Red
Hat Network.

Source RPMs

Our Workbook on RPM has focused almost entirely on binary RPM packages, which are the only type of
package files that concern most users. This section provides a quick introduction to source RPM's.

Source RPMs are usually found on separate CD-ROM's within a Red Hat Enterprise Linux distribution. Just as
binary RPM's are traditionally located with the RedHat/RPMS/ directory, source RPMs are usually found within
a SRPMS/ directory, which is usually a sibling of the RedHat/ directory.

[root@station root]# ls /mnt/cdrom/SRPMS/
ant-1.5.2-23.src.rpm
apmd-3.0.2-18.src.rpm
ash-0.3.8-16.src.rpm
aspell-de-0.1.1-17.src.rpm
aspell-es-0.2-13.src.rpm
aspell-it-0.1-16.src.rpm
...


Installing Source RPMS

Like binary RPM packages, source RPMs are installed using the rpm -i command. However, there are
important differences when installing a source RPM package.

      In order to install a source RPM, the rpm-build binary RPM must be installed. This package provide the
       /usr/src/redhat/ directory, among other things.
      Source RPM's are not databased. When a source RPM is installed, files are added to the filesystem, but
       no dependency check is made, and the RPM database is not modified.
      Source RPMs are installed entirely into the /usr/src/redhat/SOURCES/ and
       /usr/src/redhat/SPECS/ directories.

What's in a Source RPM

Source RPMs generally contain the following three items.

      A copy of the "pristine source" of an open source project, distributed as a compressed tar archive.
      A collection of "patch files" which define changes which Red Hat has made to the Open Source
       Projects.
      A "spec file", which provides a recipe for how to extract the pristine source, apply the patches to modify
       the source code, compile the executables, and then collect the newly compiled products into a binary
       RPM package file.

In the following example, the source RPM for the less package is installed.

[root@station root]# rpm -ihv /mnt/cdrom/SRPMS/less-378-11.src.rpm
   1:less                   ########################################### [100%]
[root@station root]# ls /usr/src/redhat/SOURCES/
less-378+iso247-20030108.diff less-378-ncursesw.patch less.csh
less-378-ko.patch              less-378-rh1.patch       lesspipe.sh
less-378-multibyte.patch       less-378.tar.gz          less.sh
[root@station root]# ls /usr/src/redhat/SPECS/
less.spec


Exploring a source RPM provides a glimpse into the often hidden second half of the design behind RPM. Not
only is RPM a system for distributing software, it is also a system for building open source projects.


                                                     Page 14 of 22
                                            [Red Hat Package Manager Notes]
While compiling open source software is well beyond the scope of the current course, running the command
rpmbuild -ba specfile will allow you to watch an automated build in action.

[root@station root]# rpmbuild -ba /usr/src/redhat/SPECS/less.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.51951
+ umask 022
+ cd /usr/src/redhat/BUILD
+ LANG=C
+ export LANG
...


If the build completed successfully, the compiled products should be found in the /usr/src/redhat/BUILD
directory, and the resulting binary RPM package file in a subdirectory of /usr/src/redhat/RPMS.




                                                     Page 15 of 22
                                             [Red Hat Package Manager Notes]
Yellowdog Updater Modified (YUM)
The Dependency Problem
Previous lessons have demonstrated RPM's ability to easily install, remove, and update software on a Red Hat
Enterprise Linux system. There was only one wrinkle: dependencies.
Suppose, upon attempting to install the fictional package foo-1.0-123.i386.rpm, RPM complains "this
package depends on libfoo.so.3.1". You've never heard of libfoo.so.3.1, and have no idea where to find it. Even
if you did, you might not appreciate the extra time spent fetching it and installing it, only to find that
libfoo.so.3.1 in turn depends on libbaz.so.2.2.
Automating the solution to the dependency problem is not easy, and requires access to a metadirectory of
available RPM packages. Intentionally, the rpm command does not attempt to solve the dependency problem
directly. Rather, rpm behaves as the low level, non-interactive, atomic "get it (the software) on, get it off"
utility. The dependency problem is left to a higher level utility: yum.

Introducing yum
The yum command, coupled with a remote Yum repository, simplifies adding and updating software on a Red
Hat Enterprise Linux system.
A yum repository is a collection of RPMS and associated metadata about how the RPM packages relate to one
another, published via either the HTTP or FTP protocol. Most users will not need to create their own
repositories, but instead simply subscribe to well known, network or Internet accessible repositories.
Figure 1. A YUM Repository and YUM client




Usually, repositories are defined by client-side configuration files located in the /etc/yum.repos.d/ directory,
conventionally ending with the .repo filename extension. Repository definitions begin with a unique repository
id in square brackets, followed by, at a minimum, a name and baseurl definition.
[root@station ~]# cat /etc/yum.repos.d/minimal.repo
[rha-rhel]
name=Red Hat Academy RHEL local distribution
baseurl=ftp://rha-server/pub/os/rhel5/Server

Once configured with a repository, the yum client can easily list all available packages. The list begins with
packages which are already installed, followed by packages which are available from configured YUM
repositories.
[root@station ~]# yum list
This system is not registered with RHN.
RHN support will be disabled.
Loading "installonlyn" plugin
Loading "rhnplugin" plugin
Setting up repositories
Reading repository metadata in from local files
Installed Packages
Deployment_Guide-en-US.noarch            5.0.0-19                      installed
GConf2.i386                              2.14.0-9.el5                  installed
ImageMagick.i386                         6.2.8.0-3.el5.4               installed
...
Available Packages
Deployment_Guide-as-IN.noarch            5.0.0-19                      rha-rhel
Deployment_Guide-bn-IN.noarch            5.0.0-19                      rha-rhel

                                                      Page 16 of 22
                                                [Red Hat Package Manager Notes]
Deployment_Guide-de-DE.noarch               5.0.0-19                      rha-rhel
...

If a particular package is of interest, yum can easily download and install the package.
[root@station ~]# yum install tetex-dvips
Loading "installonlyn" plugin
...
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for tetex-dvips to pack into transaction set.
tetex-dvips-3.0-32.fc6.i3 100% |=========================| 73 kB     00:00
---> Package tetex-dvips.i386 0:3.0-32.fc6 set to be updated
--> Running transaction check
--> Processing Dependency: tetex-fonts = 3.0 for package: tetex-dvips
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for tetex-fonts to pack into transaction set.
tetex-fonts-3.0-32.fc6.i3 100% |=========================| 760 kB    00:00
---> Package tetex-fonts.i386 0:3.0-32.fc6 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 tetex-dvips             i386       3.0-32.fc6       rha-rhel          585 k
Installing for dependencies:
 tetex-fonts             i386       3.0-32.fc6       rha-rhel           29 M

Transaction Summary
=============================================================================
Install      2 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 30 M
Is this ok [y/N]:

Notice that yum is not only installing the requested package, tetex-dvips, but also the uninstalled dependencies,
in this case tetex-fonts. With a confirmation, yum proceeds with the install.
Downloading Packages:
(1/2): tetex-dvips-3.0-32 100% |=========================| 585 kB             00:00
(2/2): tetex-fonts-3.0-32 100% |=========================| 29 MB              00:01
Running Transaction Test
warning: tetex-dvips-3.0-32.fc6: Header V3 DSA signature: NOKEY, key          ID 37017186
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: tetex-fonts                  #########################          [1/2]
  Installing: tetex-dvips                  #########################          [2/2]

Installed: tetex-dvips.i386 0:3.0-32.fc6
Dependency Installed: tetex-fonts.i386 0:3.0-32.fc6
Complete!

We've seen the essence of yum. Given a network accessible YUM repository, the yum client makes it trivial to
download and install software on a client system. The following sections merely flush out the details.

yum Subcommands
The yum command is only useful if invoked with a subcommand argument. Common subcommands are listed
below.
Table 1. Common yum Subcommands
Command                                Purpose
install   Install new software
remove    Remove already installed packages, resolving dependencies.
list      List all installed and available packages.
info      Provide summary of specified (installed or uninstalled) package.
search    Search for arbitrary strings related to a package.

                                                        Page 17 of 22
                                                 [Red Hat Package Manager Notes]

Command                                Purpose
resolvdep Install whatever is needed to resolve a RPM dependency.

The use of the various subcommands is straightforward, as seen with the following scenarios.
In order to free up some disk space, an administrator would like to remove the tetex-fonts package. While the
rpm command would have the administrator track down dependencies, yum does the necessary work
automatically.
[root@station ~]# rpm -e tetex-fonts
error: Failed dependencies:
        tetex-fonts = 3.0 is needed by (installed) tetex-dvips-3.0-32.fc6.i386
[root@station ~]# yum remove tetex-fonts
Loading "installonlyn" plugin
Loading "rhnplugin" plugin
...
Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Removing:
 tetex-fonts             i386       3.0-32.fc6       installed          57 M
Removing for dependencies:
 tetex-dvips             i386       3.0-32.fc6       installed         1.7 M

Transaction Summary
=============================================================================
Install      0 Package(s)
Update       0 Package(s)
Remove       2 Package(s)

Is this ok [y/N]: y
...
Running Transaction
  Removing : tetex-dvips                    ######################### [1/2]
  Removing : tetex-fonts                    ######################### [2/2]

Removed: tetex-fonts.i386 0:3.0-32.fc6
Dependency Removed: tetex-dvips.i386 0:3.0-32.fc6
Complete!

In another situation, an administrator would like to know more about the uninstalled wvdial package. The yum
command downloads information about the package.
[root@station ~]# yum info wvdial
...
Available Packages
Name   : wvdial
Arch   : i386
Version: 1.54.0
Release: 5.2.2.1
Size   : 131 k
Repo   : rha-rhel
Summary: A heuristic autodialer for PPP connections.
Description:
WvDial automatically locates and configures modems and can log into
almost any ISP's server without special configuration. You need to
input the username, password, and phone number, and then WvDial will
negotiate the PPP connection using any mechanism needed.

In yet another example, an administrator would like to know about everything available which is related to the
DocBook XML document type definition.
[root@station ~]# yum search docbook
...
docbook-slides.noarch                    3.3.1-2.1.1            rha-rhel
Matched from:
docbook-slides
DocBook Slides document type and stylesheets
DocBook Slides provides customization layers of the both the
Simplified and the full DocBook XML DTD, as well as the DocBook XSL
Stylesheets. This package contains the XML document type definition
...

gnome-doc-utils.noarch                   0.8.0-2.fc6            rha-rhel
Matched from:
gnome-doc-utils is a collection of documentation utilities for the GNOME
project. Notably, it contains utilities for building documentation and
all auxiliary files in your source tree, and it contains the DocBook
XSLT stylesheets that were once distributed with Yelp.

                                                          Page 18 of 22
                                                   [Red Hat Package Manager Notes]
...

docbook-simple.noarch                    1.0-2.1.1                           installed
Matched from:
docbook-simple
Simplified DocBook is a small subset of the DocBook XML DTD.

Simplified DocBook is an attempt to provide a proper subset of DocBook
that is simultaneously smaller and still useful. Documents written in
...

Both installed and uninstalled packages are mentioned. The complete output includes information for about 20
package.

Configuring yum
Like most Unix commands, yum can be configured via the command line, configuration files, or environment
variables (in that order of precedence).
The following table mentions some common command line switches, and when appropriate, the complimentary
directive that can be used in the configuration file. More information can be found in the yum(8) man page.
Table 1. yum Command Line Switches
          Switch             Configuration Option
-y                          assume-yes                 Don't ask for manual confirmation.
                                                       Override the default configuration file. The location can be a
-c location
                                                       filename or URL.
--installroot=dirname       installroot                Install all packages relative to the specified dirname.
--enablerepo=repoglob                                  Enable all defined repositories which match repoglob.
--
                                                       Disable all defined repositories which match repoglob.
disablerepo=repoglob
--
                    exclude                            Exclude all packages which match packageglob.
exclude=packageglob

Additionally, the following table mentions options which are available from withing the /etc/yum.conf and
related configuration files. More special-purpose directives are documented in the yum.conf(5) man page.
Table 2. Global yum Configuration File Options
                Directive                                                            Purpose
proxy, proxy_username, and                 Application level proxy server configuration which should be used for FTP and
proxy_password                             HTTP requests.
                                           If enabled, refuse to install any packages which cannot be validated by an
gpgcheck
                                           installed GPG public key.

YUM Repository Configuration Directives
Individual repositories may be configured by placing the following directives in a repository definition stanza,
usually within a file in the /etc/yum.repos.d/ directory.
Table 1. YUM Repository Configuration Directives
Directive                                                          Purpose
name        Human readable name for the repository
baseurl     URL which hosts the YUM repository. Multiple URLs may be listed, but don't use multiple baseurl statements.
mirrorlist URL which reports list of mirrors, in lieu of a baseurl definition.
enabled Either 1 or 0. Often, it can be convenient to have a repository defined, but disabled by default.


                                                            Page 19 of 22
                                                 [Red Hat Package Manager Notes]

Directive                                                        Purpose
            Either 1 or 0. The repository specific configuration has the same effect as the global option of the same name,
gpgcheck
            and takes precedence.
gpgkey      The URL from which the GPG key used to verify packages can be downloaded.

Simplifying Updates with yum update
One of yum's greatest strengths has gone yet unmentioned. With the update subcommand, yum will poll
configured repositories, and automatically download and install any published updates, essentially "freshening"
the system.
In the following example, the tar package is updated and a new kernel package is installed, simply by running
yum update.
[root@station ~]# yum update
Loading "installonlyn" plugin
Loading "rhnplugin" plugin
...

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 kernel                  i686       2.6.18-8.1.1.el5 rha-rhel-updates    13 M
Updating:
 tar                     i386       2:1.15.1-23.0.1.el5 rha-rhel-updates 750 k

Transaction Summary
=============================================================================
Install      1 Package(s)
Update       1 Package(s)
Remove       0 Package(s)

Total download size: 14 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): kernel-2.6.18-8.1. 100% |=========================| 13 MB                   00:00
(2/2): tar-1.15.1-23.0.1. 100% |=========================| 750 kB                  00:00
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: kernel                       #########################               [1/3]
  Updating : tar                           #########################               [2/3]
  Cleanup   : tar                          #########################               [3/3]

Installed: kernel.i686 0:2.6.18-8.1.1.el5
Updated: tar.i386 2:1.15.1-23.0.1.el5
Complete!




YUM Examples

Binding to a YUM repository

An administrator has been told that his corporation has a local YUM repository published at
http://yum.widgets.com/pub/widgets/RPMS. He would like to configure his machine to make use of the
repository.

He creates the new file /etc/yum.repos.d/widgets.repo, with the following contents.

[root@station ~]# cat /etc/yum.repos.d/widgets.repo
[widgets]
name=Widgets internal repository
baseurl=http://yum.widgets.com/pub/widgets/RPMS
gpgcheck=0
enabled=1

                                                          Page 20 of 22
                                             [Red Hat Package Manager Notes]
Afterward, the packages from the widgets repository are available for installation.

[root@station ~]# yum list | grep widgets
This system is not registered with RHN.
RHN support will be disabled.
widgets-intranet-portal.noarch            5.0-1                                  widgets
widgets-apps.i386                         5.0-1                                  widgets
widgets-ide.i386                          5.0-2                                  widgets

Using the Extra Packages for Enterprise Linux (EPEL) repository

The Fedora foundation is now packaging popular (though officially unsupported) software for the Red Hat
Enterprise Linux distribution, through a project called Extra Packages for Enterprise Linux (EPEL). In order to
use EPEL, you must bind to the EPEL yum repository.

To discover it's location, start by "google-ing on" the text EPEL. You should easily discover the project's
homepage at http://fedoraproject.org/wiki/EPEL. Reading the How to use link, configuration is as trivial as
installing an RPM.

[root@station ~]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-
release-5-2.noarch.rpm
Retrieving http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm
warning: /var/tmp/rpm-xfer.Fi3mSh: Header V3 DSA signature: NOKEY, key ID 217521f6
Preparing...                ########################################### [100%]
   1:epel-release           ########################################### [100%]

What did the configuration provide? A YUM repository definition and a complementary public key for package
integrity checking.

[root@station ~]# rpm -ql epel-release
/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
/etc/yum.repos.d/epel-testing.repo
...

Obtaining a list of available packages is now as easy as a yum list...

[root@station ~]# yum list | grep epel
This system is not registered with RHN.
RHN support will be disabled.
epel-release.noarch                                  5-2                         installed
DMitry.i386                                          1.3a-2.el5                  epel
GeoIP.i386                                           1.4.3-1.el5                 epel
GeoIP-devel.i386                                     1.4.3-1.el5                 epel
Macaulay2.i386                                       0.9.95-4.el5                epel
OpenEXR.i386                                         1.4.0a-4.el5                epel
OpenEXR-devel.i386                                   1.4.0a-4.el5                epel
...

... and installing the gnucash financial management application is as easy as a yum install.

[root@rhastud ~]# yum install gnucash
Loading "installonlyn" plugin
Loading "rhnplugin" plugin
...
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for gnucash to pack into transaction set.
gnucash-2.2.1-2.el5.i386. 100% |=========================| 103 kB                      00:00
---> Package gnucash.i386 0:2.2.1-2.el5 set to be updated
--> Running transaction check
--> Processing Dependency: qbanking for package: gnucash
...

                                                      Page 21 of 22
                                   [Red Hat Package Manager Notes]
Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 gnucash                 i386       2.2.1-2.el5      epel              5.6 M
Installing for dependencies:
 aqbanking               i386       2.2.9-2.el5      epel              3.0 M
 gnucash-docs            noarch     2.2.0-1.el5      epel              9.4 M
...

Transaction Summary
=============================================================================
Install     14 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 23 M
Is this ok [y/N]: y
Downloading Packages:
(1/14): perl-Crypt-SSLeay 100% |=========================| 45 kB     00:00
(2/14): guile-1.8.0-8.200 100% |=========================| 1.4 MB    00:00
(3/14): gnucash-2.2.1-2.e 100% |=========================| 5.6 MB    00:51
...
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 217521f6
Importing GPG key 0x217521F6 "Fedora EPEL <epel@fedoraproject.org>"
Is this ok [y/N]: y
...
Transaction Test Succeeded
Running Transaction
  Installing: gwenhywfar                   ####################### [ 1/14]
  Installing: libofx                       ####################### [ 2/14]
...
Installed: gnucash.i386 0:2.2.1-2.el5
Dependency Installed: aqbanking.i386 0:2.2.9-2.el5 gnucash-docs.noarch ...
Complete!

How many packages are available?

[root@rhastud ~]# yum list 2>/dev/null | grep epel | wc -l
1094




                                            Page 22 of 22

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:49
posted:12/2/2011
language:English
pages:22