- Posted In
- Red Hat Enterprise Linux
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?