This chapter is from the book
This chapter is from the book
This chapter is from the book
7.4 Adding Other Repositories
You might want to maintain other repositories on a local server. Based on the chapter so far, you should have the tools you need to create the server and configure your clients to read from that server.
As suggested earlier, there are several different repositories available for Fedora, such as Extras, Development, and Testing repositories. In many cases, you might want to add repositories from allied distributions. For example, Fedora Core 3 repositories may be suitable for RHEL 4 and related rebuild distributions. There are also third-party repositories available; many of the same third-party apt repositories described in Chapter 5, "Configuring apt for RPM Distributions," also include "yummified" RPM repositories of possible interest.
7.4.1 Using Distribution Installation Files
If you’ve followed the steps described earlier, you’ve copied the files from the Fedora Core 4 installation CDs to a directory in your yum repository. You should have a copy of the installation DVD (or CDs) in the following directory:
/var/ftp/pub/yum/4/i386/os/
You can now yummify this repository with one of the following commands. Naturally, if you’re using Fedora Core 3 or later, you should install the createrepo RPM and then yummify the repository with the second command:
yum-arch /var/ftp/pub/yum/4/i386/os/* createrepo /var/ftp/pub/yum/4/i386/os/*
If you’re running Fedora Core 4 on your clients, you can now point the fedora.repo configuration file in the /etc/yum.repos.d directory to the installation repository. If you’ve configured the FTP server described earlier, you should use the following baseurl command in that file:
baseurl=ftp://yum.example.com/pub/yum/4/i386/os/
7.4.2 Keeping Extras with yum
One useful Fedora repository is known as Extras. It includes a number of packages not integral to the smooth running of the distribution. However, the Fedora Core 4 Extras repository includes a number of packages of interest, including Tripwire, the WindowMaker GUI, the BitTorrent download manager, and even the apt tools described in Chapter 5.
Depending on how frequently you or your users need Extras packages, you might want a local copy of that repository. It might not be easy to find this repository in the rsync mirrors. For example, the mirror listed for the University of Southern California (USC) is rsync://mirrors.usc.edu/fedora/. Sometimes, you’ll find seemingly duplicate copies of the same repository in different directories. For example, the following two commands return the same list of packages from the Fedora Core 3 Extras repository:
rsync rsync://mirrors.usc.edu/fedora/fedora/fedora/3/i386/RPMS.extras/ rsync rsync://mirrors.usc.edu/fedora-core/extras/3/i386/
In this case, the packages from the first repository are newer than those I found in the second. Naturally, I want the newest version of all packages, so I synchronize with that repository.
You can copy this repository to your own system. Based on the directories and rsync commands described earlier, the following command would synchronize your system with the rsync repository from USC:
rsync -av --exclude debug rsync://mirrors.usc.edu/fedora/fedora/fedora/3/i386/RPMS.extras/* /var/ftp/pub/yum/3/i386/extras/
You can review the output in Figure 7-3. As you can see, the information includes the amount of data transmitted across the network. In this case, I downloaded over a gigabyte of data. You do not want to repeat this process often.
)
Figure 7-3 A lot of data is downloaded the first time you synchronize
7.4.3 Adding Development Repositories
Do not mirror a Development repository unless it is absolutely necessary. Development RPMs are, by definition, not stable. They are not suitable for production systems. Because the RPMs in this repository are updated frequently, sometimes daily, updates take up a lot of bandwidth.
You or your users might want access to development repositories for different reasons. For example, your users might be interested in helping with Linux development. You might need to test the latest version of a package that is adding new features that you may need. You might want to test Fedora Linux on an architecture other than standard PC 32- or 64-bit CPUs.
Development repositories are available through most of the same mirrors associated with Fedora Linux. Unless your users need access to such packages frequently, it’s best to leave such repositories on remote mirrors.
Using the techniques described earlier, find the development/repository associated with your favorite mirror. For example, as shown in Figure 7-4, the following command returns a substantial list of architectures available through this repository:
rsync rsync://mirrors.kernel.org/fedora/core/development/
)
Figure 7-4 Many architectures associated with the Fedora Development repository
The available architectures are defined in Table 7-3.
Table 7-3 Fedora architectures
|
Label |
Description |
|
i386 |
Standard 32-bit PCs |
|
ia64 |
Itanium 64-bit PCs |
|
ppc |
32-bit Power PC-based computers |
|
ppc64 |
64-bit Power PC-based computers |
|
s390 |
System 390 IBM computers; now known as zSeries |
|
s390x |
System 390 IBM computers; now known as zSeries |
|
x86_64 |
AMD 64-bit PCs |
7.4.4 Other Distribution Repositories
In some cases, you might want access to repositories available for other distributions. For example, if you’re running RHEL 4, you might want access to Fedora Core 3 repositories for additional packages. As RHEL 4 is based on Fedora Core 3, many packages from this version of Fedora work fine without modifications.
While you can mirror the repositories from other distributions, you should not do so unless you use packages from those repositories frequently. Otherwise, you’ll be using a lot of space with packages that might not work with your system. In fact, any Fedora Core 3 packages that you install on RHEL 4 are not supported by Red Hat.
If you’ve installed the yum and createrepo RPMs from Fedora Core 3 on RHEL 4, you can include the files of your choice in the /etc/yum.repos.d directory. However, you should not install the RPM that installs Fedora Core 3 repository files in this directory because it may change the version associated with your system and affect the way your RHEL 4 system communicates with the Red Hat Network.
If you do not have access to Fedora Core 3, you can get more information about the files in the /etc/yum.repos.d directory at http://fedoranews.org/ tchung/yum-mirrorlist/. For details on how these files work (as well as those for Fedora Core 4), see Chapter 6.
7.4.5 Third-Party Repositories
In some cases, you might want access to repositories available from third parties. We’ve covered several of the third-party repositories in Chapter 6. As you’ve read, they’re available for several different distributions, especially those related to Red Hat Enterprise Linux or Fedora.
Evaluation copies of RHEL are available as of this writing from http://www.redhat.com/software/rhel/eval/. The subscription is valid for 30 days, and it includes access and administration privileges on the Red Hat Network. You can read about some of the associated features in Chapter 2. After the subscription expires, you might be able to update your RHEL system using the repositories available from one of the RHEL rebuild distributions. Naturally, any packages that you download and install from a third-party are not supported by Red Hat and are done so at your own risk.
Unfortunately, many third-party repositories discussed in this book do not have rsync servers available. You’ll have to use more conventional methods, such as FTP, to download the files associated with these repositories. Many of these mirrors are administered by small groups or even individuals. They might not be able to support enterprise-level package downloads. Therefore, if you use a third-party repository frequently, consider creating your own mirror of that repository.