Automatic security updates

A security fix only protects you once it's installed. unattended-upgrades installs those fixes every day without you logging in. Here is how to check it's on, what it actually installs, and when to let it reboot.

Published . Ubuntu LTS releases and Debian stable, with the unattended-upgrades package from the distribution's own archive.

Why turn it on

On a server you look at once a month, a fix can sit uninstalled for weeks while the hole it closes is public. unattended-upgrades runs once a day, refreshes the package lists and installs updates from the origins you allow. By default that is security updates only, which rarely change behavior.

On Ubuntu the package is installed by default. On Debian, and on minimal images, you may need to add it.

Install and enable it

sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

The last command asks whether to download and install stable updates automatically. Answer yes. Then check that the schedule file has both switches on:

cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Each value is a number of days. 1 means every day, 0 turns that step off. If the second line says 0 or is missing, nothing gets installed, even though the package is there.

What it updates by default

What gets installed is set in /etc/apt/apt.conf.d/50unattended-upgrades. On Ubuntu, the active lines in Allowed-Origins are:

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";
};

So you get the security pocket, plus the ESM security pockets if the machine is attached to Ubuntu Pro. Ordinary bug-fix updates from -updates are not installed unless you uncomment that line. Packages from PPAs and third-party repositories (Docker, PostgreSQL's own repo, Node) are not in the list, so they are never updated automatically. You still have to update those yourself.

Debian uses Unattended-Upgrade::Origins-Pattern in the same file instead. Its default installs security updates but not new features.

Keep your own changes in a separate file, such as /etc/apt/apt.conf.d/52unattended-upgrades-local, as the Debian wiki suggests. Files in that folder are read in order, so later ones win, and a package upgrade won't ask you to merge your edits into the stock file.

Leave some packages out

If a package must only be upgraded by hand, for example your database server, add it to the blacklist. Entries are regular expressions matched against package names:

Unattended-Upgrade::Package-Blacklist {
        "postgresql-";
        "mariadb-server";
};

Use this sparingly. Every package on that list is one you now have to patch yourself, including its security fixes.

Test it with a dry run

A dry run shows what would be installed without changing anything:

sudo unattended-upgrade -v --dry-run

Look for the list of allowed origins near the top and the packages it would upgrade. If it says no packages are found and you know updates are waiting, those updates probably come from an origin that isn't allowed. The repository release files in /var/lib/apt/lists/ show the origin and suite names you would need to add.

Read the logs

Each run writes to /var/log/unattended-upgrades/:

sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

The first file says what was picked and why. The second has the dpkg output for each install, which is where errors from package scripts show up. /var/log/dpkg.log also records every install and upgrade on the system, however it was started.

If you want a mail after each run, set Unattended-Upgrade::Mail to your address. That only works if the server can send mail, so it needs a local mail setup first.

Automatic reboots and their risk

Some updates, such as a new kernel or C library, only take effect after a reboot. By default unattended-upgrades installs them and leaves the reboot to you. See how to tell a reboot is needed. Three options control this:

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

An automatic reboot is the moment a hidden problem shows up. A container without a restart policy stays down, a service that was started by hand doesn't come back, an encrypted disk waits for a passphrase, a mount in /etc/fstab that fails can stop the boot. Reboot once by hand at a quiet time and check everything comes back before you turn this on. Then pick a fixed time instead of "now", so it never reboots in the middle of your working day.

If you leave automatic reboots off, which is reasonable for a single production server, plan a regular manual reboot instead. A patched kernel that never boots doesn't protect you.

Stenvakt reads all of this for you. Its Review is a read-only security and health check of every server you add, and every fix it suggests shows a preview before it runs. Fixes run in safe mode: if a change cuts off your SSH, the server rolls it back by itself. It's a Mac app and isn't out yet: get early access.

Sources

  1. Ubuntu Server docs: Automatic updates
  2. Debian wiki: UnattendedUpgrades
  3. unattended-upgrade(8) manual page (Ubuntu 24.04)
  4. unattended-upgrades upstream README (option reference)
Next guideExposed MongoDB