Chapter 14 — Patching operating systems
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Rings"]
N2["14.2 Timing in schools"]
N3["14.3 Linux servers"]
N4["14.4 Measuring"]
N5["Failed updates and emergency updates"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Rings"]
N2["14.2 Timing in schools"]
N3["14.3 Linux servers"]
N4["14.4 Measuring"]
N5["Failed updates and emergency updates"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Rings]
|
v
[14.2 Timing in schools]
|
v
[14.3 Linux servers]
|
v
[14.4 Measuring]
|
v
[Failed updates and emergency updates]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) plan update rings; (2) measure update latency; (3) handle failures.
14.1 Rings
Updates install first on Dev's and two volunteer teachers' laptops, then on everyone a few days later. NIST SP 800-40 Rev. 4 describes this kind of staged rollout as a way to balance speed with stability.
The first ring is small on purpose: Dev's own laptop shows management problems, while the two teachers' laptops show whether classroom software still works after an update. If a problem appears, Dev pauses the rollout before it reaches the other ninety laptops. The few days' delay is a small cost compared with a failed update across both schools.
14.2 Timing in schools
Laptops are often closed at the end of the day and taken home. Updates install during the day and restart at lunchtime or at the end of the day with a deadline of three days. During exam weeks, restarts are delayed to avoid disruption.
The three-day deadline means a teacher can postpone a restart before an important lesson, but not indefinitely. Exam weeks are entered in the management service in advance with an end date, so restarts resume automatically once exams finish. Before the deadline was enforced, some laptops had gone weeks without restarting, which is why so many missed the fourteen-day measure.
14.3 Linux servers
Security updates install automatically each night on Linux servers. Kernel updates need a reboot; Dev schedules these on Saturday mornings.
The nightly security updates come from unattended-upgrades, which Dev already reviews weekly through its log. A kernel update is installed overnight but only takes effect after a reboot, so a server can look updated while still running the old kernel. Saturday mornings are chosen because no staff or pupils depend on the servers then, and Dev checks each server comes back before leaving.
14.4 Measuring
Tomás measures days from release to installation for each laptop. In the first month, 70 of 94 install within 14 days; the rest are laptops rarely used. He lists them for follow-up.
The fourteen-day measure counts from the vendor's release date to the date the management service reports the update installed. Laptops that were offline all month are listed separately rather than counted as late, since the cause is different. Tomás groups the 24 late laptops by owner so the school offices can ask staff to switch them on and connect.
Failed updates and emergency updates
Each month some updates fail. Tomás groups failures by cause: pending restart, low disk space, laptop offline all month. Low disk space is fixed by a clean-up task; offline laptops are chased with their owners. He samples three laptops by hand to confirm the update history matches the console, and one mismatch reveals a laptop reporting stale data, which is re-enrolled. Separately, when an update fixes a flaw already being exploited, the rings are compressed: Dev deploys to the first ring the same day and to everyone the next day, following the risk-based approach in NIST SP 800-40 Rev. 4.
Compressed rollouts are recorded in the change log with the reason, so they can be reviewed afterwards.
Worked example
After enforcing the restart deadline, 88 of 94 laptops install within 14 days in the next month.
Synthetic case. Figures are synthetic.
Errors and limits
Pausing updates for exam weeks must have an end date; otherwise pauses become permanent.
Exercises
- EX040 — Ring benefit. What does the first ring protect against? Rubric: 3 = bad updates reaching everyone;; 2 = problems;; 1 = vague;; 0 = none.
- EX041 — Kernel updates. Why schedule kernel update reboots? Rubric: 3 = needed to apply, avoid disruption;; 2 = reboot;; 1 = vague;; 0 = none.
- EX042 — Measuring improvement. Express the improvement as before and after counts. Rubric: 3 = 70 to 88 of 94;; 2 = one;; 1 = vague;; 0 = none.
Synthesis
Staged, predictable updating with measurement keeps the fleet current.
Continue studying — chapter 14 of 30
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →