content views and erratum

Latest response

I have CVs dated the first of the month (RH7_020119 for example). A hostgroup would be assigned that so non-prod would be patched mid Feburary, and production in March but use the same patches. So far so good.

But I also want to apply certain Critical/Important security updates on these hosts (python for example) that have come out after this date.

I've found this link which suggests adding erratum to CVs as an incremental update (https://access.redhat.com/solutions/2111051). Before finding that I had thought about making a composite CV that would include the RH7_020119 as well as RH7_Security CV - with a filter to include just the updates I want and then re-subscribing the clients to the composite.

Best way do do this? Can an existing CV have a filter that says "I don't want anything after Feb 1st, except for these erratum"? I don't really see an option on the filter for "or" just "and".

Thanks - Greg

Responses

Well for posterity sake I've created a security content view with activation key. Re-register client with original and new key, with the security key listed last. Was hoping for a solution that doesn't require a register --force.

Err, scratch that. Multiple activation keys doesn't work. The solution posted on the above link is the way to go (minor rev)...I just had neglected to promote it after creation.

There are three theoretical options how to achieve this:

  • use some filtering magic inside a CV. There might be some trick how to achieve that but I am not sure it exists. And such a solution would be quite hard to maintain, and error-prone.
  • use incremental versions of CV - probably the most flexible solution when you simply apply an errata you want to any host at any time you just need it. Doing so for a Content Host in a CV will then create a minor version of the CV. Then you "just" need to ensure the next version of the CV (i.e. next month, usually), contains all the errata you applied this way.
  • use composite content views - I think the best solution from maintainability point of view. Since Satellite 6.4 and auto-publish option of CCVs, automation is very similar like for incremental versions of CV.

Thanks. To satisfy my immediate need I used the incremental method. It worked well, but I just tried the composite method (keep hosts assigned to a composite CV and then move date or security related CVs in and out of them). I have been separating my CVs by version, but perhaps that is not necessary since non-applicable yum repos would be ignored. THat should help contain CV sprawl.