I have automated monitoring (via Icinga2) of the update status of my various servers, all of which currently run Debian. To date I’ve been using cron to run a daily
apt-get update, to my mind the obvious solution to “I need it to update daily”, which updates the local package cache and then the monitoring picks up whether there’s anything to update. While investigating a problem with another cron-job yesterday, I noticed messages from apt-daily and apt-daily-upgrade services and a quick Google revealed that there is a Debian way to do this.
Don’t let the title of the Wiki page fool you, although it is “Unattended Updates” the same tools and process can be used to just refresh the cache, download up-datable packages ready for install or do the upgrade.
While look at this, I did consider how I feel about letting it automatically update. My usual gut reaction to such things is to recoil in fear of breakages, on the other hand all I would do when alerted to pending updates is to login and install them. The only variable is whether or not I am supervising the update, which means am “I there to fix it if it goes awry?”. The next question I considered is how often does it go awry and I cannot recall an instance where I have personally encountered a problem (except when dist-upgrading between major releases). Balancing the risks of breakage (I and some family members lose service until it is fixed) against the risks of being unpatched, potentially for several days until I have a few minutes to run the update (risks of system abuse and data theft are my primary concerns) I have now come down on the side of allowing automated, unattended, updates on my systems.
This information is all on the wiki page, however I know from instructing and teaching that people appreciate knowing the process I followed to get somewhere so here is how I would find out about it as a sys-admin.
These are today’s log entries from the services I noticed:
May 28 02:41:12 deltaflyer systemd: Starting Daily apt download activities... May 28 02:41:12 deltaflyer systemd: apt-daily.service: Succeeded. May 28 02:41:12 deltaflyer systemd: Started Daily apt download activities.
May 28 06:54:17 deltaflyer systemd: Starting Daily apt upgrade and clean activities... May 28 06:54:18 deltaflyer systemd: apt-daily-upgrade.service: Succeeded. May 28 06:54:18 deltaflyer systemd: Started Daily apt upgrade and clean activities.
First step, locate and examine the service definition
The service files are at
/lib/systemd/system/apt-daily-upgrade.service (which can be seen from
systemctl status) respectively. Looking inside those files we can see they both run
/usr/lib/apt/apt.systemd.daily with different arguments.
Opening up the script at
/usr/lib/apt/apt.systemd.daily, there are extensive comments at the start including all the possible options and what settings are needed to do what.
The periodic update - two files, one configuration (slight aside)
The comment at the start of the
/usr/lib/apt/apt.systemd.daily script tells us to put our settings in
/etc/apt/apt.conf.d/10periodic. On my systems, at least, unattended-upgrades is not installed by default (despite the Wiki page’s message to the contrary) so that advice is good, however unattended-upgrades provides its own apt configuration file,
/etc/apt/apt.conf.d/20auto-upgrades. This file provides its own copies of the same configuration values and since this files is alphanumerically (per apt.conf’s man-page) after the first its settings will override the earlier ones. In short, once unattended-upgrades is installed,
20auto-upgrades is the one that matters and, on my installs,
10periodic does not exist by default and has to be manually created - to avoid confusion I opted not to use
10periodic at all and just stick with
Install the tools
As I have previous blogged, I use a configuration management tool to manage all my systems (which make rebuilding, in a DR type situation, and reproducing them, for testing, very easy) and I use this tool to install the packages. However, for the purposes of this post I will document the commands that would be used to do it by hand.
The tools to install are:
unattended-upgrades- this is responsible for orchestrating the actual update/upgrade
apt-listchanges- this is responsible for notifying me when packages are automatically upgraded, which will help with troubleshooting if there is ever a problem
Pre-seeding the configuration
This step is unnecessary if you are happy to rely on the default setting being to enable
unattended-upgrades (which is what I did). It will configure itself to be enabled and to auto update packages (by turning on
APT::Periodic::Unattended-Upgrade in the aforementioned
/etc/apt/apt.conf.d/20auto-upgrades configuration file). If you want to be sure it will enable itself on install, or explicitly record that it has been manually set to on, you can pre-seed the debconf database with that information:
echo unattended-upgrades unattended-upgrades/enable_auto_updates boolean true | debconf-set-selections
If the package is already installed and you change the selections, you will want to tell dpkg to reconfigure it:
dpkg-reconfigure -f noninteractive unattended-upgrades
Use your usual package management tool:
apt-get install unattended-upgrades
Pre-seeing the configuration
The key setting I wanted to change was the type of changes that are displayed. By default it is set to ‘news’ which displays news items only (the contents of the package’s
NEWS.Debian.gz file) but if I am not monitoring it, I want more information by email:
Please choose which type of changes should be displayed with APT. news : important news items only; changelogs: detailed changelogs only; both : news and changelogs. 1. news 2. changelogs 3. both
This can be pre-seeded (or altered and then applied with
dpkg-reconfigure as I mentioned above) with:
echo apt-listchanges apt-listchanges/which select both | debconf-set-selections
Another one to modify is where to display a header before each changelog with the source package name and the binary package name(s), when different to the source package name.
apt-listchanges apt-listchanges/headers boolean true | debconf-set-selections
You may want to change the default email address away from root too:
echo apt-listchanges apt-listchanges/email-address string email@example.com | debconf-set-selections
Use your usual package management tool:
apt-get install apt-listchanges
unattended-upgrade can be run manually to test:
…and that is all you need to do, although I am waiting for an update to confirm it is working as intended on my live systems.