update-and-reboot via dnf-automatic / unattended-upgrades?

[markuslf]

Idea

The system_update role ships a hand-written update-and-reboot script that applies all updates, decides whether a reboot is needed, sets an Icinga downtime, and reboots. Red Hat (dnf-automatic) and Debian (unattended-upgrades) both ship native, distro-maintained auto-updaters. Could we drop the custom script and delegate the core mechanics to these tools, keeping only our orchestration glue?

Possible solution

Use the native tool as the update/reboot engine and reattach our extras through its extension points:

• dnf-automatic.conf: apply_updates = yes, reboot = when-needed, upgrade_type = default, plus reboot_command and a command_email emitter pointing at wrapper scripts.
• unattended-upgrades: Automatic-Reboot "true", Automatic-Reboot-Time, Origins-Pattern for the security case, Mail for notifications.
• Icinga downtime and kill httpd/apache2: on RHEL via reboot_command, on Debian via DPkg::Post-Invoke or a systemd drop-in (no reboot-command hook exists there).
• pre_update_code / post_update_code, AIDE update, rpmnew/rpmsave detection: systemd ExecStartPre / ExecStartPost drop-ins.

Pros

• The update-and-reboot-decision core is delegated to a maintained, distro-native tool instead of reimplemented in shell.
• The security lane maps reasonably onto upgrade_type = security (RHEL) and security Origins-Pattern (Debian).
• Notifications fire before the reboot on both tools, so the existing mail/Rocket.Chat reporting can be preserved.

Cons (findings from inspecting the installed and upstream source)

• Weaker reboot detection on both, a regression. Our script also reboots when a running service still links an updated library (needs-restarting without flag on RHEL, needrestart -p on Debian). The native tools do not do this. dnf-automatic's reboot_needed() is a hardcoded package allowlist (9 packages on RHEL 8/9's dnf4 4.14: kernel, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon, microcode_ctl; a couple more upstream), checked only against the names changed in the transaction. unattended-upgrades only checks for the /var/run/reboot-required flag, with no needrestart integration and a hardcoded shutdown -r (no reboot-command hook). An OpenSSL, glib2 or zlib update that running daemons link would not trigger a reboot under either tool. Security-relevant, not cosmetic.
• No post-transaction, pre-reboot hook. Both run a fixed apply -> notify -> reboot sequence with the reboot triggered internally at the very end. AIDE update, rpmnew/rpmsave handling and post_update_code have to run before the reboot, so they end up split across reboot_command (only runs when a reboot happens) and ExecStartPost, which introduces a reboot-timing race.
• Asymmetric extension points break cross-distro consistency. dnf-automatic offers a configurable reboot_command; unattended-upgrades hardcodes shutdown -r <time> with no command hook. The orchestration glue would have to be wired up through different mechanisms per distro.
• Security-lane semantics differ. dnf-automatic filters by security advisory metadata, whereas our security lane isolates a dedicated frozen security repository via --disablerepo/--enablerepo. Not a drop-in equivalent.

Conclusion (current lean: negative)

Replacing update-and-reboot wholesale looks like a net negative. To keep today's reboot coverage we would have to disable the native reboot feature and keep our own reboot decision plus orchestration in a wrapper, at which point the wrapper is essentially the current script minus its one yum update / apt upgrade line, in exchange for an extra dependency and more moving parts. The only genuinely attractive target is the security lane, and even there the advisory-versus-repo-isolation difference needs a closer look. Posting this to capture the analysis and gather other opinions before anyone reinvestigates.

[NavidSassan]

I agree with the conclusion, does not make sense for us right now