Section 2.3. Configuring Red Hat Rebuilds

2.3. Configuring Red Hat Rebuilds

As discussed in Chapter 1, there are a number of groups that have built their own distributions (without the Red Hat trademarks) from RHEL source code. As they've built from source code published by Red Hat, their distributions are known as rebuilds. When Red Hat releases an update, it releases updated source code. In most cases, you can build your own packages from Red Hat source code and update your rebuild distribution.

However, this isn't always true. The rebuild groups do not have access to the same tools as the developers at Red Hat. There are often subtle differences in the resulting distributions, which go beyond the trademarks.

For example, when I loaded the source code associated with a rebuild kernel, there were dependencies. I had two choices. I could have searched for the packages built for the rebuild which would satisfy those dependencies. Instead, I had the packages built by Red Hat handy and used those instead. That did not work. The source code for the rebuild distribution would not install until I included dependent packages as customized for that distribution.

In other words, if you administer patch management on a network with rebuild distributions, it's important to configure your updates for repositories with packages built for the rebuild distribution.

Just to give you a feel for this process, I describe how you can configure updates from two of the RHEL rebuilds to the right repositories. Naturally, because the rebuilds do not offer subscriptions to the Red Hat Network, one other major difference is their techniques for patch management. The process is similar to that you learned about in Chapter 1 for Fedora Linux.

Note

Don't use the rhn_register command with the rebuild distributions. It tries to register your computer on the Red Hat Network, which requires a subscription. And if you have a subscription, you probably don't want to be running a rebuild distribution in the first place.

Unlike with the other sections in this chapter, I do not describe how you can create a local patch management repository for your LAN. You can learn about this process with the apt and yum tools in the last half of this book.

In the following sections, I'll show you how you can keep two of the "rebuild" distributions up to date; one uses yum; the other user apt. You can use the techniques described in Chapters 4 through 7 to create apt or yum repositories as needed for these rebuild distributions.

2.3.1. CentOS

My personal favorite rebuild version of RHEL is CentOS-4. This popular rebuild goes by a number of names. The proper name of the group is The cAos Foundation. CentOS 2, 3, and 4 are rebuilds of RHEL 2.1, 3, and 4 (with Red Hat trademarks removed).

The basic steps are as follows:

1.	Identify your Update Agent configuration files; they are associated with files in the /etc/sysconfig/rhn directory.
2.	In addition, if you want to configure yum updates you can do so in the files in the /etc/yum.repos.d directory.
3.	Find one or more preferred mirror sites for downloads.
4.	Identify the repositories that you want to keep up to date.
5.	Revise your yum configuration files to point to those repositories.

If you want to use up2date, as with Fedora or RHEL, you can cite or add repositories to the /etc/sysconfig/rhn/sources file.

Alternatively, the cAos rebuilds are configured to use their yum repositories. As of this writing, the default version of CentOS-4's yum.conf configuration file cites the repositories in /etc/yum.repos.d/CentOS-base.repo file. Some older versions of CentOS linked yum.conf to centos-yum.conf for repository lists.

Note

Alternatively, apt is available with CentOS, and you can use the techniques described in Chapter 4 to update from apt repositories.

As with Fedora Linux, it is in your best interest to revise your yum or sources configuration files to point to mirrors closer to your location. First, because cAos is a volunteer organization, they've had to ask for contributions to pay for all the downloads from their servers. Second, for the reasons described in Chapter 1, downloads from servers physically closer to your network are faster. You'll have to wait for Chapters 5 and 7 for instructions on how to create apt or yum repositories on your networks.

Before you revise your yum configuration files, find one or more preferred mirrors. The cAos list of mirrors is available from www.caosity.org/download/mirrors. Their "Tier 1" mirrors connect to the Internet at OC3, which corresponds to about 155Mbps. Naturally, this bandwidth is shared with others who may be downloading simultaneously.

Note

If you're downloading a distribution for the first time, you may be interested in Bittorrent, which supports large file downloads from multiple sources. I downloaded a CentOS-4 ISO file with their entire distribution (2GB+) in just over an hour on my home connection. However, not all Linux distributions support Bittorrent. For more information, see www.bittorrent.com.

As an example, inspect the mirror shown in Figure 2-13. The URL is the start of what you can enter as a baseurl in your /etc/yum.repos.d/CentOS-Base.repo file. The $releasever is 4.0. The subdirectories are as shown, and you can (and should) double-check that what you enter corresponds to an available directory on your selected mirror.

Figure 2-13. A cAos Mirror Site

If you want to use the up2date commands, you'll also want to modify the yum commands in /etc/sysconfig/rhn/sources to configure updates from the mirror of your choice.

After you select a mirror, select the repositories that you want to keep up to date. The standard settings in /etc/yum.conf refer to .repo files in the /etc/yum.repos.d directory. For example, for the Georgia Tech updates repository, you can navigate to

ftp://ftp.gtlib.cc.gatech.edu/pub/cAos/centos/4.0/updates/i386/

You should find RPMS, headers, and repodata subdirectories in each repository. The $relserver, as defined from the centos-release RPM package, is 4.0. The $basearch comes from the uname -i command. Thus, you could edit the [update] stanza in your CentOS-Base.repo file to read

baseurl=ftp://ftp.gtlib.cc.gatech.edu/pub/cAos/centos/$releasever/upda tes/$basearch/ 

You can add URLs from additional [update] mirrors below this line, such as

http://caos.oregonstate.edu/centos/$releasever/updates/$basearch/

When complete, you can use the yum command to keep your system updated. Alternatively, if you want to use up2date, you'll want to select an appropriate mirror for /etc/sysconfig/rhn/sources. For example, you could replace the default Base channel:

yum centos4-Base http://mirror.centos.org/centos/4/os/$ARCH/

with

yum centos4-Base http://caos.oregonstate.edu/centos/4/os/$ARCH/

and make parallel changes to the other channels listed in this file.

2.3.2. Lineox

Of all the available RHEL rebuild distributions, I've included Lineox as a contrast to CentOS. I do not claim that Lineox or CentOS are any better in quality or support when compared to other RHEL rebuilds. However, Lineox provides a nice contrast. They are based in Europe, offer paid levels of support, and configure their updates using apt.

One unique feature of Lineox is their paid support for updates and local patch management mirrors. Their patch management system is configured by default to synchronize your repositories on a daily basis. Lineox actually omits the Red Hat Update Agent from its Lineox 4 rebuild distribution.

We'll describe the apt patch management process in Chapters 4 and 5. However, you can configure your /etc/apt/sources.list file using basic methods described in Chapter 1 for Debian Linux. But remember, distributions related to Red Hat use a different package format, the RPM. So the default commands in the /etc/apt/sources.list file include the rpm command, including

rpm http://www.raimokoski.com/ pub/lineox/4.0/updates/i386 updates rpm-src http://www.raimokoski.com/ pub/lineox/4.0/updates/i386 updates 

You may not want to use the default URL unless you're physically located near the home of Lineox, which is Finland. Lineox makes other options available in various files in the /etc/apt/sources.list.d directory.

2.3.3. Other Rebuilds

As suggested in Chapter 1, there is a wide variety of rebuild distributions created from RHEL source code. There are almost as many variations on patch management as there are rebuilds. But they almost invariably rely in some way either on the yum or apt commands. And you can learn more about these commands and associated repositories in the second half of this book.