Run this every patch cycle. The pre-run items go before the window opens; the post-verify items go immediately after each batch, not at the end of the month.
The commands are written for Debian and Ubuntu targets. On EL hosts substitute
dnf check-update, dnf repolist, dnf versionlock list, needs-restarting
and rpm -qa for their apt equivalents - the checks are the same, the tools
differ.
What a failure means
Patching has a failure mode the other checklists do not: it can report complete success while changing nothing. A held package, a running service that was never restarted, a kernel installed but not booted - all three produce a green recap and a host that is still vulnerable.
That is why so much of this list is post-verification. The critical items
before the run are about not breaking the fleet; the critical items after it
are about the patch having actually happened.
Access this needs
Most commands here go through the command module and read: apt-get -s
simulates without changing anything, apt-cache, apt-mark showhold,
needrestart -b and dkms status report state. They need become on most
hosts. The fact modules - setup, package_facts, service_facts, stat,
find - read only.
The command module will run whatever you hand it. Every invocation in this
list is read-only as written; check any variation you make before running it
against a fleet.
Where the evidence goes
The before-and-after package_facts output is the patch record. Keep both, per
host, with the run timestamp. It is what answers the scanner when the scanner
disagrees, and it is the only artefact that distinguishes “we patched it” from
“we ran the patch play against it”.
Sign-off
- Patch owner: ______________ Window: __________
- Post-verify by: ___________ Date: ___________