| name | update_rhel |
| description | Runs ansible/update_rhel.yml to report pending dnf updates on a RHEL-family host, and optionally apply them, as part of the Linux SOE. Use when asked what updates are pending, or to patch/update a host — as distinct from the general host baseline (configure_rhel.yml), which does not touch package updates at all. |
update_rhel
Runs ansible/update_rhel.yml, a purpose-built playbook pairing the
system_update_report_pre role (active by default) with the
system_update role (commented out by default). See
docs/ARCHITECTURE.md for the six-playbook layout this fits into, and
each role's own SKILL.md for full detail — system_update_report_pre
and system_update.
What the playbook actually does
Encoded directly in ansible/update_rhel.yml's vars: block:
system_update_reboot_policy (default when_needed, checked via dnf needs-restarting) and system_update_display_updates: true — these
configure system_update, but since that role is commented out of the
roles: list by default, they currently have no effect until it's
uncommented.system_update_report_pre_display_updates: true — configures the
active role, so its output actually is displayed by default.roles: lists system_update_report_pre active, system_update
commented out (#- system_update) directly below it.
By default, running this playbook only reports what dnf would update —
it never actually updates anything, because the one role that applies
updates is commented out. This is deliberate (see system_update's
SKILL.md) — the same behavior the old site.yml achieved by leaving
system_update off its roles: list entirely, just implemented here as a
commented-out line in a dedicated playbook instead.
What to do
Report pending updates (safe, read-only by construction — no --check
needed, though it's harmless to include for consistency):
ansible-playbook ansible/update_rhel.yml
Summarize the reported package list in plain language.
Apply updates (modifies the system, can reboot the host — only after
the user explicitly asks, and only after uncommenting system_update in
ansible/update_rhel.yml's roles: list):
ansible-playbook ansible/update_rhel.yml --tags system_update --check --diff # audit first
ansible-playbook ansible/update_rhel.yml --tags system_update # then apply
Confirm system_update_reboot_policy with the user before applying —
when_needed/when_updated/always can all reboot the host as part of
this run; never will not.
Propose a change to this playbook: never edit and commit directly. On a
branch named soe/update_rhel/<short-desc>, edit ansible/update_rhel.yml,
validate locally (--syntax-check, --check --diff against a real/test
host if available), then push and open a PR titled
[update_rhel] <what changed> with the --check --diff output in the
body. Then stop — a human reviews and merges; see docs/ARCHITECTURE.md's
"Contribution workflow". Don't uncomment system_update permanently in
this playbook without an explicit decision from a human operator —
fleet-wide auto-patching needs a deliberate choice, not a default.
Notes
- Under
--check, system_update's dnf update * doesn't perform the
update, so needs-restarting-based reboot-policy evaluation during an
audit reflects pre-update state — --check --diff here previews what
would update, not reliably whether a reboot would follow. See that
role's own SKILL.md.
system_update_report_pre and system_update both support emailing
and/or PDF-reporting the update list (_email_report, _pdf) — the PDF
option needs enscript/ghostscript on the control host, not the
target, and both default false here.
