8.6. Find the Right Update Repository
Default configurations can be annoying when you're trying to keep your system up-to-date. If you're located outside the U.S., default update repositories for U.S.-based distributions can doom you to long wait times, and sometimes even failures, when you try to update your systems to the latest features and security updates.
Some distributions such as Debian suggest that it is inappropriate to connect directly to Debian servers for all but security updates. It increases the costs for this distribution of volunteers and makes access more difficult for those who mirror the Debian repositories.
In general, repositories are organized into separate installation and update repositories. The installation repository includes all packages associated with the original release of a distribution; for example, the installation repositories for Fedora Linux include the packages that you would find on the Fedora Linux CDs. The corresponding update repository includes any packages built after the initial distribution release. One exception is Red Hat Enterprise Linux (RHEL), where update packages are incorporated into the main repository (which is known as a channel on the Red Hat Network).
In this annoyance, we'll examine default update servers, and how you can reconfigure your systems to point to mirrors more well suited to your system. As this book is limited to Red Hat/Fedora, SUSE, and Debian, I do not address mirrors available for other distributions. However, the techniques are similar.
In some cases, the best update channel is one that you configure yourself. In "Too Many Computers to Update over the Internet" in Chapter 11, I'll show you how to configure a mirror of your preferred update server. A local mirror can minimize update-related traffic on your Internet connection and often speeds updates if you have more than a few Linux computers on your network.
Debian Linux uses the apt commands to keep its systems up-to-date. The apt commands rely on sources configured in the /etc/apt/sources.list configuration file. Before you modify this file, you need to know how the directives that you can add to this file work. I've summarized some of the more important directives in Table 8-2. As you can install the apt commands on many RPM-based systems, I've included some directives you might see on RPM-based distributions.
Now you'll want to configure your /etc/apt/sources.list file to point to repositories closer to your network. Unless the mirror is slow, pick the mirror physically closest to you. The official list of Debian mirrors is available from http://www.debian.org/mirror/list.
For example, if I were closest to Berkeley, CA, I'd connect to the mirror at the University of California at Berkeley. As you can see, FTP and HTTP mirrors are available. If you have a special architecture, make sure it's listed in the righthand column. I prefer FTP servers for my system; I can link to the noted server at ftp://linux.csua.berkeley.edu/debian/.
In my /etc/apt/sources.list file, I start with the deb directive, proceed with the URL of the repository, and add the label for the distribution, as well as the repositories to which I want access. As I use Debian Sarge, that is the stable distribution. As I want access to all three repositories, I end up with the following line in my configuration file:
deb ftp://linux.csua.berkeley.edu/debian/ stable main contrib non-free
If I want access to the source code for each of these repositories, I can add the following line:
deb-src ftp://linux.csua.berkeley.edu/debian/ testing main contrib non-free
Unfortunately, Debian does not support mirrors of its security updates; you'll need to keep the following entry in your /etc/apt/sources.list file:
deb http://security.debian.org/ testing/updates main contrib non-free
While some have created apt repositories for SUSE Linux, the company encourages the use of official repositories and mirrors through YaST Online Update (YOU). While SUSE encourages the use of its GUI interface, you can also configure YaST updates from the command line. As the root user, run the yast online_update command to open the update menu shown in Figure 8-1.
Figure 8-1. YaST Online Update
Naturally, you'll want to configure updates from the mirror closest to you. The Installation Source drop-down text box includes several preconfigured locations. It also allows you to select a User-Defined Location, which you can select from one of the SUSE mirrors.
If you're running SUSE Linux Professional, you can select your mirror from the official list at http://www.novell.com/products/suselinux/downloads/ftp/int_mirrors.html. To configure your own location, take the following steps:
While the list of official mirrors seems limited, you may want to search further. I've found SUSE repositories on servers listed in the Fedora mirror list. For example, I've been able to configure updates from the servers at the University of Mississippi. The URL for its server is ftp://mirror.phy.olemiss.edu, and the associated "Directory on Server" is suse/suse/.
In "Too Many Computers to Update over the Internet" in Chapter 11, I show you how to configure a local mirror. Once you share that mirror on your network, you can reconfigure YaST Online Update to point to that share.
For much of this book, Red Hat Enterprise Linux (RHEL) and Fedora are essentially the same distribution. Both distributions use the same basic Red Hat tools. However, unlike RHEL, Fedora updates are freely available. Fedora's default version of /etc/yum.conf points to files in the /etc/yum.repos.d directory for updates.
By default, Fedora Core includes six files in that directory, described in Table 8-3, which you can use to link to the repositories.
By default, there are no active directives in the devel and testing files. Unless you're willing to take the risks associated with software that is not ready for production, you should not activate directives in those files. In fact, you can delete fedora-updates-testing.repo, fedora-extras-devel.repo, and fedora-devel.repo without problemsand probably should on systems for regular users.
However, you will want to change the defaults in the first two files. The default version of fedora.repo includes:
[base] name=Fedora Core $releasever - $basearch - Base #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-$releasever enabled=1 gpgcheck=1
By default, $releasever is the released version number as defined in /etc/redhat-release and $basearch comes from the uname -i command, which specifies the hardware platform. If you want to disable a repository, set enabled=0.
As you can see, the repository depends on the mirrorlist directive, which points to a URL with a list of specified repositories. For Fedora Core 4, the default mirrorlist file is fedora-core-4, which includes a list of mirrors on several different continents. When yum looks for an update repository, it takes a random URL from this file, which is less than ideal.
Therefore, you'll either want to specify a repository closer to you or at least revise the mirrorlist file to one that makes more sense. There is a directory of mirrorlist files available at http://fedora.redhat.com/download/mirrors/ with lists for a number of different countries. I use the fedora-core-3.us.west file, which includes a number of mirrors suitable for me.
8.6.4. Red Hat Enterprise Linux
Updates for Red Hat Enterprise Linux (RHEL) are supported through the Red Hat Network. They are organized differently from most other Linux distributions, in that there is no separate update repository. When an update is released, you can install it from the same channel as the main installation repository. (RHEL repositories are known as channels.)
Each system requires a subscription, which provides access to several update channels. As shown in Figure 8-2, I can assign a number of different channels to one of my systems that is subscribed to RHEL 4.
Figure 8-2. Red Hat Network channels
The channels shown in the figure are just those to which I subscribe. If you have a Red Hat Network subscription, you can click Channels on the top bar to review a full list of available channels. I describe some of the Red Hat Network channels in Table 8-4. For more information, navigate to https://www.redhat.com/software/rhn/ or contact Red Hat sales at 866-273-3428.
If you want to verify the channels to which you've subscribed, run the following command:
# up2date --show-channel rhel-i386-as-4 rhel-i386-as-4-extras rhel-i386-as-4-hwcert rhel-i386-as-4-sdk rhn-tools-rhel-4-as-i386
As you can see from the output, this particular system is subscribed to five different channels, all of them based on RHEL 4. In order of display, they correspond to the following channels: main, extras, hardware certification, software development kit, and network tools.
If you want to cache content locally, you can set the Red Hat Update Agent to save downloaded RPMs in the /var/spool/up2date directory. You can then use the yum tools described in the next annoyance to create headers from this repository. Downloaded RPMs are, by default, deleted after installation.
To make the Red Hat Update Agent save the RPMs after installation, take the following steps:
The Red Hat Network also offers specially configured Proxy and Satellite Servers, which can cache update content locally. For more information, read the associated manuals at http://www.redhat.com/docs/manuals/RHNetwork/.