[rhn-satellite-users] Re: [rhn-users] Strange application of an errata today

[inode0]

On 3/19/07, Clifford Perry <cperry at redhat.com> wrote:
> inode0 wrote:
> > I'm not sure whether this is a hosted or proxy issue and I'm not sure
> > if it is operator error or something else that caused it. We have a
> > hosted environment running a current release proxy server with custom
> > channels. A product enhancement errata was released for some of those
> > custom channels a couple of days ago and today it was scheduled for
> > every system subscribed to the pertinent channels (or so it seems at a
> > glance).
> I assume you are talking about Red Hat Errata, and not Custom Errata.

No, the errata that went wild is a product enhancement errata for some
custom channels, I guess that makes it a custom errata.

> > Question 1: Should this errata be scheduled for machines which don't
> > have any relevant package installed? It was but this seems silly. They
> > picked it up and failed to install it harmlessly.
> No - not by default.
>
> > Question 2: Should it be scheduled for systems with auto errata update
> > set to no? It was. I can't tell how the scheduling is done, it is
> > listed as (none).
> >
> No. (none) is normally used by RHN when auto-update is kicking in,
> rather than a user logging in to schedule a task, which will then list
> the user.

So is there something different here given that this was a custom
errata? Or do we have a scheduling bug on the RHN side?

> > Question 3: Should systems with this errata scheduled but which have
> > auto errata updates set to no pick up the package and install it when
> > doing the next rhn_check? They did. This caused major grief as it
> > broke openAFS in this case and it seems to me that this should not
> > have happened.
> Yes.

Right, I wasn't thinking clearly here. Once scheduled, the errata
would be picked up regardless of the auto errata update flag. So the
scary part here is that the errata was scheduled for *many* systems
with auto errata update set to no and that is supposed to protect them
from having this happen. Many systems also had this scheduled when
they were subscribed to relevant channels but did not have any of the
packages relevant to the errata installed. We'll hold off on releasing
any further errata as a precaution for the time being.

Thanks,
John