RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2004572 - [RFE] Stream 9 dnf-automatic
Summary: [RFE] Stream 9 dnf-automatic
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: distribution
Version: CentOS Stream
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: RHEL Program Management
QA Contact: Release Test Team
Depends On:
TreeView+ depends on / blocked
Reported: 2021-09-15 15:01 UTC by Pat Riehecky
Modified: 2023-03-15 07:27 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2023-03-15 07:27:54 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELBLD-7465 0 None None None 2021-09-15 15:02:34 UTC
Red Hat Issue Tracker RHELPLAN-97266 0 None None None 2021-09-15 15:02:36 UTC

Description Pat Riehecky 2021-09-15 15:01:44 UTC
Description of feature:

Enable automatic notification of updates for CentOS Stream 9

User Benefits:

Automatic notification of updates on a regular basis encourages folks to apply pending updates (and not forget security fixes).  Professional admins can trivially disable this to accommodate their patching cycles.

This default would bring the system closer to the recommended settings from SCAP Security Guide.

Requirements / Use Case/Proof of Concept / Partial Development demo :

* add `dnf-automatic` to comps.xml @BASE as a "default" package
* set `dnf-automatic.timer` to enabled via `system-preset`
similar to `90-default.preset` for centos-stream-release

Version-Release number of selected component (if applicable): Stream 9

Actual results:

Stream 9 is a continuous delivery OS but, if folks don't apply the
updates, are they delivered?

Additional thoughts:

Personally, I'd lean towards an "apply the updates" workflow, but a number of folks expressed concerns that it would be too aggressive.  This provides a clear midpoint that encourages timely application of updates, without significant overhead.

Additional info:
this is a proposed Feature Request for Stream9

Further reading:

Comment 3 Mike Rochefort 2021-09-15 16:11:07 UTC
Guessing from the the general Linux community sentiments on auto-updates, this will probably end up being a touchy subject. However, for how Stream operates I think this is a good discussion to have.

From a user perspective, I would be okay with an auto-update mechanism if the following two conditions were satisfied:

1) A preference toggle is clearly exposed at installation time for what update method to use (can default the selection to apply+notify), and
2) This only applies by default for interactive installations.

I could be wrong, but I would like to assume that admins authoring kickstart configs for non-interactive provisioning have a stronger update procedure than most. As such, the default value of some "updatepolicy" command should be to not apply updates automatically. I'd lean towards a default of notifying of available updates without downloading said updates over doing nothing. Having this be opt-in for more advanced users sounds like a better option to me.

Comment 4 Phil Perry 2021-09-15 16:16:27 UTC
Am I correct in assuming that we are effectively discussing the policy for RHEL9 here, as what is in Stream9 will end up in RHEL9?

Comment 5 Brian Stinson 2021-09-15 16:26:33 UTC
If we move forward with this feature, this is one instance where CentOS Stream behavior may differ from RHEL behavior.

Comment 6 Phil Perry 2021-09-15 16:34:26 UTC
Hi Brian,

What would be the justification for the divergence in behaviour?

Comment 7 Josh Boyer 2021-09-15 16:55:02 UTC
(In reply to Phil Perry from comment #6)
> Hi Brian,
> What would be the justification for the divergence in behaviour?

The distribution model of the project vs. the product are significantly different.

CentOS Stream is a continuously delivered OS, with no point releases, with updates reflecting the development state of the next RHEL release flowing directly into a single set of repositories.

RHEL continues to have minor releases in 6mo intervals, with updates and bug fixes for those minor releases.  This is not modeled forward to CentOS Stream, and the development binaries of RHEL are conversely not delivered publicly as CentOS Stream provides that.  RHEL channels also require entitlement and subscription.  Further, Red Hat has other tooling and management products in place to help manage and update RHEL instances and long-standing recommended practices.

There is nothing preventing a RHEL customer from enabling dnf-automatic for their installations if that is the management and update strategy that their process and policies prefer.  However, it is highly unlikely that we will make that the default in RHEL.

In regards to the default in CentOS Stream, my personal preference would likely be to do the following:

1) An RFE to configure root notification during installation, having the option for a day 0 operation instead of day 1 configuration after the fact.
2) dnf-automatic defaulting to "notify"
3) An option to opt-into "apply+notify"

While I like the idea of helping CentOS Stream users be more aware of pending updates, I'd hesitate to apply those automatically out of the box.  The cases like kmod-nvidia (or other kmods) will cause issues for a not insignificant number of users.  Further, remediation of bugs introduced becomes harder for cases where an update causes a large impact, particularly if a whole fleet of installations is updated at once as opposed to a few canary updates, etc.

I do like Mike's twist of having this be contingent on interactive installations if we pursue anything.

Comment 8 Matthew Miller 2021-09-19 03:36:56 UTC
I think this is a good idea -- not just notification but apply by default.

I don't think interactive vs. kickstart is a good way to distinguish. There are _plenty_ of kickstart installed systems which would also benefit. And, arguably, the cases identified where there might be problems (kmod-nvidia, say) are _more_ likely to be interactive (single-system desktop) installs.

I think it'd be better to have the default be to set to automatically update, but clearly document a kickstart command to change that. Admins going through building their EL 9 kickstarts will be going through the documentation in doing so, I hope. (And those who don't.... well, automatic updates seems like an _especially_ good choice.)

What about starting with the default of notification but no updates, and at the same time propose a feature in Fedora Server to enable _applying_ updates, with the kickstart command to adjust? Then, after baking in Fedora for a little bit and time to digest and document for CentOS stream, automatic updates could become the default there too.

(Incremental progress towards the somewhat better, times time, is how big change really happens!)

Comment 9 Carl George 🤠 2021-09-21 02:46:39 UTC
I am highly concerned about community blowback if we default to automatically applying updates.  A popular critical narrative is that the goal of the Stream changes are to convert CentOS users into RHEL beta testers.  This is of course false, but this change would fit far too easily into that narrative.

"First you took away my point releases, now you're defaulting me to automatic updates?"

I am in favor of giving users installer and kickstart options to opt-in to automatic updates.  As Matthew pointed out, these should go to Fedora first and be given time to mature, before being brought to CentOS Stream.

Comment 10 Pat Riehecky 2021-09-21 13:07:53 UTC
The thoughts from Matt (https://bugzilla.redhat.com/show_bug.cgi?id=2004572#c8) sound good to me :)

Comment 11 Pat Riehecky 2021-12-03 16:02:29 UTC
Looks like 'notify only' didn't make it for the Stream9 announcement today.  How can I help this move forward?

Comment 12 Pat Riehecky 2022-01-13 18:57:09 UTC
It doesn't look like I've got the relevant rights to submit this as a change proposal for Fedora 36...

Comment 13 Clovis_Sangrail 2022-11-30 21:06:21 UTC
I'm trying to use Centos 9 Stream on my Laptop. I figured it'd be a way for me to get familiar with what's coming on the RHEL servers I support.

But I'm running into stability issues, and the majority of the ones I encounter involve failures of dnf due to broken or incompatible versions of things being dependencies for different packages. This is made much worse by the Windows-Style go-away-I'm-busy-updating-your-computer automatic execution of dnf.

Today it hung on shutdown, and after about 20 min I had to power-cycle the machine, and was fortunate to have it come up. It's become unbootable after I did that at least once before.

Maybe Centos 9 Stream is just too unstable for it to be my work laptop OS, or maybe not. But my experience is that the more-or-less rolling update process is sending out too many updates with installation issues for any kind of automatic update process to be a good idea.

Comment 16 RHEL Program Management 2023-03-15 07:27:54 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Note You need to log in before you can comment on or make changes to this bug.