This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
A patch is a change with a reboot you named
A patch window has a list of hosts, a start time, a person, and what done means. Done is not the package manager exiting 0 if the kernel is still the old one until reboot. Write whether this window reboots. If it does not, write the later window that does. A security fix that is installed and not running is a fix you do not have yet.
The ring is the order. One lab host, then a canary that can fail without taking the business, then the rest. The scheduler on this site can lay those times out. It does not connect to a patch server. The same package set lands on the canary before it lands on the rest, so the canary is a real test and not a different OS.
End of life is a date. The lookup on this site maps an OS name to the date the vendor published. After that date you are not late on a patch. You are on a system that will not have one. The replacement is a migration or an upgrade project, not a longer exception list.
Emergency changes are still changes. They have a smaller ring, not a missing rollback. The rollback is the previous package or the previous image, which you have because the backup or the image repository exists. A host you cannot reinstall is a host you patch last, not a host you never patch.
One lab host, one reboot, one proof
On the lab host, record the current kernel or the current package version you care about. Apply the updates the organisation's repository already serves. Do not add a third-party repository in the same window. Reboot if the ticket says the kernel or a service needs it. After reboot, record the new version and confirm the one service you named came back.
If the service does not come back, the window stops. Rollback is the previous version or the snapshot you took for this lab, used now, not next week. A second package added to see if that fixes the first failure is a new change you did not plan.
Write the start, the finish, the version before, the version after, and whether you rebooted. That note is the template for the canary. The canary gets the same note. The rest of the hosts do not start because the lab felt fine and the canary was skipped.
The hardening guide assumes the host is on a supported release and has a patch path. A host past end of life fails that assumption. Look the date up before you promise a hardening pass.
A change you can finish
The production ring follows the lab note. One canary. A wait you decided, long enough to see the failure mode you care about, short enough that you do not drift. Then the rest, in the order the business can stand.
A failed canary stops the ring. You do not push the same packages to fifty hosts because the maintenance window was booked.
- List the hosts and the ring order.
- Record the version before.
- Patch the lab from the existing repository.
- Reboot if the running system will not pick up the fix otherwise.
- Record the version after and the service check.
- Repeat on the canary. Stop the ring if the canary fails.
- Look up end of life for the OS and file the date.
Mistakes that outlive the command
patch management fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- Calling a host patched when the old kernel is still running.
- A new repository added in the patch window.
- Skipping the canary because the lab was fine.
- Continuing the ring after the canary failed, to use the window.
- An exception list that is actually a list of hosts past end of life.
- No rollback image or package, on a host you cannot reinstall.
- Patching and hardening and migrating in one night.
- A third-party package installed with the security updates because it was in the same command's default set and nobody read the list.
Decisions to write down before the window
Decision 1 for patch management. The repository is the one you already trust. No new repo in this window. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 2 for patch management. Reboot is yes or no, and the running version after the window matches that answer. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 3 for patch management. The ring is lab, canary, then the rest. The canary can fail without stopping the business. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 4 for patch management. A failed canary stops the ring. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 5 for patch management. Before and after versions are in the ticket for each host. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 6 for patch management. End of life was looked up. A date in the past opens a migration ticket, not another exception. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 7 for patch management. Rollback is a previous package or a previous image you can actually use. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 8 for patch management. The service you named was checked after reboot, not assumed. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 9 for patch management. Emergency still has a person and a rollback. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 10 for patch management. The scheduler's times match the calendar the business agreed. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Decision 11 for patch management. A second person saw the canary's after-version before the ring continued. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.
Patch checks before the ring continues
Check 1 in Patch checks before the ring continues. The host list and the order are in the ticket. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 2 in Patch checks before the ring continues. The version before is recorded. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 3 in Patch checks before the ring continues. No new repository was added. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 4 in Patch checks before the ring continues. Reboot happened if the kernel or the service required it. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 5 in Patch checks before the ring continues. The version after is the one you intended. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 6 in Patch checks before the ring continues. The named service answers after the reboot. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 7 in Patch checks before the ring continues. The canary passed, or the ring is stopped. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 8 in Patch checks before the ring continues. End of life date is filed. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 9 in Patch checks before the ring continues. Rollback was available before you started. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 10 in Patch checks before the ring continues. The package list was read, not only the summary count. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 11 in Patch checks before the ring continues. A second person saw the canary result. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 12 in Patch checks before the ring continues. The next ring's start time is still in the future when you decide to continue. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 13 in Patch checks before the ring continues. A host past end of life is not marked patched. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 14 in Patch checks before the ring continues. The hostname in the prompt matches the hostname in the ticket for patch management. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 15 in Patch checks before the ring continues. The result line includes the time and the person, not only the command. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 16 in Patch checks before the ring continues. You can point at the rollback value without searching a chat history. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Check 17 in Patch checks before the ring continues. Done is a sentence a second person can repeat: the proof for patch management happened, and the next host is not started early. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar. A published page is linked. The others are named until they are published.
- Comparison: apt vs dnf vs zypper vs pacman
- Cheat Sheet: apt Cheat Sheet
- Cheat Sheet: dnf Cheat Sheet
- How-To: Adding Third-Party Repositories Safely
- How-To: Automatic Updates on Linux
- Explainer: Linux Kernel Versions Explained
- Reference: OS End-of-Life Calendar
- Explainer: Patch Tuesday Explained
- How-To: winget and Chocolatey for Admins
The content plan also names a companion in another desk: Security: Patch Management Process.