Home / server / Questions / 602335
Accepted
Koen van der Rijt
Asked: 2014-06-07 04:09:29 +0800 CST

YUM, "patchlevel" and the DTAP street on redhat/centos

  • 772

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.

centos

2 Answers

  1. 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.

    • 1
  2. Best Answer

    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.
    • 1