Patch management: planned updates and live patching
You follow security advisories, split updates into test and production rings, and manage automatic updates, restart requirements and live kernel patching.
Level 401 · 15 lessons · 12 practice labs
Lessons
Knowing
- Security advisories: reading DSA, USN, RHSA and CVEs
- An inventory of pending updates
- Which service needs a restart: needrestart and reboot-required
- Short task: prioritise this week's advisories against your servers
Applying
- unattended-upgrades and dnf-automatic
- The ring model: test, pilot and production
- Maintenance windows and rollback plans
- Snapshots and checks before an update
- Short task: roll an update out in three rings and catch the problem in the first
The kernel
- Kernel update strategy and old kernels
- Live patching: how kpatch and livepatch work
- CPU microcode and firmware updates: fwupd
- Short task: tie a critical kernel flaw to a reboot schedule
Reporting
- Patch compliance reports and metrics
- Capstone: run the monthly patch cycle for twenty servers end to end
Practice labs
- List pending security updates: On Debian and Rocky servers separate pending updates that are security fixes and submit the count per server.
- Find the servers affected by a security advisory: From the package and version range in a given advisory, determine which of four servers are affected and list them with reasons.
- Draw up patch priorities and a maintenance window plan: Using Yelkovan Bankası's server inventory and open advisories, write a patch plan ordered by exposure and criticality.
- Apply security updates only: Apply only security updates to a server and show that the other packages kept their versions.
- Set up controlled automatic security updates: Limit automatic updates to the security repository, exclude the database package and review the output of a dry run.
- Roll a patch out to a canary first, then in waves: Apply an update to one server first, spread it to the rest in two waves if the health check passes, and script a stop on failure.
- Find the servers that need a reboot: Identify the servers and services still running on an old kernel or old library after updates.
- Go back to the old kernel after a bad update: Boot a server whose network driver fails on the new kernel into the old one, make it the default and exclude the faulty version.
- Reboot a cluster in turn without downtime: Write a rolling reboot script that moves three web servers to the new kernel, draining one at a time and verifying its return.
- Extract last month's patch history: List the packages updated in the last thirty days with their dates from the package manager history.
- Produce a patch compliance table for the servers: With a script collecting last update date, pending security fixes and running kernel from four servers, produce a single table.
- Document patch exceptions with reason and mitigation: For two servers that cannot be patched, prepare an exception record with reason, compensating control and review date, plus the audit report.
About this course
You follow security advisories, split updates into test and production rings, and manage automatic updates, restart requirements and live kernel patching.
What you will learn
- Knowing
- Applying
- The kernel
- Reporting
Prerequisites
You should have practised the topics of the same path up to level 301.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 401; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.