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