Using `yum` to Update all installed RPMs to a target installation-set

Latest response

Currently, we do provide monthly updates for our production RHEL systems (actual updating is optional, but the update mechanisms are at least made available).

Basically, each month, one of our build engineers takes a reference system and does a generic `yum update downloadonly` kind of "install" to generate a list of RPMs to bundle up and push out to our production systems as a montly release bundle. We refer to these release-bundles by way of an X.Y.Z designation. If a given RHEL 5.x release has been out for three months, our internal release number would be something like "5.6.3". This allows the various programs we host to be able to request a specific combination of RPMs that they certify their applications against in a predictable way (such that, if they need to rebuild a system or stand up a new partner system, they can be assured that the newly-built system matches what they took through their certification process).

Soon, we will be deprecating the system patching framework that we leverage for this and go to a model where we maintain things via Satellite. However, we want to maintain something analogous to our internal release model/system. I found an article on access that sort of speaks to this topic. However, when I went to test to see how it actually played out, doing a yum update <KernelVersion> seems to be fine with updating my kernel, but it doesn't grab all the RPMs that we'd typically associate with that kernel as a "monthly release".

I've Googled around and seen people saying that the way to address it is with custom channels. Will this is an avenue that's likely available to other environments, it likely won't be available to us. Along with jettisoning our current software distribution framework, we'll also be losing overall ownership of our software repositories. That means no ability to maintain custom channels. So, is there a way to preserve our previous release-style from repos that don't have custom channels? I looked at an old Satellite server we have in our labs - and it appears to have all of the kernel (and presumably other) RPMs on it from its original standup up through its last update. So, presumably, one could emulate our prior release-model using a Satellite-type repository. The key is how to most easily/efficiently do it. I suppose we could push out a "request these RPMs" script to Satellite-registered systems and have them update themselves, but is that the best/most efficient method?

Responses

Custom channels are the ideal thing for you. You just pick a date you want the channel synced to, and Satellite does the rest. This even works historically, we often see people pick the date before another minor release goes GA, so you can get "the latest RHEL X.Y" without going to "RHEL X.Z". This would also allow you to very precisely make your "RHEL X.Y.1, X.Y.2" and so on. I write this in the hope it helps you make a business case for permission to manage your own custom channels.

The reposync command allows you to do this manually, and only for what is available "right now", not historically, and only works for a similar major version and architecture. ie: You can only get RHEL 6 x86_64 updates by running reposync on a RHEL 6 x86_64 system, so you need one "reposync server" for each major version and architecture you use.

Its usage is briefly covered at:

 How can we regularly update the system without internet connection ?
 https://access.redhat.com/knowledge/solutions/29269

Thanks for the answer, but notice that I'd indicated that I was already aware of the custom channels options but that it likely was a non-starter for us due to

"Along with jettisoning our current software distribution framework, we'll also be losing overall ownership of our software repositories."

Basically, we're losing funding to continue maintaining our own software-distribution system. We're being forced to rely on another group's Satellite service as a (semi) replacement. As we don't own that service, nor do or will we have administrative rights to it, nor can we prescribe how it's set up to support our specific needs, implementing custom channels is simply not possible. Thus, custom channels are an absolute non-starter for us and needing to find an alternate method for accomplishing an end that might more normally be accomplished through custom channels.

Yes, I understand. I wrote the description of the Satellite custom channels in the hope that you may be able to present a business case to your management and have processes changed within your company.

If that's a no go, then reposync will do what you're after, just with less flexibility.

The problem is that processes are changing - towards stance that undercuts good configuration management and control. The best I can hope to do is minimize the damage.

Oh well, the joys of "consolidation".