[CentOS-devel] Stream 9 and dnf-automatic

Wed Sep 15 14:58:03 UTC 2021
Rich Bowen <rbowen at redhat.com>

There was a little discussion of this topic in today's Board AMA, which 
you can read here: 
https://www.centos.org/minutes/2021/September/centos-meeting.2021-09-15-14.10.log.html

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://fedoraproject.org/wiki/AutoUpdates#Why_use_Automatic_updates.3F
> https://github.com/ComplianceAsCode/content/issues/5180
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>