Bug 1489595
| Summary: | dnf-automatic in 2.x is not compatible with 1.x, this is not explained in the docs anywhere, docs for new timer-based approach are unclear | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
| Component: | dnf | Assignee: | rpm-software-management |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 26 | CC: | cdonnell, dhgutteridge, fleite, jmracek, kevin, kparal, lslebodn, mluscon, packaging-team-maint, rpm-software-management, vmukhame |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | dnf-2.6.3-11.fc26 dnf-2.6.3-11.fc27 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-09-14 21:55:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Adam Williamson
2017-09-07 20:38:09 UTC
As well as this not being documented at all (AFAICT), there doesn't appear to be any effort made at all to provide some kind of warning to the sysadmin. I can think of all sorts of ways to do this: for instance, if `download_updates` or `apply_updates` are set in automatic.conf but no timers are enabled, print a warning any time the admin runs dnf. Or, include a dummy dnf-automatic.service - the name of the catch-all service from 1.0, which doesn't exist in 2.0 at all any more - which causes some kind of notification about the transition. It is also not mentioned in the Fedora 26 Release Notes: https://docs.fedoraproject.org/f26/release-notes/ Marking private for now in case we treat this as a security issue. Sorry, bit of a correction: https://dnf.readthedocs.io/en/latest/automatic.html *does* mention the timer units, but it *also* still covers the config file directives, and doesn't make any attempt to explain why there are two apparently conflicting mechanisms, or reconcile their practical effects. As nearly as I can tell, when dnf-automatic *does* run, it will still read and respect the config file directives. So this is actually just even more odd. You have to enable one of the function-specific timer units to get dnf-automatic to run automatically at all again - but since the config file directives are still considered, you can't actually guarantee that any of the timer units *actually* only does what it says it does. By which I mean: if you enable dnf-automatic-notifyonly.timer , despite the name, if your automatic.conf has `apply_updates = yes` in it, then when the timer causes dnf-automatic to run, it will apply the updates. So really this is just an ungodly mess... My suggestion for fixing this, btw, would be:
* Keep the config file directives
* Make the CLI args boolean (right now they can set True but not False)
* Re-introduce plain dnf-automatic.{service,timer} , which calls the binary with none of the relevant args specified in any way (and thus behaves exactly as the config file says)
* dnf-automatic-notifyonly.service would pass --notify=yes --download=no --install=no (or whatever the exact syntax is)
* dnf-automatic-download.service would pass --notify=yes --download=yes --install=no
* dnf-automatic-install.service would pass --notify=yes --download=yes --install=yes
* Fix up the docs (and config comments) to explain all this properly
This should fix all the problems. Existing configurations would work as they did before (via the resurrected dnf-automatic.service), and the behaviour of the action-specific timers/services would no longer be affected by the configuration files.
dnf-2.6.3-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-750b4f0a28 dnf-2.6.3-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b629284474 dnf-2.6.3-11.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f2f4fe090e dnf-2.6.3-11.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9fe37c9984 dnf-2.6.3-11.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f2f4fe090e dnf-2.6.3-11.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9fe37c9984 dnf-2.6.3-11.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. Bug https://bugzilla.redhat.com/show_bug.cgi?id=1473892 is likely addressed by this change. I've enquired in that ticket. dnf-2.6.3-11.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. |