Google Site SearchFN Site Search FN Blog Login FN Blog Login
Site Navigation:
 
 

How to Build Custom Yum Repository

by Tony Smith (Contributing Writer)

This article builds on the article submitted by Hal Canary How to make a local yum repository mirror. This article can be used in conjunction with the aforementioned article, or on it's own in it's own right. Why is there a need to build a custom yum repository? I think this question is really quite easy to answer, whilst the vast majority of your requirements will be met by the standard released rpms, be them the base rpms or updates, there are some which quite simply are not supplied as standard, or those that are available from Red Hat /Fedora need to be customized. So how do you ensure that your non-standard rpms are updated across your managed systems, a simple answer is to use yum.

Step 1. Create Or Obtain Your Non-Standard RPMS

Using the article Upgrading MySQL version 3 to 4 RedHat / Fedora as a base. We will build a MySQL rpm, and customized php rpms. We will not go into the mechanics of creating these custom rpms. We are using the MySQL example as this provides an example of a new non Red Hat distributed rpm and some customized verions of Red Hat distributed rpms.

Note:
If the rpms are completely separate from those distributed by Red Hat then the Release line in the source rpms spec file can be left as the default value, however, if you are modifying the rpm of a Red Hat distributed rpm you must alter the Release line of the spec from say 1 to 1.MY4 before rebuilding the rpm using the spec file.

Step 2. Create The Yum Repository Directory Structure

You now have access to some customized or new rpms that you wish to distribute system wide, and you have decided that the best way to do this is to use yum. You now need to decide on the directory structure that you wish to use. The set up that will be designed here is one in which the yum repository will be accessed via a web server. hence the directory structure used will be
/var/www/html/fedora/linux/custom/updates/1/i386

Step 3. Populate The Custom Yum Repository

Once the yum repository directory tree has been created, simply copy your custom and non Red Hat distributed rpms into this directory.

Step 4. Yumify The Directory

Even though all the rpms that we require are now in our new custom yum directory they are still unusable through yum as it currently stands, basically we are still missing the headers. To create the required headers simply issue the following command:

yum-arch /var/www/html/fedora/linux/custom/updates/1/i386 [ENTER]

Issuing the above command will produce output similar to that shown below:

       Digesting rpms 100 % complete: php-xmlrpc-4.3.4-1.1.MY4.i386.rpm
             Total: 38
             Used: 38
             Src: 0
      Writing header.info file


This now completes the yumification of your custom yum directory.

Step 5. Configuring The Clients' yum.conf

The only configuration step left to take, is to ensure the systems that you wish to use the repository are configured to do so. This is a relatively simple task, all that is required is that the following is inserted into /etc/yum.conf

[custom updates]
name=Fedora Core $releasever Custom Updates
baseurl=http://[YOUR WEBSERVER]/fedora/linux/custom/updates/$releasever/i386/

Step 6. Further Configuration

As can be seen, combining this mini-tutorial, with Hal Canary's howto, illustrates how you can also minimize your own bandwith usage, by having your own onsite yum mirror that is synchronized once every 24 hours, when your bandwith use is at it's minimum. Your systems then use your local mirror, along with your local custom rpm yum repository for updates.

Gotcha's

As you are now aware this is a very simple implementation, however you must take into account the follwing:

  1. If using customized Red Hat distributed rpms, you need to ensure that you rebuild any updated rpms from source to match your installation, including editing the Release: entry in the spec file. Otherwise when yum update is executed, you run the risk of damaging your client systems setup. Taking the MySQL 4 example, if new php rpms are released, and your systems have your customized php-mysql rpm installed, if your systems update using Red Hat's distributed rpm, your MySQLinstall will be downgraded back to version 3
  2. When you add new rpms to your custom yum repository, you must re-run the yum-arch command, otherwise yum will not pick up these newly added rpms