Managing custom quaterly channels in 5.6.0
Hi All,
Im planning to roll out a quarterly patch set of channels for my small linux estate (less than 50 servers).
My plan is to do the following:
- take a clone of the Redhat channels (that sync with Redhat every night) every quarter and store them in a separe child channel of the Linux version they refer to i.e.
Rhel 6 x86_64 Server (parent channel owned by Redhat)
EPEL
Server Optional
etc...
Rhel 6 (parent channel created by me) (empty)
RHEL 6 2016 Q4 (clone of Rhel 6 x84_64 Server parent channel above)
RHEL 6 2017 Q1
RHEL 6 2017 Q2
- also take a quaterly clone of the Server Optional, EPEL, Hardware Tools, etc channels and store them separate child channels under the Rhel 6 parent.
This ensures all servers are patched to the same level (e.g. 2017 Q1, 2017 Q2, etc), but it seems like a massive overhead and the Rhel 6 parent channel will get very large (4 channel clones per channel per year (Q1,Q2,Q3,Q4)).
Other options I've considered are:
-
leaving eveything assigned to the RHEL owened parent channel and doing 'yum update' up to a certain date manually, i.e. not doing any clones. Not sure this is best as I also have a number of custom child channels and not sure if I can store these under the main RHEL owned parent channel.
-
creating the clone structure above, but updating the same child channels with updats every quarter. ie. not having q1,q2,q3,q4 for each channel, but only one instead...
Just wondered what people would suggest, if all my ideas are rubbish, or if im kinda going down the right path!
Cheers,
Matt
Responses
There are generally two disciplines you can use with patching and content in Satellite
- define the workflow and move content to the systems.
- define the content and create a workflow to move the systems to the content.
The pros of the former (define the workflow and move content to the systems.) is that it aligns logically with how systems are managed (Dev->QA->Prod), etc. The cons is that (at least with Satellite 5), is that if you run clone-by-date or similar tooling against the same channels you lose the old state of that channel. So if you have a need to reproduce a build from 'SOME PREVIOUS DATE', that may be challenging. In this model you promote content to the systems.
The pros of the latter (define the content and create a workflow to move the systems to the content) is that you get to keep those old channels (the RHEL 6 2016 Q4, RHEL 6 2017 Q1, etc) forever. The cons is that you need to move systems to the new clones when created. In this model, you promote systems to the content.
I've seen various customers do both. It really is a matter of which you prefer. I would say to not do this though: "leaving eveything assigned to the RHEL owened parent channel and doing 'yum update' up to a certain date manually,"
Lastly, take a look at this guide, which covers a LOT of the setup of spacewalk-clone-by-date to do the first model (which can be easily adapted to the latter)
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
