Patch Management Guide for Sysadmins

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

One decision for patch management: The repository is the one you already trust. No new repo in this window. Reboot is yes or no, and the running version after the window matches that answer. The ring is lab, canary, then the rest. The canary can fail without stopping the business. A failed canary stops the ring. Before and after versions are in the ticket for each host. End of life was looked up. A date in the past opens a migration ticket, not another exception. Rollback is a previous package or a previous image you can actually use. The service you named was checked after reboot, not assumed. Emergency still has a person and a rollback. The scheduler's times match the calendar the business agreed. And a second person saw the canary's after-version before the ring continued.

Patch checks before the ring continues

Confirm this before you call the change done: The host list and the order are in the ticket. The version before is recorded. No new repository was added. Reboot happened if the kernel or the service required it. The version after is the one you intended. The named service answers after the reboot. The canary passed, or the ring is stopped. End of life date is filed. Rollback was available before you started. The package list was read, not only the summary count. A second person saw the canary result. The next ring's start time is still in the future when you decide to continue. A host past end of life is not marked patched. The hostname in the prompt matches the hostname in the ticket for patch management. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for patch management happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Security: Patch Management Process.