We have a fairly strict patching process that we have to follow:

  1. Patch a development or testing machine
  2. Wait one week to see if it explodes
  3. Patch the corresponding production machine to the same package versions

I can't seem to accomplish this with yum, as it insists on updating the packages to the latest version on the production servers. Has anyone else developed a workflow/procedure to accomplish this?

I've tried:

  • Mirroring packages locally and controlling when the mirrors are updated. But, since some systems are tied to license numbers (Oracle Linux in this case), I don't think I can mirror those repos.
  • Disabling the yum-updatesd daemon and running yum check-update on both the production machine and testing at the same time. But, later when I run yum update -C to try and update from cache, it fails (Something with EPEL).

The right way to go about this is doing exactly what you recommended. Set up a local update server and point all of your systems at it. That way you can control when your packages get updated. That may not solve your licensing question, you will need to contact your sales rep and talk to them.

Since you talk about yum, I'm going to assume you're using RedHat or a derivative. If you're using RHEL, then look talk to them about Satellite and whether or not you're licensed for it. Otherwise, look into the Spacewalk project. It is the upstream project for RHN Satellite. Between the direct Satellite interface, and the underlying cobbler install, you have everything you need to mirror repositories, manage and report on system patch levels, blah, blah.

Beyond that, you should definitely definitely disable yum-updatesd. Since you are trying to actually follow a patch schedule, you need to take direct control of when updates get applied. Whether you do this by manually logging into systems and running updates or having a cronjob to apply updates for you will depend on your comfort level and discussion with your change management office. I do, however, strongly recommend going the automated route. Historically, cron has been significantly less likely to get distracted and forget to perform a task than the human counterparts.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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