Section 6.2. Sample YUM Clients

6.2. Sample YUM Clients

This book is focused on Red Hat/Fedora, SUSE, and Debian. The only distribution from this list that natively supports yum is Fedora Linux. However, a variety of yum repositories is also available for Red Hat Enterprise Linux. And several of the Red Hat Enterprise Linux rebuild distributions use yum as their primary means for patch management.


Before adding a yum repository to your configuration files, make sure the cited URL exists. As you'll see in Chapter 7, yum repository URLs should include either a headers/ or repodata/ subdirectory, which includes the headers from all of the enclosed RPM packages.

6.2.1. Fedora

We examined how you can configure Fedora as a yum client briefly in Chapter 1, "Patch Management Systems." In this section, we'll examine the configuration process in more detail. There are two parts to this process. You've already configured your Fedora computer as a yum client. In this section, you'll direct Fedora's version of the Red Hat Update Agent to the same yum repositories.


Starting with Fedora Core 5, Red Hat has replaced the Update Agent with the Package Updater, also known as Pup. If you prefer the Update Agent, you can still install the up2date and up2date-gnome packages from the Fedora Core 5 repository. Unfortunately, I could not include Fedora Core 5 in this chapter, as the first test (beta) release was made available as this book was being sent to the printer.

Fedora's Red Hat Update Agent and yum

By default, Fedora's version of the Red Hat Update Agent is configured to use yum. The key configuration file associated with the Update Agent is the sources file in the /etc/sysconfig/rhn directory. For Fedora Core 3, default repositories were directly cited in this file. Starting with Fedora Core 4, the following command searches through repositories as specified in the /etc/yum.repos.d directory:

repomd fedora 

In this section, I'll examine configuration files from Fedora Core 3 and 4. While this may be confusing at first, I believe you can learn a lot about configuring yum for updates, based on the contrasts. In addition, if you use Red Hat Enterprise Linux 4 (or one of the related "rebuild" distributions), you'll see later in the chapter why it helps to know how to configure yum on Fedora Core 3.

As suggested in Chapter 1, there are four repositories associated with Fedora Linux releases (and two more of interest):

os is associated with the basic release files and includes those packages that you would find on the Fedora installation CDs.

updates includes stable packages that are updated or otherwise revised to address security problems or introduce new features.

updates-testing adds candidate files for updates that are not considered to be production-ready (but what you might consider if you're desperate for an update).

development includes those unstable packages that may be revised as often as every day.

extras is a fifth super-category; there are actually several additional developmental and testing repositories available in the extras category. If you're interested in this level of detail, search the extras subdirectory of your favorite Fedora mirror.

extras-development is a sixth category, similar to the regular development repository.

The default configuration for Fedora Core 3 includes the following four command lines, which configure connections to the yum installation (os) and updates repositories:

yum fedora-core-3$ARCH/os/ yum updates-released-fc3 $ARCH/ yum-mirror fedora-core-3 mirrors/fedora-core-3 yum-mirror updates-released-fc3 

In contrast, the default configuration for Fedora Core 4 points to default repositories in files in the /etc/yum.repos.d directory. The files associated with the installation (os) and updates repositories are fedora.repo and fedora-updates.repo. The key commands from these files include the following:

mirrorlist= $releasever mirrorlist= fc$releasever 

These files (and any others in the /etc/yum.repos.d directory) are active if you see the following directive in the configuration file:


For both Fedora Core 3 and Fedora Core 4, these commands connect your computer to the os and updates repositories on two different servers: and a random mirror as specified in the fedora-core-3 and updates-released-fc3 files (as well as fedora-core-4 and updates-released-fc4 files) at

It's best to change these command lines to point to a different mirror. A list of mirrors is available from Before making any change to the URL, check the associated directory. You may need to change that as well.

For example, as of this writing, if you were to use the mirror server at the University of Southern California, the server URL is However, because the subdirectories with the os and updates repositories are different; the resulting command lines would be

yum fedora-core-3$ARCH/os/ yum updates-released-fc3$ARCH/ 

In Fedora Core 3, you'll find two sets of command lines in /etc/sysconfig/ rhn/sources. The second two command lines are an attempt to select a second repository. The defaults actually select a random repository from the list available from the following files: 

Take a look at these files. You'll find URLs pointing to servers all over the world. In principle, listing alternate servers for the os and updates repositories is an excellent idea. But be careful. If you're in Korea and you get connected to a repository in Austria, patch management performance may suffer.


When you test the Red Hat Update Agent with aforementioned mirrors files, run up2date -u at the command line interface. The first lines of output tell you which mirrors are used. Remember, the actual mirror varies at random among those mirrors listed in the aforementioned files linked via /etc/sysconfig/rhn/sources.

On the other hand, there are country-based mirror lists available at and These directories includes a list of files with country name extensions, in ICANN top-level domain format. For more information, see

For example, if you're located in Germany, you might consider the file, which includes URLs for several different servers. If these servers are acceptably close to you, they are excellent options that can ensure you're able to connect to appropriate yum repositories even when there are connection problems.

Don't accept these files blindly; it's possible that someone may include a server from a different continent in a file by mistake. Some of these files may be empty. And some files may not be suitable. For example, if you're located in eastern Canada, the file may not be right for you, because it currently lists only one server, which happens to be in western Canada (Calgary, Alberta). While the corresponding file for Fedora Core 4 includes a wider variety of Canadian mirrors, it's possible that mirrors in the U.S. may be closer than any of the four listed in the file. (However, I certainly understand that some prefer to keep their international Internet traffic to a minimum.)

I'm located on the West coast of the U.S. Because the list of mirrors in the file suits my location well, I've included that URL in the /etc/sysconfig/rhn/sources file on my Fedora Core 3 computer:

yum-mirror fedora-core-3 mirrors/ yum-mirror updates-released-fc3 

As for my Fedora Core 4 computer, I've revised my /etc/yum.repos.d/fedora-updates.repo file to point to the file with the list of U.S. West Coast mirrors: 

Using the same tools, you can also connect your computer to updates-testing, development and even the extras repositories. Unfortunately, in several cases, the list of repositories in a mirrors file is too short. If it includes only one repository, or if there is no geographically appropriate file, you may want to create your own list using several baseurl directives. For example, a user in Switzerland might not be satisfied with the one server listed in the mirror list file (ch is the standard two-letter code associated with Switzerland). If I were in Switzerland, I'd include the following in my /etc/yum.repos.d/fedora.repo configuration file, which includes the Swiss mirror, along with a mirror in southern Germany:

[base] name=Fedora Core $releasever - $basearch - Base baseurl=$ARCH/ os/ baseurl=http://ftp-stud.fht-$ARCH/os/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora 

If you're running Fedora Core 4, you'll have to update the appropriate files in the /etc/yum.repos.d directory. For example, if you're interested in the latest package builds and want to activate the development repository, take the following steps:


Open the fedora-devel.repo file, from the /etc/yum.repos.d directory, in the text editor of your choice.


Change the mirrorlist directive to point to the most appropriate geographically based mirror file. For example, if you're on the East Coast of the U.S., you might replace the mirrorlist directive with the following:



Make sure the enabled directive is active, or set to 1. By default, it is inactive, or set to 0:



Make sure the gpgcheck directive is active, or set to 1. By default, it is inactive, or set to 0:



Cite the appropriate GPG file, in this case with the following directive:



Save the file. The next time you run up2date, you should find the development repository in the channel list.


Don't activate the development repository on production computers. This repository includes nightly builds of the latest packages, designed for testing. By definition, they may still have bugs.


Be careful. For all versions of Fedora Linux released as of this writing, there is one command in the sources file that would try to connect your Fedora Linux computer to the Red Hat Network. If you have a subscription to Red Hat Enterprise Linux, activating the following command would cause the Red Hat Update Agent to prompt you to register this computer on the Red Hat Network, which could use up a valuable subscription to this service. Do not activate this command!

#up2date default 

Before running the Red Hat Update Agent, you should make sure that the key components are themselves up to date. You can do so with two simple commands:

up2date up2date up2date yum 

Updates don't happen often to either of these two packages. However, if you configure a script to automate updates, you should make these commands part of that script.

When properly configured, you can proceed in two ways. If you want to update all but kernel packages from the command line interface, run the following command, which downloads and installs all available updates by default.

up2date -u 

Gosh, isn't that simple? But be warned, the first time you run this command with Fedora Linux, it could take some time. In my case, this command downloaded around 2,000 headers to /var/spool/up2date; the process took nearly a full hour.

But you may not want to update all packages. For example, as of this writing, updates to the Firefox Web browser can break any plugins that you've installed. In that case, you may want to keep Firefox off the update list. You can find the list of available updates with the following command:

up2date -l 

If the list is long, you may want to pipe the output. For example, if you want to see if there's an upgrade to Firefox in the update list, you could run the following command:

up2date -l | grep firefox 

If Firefox is on the list, you can make the Update Agent exclude it. Sure, you could configure it with up2date --configure, but this is only a temporary measure. I'm assuming that you eventually do want the security updates associated with new versions of the Firefox browser.

With Fedora Linux, the Update Agent is configured to use yum by default. That means you can take advantage of the switches and options associated with the yum command. You can use yum command switches, such as --exclude. In this case, you can exclude Firefox from the update list with the following command:

up2date -u --exclude=firefox 

You can use the --exclude switch for as many packages as you want to exclude from the update list. Now, isn't that easy?

Even with the versatility of the command line version of the Update Agent, there are administrators who prefer the interactive mode available when you run the Update Agent in the GUI. If this is what you want to do, take the following steps:


Run the up2date command from a command line interface.


Unless you've logged in as the root user, you're prompted for the root administrative password.


When you see the Welcome to Red Hat Update Agent window, select Forward.


You'll see the channels associated with your repository configuration file (/etc/sysconfig/rhn/sources for Fedora Core 3; the files with the enabled=1 directive in the /etc/yum.repos.d directory for Fedora Core 4), along with the mirror selected, as shown in Figure 6-1. Unselect any channels that you do not desire to use in this update, and select Forward to continue.

Figure 6-1. Fedora updates with a random mirror

Fedora systems are not part of the Red Hat Network described in Chapter 2, "Consolidating Patches on a Red Hat/Fedora Network," so ignore the message about subscribing to channels in Figure 6-1.


You're taken to the Packages Flagged to be Skipped window. As with most updates, it's generally not desirable to download or install a new kernel unless you know your system is ready. Unless you're ready to install a new kernel, do not select the kernel related packages; click Forward to continue.


You're taken to a long list of available package updates, such as those shown in Figure 6-2. Select those packages that you want updated, and select Forward to continue.

Figure 6-2. List of available package updates


The Update Agent begins to test dependencies, using yum. Any dependent packages are added to the update list. The Update Agent then proceeds with retrieving packages. When the process is complete, click Forward to continue.


The Update Agent proceeds with installing the downloaded packages. When the process is complete, click Forward to continue.


The Update Agent lists the packages that it installed or upgraded on your system. Click Finish when you've reviewed these packages.


With thousands of packages, the first rule when running the Red Hat Update Agent is patience. You may be downloading hundreds of MB of headers. Only after the headers are installed can yum check your requested updates for dependencies. Only then does the Update Agent download the actual packages. Then the packages are installed. By default, they are then deleted from the /var/spool/up2date directory. Each of these steps takes time. My first update for Fedora Core 3 took over two hours on a high-speed cable modem connection. Naturally, this should focus your mind on how much you need patch management, along with a local repository.

There can be problems even after yum resolves dependencies. If you run into a problem, you could rerun the Update Agent in verbose mode with the -v switch:

up2date -v -u 

Alternatively, you could watch the messages as they appear with the following command:

tail -f /var/log/up2date 

There are occasional errors, such as IOError: Not a gzipped file. In that case, try a different mirror. Updates may not be as consistent on the mirror that you've selected.

One other error I've encountered relates to an unresolvable dependency. You might think this is not possible with yum, because it automatically resolves dependencies. However, by default, the Update Agent does not download or install a newer version of the Linux kernel. The related error I encountered is

Unresolvable chain of dependencies: hal-0.4.7-1.FC3                     requires kernel >= 2.6.10 

While we discuss yum in detail later in this chapter, we already know that the --exclude switch is useful; for example, the following command excludes the hal RPM from that list:

up2date -u --exclude=hal 

I can also exclude the Firefox browser (and similarly named packages, courtesy of the wildcard) from the update list:

up2date -u --exclude=hal --exclude=firefox* 

6.2.2. Red Hat Enterprise Linux

In Chapter 2, we explored how you can configure Red Hat Enterprise Linux (RHEL) on the Red Hat Network. You can also configure yum on RHEL. While this package isn't available as of this writing through normal Red Hat Network channels, it is available from third parties.


Before looking to third parties, check all available RHEL channels. Red Hat provides a number of additional packages for its Enterprise Linux distributions in alternative channels. These include packages such as Java, Macromedia Flash, and Real Player. Run a search. You might be pleasantly surprised. My educated guess is that Red Hat will add yum to one of these channels sometime in the future.

You can get yum from a Fedora or Red Hat mirror or from one of the rebuilds of RHEL that uses yum repositories. If you're running RHEL 3, you can get a compatible version of yum from a RHEL 3 rebuild or Red Hat Linux 9. If you're running RHEL 4, you can get a compatible yum from a RHEL 4 rebuild or Fedora Core 3. As described earlier, Fedora mirrors are listed at Red Hat Linux 9 is often available from the same mirrors; you may need to do some searching up or down the directory tree to find those files. As of this writing, useful RHEL repositories are available from the following sources:

ATrpms includes four levels of repositories. The stable repository is straightforward. The good repository includes stable packages along with a few others that have not undergone sufficient testing to be considered stable. The testing repository includes good packages along with a few that are equivalent to betas on many systems. The bleeding repository includes all current ATrpms packages, including many which are currently in development. For more information, see

The Dag Wieers repositories are excellent sources for packages such as the pine email reader. While pine is still popular (, it is not included in distributions, such as RHEL 4, for licensing reasons. For more information on connecting to these repositories, see

The Macromedia repository is available for the Flash plugin associated with many Web sites. While available as part of the Extras channel for RHEL 4, the Extras channel is not available for RHEL 3.


Many of the developers behind these disparate repositories are combining their efforts. You may be able to find RHEL 4 repositories at

With the following steps, we'll download yum from a mirror for Fedora Core 3 and install the pine email reader on RHEL 4. Then we'll connect RHEL 4 to two different yum repositories. You can use the same basic steps to connect to other yum repositories of your choice, even those that you've configured locally. If you don't qualify for support, you can connect to the repositories of one of the RHEL rebuilds, as described in the next section.


Any package that you install on RHEL that is not part of one of your subscription channels on the Red Hat Network will not be supported by Red Hat. If you install a third-party RPM, you may put the Red Hat support for your system at risk.

  1. From your RHEL 4 computer, navigate to Select the mirror appropriate for your location.

  2. Navigate to the directory with Fedora Core 3 operating system files. The actual directory may vary by mirror. In my case, I've navigated to

  3. Download and install the yum RPM. For Fedora Core 3, it's yum-2.1.11-3.noarch.rpm.

  4. Review the installed /etc/yum.conf. As you can see from the comments, you can specify yum repositories in the /etc/yum.repos.d directory.

  5. Now, add an atrpms.repo file in the /etc/yum.repos.d directory. Open this file in a text editor. Per, add the following commands to that file (If there is a mirror closer to you, substitute it for the URL shown below):

    [at-stable] name=ATrpms for Fedora Core $releasever stable baseurl=$basearch/at-stable 

    Before implementing this change, make sure the cited URL still exists and includes the desired yum repository. Save the file.

  6. Test the result. Run the yum list command. You should be able to watch as your system connects to the repository and lists the available packages.

  7. Next, add a dag.repo file in the /etc/yum.repos.d directory. Open this file in a text editor. Per the installation instructions available from, add the following commands to that file (if there is a mirror closer to you, substitute it for the following URL):

    [dag] name=Dag RPM Repository for Red Hat Enterprise Linux baseurl=$basearch/dag gpgcheck=1 enabled=1 

  8. Test the result. Run the yum list command. You should be able to watch as your system connects to the repository and lists the available packages.

  9. Import the associated RPM GPG (GNU Privacy Guard) key, available from You can do so with the following command:

    rpm --import 

  10. Make sure the pine email reader is available from your configured repositories with the following command:

    yum list | grep pine 

    The output should include a line similar to the following, which cites the package, architecture, version, and repository:

    pine.i386     4.62-1.2.el4.rf     dag 

  11. Install the pine email reader with the following command:

    yum install pine 

  12. Confirm installation with the rpm -q pine command.

  13. Configure pine for your users.


There are reports of Fedora users who connect to multiple third-party repositories who experience unresolvable dependencies. Take care when using non-Fedora or non-Red Hat repositories.

6.2.3. Red Hat Enterprise Linux Rebuilds

Several rebuilds of RHEL use yum for updates, with techniques and configuration files similar to those described earlier for Fedora Linux.

In Chapter 2, we reconfigured a CentOS-4 system to point toward more local mirrors. The key file is CentOS-Base.repo, in the /etc/yum.repos.d directory. If you want to activate all the repository directories listed, be careful. The names and locations of each repository directory may vary by mirror. Check each repository directory URL yourself. For example, the CentOS-4 testing repository may not be available on many mirrors.

You can add the same files described previously for yum on RHEL 4. In fact, I've copied the files that I created from the previous section directly and installed the pine email reader on my CentOS-4 system from the Dag Wieers repository.

However, CentOS-4, like RHEL, Fedora, and other RHEL rebuilds, relies on the Red Hat Update Agent to keep its systems up to date. As discussed earlier in this chapter, the Update Agent relies on how you configure the sources file in the /etc/sysconfig/rhn directory. By default, the CentOS-4 version of this file points to the following repositories:

yum centos4-Base$ARCH/ yum centos4-Updates$ARCH/ yum centos4-extras$ARCH/ yum centos4-contrib$ARCH/ yum centos4-addons$ARCH/ 

As discussed earlier in this book, CentOS-4 is built by volunteers. If you connect to a mirror, as opposed to directly to their servers, you can help keep their costs down. To do so, revise these URLs to point to a CentOS mirror closer to your location. For a full list, navigate to For example, if you're located in California, you might use the mirror located at the University of California, Riverside. The base URL cites a different base directory: 

You would substitute this URL for in the command lines shown previously. To make sure things worked, you can check available channels with the following command:

up2date --show-channels 

But this command does not check the URLs. You should see the available channels as you check the list of available updates. If there's a problem with one of your URLs, you should see a connect error. For example, when I made a mistake typing in an HTTP URL, I got a 404 (file not found) error. Problems should be saved in the Update Agent log file, /var/log/up2date.

The first time I ran up2date -l, I found two critical packages in the list: centos-yumconf and up2date. The centos-yumconf package provides the rebuild specific yum configuration file, /etc/yum.repos.d/CentOS-Base.repo. If you're using a different rebuild, it will have a different, equally important package. Naturally, these packages affect how other packages are updated. I wanted to download and install these packages first before downloading others. I could do so with the following command:

up2date up2date centos-yumconf 

Updates don't happen often to either of these two packages. However, if you configure a script to automate updates, you should make these commands part of that script. You never know when a package will be updated.

If you've already revised associated configuration files, such as /etc/sysconfig/rhn/sources and /etc/yum.repos.d/CentOS-Base.repo, they are not changed when new versions of the up2date and centos-yumconf RPMs are installed. The proposed updated files are stored in the same directories, with .rpmnew extensions.

After updating the Update Agent, it's appropriate to run up2date -l again. In my case, I wanted to keep the current versions of the ipsec-tools and firefox RPMs and install all other non-kernel updates. I performed this task with the following command:

up2date -u --exclude=firefox --exclude=ipsec-tools 

Of course, you can run the Update Agent from the GUI. Run the up2date command in a GUI console. As you can see in Figure 6-3, the Update Agent shows available channels as you configured in /etc/sysconfig/rhn/sources.

Figure 6-3. CentOS-4 updates with a random mirror

As with other yum enabled Red Hat-style systems, headers are downloaded and stored in /var/spool/up2date during this process. In Chapter 7, you'll learn to use this directory of headers to help create a general repository for your network.

Linux(r) Patch Management(c) Keeping Linux(r) Systems Up To Date
Linux Patch Management: Keeping Linux Systems Up To Date
ISBN: 0132366754
EAN: 2147483647
Year: 2006
Pages: 80
Authors: Michael Jang

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: