Suggestions, help, with katello patching groups


I am new to Foreman and have been left a large CentOS Linux environment that has not been cared and fed for a while. In any event, what is the best practice or suggested method for grouping machines into different content patching groups? What are you guys doing?

I have dev, qa, test, and production hosts. So if I wanted to just deploy certain patches to one environment first like test, is the idea to create a new organization for each content patch group, or should I create a new life cycle environment for each group? What are you guys doing for this.

Just looking for some guidance thank you in advance.


the suggested method would be using one (or more, depending on your needs) lifecycle environment paths with different lifecycle environment environments. This is especially usefull if you want to stage your updates to make sure nothing breaks in production. With LCEs, the hosts that shall not be updated at the moment won’t even see the new package versions. This setup can be a little pain when you have to push security updates fast through all environments, but it’s generally woth the trade in my opinion.

We have realized an additional level of grouping via host collections to realize different time windows for patching certain systems. This is especially usefull for stuff like clustered applications. We then schedule the updates via foreman-rex based on LCE and filtered by host collections in advance and can then usually just roll with that.


1 Like

I want to add to areyus suggestion that security update handling gets much easier when you add errata to a repository enabling you to create incremental versions of a content view. This means some extra work for CentOS as they do not provide errata metadata and you need some additional tooling for it. I really hope with the switch to koji as build environment they will add errata to CentOS 8. And for third party vendors you will typically have no erratas at all.

For different patch groups like clustered application I recommend a look at the distributed lock manager which could be integrated in the update process to prevent multiple nodes doing updates at the same time.

1 Like

Thanks for the suggestions guys.