[CentOS-devel] Stream 9 and dnf-automatic

Patrick Riehecky

riehecky at fnal.gov
Mon Sep 13 12:57:02 UTC 2021


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



More information about the CentOS-devel mailing list