fix(roles/system_update, roles/schedule_reboot): report only what a run actually did

[NavidSassan]

The weekly update mails were misreporting on every host. This started as a review of two weeks of system_update / schedule_reboot mail from a ~24 host fleet, where 20 of 21 "System updated without Reboot" mails on one update day were false.

What was wrong

1. A mail on every update day, describing an earlier run. update-and-reboot used to be queued by at(1) from the "updates are available" branch of notify-and-schedule, so it never ran on a week with nothing pending. Moving it onto its own timer in v8.0.0 made it run every update day, but its closing send_msg stayed unconditional. The body made it worse: a bare yum history info prints the last transaction, so a quiet week produced one mail per host listing the previous week's packages, kernel installs included. A mail titled "System updated without Reboot" whose body was a kernel install that had required one.

The security lane already had the right gate, but wrote a bare yum history info into the reboot spool, so an upgrade that installed nothing after all handed do-reboot an unrelated transaction. On a day where both lanes run, that is the weekly lane's transaction from minutes earlier.

2. AIDE was re-baselined at the wrong time, and unconditionally. The aide --update block sat directly below the RedHat transaction while the Debian transaction runs further down, so on Debian the database was refreshed against the pre-upgrade filesystem and the next aide-check flagged every file the upgrade had touched. It has been that way since the block was introduced.

It also ran unconditionally. The script already detects that aide-check.service was failing beforehand, mails about it and saves the log, then re-baselined three lines later and restarted the unit, clearing the failed state and burying the very finding it had just reported.

3. The Debian lane checked no return codes. A failing maintainer script returns 100, but the run continued into the reboot decision and the closing notification, so a broken transaction produced a success mail or rebooted a half-configured host.

4. The From header was invalid whenever a subject prefix is set. SENDER was built as "$SUBJECT_PREFIX <address>", putting brackets into an unquoted display name. RFC 5322 permits only atoms there, so a strict parser returns an empty address, not merely a mangled display name. Any consumer built on one sees mail with no sender at all. Hosts without a prefix were unaffected, which is why it went unnoticed.

What changed

Each commit is self-contained:

Commit	Change
b09a243a	Capture the dnf transaction id before and after the transaction, report only the one this run created, stay quiet when there is none. Same for the security lane.
6be246a4	Re-baseline AIDE after the transaction on both distributions, and only when the run changed packages and the check was passing beforehand.
e977bb95	Check both apt-get update and apt-get upgrade.
c192278b	Quote the From display name; pass the bare address to sendmail -f.

The reboot checks still run when nothing was updated, so a reboot carried over from an earlier window is picked up either way; its spool entry then says that no packages changed instead of repeating an old transaction.

Behaviour changes worth noting

• A host whose AIDE check was already failing keeps failing, instead of having the weekly update quietly clear it. That is the point of the change, but it is visible in monitoring.
• Hosts with nothing to update go silent on their update day.

Not covered

apt-get update exits 0 when a mirror merely fails to answer, printing a W: Failed to fetch warning and carrying on with the old lists. It only reports a non-zero status for hard errors such as an unreadable sources list, so the new check catches a broken configuration, not a mirror outage. Its stderr keeps going to the journal, where an outage stays visible. Closing that gap needs a Debian counterpart to makecache_with_retry and is deliberately not part of this PR.

Verification

Templates rendered for RedHat and Debian, with and without cache_only, pre/post hooks and Rocket.Chat, all passing bash -n and shellcheck; pre-commit run --files clean.

Behaviour was measured in containers rather than reasoned about:

• dnf, Rocky 9: an up-to-date host running yum -y update again exits 0 with "Nothing to do" and leaves the transaction id unchanged, while a bare yum history info still prints the previous transaction in full. Rendered script run twice: one mail, not two. Carried-over reboot case: reboot still requested, spool entry reads No packages were changed in this run.
• AIDE: aide --check exits 1 on a mismatch (aide 0.19.2, Rocky 9), which is what makes is-failed a valid signal. Full gating matrix exercised: clean+updates re-baselines, clean+no-updates does not, already-failing does not and leaves the unit failed with the pre-update log preserved, AIDE-not-managed is a no-op.
• apt, Debian 12: a package whose postinst exits 1 makes apt-get upgrade return 100 and the script exit 1 with a failure mail carrying both streams, and no reboot requested. An unreachable mirror returns 0 with only W: warnings; a malformed sources list returns 100.
• Mail headers: parsed with a strict RFC 5322 parser. The old form yields addr='' with InvalidHeaderDefect; the new form parses intact, including prefixes containing a double quote or a backslash. End to end through Postfix 3.5.25 on Rocky 9, reading the queued message directly.

[NavidSassan]

Waiting for the run in the test-vDC on 2026-08-28, merging after that