fbpx
1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

How to Setup a Local Redhat 5 Update Repository

windchill features best plm software
Written by SPK Blog Post
Published on September 1, 2011

In a previous post, my colleague Mike described how to setup a Redhat 4 (RHEL4) local update repository. With Redhat 5 (RHEL5), the procedure to setup a local repository has changed somewhat. At SPK, we often will setup a local update repository for Redhat or Debian/Ubuntu-based Linux servers as part of our infrastructure management service. Setting up a local repository reduces overall patching time and WAN bandwidth significantly which means less downtime and happy users.

For this example, I’m going to be setting up a local repository on a file server that also is an NFS server which has an NFS export directory named /updates that all servers in the organization can mount. There are a few requirements in setting up a repository in this fashion:

  1. You need to have a fairly fast WAN connection to the internet. The initial sync with RHN (RedHat Network) can take quite a while, even on a 10Mbps link.
  2. You need to have a valid RHN subscription for every RHEL5 server you plan to use with this local repository. If you don’t want to purchase a subscription, consider installing CentOS.
  3. Good amount of free disk space on your NFS mount point. My recommendation is at least 50 gigs free if not more.

First, choose a server that you’d like to handle downloading from RHN. I typically like to utilize a machine that is not as heavily used as others, but if that’s not an option for you, choose the fastest machine. Make sure you setup a permanent NFS mount for /updates in your /etc/fstab file so that directory is always available even after reboots. You could set it up as an automount as well, but that is beyond the scope of this procedure.

Next, you’ll need to register your server with Redhat by typing the following command as root:

rhn_register --nox

The –nox parameter forces registration to stay at the command line and not go to the GUI.

Now, if you haven’t already, download the yum-utils package from RHN. This includes the reposync command which will be doing the heavy lifting for this procedure.

yum install yum-utils

Now it’s time to sync the RPM packages from RHN to your local server. Type the following command to start the process:

reposync -p /updates --repoid=rhel-x86_64-server-5 -l

This will start the sync process. You can choose which repoid you want to sync by issuing the “yum repolist” command and selecting a specific one. This sync will take a bit of time depending on your WAN connection speed. After it finishes, we need to make the downloaded RPM packages into a Yum repository. We use the createrepo command to do this. Depending on your RHEL distribution, this could be a separate package or part of the yum-utils package. Issue this command to create the repository:

createrepo /updates

This will scan all of the RPMs in that directory and create a repository. Also, if you have 3rd party RPMs, you can add them to the /updates subdirectory and they’ll be added to the repository as well.

After all this, you now have a local repository! But, you’ll need to let other machines in your network know how to access it. Here’s a sample entry for your yum.conf file:

[rhel-baserepo]
name=Base Red Hat Enterprise Linux $releasever - $basearch
baseurl=file:///updates/rhel-x86_64-server-5
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

Now type “yum repolist” from the target machine and you should see the new local repository being loaded. You have now successfully setup your own RHN repository.

One final thing. We need to keep the repository updated every night with fixes from RHN, so I recommend running a shell script via cron to accomplish this. You’ll basically need to run the same commands you did in the initial setup. I typically run it once a day at around 2am so as not to disrupt any users.

That’s it! Feel free to comment below with any questions or ideas you might have regarding this topic!

Bradley Tinder
Systems Integrator, SPK and Associates

Latest White Papers

A 3-Phase Approach to Automated Software Delivery

A 3-Phase Approach to Automated Software Delivery

Is your software delivery process outdated? Modernizing your software delivery workflows does not have to be difficult. Explore this eBook to discover how GitLab can help you modernize your software delivery pipelines. What You...

Related Resources

The Pitfalls of Outdated Tools in Managing Global Teams

The Pitfalls of Outdated Tools in Managing Global Teams

The dynamics of product development have shifted dramatically in the past 5 years.  Teams are no longer confined to a single location or even a single time zone.  Instead, they span continents, collaborating across borders to bring products to market faster than ever...