You are not logged in.

#1 2018-07-14 06:50:23

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 4,675
Website

[notabug?] unattended-upgrades will not run by default

This is something that BunsenLabs users might run into if they install unattended-upgrades and expect it to run with the default config.

You should check over the Debian Wiki article anyway, and probably want to enable emails to "root", but what must be changed in /etc/apt/apt.conf.d/50unattended-upgrades is line 39

     "origin=Debian,codename=${distro_codename},label=Debian-Security";

because on BunsenLabs, ${distro_codename} will resolve to "helium". (No debian-security upgrades come from us, unfortunately. neutral) Change it to "stretch" and upgrades should start to work:

     "origin=Debian,codename=stretch,label=Debian-Security";

Run

sudo unattended-upgrades -v -d

before and after the change to see.

I've only just hit this, so I'll have to wait till the next security upgrades come in to be 100% sure.

A bug? The reason ${distro_codename} doesn't resolve to the Debian release "stretch" is presumably that 'lsb_release -sc' returns "helium" on BL Helium. That's as it should be, other things considered, but I'm not sure where else to report this.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#2 2018-07-14 08:03:59

brontosaurusrex
Middle Office
Registered: 2015-09-29
Posts: 1,594

Re: [notabug?] unattended-upgrades will not run by default

The possible (small) problem is that people might update to buster and forget about manual interventions like this. What is the procedure to assign this env variables and is it easily tweakable somehow? (If not easy i'd call this post a solution and not waste any sleep over it).

P.s. Personally i'd classifie unattended-upgrades as something that runs on server mostly. If that is true than this is a no problem.

Last edited by brontosaurusrex (2018-07-14 08:10:25)

Offline

#3 2018-07-14 08:28:29

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 4,675
Website

Re: [notabug?] unattended-upgrades will not run by default

It's not an env variable as far as I can tell without digging deeply into the code - I'm guessing it's something apt or unattended-upgrades is generating, possibly from the output of 'lsb_release -sc', which on normal Debian systems would be the Debian codename.

lsb_release's info is configured by our bunsen-os-release package, according to standards, and necessary for some other things to work correctly, but nothing specifically BL in fact. Grub menu, software-properties-gtk...

If that package was removed then lsb_release would revert to reporting "stretch" or "buster", and this has been reported as the fix for another issue I now forget (printer driver?).

No, the situation is not quite optimal, but in fact most users of unattended-upgrades are expected to edit /etc/apt/apt.conf.d/50unattended-upgrades anyway.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#4 2018-07-14 11:20:41

brontosaurusrex
Middle Office
Registered: 2015-09-29
Posts: 1,594

Re: [notabug?] unattended-upgrades will not run by default

So that could be Debian/nodejs/etc related bug and has nothing to do with BL, however I can imagine a lot of people dealing with nodejs and that could be a problem.

Offline

#5 2018-07-15 06:49:04

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 4,675
Website

Re: [notabug?] unattended-upgrades will not run by default

Well I'm not sure if this is a bug at all TBH:

If unattended-upgrades is installed on a system which is not pure Debian (as reported by 'lsb_release') then the default configuration will probably need adjusting.

As I mentioned above, users are really expected to check the configuration file anyway.

---
I did dig a bit further and found:

/usr/share/doc/unattended-upgrades/README.md.gz wrote:

Variable substitution is supported
for ${distro_id} that contains the output of `lsb_release -i` and
${distro_codename} that contains the output of `lsb_release -c`.

NB the below is not true:

/etc/apt/apt.conf.d/50unattended-upgrades wrote:

// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}            Installed origin.
//   ${distro_codename}      Installed codename (eg, "jessie")

Anyway, indeed, on BL the default config would look for upgrades from 'helium' labelled 'Debian-Security'. Replace '${distro_codename}' with 'stretch' and all is well.

The behaviour of unattended-upgrades wrt config files changed between Jessie and Stretch, so Buster might be different again, but /etc/apt/apt.conf.d/50unattended-upgrades will likely need tweaking once more.

Last edited by johnraff (2018-10-13 02:48:05)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

Board footer

Powered by FluxBB