v1.0.1 - Fixes from live-fleet testing
Fixes found by running playbooks/baseline.yml / playbooks/postcheck.yml against a real 10-node Ubuntu fleet (Multipass) for the first time -- none of these were reachable from the macOS-only testing available during initial development.
Fixed
- Service-name resolution was non-deterministic. Every
<candidates> | intersect(<present services>) | firstlookup (time-sync,sssd,systemd-journald) usedintersect(), whose result order is not guaranteed to follow either input list -- it could return a different match on every run against the identical host state, occasionally picking a present-but-inactive unit (e.g.ntp.service, stopped) over the actually-running one. Replaced with<candidates> | select('in', <present services>) | list | first, which deterministically preserves the candidate list's priority order. linux_vitals_time_sync_candidatesnever included Debian/Ubuntu's actual service names. It only listedchronyd*(RHEL's name) andntp*, missingchrony.service/chrony(the real unit installed by Debian/Ubuntu'schronypackage) andsystemd-timesyncd.service/systemd-timesyncd(Ubuntu's out-of-the-box default). Every stock Ubuntu host was reporting a false "chronyd or ntp is not installed" finding despitesystemd-timesyncdrunning the whole time. Both are now in the candidate list.- Systemd alias units report
state: active, notstate: running.chronyd.serviceis often a symlink alias tochrony.serviceon Debian/Ubuntu;ansible.builtin.service_factsreports alias units withstate: activerather thanrunning. Thesssd/systemd-journald/time-sync "is it up" checks, and the self-healing restart-success check, only acceptedrunningand treated a perfectly healthy aliased service as down. Both now acceptstate in ['running', 'active']. - Same-task variable self-reference in bootloader validation.
linux_vitals_bootloader_validation_messagereferencedlinux_vitals_bootloader_default_matches_latestfrom within the sameset_factcall that defined it -- Ansible templates every key in aset_factdict against the variable context that existed before the task ran, so this was always undefined at evaluation time. It only surfaced as a hard failure once bootloader detection actually reachedstatus: resolved(i.e. on a real host with workinggrubby/grub2-editenv, never on the macOS dev machine). Split into two sequential tasks.