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.

Screenshot of unattended-upgrade script

Unattended-upgrade in action

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:

Happy updating!

Relevant commands in this article

Like to learn more about the commands that were used in this article? Have a look, for some there is a cheat sheet available:

  • apt
  • dpkg-reconfigure

Feedback

Small picture of Michael Boelen

This article has been written by our Linux security expert Michael Boelen. With focus on creating high-quality articles and relevant examples, he wants to improve the field of Linux security. No more web full of copy-pasted blog posts.

Discovered outdated information or have a question? Share your thoughts. Thanks for your contribution.

Mastodon icon