[CentOS-devel] Stream 9 and dnf-automatic

Based on the discussion noted there, I filed :
https://bugzilla.redhat.com/show_bug.cgi?id=2004572

Pat

On Wed, 2021-09-15 at 10:58 -0400, Rich Bowen wrote:
> There was a little discussion of this topic in today's Board AMA, which
> you can read here: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_minutes_2021_September_centos-2Dmeeting.2021-2D09-2D15-2D14.10.log.html&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=YQ7R12z0Keq1JcXmLY6nY3aFecDI69O5_PjMjNYYoj0&s=9NMQlnqjBeFMYw3Sb5ekkjjLFztZXlDUuqq2l2x0j7s&e=
>  
> 
> On 9/13/21 8:57 AM, Patrick Riehecky wrote:
> > I've been thinking about the defaults in CentOS Stream 9 and wanted
> > to
> > chat about the workflows of the system.
> > 
> > I'd like to make the following proposal to see what people think
> > about
> > it:
> > * add `dnf-automatic` to comps.xml @BASE as a "default" package
> > * set `dnf-automatic-install.timer` to enabled via `system-preset`
> > similar to `90-default.preset`
> > 
> > Before imminently saying "No, absolutely not" lets look at the
> > workflow
> > options:
> > 
> > When setting defaults for updates, there are a few choices:
> > * do not apply
> > * notify the user/admin
> > * apply and notify the admin
> > * apply but do not notify
> > 
> > The "apply but do not notify" option feels like a non-starter to me.
> > Silent system changes are not good.
> > 
> > The current default in CentOS Stream 8 is "do not apply".  I've no
> > interest in changing CentOS Stream 8 on this front.
> > 
> > # I'd like to ask, is this a good default?
> > 
> > For professional admins with a clear policy on testing and scheduling
> > updates, I believe it is a good default.
> > 
> > For novices who may not have these processes and procedures in place,
> > I
> > believe this is not a good default.  For these folks I'd recommend
> > "apply and notify the admin".
> > 
> > # Why change?
> > 
> > I'd like to ask a specific question: 48 hours after the release of
> > update packages for Heartbleed or ShellShock, how many CentOS systems
> > in - in their default configuration - installed the updates?
> > 
> > Or perhaps a more pointed question, how many folks running EL7 still
> > haven't applied those patches?
> > 
> > If the default was "apply and notify the admin", we'd be confident
> > that
> > most folks out there are patched.  The default state would generally
> > result in more secure hosts as the updates get applied.
> > 
> > Stream 9 is a continuous delivery OS but, if folks don't apply the
> > updates, are they delivered?
> > 
> > The current recommendations from the scap-security-guide are:
> > - install and enable dnf-automatic
> > - configure dnf-automatic to apply updates
> > - set a location for `root`'s email via /etc/aliases
> > 
> > This is an "apply and notify the admin" workflow.
> > 
> > Scientific Linux defaults to "apply and notify the admin".  The SL
> > community is comfortable with this default.
> > 
> > # Why is the default "do not apply"?
> > 
> > As I see it there are basically a few options:
> > 
> > A) any change to the system state creates risk of unplanned
> > outage/bugs/behavior changes.
> > B) as a community we trust system admins to "do the right thing" for
> > their environment.
> > C) if we publish a buggy update and it gets applied by default, that
> > isn't great for our reputation.
> > 
> > Argument (A) is really strong.  Sites with a clear policy on testing
> > and scheduling updates have those policies explicitly because of
> > these
> > risks.  To be clear, I like and support those policies.  Everyone
> > should have them.  But not everyone does.
> > 
> > I think Argument (B) can bend in any direction.  If we can trust an
> > admin to "do the right thing" and install updates on a schedule of
> > their choosing, can we not also trust them to add `systemctl disable
> > dnf-automatic-install.timer` to their kickstart/puppet/ansible/etc?
> > As
> > a default, but - not mandatory package - it could also be excluded
> > with
> > `-dnf-automatic` in the `%packages` section.
> > 
> > I'm not sure that Argument (C) is terribly strong.  A giant botnet of
> > unpatched hosts isn't great either.  I'm not sure that is our
> > responsibility, but "safer defaults" feels like a good call.
> > 
> > 
> > # Further reading
> > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_AutoUpdates-23Why-5Fuse-5FAutomatic-5Fupdates.3F&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=YQ7R12z0Keq1JcXmLY6nY3aFecDI69O5_PjMjNYYoj0&s=-l1Giyi9YT_QfuttalORuJ1iClDvklzrK67zmuGGtko&e=
> >  
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ComplianceAsCode_content_issues_5180&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=YQ7R12z0Keq1JcXmLY6nY3aFecDI69O5_PjMjNYYoj0&s=wA85H881TwSzU8F-yZYdveXNvON1TFdskjFhreEWDOI&e=
> >  
> > 
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos-2Ddevel&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=YQ7R12z0Keq1JcXmLY6nY3aFecDI69O5_PjMjNYYoj0&s=ouv4NPZknlLZAqN2SFu4RrZP3Op8cLYX8DJdVDxcoDo&e=
> >  
> > 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos-2Ddevel&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=YQ7R12z0Keq1JcXmLY6nY3aFecDI69O5_PjMjNYYoj0&s=ouv4NPZknlLZAqN2SFu4RrZP3Op8cLYX8DJdVDxcoDo&e=
>