Bug#638024: user story --- bad Default-Release breaks unattended-upgrades

["Trent W. Buck" <trentbuck@gmail.com>]

Hi, I have a user story relevant to #638024.

TL;DR version:

  When Default-Release is set and /var/lib/apt/lists is empty,
  apt-get check errors, and unattended-upgrades silently fail.

Boring backstory follows.

I'm making headless servers to be deployed in the homes of non-technical users.
To harden them against operator error, their OS is a read-only Debian Live image.

As part of my Best Current Practice I set Default-Release "stretch",
to prevent accidental dist-upgrades when sources.list is in an unusual state.
(For THIS server, that's unlikely, but it's BCP so I do it everywhere.)

To make the image smaller, /var/lib/apt/lists is not included.
(It'll have to download the full Packages files after each reboot, but
these servers won't reboot regularly, so that's fine.)

As part of my Best Current Practice I install and enable unattended-upgrades.
This won't fix kernel vulns (since it's a read-only image), but
it WILL fix userland vulns (e.g. to glibc).
(It'll have to re-download all the security patches after each reboot, but
these servers won't reboot regularly, so that's fine.)


With this framework, unattended-upgrades doesn't work, and this shows why:

    root@datasafe:~# cat >/etc/apt/apt.conf.d/20derp
    APT::Periodic::Verbose "2";

    root@datasafe:~# /usr/lib/apt/apt.systemd.daily update
    verbose level 2
    Reading package lists... Done
    E: The value 'stretch' is invalid for APT::Default-Release as such a release is not available in the sources
    error encountered in cron job with "apt-get check".

Note that APT::Default-Release is the ONLY problem here:

    root@datasafe:~# apt-get check
    Reading package lists... Done
    E: The value 'stretch' is invalid for APT::Default-Release as such a release is not available in the sources

    root@datasafe:~# apt-get check -t ''
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done

Doing the first apt update by hand fixes the immediate problem:

    root@datasafe:~# apt update -qq
    All packages are up to date.

    root@datasafe:~# rm /var/lib/apt/periodic/update-stamp
    root@datasafe:~# /usr/lib/apt/apt.systemd.daily update
    verbose level 2
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    check_stamp: missing time stamp file: /var/lib/apt/periodic/update-stamp.
    Hit:1 http://security.debian.org stretch/updates InRelease
    Ign:2 http://cdn-fastly.deb.debian.org/debian stretch InRelease
    Hit:3 http://cdn-fastly.deb.debian.org/debian stretch-updates InRelease
    Hit:4 http://cdn-fastly.deb.debian.org/debian stretch-backports InRelease
    Hit:5 http://cdn-fastly.deb.debian.org/debian stretch Release
    Reading package lists... Done
    download updated metadata (success).
    send dbus signal (success)
    check_stamp: interval=0
    download upgradable (not run)
    unattended-upgrade -d (not run)

Unfortunately that basically means I have to run "apt update" by hand after every reboot.
I could do that in a simple @reboot cron job (or systemd.timer equivalent), but
what happens if the user turns on the computer while the network cable is unplugged?

In that case, the @reboot apt update will fail, and we're back to unattended-upgrades not applying.

I could run apt by hand when "the" network is up, e.g. via network-wait-online.target or an interfaces(5) post-up command.
But this actually runs as soon as systemd-networkd has a route to google, not when HTTP to deb.debian.org is allowed, so
it can still fail in obscure edge cases (e.g. if the device is booted behind a hotel's captive portal).



Is there some way to resolve this on your end?
Allowing Default-Release "foo" when /var/lib/apt/lists is empty would be ideal for me, but I suspect not for you. ☺

In the meantime, AFAICT my options are:

  • don't set Default-Release, and
    accept the low-chance high-impact risk of accidental dist-upgrade.

  • run apt update by hand whenever "the" network is "up", and
    accept the low-chance high-impact risk of no security patches if the update fails.

  • make /var/lib/apt/lists persistent across reboots, and
    accept the extra cost (for the HDD or whatever), complexity, and
    failure modes when the storage dies or gets corrupted.