Maintain A Local Repo

NextStep4it has a nice little tutorial on setting up a local CentOS yum mirror using reposync. Maintaining a local mirror has several benefits, and is a recommended practice for maintaining even modest number of servers. Pointing all your updates at a local mirror speeds up patching, reduces bandwidth consumption, and standardizes patch sets across periods of time.

One of the first systems I set up when building a new SuSE environment back in 2006 was to setup a local patch mirror. SLES 8 and SLES 9 allowed mirroring the entire repository locally, as long as you could provide support credentials. I believe that practice changed with SLES 10, but I’m not sure. By the time migration to SLES 10 was being discussed, we were well on our way to switching to Red Hat Enterprise Linux. RHEL was solid for the years that we ran it, but one of the things that always bothered me was how they managed access to the patches.

Since we were used to having our own local repository, one of the first things I wanted to do was replicate the setup. However, RHEL is setup to expect to either grab patches straight from Red Hat’s servers, or to download them locally from a Satellite server, at an annual price of around $25,000, if I remember correctly. The price was high enough that we were not going to easily get it through upper management.

So, we went without for a while, and I missed the local repo each and every time we went to patch our systems. At one point we even maxed out our Internet connection by kicking off a yum update on too many servers at once. In fact, the lack of control over the patching system is one of the reasons we made the switch to CentOS last year. That and the freedom from licensing fees. I understand that there are ways around the restrictions, but when you are operating at an enterprise level, most people involved are reluctant to step outside of the supported box.

Another benefit of maintaining your own local repository is the ability to ensure that all servers in your environment are receiving the same set of patches. Since new patches are released nearly every day, if you are patching production weeks after test, it is almost a guarantee that you are not getting the same set of patches. The best way to do an accurate test of the patches as they flow up from test, to QA, to production is to turn off the sync during patching periods. You won’t get the latest patches, but if you are applying patches on a regular schedule you can ensure that your environment stays relatively up to date and in sync.

For the past year since switching to CentOS we’ve been maintaining a Spacewalk server, which is the open source counterpart of Red Hat’s Satellite. But, since we are moving over to Puppet for configuration management, and still need finer grained control over patching than Spacewalk can give us, I’ll soon be returning to the way we did things with SLES in 2006. As soon as this round of patching is over, we’ll be shutting down Spacewalk and setting up a local mirror, most likely using reposync.