As I’m testing & prototyping products, content views, & lifecycle environments, I’m discovering that hosts provisioned to a [composite] content view that was promoted & published but isn’t completely current to the available external repositories will be tagged as having “Security errata applicable” on the “Hosts/All hosts/” page in the GUI. Executing a “yum clean all” and “yum check-update” on the hosts in question show no updates available, nor does the Errata tab in “Hosts/Content Hosts/”.
Unless I’m completely missing something, shouldn’t the “Hosts/All hosts/” show no applicable errata in this case? Likewise, the “Hosts/All hosts” should not show a red problem/applicable errata icon next to these hosts. My intent is to get to a staged release methodology where I can push content at a particular point in time through successive stages of host operation, i.e downloads -> development -> QA -> production.
Katello master is running on a fully patched CentOS 7 host, with the release versions of Katello & The Foreman.
katello-3.14.1-1.el7.noarch
foreman-1.24.2-1.el7.noarch
And something I just noticed in “Hosts/Content Hosts/” on the Errata tab: I have a choice of “Library Synced Content”, “Previous Lifecycle Environment” or “Current Lifecycle Environment”. If I pick “Library Synced Content”, then I get errata that could be applied, but only after a content view (or more) get new versions published & promoted.
To my way of thinking, and in the way that I’m building products, content views, etc., the errata should not be considered to be applicable until available in appropriate lifecycle environment.
Is this the intended behavior? If so, anyone who’s looking at “Hosts/All hosts” or the detail entries would need to understand that the errata available flag is not necessarily accurate as the hosts won’t have visibility until content is promoted through.
From my experience, this is intended behaviour.
You also need to understand that there is a difference between applicable and installable errata, as seen under “Content -> Errata”. Applicable errata are the ones that affect a system in question, installable errata are the ones that actually can be installed on the system (due to Content View and LCE situation).
I assume the reason why this behavior is chosen (at least by default, I do not know if this is configurable) is due to the fact that it is more important to most people to know if there are security errata available at all rather then if a system is “complient” with the current staged patch set. It’s a trade-off between “lifecycle view” and “operating view”.
We have a similar setup to the one you are aiming for and we decided to educate our users about the meaning of that warning.
@areyus, if you’ve got any sort of a reasonable patch cycle in place, errata will be covered. Yes, I know, in the case of a zero-day or the like, an out of cycle patch may be necessary. And yes, I do grok the difference between installable and applicable (see zero-day issues.)
Setting the “Installable errata from Content View” to yes is the behavior that I expect.
Any hosts that are built to standards, i.e. an appropriate lifecycle environment with the right content views, etc., should be listed as fully patched. When I publish new versions of content views, and promote into the lifecycle environments, then I expect to see that errata can be installed.
I don’t disagree in the least that there does need to be a method to determine if any downloaded errata could be applicable. This is the poster child case for zero-day exploit remediation, and what I expect to see in an applicable errata list.
