Creating a Redhat Yum Repository

Although many publically available yum repositories exist, creating one's own repository can result in better access and more control over the repository.

Yum or Apt?

While aficionados will heatedly argue the advantages of one over the other, it basically does not matter whether you use yum or apt. What is critical, however, is that you stay up-to-date with one of these (or with Redhat's up2date server) in order to prevent security compromises. Historically, it seems that apt was initially more popular. However, yum has been incorporated into Fedora Core, the successor to Redhat Linux, and therefore may have overtaken apt in popularity. The approach taken in this document is to describe how to create a repository that is compatible with yum and/or apt. In doing so, the scripts used by the Creating a Redhat Apt Repository document are modified to create either or both repositories.

Overview

The basic steps to creating a repository are first to create a mirror of the Redhat distribution and then to create a yum repository from the mirror. After the repository is created, it should be made available through a server so that clients can access it. Finally, the repository should be kept up-to-date by regularly refreshing the mirror and regenerating the yum header files. These tasks involve precisely specifying lengthy directory locations, so they are best accomplished by scripts in order to eliminate typographical errors.

Create a Redhat mirror

A redhat mirror can be created using the script provided by the Creating a Redhat Apt Repository document.

Download and install yum rpm

In order to create a yum repository, the yum rpm must be installed on the server in order to access the indexing program (yum-arch). Although yum is written in python and therefore should be architecture independent, different versions of the yum rpm are required for different versions of Redhat linux because of changes in the rpm format. Download the version of yum appropriate for your architecture

• yum-1.0.3-1_73.noarch.rpm for Redhat 7.3 or prior (w/conf file edit)
• yum-1.0.3-1_80.noarch.rpm for Redhat 8.0 (requires librpm404 and rpm404-python)
• yum-2.0.5-1.noarch.rpm for Redhat 9

or visit Yum: Download and obtain the latest version for your particular architecture.
Install the rpm.

Create yum repository

The two steps to creating a yum repository are to provide the rpms in an organized directory structure and then to index the rpms.

The problem with providing the operating system and update rpms is that they are organized differently in the redhat distribution. The originally distributed operating system is distributed in a single directory with i386, i686, and noarch rpm's, whereas the updates are distributed in separate directories for different architectures. While yum repositories can handle this difference in directory structure by recursively descending the directory tree and searching for rpms, an apt repository is better organized with the operating system and the updates to each in a single directory. Thus the solution for apt repositoies is to use links, so that the operating system directory becomes the "os" apt directory, and the various redhat update rpms are combined into a single "update" apt directory. Finally, an "extras" apt directory can be created for third party rpm's. Since the repository described by this document is both apt and yum compatible, this approach is taken here.

After an appropriate repository structure is created, the rpm (or in this case, linked rpm) headers must be extracted to create the yum database. Yum does this with the yum-arch tool which writes the rpm headers into a "header" directory within each directory being indexed. Note that the "-l" switch is required in this case for yum-arch to follow symbolic links.

A redhat yum repository can be created by slightly modifying the script provided by the Creating a Redhat Apt Repository document.

• Comment out the line starting with "genbasedir" in 4 places (the OS, UPDATES, EXTRAS, and HASH sections)
• Uncomment out the 3 consecutive lines starting with "echo", "rm", and "yum-arch" in 3 places (in the OS, UPDATES, and EXTRAS sections)

Leaving the "genbasedir" lines uncommented while uncommenting the "echo", "rm", and "yum-arch" lines will produce a script that produces both apt and yum repositories.

The script would intially be invoked as 'make-apt full 9' and subsequently invoked as 'make-apt quick 9'. Of course, modify the local mirror and yum repository locations appropriately, and use the desired redhat release, e.g., '7.3' or '8.0' in place of '9' as desired.

Serve up yum repository

Once the repository is constructed, it must be made available by http, ftp, or rsync. If the repository is made in the root document tree of your web server, e.g., /var/www/html/apt, the following entry should be added to /etc/httpd/conf/httpd.conf:

in order to allow the directories to be listed. Reload the httpd configuration file with

The yum repository can now be accessed at http://myserver.domain.edu/apt

The "apt" directory location has been retained in this document to be consistent with the the Creating a Redhat Apt Repository document, but it could be changed to a more appropriate "yum" location if desired.

Update yum repository

The yum repository should be regularly updated via a daily or weekly cron job. The two commands that must be executed are 'make-redhat-mirror quick 9' and 'make-apt quick 9', the desired redhat release, e.g., '7.3' or '8.0' in place of '9' as desired. This pair of commands needs to executed for each Redhat version being maintained in the repository.

Add to yum repository

The os directory contains the original redhat distribution rpms, and the updates directory contains Redhat update rpms. The extras directory is intended for one to place additional rpms.

Instruct clients to use repository

Clients can use the repository by editing their /etc/yum.conf file as follows

where $releasever will replaced with "7.3", "8.0", "9", etc. as appropriate and $basearch will be replaced with "i386" for 386, 686, athlon, etc architectures. Clients can then check for updates with

References