On 13.09.21 14:57, 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
Just my assessment - either notify-only via email or/and install updates, both needs proper configuration. It falls for me in the same category as services with network sockets open to the public - they are also not enabled by default.
Maybe a stdio emitter as default to log into the journal could be enabled as standard?
It seems to be already the default:
# grep ^emit_via /etc/dnf/automatic.conf emit_via = stdio
-- Leon