My company uses Red Hat Satellite to approve & download the patches needed for each system.
However we deploy the patches using Bigfix so we can schedule them from a central source.
We have RHEL 7.6 installed, and if we use satellite directly, only patches relating to 7.6 will be installed. However, BigFix shows all 7.7 patches as being relevant.
This is fine in a way because we can select to install everything in BigFix, but it will only be successful for 7.6 patches due to the approval in satellite.
What I can’t figure out is how to report only 7.6 patches needed.
We have a system that is fully patched with 7.6 patches, but it still shows >200 fixlets as relevant because they are for 7.7. I would like to report on the compliance level for the installed version.
It’s hard to justify using bf for linux patching if it shows low compliance compared to satellite which shows 100% compliance.
Yeah, it is a tricky problem. You’re asking BigFix to not tell you when something is applicable. If there were enough demand for it I suppose we could maintain separate fixlet sites for each minor release, but so far I haven’t much seen anyone ask.
And in fact it’s not quite my recollection of how the fixlets are coded but I haven’t had time to rebuild my RHEL server to check.
It’s not listed as needed in Satellite for 7.6 because I’ve been advised that this vulnerability only affects 7.7.
Since Bigfix uses Satellite in our environment, it fails to install but it’s still reported as relevant. So while the computer is 100% compliant with 7.6 patches in satellite, it’s showing 200+ patches are needed to be compliant due to 7.7+ patches needed
IMPORTANT
It is important to understand that updates to non-current or older minor releases will not include all Security and Bug errata. Please refer to theRHEL Life Cycle documentation and the Extended Update Support (EUS) Add-On for further details.
Based on their lifecycle, “mainstream” support for each minor version ends immediately upon release of the next minor version, and the older one then enters the “Extended Update Support” phase which may require a different set of repos (or possibly even contracts, I’m not sure on that point).
In short, I think that if you remain on 7.6 you will remain vulnerable to any of the bulletins issued for 7.7 (or later) releases of 7.x
I’m not a Unix guy so my information is coming from those engineers, please excuse any of my misunderstandings as well.
Some of our customers subscribed to EUS, but that shouldn’t be too relevant here.
If you don’t lock to a specific version you are assumed to be on the “latest” release, however, RHEL provide full support for both the latest and the latest -1 versions, and the process to move from one release to the next needs to be a planned step, as additional features and changes will break some applications.
So, in more concrete teams, 7.8 is now the latest, but RedHat is still releasing all patches for both 7.8 and 7.7 including all security patches. Most customers will not move to 7.8 immediately, but are fully covered by staying on 7.7 for a period of time (approx 6 months), however the report does not indicate that is the case, as the patch “numbers” are slightly different.
My example earlier is probably not the best now that 7.8 has been released. So if I change 7.6 to 7.7 the same problem still occurs as I could install all patches to the 7.7 according to Satellite, but Bigfix will still not report full compliance since 7.8 fixlets would be relevant.