Ubuntu 24.04 unattended-upgrades dey on by default?

Why automatic security updates dey worth setting up

Server wey no get patches na the easiest target for internet. Most breaches for small servers no dey involve clever tricks; na known bug for old package wey owner never update. Ubuntu get tool wey dey close this gap by itself: unattended-upgrades dey install security updates automatically, according to schedule, without you logging in. Na the cheapest security improvement wey you fit get for VPS, and for Ubuntu, setup na only few minutes.

The tool dey deliberately conservative. By default, e dey apply only security updates, no be every package upgrade, because security patch get low risk and e worth applying without review, while feature upgrade fit change behaviour wey you dey depend on. That default dey correct for most servers, and this guide go keep am while e show the few settings wey worth changing.

Step 1: Install and enable am

For Ubuntu Server 24.04, package dey installed and enabled by default. Ubuntu server documentation talk say unattended-upgrades dey installed by default, and automatic installation of security updates dey enabled immediately after installation. The question wey package ask during installation dey default to yes. So unless person explicitly answer no, daily job don already dey on. Custom or trimmed provider image fit still different, so confirm am instead of assuming. These commands safe for either case: dem go install package if e dey missing, and ask again the one question wey turns am on:

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

The dpkg-reconfigure prompt ask one yes-or-no question: whether to download and install stable updates automatically. Answer yes. This one write the file wey switches the daily job on:

cat /etc/apt/apt.conf.d/20auto-upgrades

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

The first line refresh package list every day; the second runs unattended upgrade every day. When both set to 1, e mean say the machine checks for and applies security updates every day through a systemd timer, without any further action from you.

Step 2: Decide wetin go apply automatically

The policy dey inside /etc/apt/apt.conf.d/50unattended-upgrades. Open am and check the Allowed-Origins block near the top:

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

Na the -security lines matter, and dem dey enabled by default. This na the conservative policy: security updates go enter automatically, while ordinary feature updates remain for you to apply by hand whenever you choose. You fit uncomment the "${distro_id}:${distro_codename}-updates" line for the same block to also take Ubuntu regular stable updates automatically. This one widen the policy only to Ubuntu -updates archive, not every repository or PPA for the machine. The normal checks still apply: the tool hold back any package wey go bring configuration-file prompt, and e no go install anything wey dependencies no fit come from allowed origin. For server wey dey host something important to you, na safer default to apply only security patches automatically. Leave am as e ship unless you get specific reason to change am.

Step 3: Handle reboots

Some updates, like kernel or core library, only go take full effect after reboot. unattended-upgrades no go reboot your server unless you tell am to, which mean say patched kernel fit remain unused until you restart the server. Decide how you want handle this, and set am clearly inside 50unattended-upgrades:

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

That one go reboot the server by 4 in the morning when, and only when, an update require am. For one VPS wey no get cluster to fail over to, short early-morning reboot normally na the correct trade-off for staying current with kernel fixes. If your server dey run something wey must never restart unexpectedly, leave reboot off and make habit of rebooting by yourself after you check /var/run/reboot-required.

Step 4: Prove say e dey work

No wait one day before you find out whether the job dey run. Trigger dry run wey go show exactly wetin go apply, without changing anything:

sudo unattended-upgrade --dry-run --debug

The output dey list the packages wey e consider and the origins wey dem come from, so you fit see the policy as e dey work. After the real job don run at least once, the record dey here:

cat /var/log/unattended-upgrades/unattended-upgrades.log

That log na the answer to “my server dey patch itself?” If e show security packages wey dey install according to schedule, the job dey work. If na PHP site dey run for this server, no use php -v take judge whether one particular patch don land; how to confam say PHP security update don land for Ubuntu show you how to check the package version and restart php-fpm or Apache make the patched code begin run.

Where this one fit

Automatic updates na one layer of hardened server, no be the whole thing. Dem dey stop known bugs from remaining, but dem no do anything about who fit log in or wetin dey exposed. Join am with key-only SSH hardening so nobody fit brute-force the entry point, default-deny UFW firewall so only the things wey you choose fit reachable, and unprivileged service users so breached app no fit take control of the whole machine. The apps wey you host get their own secrets on top of all this, so if this machine dey run self-hosted password vault, a Vaultwarden hardening pass go protect the admin token and backup file wey no amount of apt patching fit protect. Patching dey close the holes wey you know; the other layers dey limit damage from the ones wey you no know.

FAQ

Does unattended-upgrades apply every update or only security ones?

By default, na only security updates. The Allowed-Origins block inside /etc/apt/apt.conf.d/50unattended-upgrades dey enable -security origins and leave ordinary feature updates for you to apply by hand. Na deliberate choice: security patches get low risk and worth applying automatically, while feature upgrades fit change behaviour, so most servers suppose keep the conservative default.

Will automatic updates reboot my server?

Only if you tell dem to. Set Unattended-Upgrade::Automatic-Reboot "true" and Automatic-Reboot-Time inside the config, and the server go reboot at that time when update require am, for example after kernel patch. If you leave am off, patched kernel go wait until you reboot by yourself; check /var/run/reboot-required to know when one dey pending.

How do I check that automatic updates are actually running?

Run sudo unattended-upgrade --dry-run --debug to see wetin go apply now, without changing anything, and read /var/log/unattended-upgrades/unattended-upgrades.log for record of past runs; every automatic install also dey enter /var/log/apt/history.log. If the log show security packages installed every day according to schedule, the timer dey work. If the dry run print No packages found that can be upgraded unattended, e either mean say everything don already current or your allowed origins too narrow to match the security repository.

Is unattended-upgrades enough to keep my server secure?

No, but e be necessary layer. E dey stop known vulnerabilities from remaining unpatched, which dey prevent the commonest type of breach, but e no control access or exposure. Combine am with SSH hardening, default-deny firewall, and least-privilege service users to get server wey genuinely hard to break into.