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= >