Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a way to make yum update to a certain patchlevel?

I always promise my devs the servers between Dev, Test, Acc and Prod are the same with versions of software. But when u use yum via the redhat network it will just update to the latest versions regardless.

the problem arrives when u roll out to a server beyond dev or Test. You can of course exclude important packages from this update process. But al kinds of other packages will still update to a newer version if there is a new version available since u updated last. This way your servers wont exactly be the same.

Is there a way (via yum) to be certain you will get the exact same package configuration as the other servers in your DTAP street.

share|improve this question
up vote 1 down vote accepted

This is the beauty of configuration management... E.g. using Puppet, I could ensure => latest or even ensure => '1.2.2-7.el6'

Can you please give an example of the particular packages whose versions you wish to control?

I ask because this is Red Hat/CentOS, and a tremendous amount of effort is made to keep the major versions of packages compatible between minor revisions throughout the server product's lifetime. In reality, it shouldn't matter if you're running package-0.17-39.el6 or package-0.17-43.el6. Not to mention the bug and security fixes that are constantly backported...

So in some respects, my dev, test and production servers look alike only in that they are the same revision of RHEL/CentOS and have the same packages. But minor versions may change, depending on circumstances like install date, patch schedule, uptime/availability requirements, hardware platform, etc.

My advice:

  • pin the specific versions of packages that matter to you (either by yum, local repo or config management).
  • disable autoupdates.
  • develop a patch schedule that encompasses your entire environment.
  • revise your build process.
  • implement configuration management, of course.
share|improve this answer
I indeed have some exclusions for important software (database etc) It just seemed really awkward that there wasnt "a button" I started using puppet a couple months ago. We will look into it for config mgmnt. Thanks for the input – Koen van der Rijt Jun 6 '14 at 12:39
We used this approach too but even minor changes of libraries broke our application a few times. After that whenever there was even the slightest problem dev/QA always asked us to verify that it wasn't again related to minor version changes. To avoid this we went the way I describe in my answer... – faker Jun 6 '14 at 12:43

We do this by having local mirrors of CentOS repositories (+ all other software that we use) and configure all our servers via configuration management systems to only use internal mirror repositories.

That way we can control the exact time patches show up in the repo.
Newly installed servers will have the same packages just like the already installed systems (during kickstart we already point to our internal mirrors).
We have different repository servers for QA and production.
That way we can also test patches first on QA servers and then sync this repository to the production repository.

There might be more complex systems to manage this (spacewalk?) but this simple solution worked all right for us.

share|improve this answer
I was afraid of this ;-( was hoping I overlooked something.. but thanks for the answer! – Koen van der Rijt Jun 6 '14 at 12:33
Yeah, Spacewalk does all this for you. So if you're starting fresh it's worth looking into. – Michael Hampton Jun 6 '14 at 15:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.