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.
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 http://fedora.redhat.com/
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):
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 http://download.fedora.redhat.com/pub/fedora/linux/core/3/$ARCH/os/ yum updates-released-fc3 http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/ $ARCH/ yum-mirror fedora-core-3 http://fedora.redhat.com/download/up2date- mirrors/fedora-core-3 yum-mirror updates-released-fc3 http://fedora.redhat.com/download/up2date-mirrors/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=http://fedora.redhat.com/download/mirrors/fedora-core- $releasever mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released- 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: download.fedora.redhat.com 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 http://fedora.redhat.com/download/up2date-mirrors/.
It's best to change these command lines to point to a different mirror. A list of mirrors is available from http://fedora.redhat.com/download/mirrors.html. 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 http://mirrors.usc.edu. However, because the subdirectories with the os and updates repositories are different; the resulting command lines would be
yum fedora-core-3 http://mirrors.usc.edu/pub/linux/distributions/fedora/3/$ARCH/os/ yum updates-released-fc3 http://mirrors.usc.edu/pub/linux/distributions/fedora/updates/3/$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 http://fedora.redhat.com/download/mirrors/ and http://fedora.redhat.com/download/up2date-mirrors/. These directories includes a list of files with country name extensions, in ICANN top-level domain format. For more information, see http://www.iana.org/cctld/cctld-whois.htm.
For example, if you're located in Germany, you might consider the fedora-core-4.de 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 fedora-core-3.ca 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 fedora-core-4.ca 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 fedora-core-3.us.west 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 http://fedora.redhat.com/download/up2date- mirrors/fedora-core-3.us.west yum-mirror updates-released-fc3 http://fedora.redhat.com/download/up2date-mirrors/updates-released- fc3.us.west
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 fedora-core-4.ch 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=http://mirror.switch.ch/ftp/mirror/fedora/linux/core/4/$ARCH/ os/ baseurl=http://ftp-stud.fht- esslingen.de/pub/Mirrors/fedora.redhat.com/linux/core/4/$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:
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!
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.
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:
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:
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 fedora.redhat.com/download/mirrors.html. 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:
Many of the developers behind these disparate repositories are combining their efforts. You may be able to find RHEL 4 repositories at www.rpmforge.net.
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.
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 http://mirror.centos.org/centos/4/os/$ARCH/ yum centos4-Updates http://mirror.centos.org/centos/4/updates/$ARCH/ yum centos4-extras http://mirror.centos.org/centos/4/extras/$ARCH/ yum centos4-contrib http://mirror.centos.org/centos/4/contrib/$ARCH/ yum centos4-addons http://mirror.centos.org/centos/4/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 www.centos.org/modules/tinycontent/index.php?id=13. 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 http://mirror.centos.org/centos/4/ in the command lines shown previously. To make sure things worked, you can check available channels with the following command:
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.