Security Updates and Maintenance Windows

A security fix is useful only when it reaches the affected system and the relevant code is running. Package availability, a successful installation, a service restart and a verified recovery are separate events. This chapter turns them into an observable maintenance procedure.

Decide what must change

A distribution often backports security fixes without changing the upstream-looking version to the latest upstream release. Compare the installed package version and its Ubuntu security notice or changelog; an upstream version string alone does not establish exposure. Check the release, enabled repositories, support status and whether the affected component is actually used. Ubuntu’s security-update documentation describes its archive and extended security coverage.

A maintenance window is an agreed period for a change and its verification. Establish a responsible operator, expected disruption, dependencies, a restorable backup, access through a console if networking fails, and a stop condition. For a fleet, update a representative canary first and measure results before proceeding. A backup is only a recovery plan if its restore has been tested and the application data is consistent.

Observe policy and evidence

On bl05-packages-lab, start the previously prepared clone with the original bl02 powered off. The two share an identity and must not be online together. Confirm the lab identity and inspect:

hostnamectl
cat /etc/os-release
apt-cache policy
apt-mark showhold
systemctl list-timers 'apt-*'
apt-config dump | grep -E 'APT::Periodic|Unattended-Upgrade'

A missing timer or an empty match is evidence to investigate, not proof that no other automation exists. Configuration may be spread across files and list options can accumulate. Review the effective settings and their source files; a later scalar assignment can override an earlier one, while list entries may be added. Avoid placing credentials in shared logs.

dpkg-query -W unattended-upgrades
systemctl status apt-daily.timer apt-daily-upgrade.timer --no-pager
sudo journalctl -u apt-daily-upgrade.service --since '7 days ago' --no-pager
sudo ls -l /var/log/unattended-upgrades/

Some images omit these packages, timers or logs. A timer’s next activation does not prove the previous run succeeded, nor that it covered a particular repository. If present, inspect the unattended-upgrades log and compare its timestamp and actual package changes with the security policy. APT periodic downloads, unattended installation, Snap refreshes and reboot scheduling are distinct controls. The Ubuntu documentation recommends local drop-ins instead of editing the packaged 50unattended-upgrades file; review the active origins and reboot policy rather than assuming defaults apply to every image or third-party source.

Perform a controlled update on the clone

The clone needs working DNS and access to its configured, trusted repositories. Record its installed versions and running kernel; ensure the virtual console works and a recovery copy exists. apt update changes the local package indexes and requires network access:

uname -r
sudo apt update
apt list --upgradable
sudo apt-get -s upgrade

Read the complete simulation, including held-back packages, conffile implications and any service or kernel changes. A simulation is not a reservation: repository state, other package operations or local policy can change before execution. upgrade and full-upgrade have different removal behavior; do not substitute the latter merely to make the list empty.

If the lab’s proposed changes are understood and a maintenance window is available, run sudo apt upgrade on the clone, read the actual proposal and confirmation, and decline if it differs unexpectedly. Do not interrupt a running package transaction. Record the result and investigate errors before attempting another operation:

sudo dpkg --audit
apt list --upgradable
journalctl -b -p warning --no-pager

Some updates may remain phased, held or unavailable through the configured sources. Check apt-cache policy PACKAGE for a specific package; do not assume an empty audit proves every workload healthy. Test the service or command affected by each update and record versions, timings and any required restart or reboot. The next chapter handles the kernel decision. Leave the clone available for the next lab.

Diagnose a missed update

If an advisory’s fix is absent, first establish the distribution release, architecture, installed version and advisory’s fixed version. Then inspect sources, apt-cache policy, hold state, timer/service logs and network or signature errors. A fresh index cannot fix an untrusted or unreachable repository, and an installed library does not automatically replace code already mapped into every running process. Decide on a service restart or reboot with the workload owner, then verify the running service and client-visible behavior.

Practice and recall

Write a one-page maintenance record with preconditions, the simulated proposal, actual result, restart decision and acceptance check. Explain why automatic installation does not guarantee automatic remediation and why a clean package database is only one success signal.