Automatic updates

Module 4: Software and updates · Reading time: 10 minutes

Learning objective: After this lesson you can turn on and check automatic security updates, you know what does and does not happen automatically, and you know when a reboot is needed.

Key concepts: unattended-upgrades, 20auto-upgrades, 50unattended-upgrades, Origins-Pattern and Allowed-Origins, apt-daily timers, needrestart, /var/run/reboot-required, Automatic-Reboot, kernel update, dnf-automatic

Why automatic?

Security holes are found, fixed and then actively exploited, often within days. So a server you update once a month is exposed to known holes for weeks on average. The Dutch NCSC counts installing updates on time among the basic principles of digital resilience: "Updating and patching software on time helps to fix vulnerabilities quickly."

Still, "everything automatic" isn't right either. A new version of a program can behave differently from the old one, and a server that reboots itself in the middle of the day can affect your visitors. The usual middle ground on Debian and Ubuntu is:

• security updates automatically, every day;
• other updates and release upgrades by hand, at a time you choose, with a snapshot first;
• reboots planned, at a quiet moment, and checked.

The program that handles this is called unattended-upgrades.

Turning on unattended-upgrades

On Ubuntu Server, unattended-upgrades is installed by default and automatic security updates are on straight after installation. On Debian it is also present on many installations and images, but not always. Check and turn it on:

anna@web1:~$ sudo apt install unattended-upgrades
anna@web1:~$ sudo dpkg-reconfigure -plow unattended-upgrades

The second command asks "Automatically download and install stable updates?". Choose Yes. That writes the file /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

The 1 means: every day. With 0 you turn it off. The actual work is started by two systemd timers (lesson 6.3), which you can view like this:

anna@web1:~$ systemctl list-timers 'apt*'
NEXT                        LEFT     LAST                        PASSED  UNIT                    ACTIVATES
Tue 2026-11-10 06:24:11 CET 9h left  Mon 2026-11-09 06:41:03 CET 14h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Tue 2026-11-10 08:02:47 CET 11h left Mon 2026-11-09 19:12:30 CET 1h ago  apt-daily.timer         apt-daily.service

apt-daily fetches the lists (like apt update), apt-daily-upgrade installs the updates. The times are randomly spread, so that not every server in the world hits the package repositories at once.

What gets installed automatically?

That is set in /etc/apt/apt.conf.d/50unattended-upgrades. On Debian the block is called Unattended-Upgrade::Origins-Pattern, on Ubuntu Unattended-Upgrade::Allowed-Origins. By default the security repository and the stable repository of your release are on, and the -updates repository is off. On Ubuntu it looks like this:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Lines starting with // are off. Leave this as it is for a first server. Don't edit the file directly, because a later version of the package may want to replace it. Debian recommends putting your own changes in a file of your own, for example /etc/apt/apt.conf.d/52unattended-upgrades-local; later files take precedence over earlier ones.

Packages from extra repositories (Docker, Caddy, PostgreSQL from the vendor) are not updated automatically by default. That is a deliberate choice: you keep track of those yourself (lesson 9.4), or you add the repository to the list by hand if you trust the vendor and understand the consequences.

A few settings you will often want:

// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Mail "root";
Unattended-Upgrade::MailReport "only-on-error";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Automatic-Reboot "false";

Mail only works if the server can send mail (a small relay, lesson 8.3). If it can't, skip it and use the monitoring from lesson 8.3.

Checking that it works

An automatic process that silently stops is more dangerous than none at all, because you think you're safe. So check three things.

1. A dry run. This shows what would happen, without changing anything:

anna@web1:~$ sudo unattended-upgrade --dry-run --debug
...
Allowed origins are: origin=Debian,codename=trixie,label=Debian, origin=Debian,codename=trixie-security,label=Debian-Security, ...
Packages that will be upgraded: libssl3t64 openssh-server

2. The log. Every run writes to /var/log/unattended-upgrades/unattended-upgrades.log:

anna@web1:~$ sudo tail -n 5 /var/log/unattended-upgrades/unattended-upgrades.log
2026-11-09 06:41:15,201 INFO Packages that will be upgraded: openssh-server
2026-11-09 06:41:15,202 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2026-11-09 06:41:29,874 INFO All upgrades installed

3. What is still pending. After a night, apt list --upgradable (lesson 4.1) should no longer show any packages from -security. If they stay there for days in a row, something is stuck: a full disk, a lock held by a manual apt that hangs, or a package asking a question.

Restarting: services and the kernel

An updated program on disk is not the same as an updated program in memory. If OpenSSH has been running for three weeks, the old code keeps running until the service restarts.

• Services: the program needrestart checks after an update which services are still using old libraries. On Ubuntu 24.04 and later, unattended-upgrades restarts those services automatically via needrestart by default. On Debian, needrestart is a separate package (apt install needrestart) that asks you interactively which services to restart.
• The kernel: a new kernel only takes effect after a reboot of the whole server. Debian and Ubuntu then create the file /var/run/reboot-required:

anna@web1:~$ cat /var/run/reboot-required
*** System restart required ***
anna@web1:~$ cat /var/run/reboot-required.pkgs
linux-image-6.12.57+deb13-amd64

You have two choices. Either you reboot yourself, for example every week at a fixed time after checking whether the file exists. Or you let unattended-upgrades do it:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

The default is false. Only turn it on if you are sure everything comes back up by itself after a reboot: services with enable (lesson 6.1), containers with a restart: policy (lesson 9.3), and monitoring that warns you if they don't (lesson 8.3). Test it once by hand first: sudo reboot, and see whether everything comes back.

Through Ubuntu Pro, Ubuntu also offers Livepatch, which applies some kernel fixes without a reboot. That is an addition, not a replacement: even with Livepatch you still reboot now and then.

What you don't do automatically

• Release upgrades (from Debian 12 to 13, from Ubuntu 24.04 to 26.04): always by hand, with a plan (lesson 4.3).
• Major versions of your own applications (a new major version of a database, a CMS): always by hand, after a backup and reading the release notes.
• Containers: unattended-upgrades does not update them. An image from 2024 stays the image from 2024 until you run docker compose pull (lesson 9.4).

On AlmaLinux and Rocky Linux

There the tool is called dnf-automatic. Install it with dnf install dnf-automatic. In /etc/dnf/automatic.conf you set upgrade_type = security and apply_updates = yes, and you turn on the timer with systemctl enable --now dnf-automatic.timer. On RHEL-like systems a kernel reboot is just as necessary as on Debian; dnf needs-restarting -r tells you whether one is needed.

In practice

At WebOké a VPS works the same way as elsewhere: you manage what gets updated inside the server yourself. The provider updates the hardware and the virtualisation platform, not your operating system. Take a snapshot in your provider's panel before a major manual update; for the daily automatic security updates that isn't needed.

Summary

• Turn on automatic security updates with unattended-upgrades (Ubuntu: on by default; Debian: check with dpkg-reconfigure -plow unattended-upgrades).
• By default only the security repository and the stable release repository are updated automatically; extra repositories are not.
• Check with a dry run, the log in /var/log/unattended-upgrades/ and apt list --upgradable.
• Services need to restart after an update (needrestart), the kernel needs a reboot (/var/run/reboot-required).
• Release upgrades, major application versions and containers you update by hand.

Quiz

Exercise

Exercise O4.2: Turning on and checking automatic updates. On your own server, turn on unattended-upgrades (or check that it is on), do a dry run and look at the log and the timers. Fill in the checklist and answer: which repositories are updated automatically on your server, when did the last run take place, is a reboot pending right now, and how will you reboot (yourself at a fixed time or automatically, and why)?

Further reading

• Securing your VPS: the first five minutes
• Debian Wiki, automatic updates (UnattendedUpgrades): https://wiki.debian.org/PeriodicUpdates
• The Dutch NCSC, Basic principle 3: Protect systems, applications and devices (Dutch source): https://www.ncsc.nl/basisprincipes/basisprincipe-3-bescherm-systemen-applicaties-en-apparaten
• Ubuntu Server documentation, Automatic updates: https://ubuntu.com/server/docs/how-to/software/automatic-updates/