Bug#638024: user story --- bad Default-Release breaks unattended-upgrades
David Kalnischkies wrote: > On Wed, Jan 24, 2018 at 02:10:43PM +1100, Trent W. Buck wrote: > > 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.) > > As your entire story depends on this, could you tell us please what you > mean here? "accidental dist-upgrade" and "unusual state" don't make > a lot of sense to me. Sorry that wasn't clear. The unusual state I'm thinking of is along the lines of this: * my normal system runs stable * the frobozz maintainer claims #123456 is fixed in unstable, and asks me to check it * rather than setting up a whole new unstable test VM, just enable unstable in sources.list temporarily, cherry-pick frobozz, test it, then downgrade again. (Obviously this wouldn't work for something hairy like mysql, but for GUI apps it's usually fine.) * whoops, "apt install frobozz" has upgraded libc and friends because I wasn't paying attention and just hit yes. Now important parts of my system are running unstable, not just that app. When Default-Release is set, in that last step, I have to explicitly ask for any dependencies that can't be met from stable. These days I personally am more likely to roll an in-house backport package, but at least three times my coworkers (who aren't debian experts) have bricked their laptops by trying something along these lines, usually because "stackoverflow/reddit said this would work". This is also a helpful safety net if I forget to remove unstable from sources.list afterwards. In the old days, before I knew about rmadison, I would just leave my system with stable, testing, unstable and experimental all enabled, but only actually install stuff from stable, so I could use apt-cache policy to find out what versions of frobozz debian had. Now that you've made me spell it out, I realize that a lot of the stuff I've described isn't officially supported, and I haven't actually used much since about 2013. I guess at this point I'm setting Default-Release out of habit, because it's saved me from my own stupid mistakes in the past. > Nuking /var/lib/apt/lists isn't the best practice either as some > security features use the "old" data to put up constraints for the "new" > data – including that a repository can't change its Codename from > "buster" to "bullseye" without a user explicitly confirming this (even > if "stable" is written in the sources.list – implemented in 1.5 which is > why I talk about stable+1 and stable+2 at the time of writing). When I have persistent storage, I keep /var/lib/apt/lists. The case where this bit me was a Debian Live environment, where to keep the image small (<128MB) I habitually strip out a lot of stuff, including apt lists. I didn't know about the safety net stuff you describe; that might be valuable enough to compile apt lists into the Debian Live image — I'll try it and see how it affects image size and boot time. Let's see, normal build gives me 4.7Mlive/boot/vmlinuz 17M live/boot/initrd.img 85M live/boot/filesystem.squashfs 106Mtotal Including /var/lib/apt/lists gives me 4.7Mlive/boot/vmlinuz 17M live/boot/initrd.img 98M live/boot/filesystem.squashfs 119Mtotal So, a 10.9% increase in image size. Bleh — although it's still <128MiB, so I'll think about it.
Bug#638024: user story --- bad Default-Release breaks unattended-upgrades
On Wed, Jan 24, 2018 at 02:10:43PM +1100, Trent W. Buck wrote: > 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.) As your entire story depends on this, could you tell us please what you mean here? "accidental dist-upgrade" and "unusual state" don't make a lot of sense to me. I /guess/ you are talking about an upgrade from stretch to buster at the time buster becomes stable – but that would only happen if you would use "stable" in your sources.list instead of "stretch" and is hence kinda the point of using "stable" there… Nuking /var/lib/apt/lists isn't the best practice either as some security features use the "old" data to put up constraints for the "new" data – including that a repository can't change its Codename from "buster" to "bullseye" without a user explicitly confirming this (even if "stable" is written in the sources.list – implemented in 1.5 which is why I talk about stable+1 and stable+2 at the time of writing). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#638024: [apt] RE: Bug#638024: user story --- bad Default-Release breaks unattended-upgrades
Package: apt Version: 1.4.8 Just adding as a user watching this bug, I looked into this 'can't satisfy default release' problem recently as I changed Devuan repositories in use (https://bugs.devuan.org/db/17/172.html if you can stomach complete lack of MIME-email handling in that bug system...). From my notes: In libapt-pkg5.0/apt-1.4.8/apt-pkg/policy.cc:pkgPolicy::pkgPolicy, if a Default-Release has been specified, the code loops through all package cache files (cached versions of the repo release files) looking for one which has an archive (suite), codename or version that matches the Default-Release. When you change all repo URLs (or in your case have no cached repo info at all), these caches are invalidated and only the '/var/lib/dpkg/status' package cache file remains - which has archive 'now' and little else. So when you do 'aptitude update', the loop checks just this file and then says 'nope, no matching repo found'. Normally for me this error happens just before the repo information is fetched, so the problem is immediately fixed when they are downloaded and processed - naturally the next command that needs to run (e.g. aptitude full-upgrade) finds the relevant archive/codename and is happy. --- System information. --- Architecture: Kernel: Linux 4.9.0-5-amd64 Debian Release: 9 990 testing-updates 10.1.0.3 990 testing-security 10.1.0.3 990 testing 10.1.0.3 500 unstable10.1.0.3 500 quodlibet-unstable lazka.github.io 100 ascii-proposed 10.1.0.3 --- Package information. --- Depends (Version) | Installed ===-+-= adduser | 3.115 gpgv| 2.1.18-8~deb9u1 OR gpgv2 | OR gpgv1 | debian-archive-keyring | 2017.5 init-system-helpers (>= 1.18~) | 1.48+devuan2.0 libapt-pkg5.0 (>= 1.3~rc2) | 1.4.8 libc6 (>= 2.15) | 2.24-11+deb9u1 libgcc1 (>= 1:3.0) | 1:6.3.0-18 libstdc++6 (>= 5.2) | 6.3.0-18 Recommends (Version) | Installed =-+-=== gnupg | 2.1.18-8~deb9u1 OR gnupg2| 2.1.18-8~deb9u1 OR gnupg1| Suggests (Version) | Installed ==-+- apt-doc| 1.4.8 aptitude | 0.8.7-1 OR synaptic | 0.84.2 OR wajig | dpkg-dev (>= 1.17.2) | 1.18.24 powermgmt-base | 1.31+nmu1 python-apt | 1.4.0~beta3 signature.asc Description: OpenPGP digital signature
Bug#638024: user story --- bad Default-Release breaks unattended-upgrades
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.
