Using unattended-upgrades on Debian and Ubuntu
To counter the biggest threat to software packages, they should be updated on a regular basis. Vulnerabilities are discovered on a daily basis, which also requires we monitor daily. Software patching takes time, especially when testing and reboots are needed. Fortunately, systems running Debian and Ubuntu can use unattended-upgrades to achieve automated patch management for security updates.
Installation
With most software packages, unattended-upgrades has to be installed.
apt install unattended-upgrades
If you are not logged in as the root user, use the sudo
command to get temporary privileges. Since configuration is needed, we suggest to switch to root and install the package. The only exception is when you directly deploy your configuration with a tool like Ansible, CFEngine, Chef or Puppet.
Unattended-upgrade and Unattended-upgrades
While the package is named unattended-upgrades, the actual script to perform the upgrade is named unattended-upgrade. To avoid confusion, unattended-upgrades (with s) is actually a symlink to the script.
Configuration
After installing, it is time to configure the package. Although there aren’t many things to configure, the configuration file is named /etc/apt/apt.conf.d/50unattended-upgrades. By default, only security upgrades will be installed, which is what most people want.
Next step is to configure the package:
dpkg-reconfigure --priority=low unattended-upgrades
Select that you want to have stable packages installed.
Interactive usage
First time when testing the package, use the -v parameter. This will the actions on screen.
Logging
By default all actions are logged to /var/log/unattended-upgrades/unattended-upgrades.log. Information is also available per day, when actual upgrades are found and installed. In this case data is logged to the /var/log/unattended-upgrades directory, with a name similar to unattended-upgrades-dpkg_2015-03-09_18:17:39.573099.log.
Log rotation
Log are rotated via the logrotate service. Usually no action is needed to ensure that the files are rotated as well. It is still advised to check /etc/logrotate.d/unattended-upgrades for more details and confirm things are properly configured.
Rebooting
Although software packages are maintained this way, we still need to reboot systems. The package does actually enable the possibility to reboot the system for you:
// Automatically reboot *WITHOUT CONFIRMATION*
// if the file /var/run/reboot-required is found after the upgrade
Unattended-Upgrade::Automatic-Reboot "true";
// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
// Default: "now"
Unattended-Upgrade::Automatic-Reboot-Time "02:00";
If you rather do it manually, use the file /var/run/reboot-required, to determine if a reboot is needed.
Or if you want to know why a reboot is needed, check /var/run/reboot-required.pkgs. Often a reboot is needed due to updates to the Linux kernel, functions (libraries) or other software, which is integrated closely with the kernel.
See our related blog post: how to check for a required reboot for Debian, Ubuntu, and others
Tips
Although unattended-upgrades helps with simplifying patch management, some remaining actions are left. Some tips while setting it up:
Monitor for reboot
Configure your monitoring tool (e.g. Nagios) to monitor for the presence of /var/run/reboot-required.pkgs. If the file is available, then send out an alert. This way the system administrators know a reboot is needed and downtime can be planned.
Additionally, monitor also for uptime. While Unix based systems are stable, it is not wise to let them run for a year. At least patch regularly and when a reboot is needed, to schedule it. It is better to “plan for failure” and ensure systems can be rebooted easily, knowing other systems take over functionality.
Audit system on a regular basis
Automation can fail. In other words: trust, but verify. Regularly auditing the configuration and proper functioning of the tool, is advised. Tools like Lynis can help with automating this audit process.
Subscribe to the mailing lists
Even if software is simplifying the patch management process for you, the key is in knowing what actual threats endanger your systems. Subscribe to the security mailing lists:
- Debian: Debian security list
- Ubuntu: Ubuntu security list
Happy updating!