The Burden of Manual Patch Management
One of the most critical responsibilities of a Linux system administrator is ensuring that servers are protected against newly discovered vulnerabilities. However, in an infrastructure comprising dozens or hundreds of Ubuntu servers, manually logging in via SSH to run apt update and apt upgrade is operationally unscalable.
If a zero-day vulnerability (like Heartbleed or Log4Shell) is disclosed over a weekend, waiting until Monday morning to apply the patch leaves your infrastructure exposed to automated exploitation.
To solve this, Ubuntu includes a highly configurable, native utility called unattended-upgrades. This service automates the process of checking for, downloading, and installing security updates without any human intervention.
Step 1: Installing and Enabling unattended-upgrades
While the package is included by default on most modern Ubuntu Server deployments, it is not always enabled. First, ensure the package is installed:
sudo apt update
sudo apt install unattended-upgrades apt-listchanges -yTo enable the automated service, run the interactive configuration tool:
sudo dpkg-reconfigure --priority=low unattended-upgradesA pink terminal GUI will appear asking if you want to automatically download and install stable updates. Select Yes.
Step 2: Configuring the Update Sources
By default, unattended-upgrades is highly conservative. It is configured to install only packages originating from the official Ubuntu “security” repository. This guarantees that standard software (like Nginx or Docker) won’t unexpectedly jump to a new major version and break your application.
To verify or modify which repositories are approved for automated updates, open the primary configuration file:
sudo nano /etc/apt/apt.conf.d/50unattended-upgradesLook for the Unattended-Upgrade::Allowed-Origins block. It should look like this:
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
// Extended Security Maintenance; doesn't necessarily exist for
// every release and this system may not have it installed, but if
// available, the policy for updates is such that unattended-upgrades
// should also install from here by default.
"${distro_id}ESMApps:${distro_codename}-apps-security";
"${distro_id}ESM:${distro_codename}-infra-security";
};Leave this default configuration intact. Uncommenting the -updates repository is generally discouraged on production servers, as it includes non-security-related bug fixes that could introduce instability.
Step 3: Excluding Specific Packages
Occasionally, you may have a specific application that relies on a very precise, pinned version of a library, or a kernel module that you do not want updated automatically.
In the same 50unattended-upgrades file, scroll down to the Unattended-Upgrade::Package-Blacklist section. You can explicitly block packages from the automated process.
Unattended-Upgrade::Package-Blacklist {
"nginx";
"docker-ce";
"linux-image-generic";
};By blacklisting the kernel (linux-image-generic), you ensure that automated patching does not trigger a scenario requiring an unexpected reboot.
Step 4: Configuring Automatic Reboots
If a critical security patch updates the Linux kernel or the glibc library, the server must be rebooted to apply the fix in memory. By default, unattended-upgrades will install the patch but will not reboot the server. Instead, it creates a file at /var/run/reboot-required.
To fully automate the patching lifecycle, you can instruct the service to reboot the server automatically, but only during a specified maintenance window (e.g., 3:00 AM).
Scroll down in the configuration file and modify the following lines:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";This ensures that if (and only if) a reboot is mandated by a patch, the server will gracefully restart at 3:00 AM local time.
Step 5: Setting Up Email Notifications
Silent automation is dangerous if it fails. You must configure unattended-upgrades to email you when patches are applied or if an error occurs during the installation process.
First, ensure your server has a functional Mail Transfer Agent (MTA) installed, such as Postfix, configured to send outbound emails.
Then, find the Mail configuration in the file and set your email address:
Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";The on-change directive ensures you are only emailed when an upgrade is actually performed, preventing daily spam.
Step 6: Verifying the Automation Timing
The actual schedule for when the system checks for updates is controlled by a separate APT configuration file.
sudo nano /etc/apt/apt.conf.d/20auto-upgradesEnsure the file contains the following directives:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";The “1” means the task will run daily via the apt-daily.timer and apt-daily-upgrade.timer systemd services.
Conclusion
Configuring unattended-upgrades is a mandatory step in securing any Ubuntu Server deployment. By strictly limiting automated updates to the security repository, defining precise maintenance reboot windows, and configuring email alerts, system administrators can achieve rapid, zero-day protection while maintaining absolute stability across their production infrastructure.