Ship unattended-upgrades with BunsenLabs?

johnraff · 2017-08-17 03:33:21

This is a continuation of a discussion about whether to ship unattended-upgrades with BunsenLabs by default. As far as I can tell, unattended upgrades still have to be enabled after installing the package.

Checking installed files (docs etc have been omitted here):

john@bunsen1:~$ dpkg -L unattended-upgrades
/lib/systemd/system/unattended-upgrades.service
/etc/init.d/unattended-upgrades
/etc/kernel/postinst.d/unattended-upgrades
/etc/pm/sleep.d/10_unattended-upgrades-hibernate
/etc/logrotate.d/unattended-upgrades
/etc/apt/apt.conf.d/50unattended-upgrades
/usr/share/doc/unattended-upgrades/README.md.gz
/usr/share/unattended-upgrades
/usr/share/unattended-upgrades/20auto-upgrades
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
/usr/share/unattended-upgrades/20auto-upgrades-disabled
/usr/bin/unattended-upgrade
/var/log/unattended-upgrades
/usr/bin/unattended-upgrades # symlink to /usr/bin/unattended-upgrade

But:

man unattended-upgrade wrote:

This script is the backend for the APT::Periodic::Unattended-Upgrade option.

And:

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

This script can upgrade packages automatically and unattended.
However, it is not enabled by default.
...
If you would prefer to enable it from the command line, run
"sudo dpkg-reconfigure -plow unattended-upgrades".
...
To activate this script manually you need to ensure that the apt
configuration contains the following lines (this can be done via the
graphical "Software Source" program or via dpkg-reconfigure as well):
```
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
```

APT config settings are amalgamated from the contents of /etc/apt/apt.conf.d. You can see them with 'apt-config dump'.
After installing unattended-upgrades:

john@bunsen1:~$ apt-config dump | grep -i 'periodic'

After running 'sudo dpkg-reconfigure -plow unattended-upgrades' and choosing to enable them:

john@bunsen1:~$ apt-config dump | grep -i 'periodic'
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

So running the dpkg-reconfigure command has the same result as adding the two apt configs mentioned in README. It creates the file /etc/apt/apt.conf.d/20auto-upgrades (but any file in apt.conf.d would do).

There is quite a selection of tweakable settings for u-u in /etc/apt/apt.conf.d/50unattended-upgrades but the defaults look OK.

The systemd.service file runs /usr/share/unattended-upgrades/unattended-upgrade-shutdown, a Python script that seems to be checking the apt configs, which - if true - would confirm the above.

It takes a while to see if any updates are being installed or not, but it looks as if just installing the package will not trigger them. I've just enabled this on my Jessie machine to see what happens, but if anyone would like to try it on Stretch it would be nice to confirm that auto-upgrades have to be enabled by the user.

We could ship the package by default, disabled (as it seems to be by default anyway) and them offer to enable it in bl-welcome? The script would just have to drop a file in /etc/apt/apt.conf.d - or run the dpkg-reconfigure command, with the same result.

Last edited by johnraff (2017-08-17 07:03:48)

Sector11 · 2017-08-17 03:48:57

Oh ... not enabled by default. Then by all means:

johnraff wrote:

We could ship the package by default, disabled (as it seems to be by default anyway) and them offer to enable it in bl-welcome? The script would just have to drop a file in /etc/apt/apt.conf.d.

I concur.

KrunchTime · 2017-08-17 04:46:57

I vote no; another package I have to remove.

brontosaurusrex · 2017-08-17 06:05:25

They seem to be
- complicated to understand (when enabled; for example, will this reboot by default or not)
- something from server world
- when enabled; possibly delaying stuff in cron.daily due to random delays in apt execution (not sure)
- when enabled; what are the possibilities this will run in the middle of my slither game and take the needed bandwidth?
- something Microsoft would enable by default
So for a desktop I'd say no.

Last edited by brontosaurusrex (2017-08-17 06:27:04)

Head_on_a_Stick · 2017-08-17 06:33:22

johnraff wrote:

We could ship the package by default, disabled (as it seems to be by default anyway) and them offer to enable it in bl-welcome? The script would just have to drop a file in /etc/apt/apt.conf.d.

That sounds perfect.

I used this method to activate unattended-upgrades in my Debian laptop (it was a while ago), I will try with a fresh setup when I have time.

MALsPa · 2017-08-17 07:00:26

KrunchTime wrote:

I vote no; another package I have to remove.

Same here. Ugh. Disabled by default would be good. Not installed at all would be better, in my book. But then, the reason this thread caught my eye was that I recently removed the unattended-upgrades package from two of my Stretch installations. I think it's brought in by the GNOME and KDE desktops in Debian now.

nobody · 2017-08-17 08:41:49

Unattended-upgrades is for server systems. Especially since a personal computer can be shut down any second by the user, or in the case of a laptop, power loss, leaving the package manager in an inconsistent state. Otherwise, it must be at the very least ensured that shutdown is inhibited somehow, which probably is going to rely on systemd or some dbus interface. Needs to be tested too, of course.

Steve · 2017-08-17 08:59:13

Would something like this be better?

Cron-apt

I like the sound of this one as it just downloads the updates and does not install them, also has the ability to email you the update list so you can take a look at it.

automatic update of packages using apt-get
Contains a tool that is run by a cron job at regular intervals. By default it just updates the package list and downloads new packages without installing. You can instruct it to run anything that you can do with apt-get (or aptitude).
It can optionally send mail to the system administrator on errors, log to syslog or a separate log file.
Observe that this tool may be a security risk, so you should not set it to do more than necessary. Automatic upgrade of all packages is NOT recommended unless you are in full control of the package repository.

Last edited by Steve (2017-08-17 08:59:29)

tknomanzr · 2017-08-17 14:39:43

I check for updates via a systemd unit file that calls apt update every 6 hours or so. I then parse apt --list-upgradable to get the number of updates available and a list (sometimes partial) of available updates. It does not download or install anything but does give me a nice reminder to update my system.

My original post on this subject are here: Update Notifications
and the scripts can be found here: https://github.com/tknomanzr/scripts/tr … st-updates

I know this is not quite what @johnraff was asking but it is my preferred method.

DeepDayze · 2017-08-17 16:15:42

tknomanzr wrote:

I check for updates via a systemd unit file that calls apt update every 6 hours or so. I then parse apt --list-upgradable to get the number of updates available and a list (sometimes partial) of available updates. It does not download or install anything but does give me a nice reminder to update my system.
My original post on this subject are here: Update Notifications
and the scripts can be found here: https://github.com/tknomanzr/scripts/tr … st-updates
I know this is not quite what @johnraff was asking but it is my preferred method.

I like that idea of an update notifier and perhaps ask if you want to review and/or install the updates.

Sector11 · 2017-08-17 16:26:04

tknomanzr wrote:

I know this is not quite what @johnraff was asking but it is my preferred method.

OH I have been looking to do that for a long time, totally missed that other thread. THANK YOU!
Made some tweaks since all I want is numbers.

For me this is perfect, I see there are updates available .... I go get them!

/home/sector11/bin/list-updates

#!/bin/bash
#Original by: tknomanzr - BL Die Hard
#found here: https://github.com/tknomanzr/scripts/tree/master/list-updates
#discussed here: https://forums.bunsenlabs.org/viewtopic.php?pid=58531#p58531
#Tweaked: 2017-08-17

readarray -t updates <<< "$(apt list --upgradable 2>/dev/null)"
numupdates=$((${#updates[*]}-1))
echo $numupdates
exit 0;

and /home/sector11/bin/list-installed

#!/bin/bash
#Original by: tknomanzr - BL Die Hard
#found here: https://github.com/tknomanzr/scripts/tree/master/list-updates
#discussed here: https://forums.bunsenlabs.org/viewtopic.php?pid=58531#p58531
#Tweaked: 2017-08-17

readarray -t instd <<< "$(apt list --installed 2>/dev/null)"
numinstd=$((${#instd[*]}-1))
echo $numinstd
exit 0;

In the conky:

Bunsenlabs Installed: ${execpi 1800 list-installed}
 Update(s) Avaliable: ${execpi 1800 list-updates}

EDIT: What's the 2 for?

readarray -t updates <<< "$(apt list --upgradable 2>/dev/null)"

Last edited by Sector11 (2017-08-17 16:33:12)

Sun For Miles · 2017-08-17 16:48:33

Sector11 wrote:

EDIT: What's the 2 for?
readarray -t updates <<< "$(apt list --upgradable 2>/dev/null)"

It's one of three file descriptors, means "stderr". Here is a bit more in depth about the topic.

Sector11 · 2017-08-17 17:00:25

I see said the blind man ... thank you.

1 stdin (the keyboard),
2 stdout (the screen), and
3 stderr (error messages output to the screen)

OOPS, no not that ---
stdin, stdout, and stderr are 0, 1, and 2, respectively

0 stdin (the keyboard),
1 stdout (the screen), and
2 stderr (error messages output to the screen)

Makes sense pushing the errors to /dev/null and not the conky.

It's a good day - I learned two things.

Last edited by Sector11 (2017-08-17 17:08:35)

Sun For Miles · 2017-08-17 17:06:25

You welcome.

Ontopic: I don't mind having an option to enable unattended updates, but I wouldn't like it turned on by default.

Last edited by Sun For Miles (2017-08-17 17:07:41)

johnraff · 2017-08-18 07:08:38

Clearly not a great deal of support for installing unattended-upgrades, even disabled by default.

Perhaps these alternatives:
1) Put an option in bl-welcome to install and configure unattended-upgrades.
2) Use tknomanzr's script to check for available updates and notify the user - enabled by default...
3) ... or via a bl-welcome question.

I'm leaning towards 3) atm, but, opinions?

KrunchTime · 2017-08-18 08:43:10

^ I vote for option 3, since I don't use the bl-welcome script. I've already stated my opinion about option 1. I don't like option 2 either, although that is better than option 1 since it doesn't download or install anything. I guess I'm old school...if I want to know if there are any updates, then I'll use apt/apt-get/aptitude.

Sector11 · 2017-08-18 19:01:27

johnraff wrote:

Clearly not a great deal of support for installing unattended-upgrades, even disabled by default.
Perhaps these alternatives:
1) Put an option in bl-welcome to install and configure unattended-upgrades.
2) Use tknomanzr's script to check for available updates and notify the user - enabled by default...
3) ... or via a bl-welcome question.
I'm leaning towards 3) atm, but, opinions?

What is the difference between 1 and 3?

If #3 is having it already installed by default and the question is: "Do you want it configured?" Well I would go for #1 since having it installed but not configured to run is kind of lame for a noob like me, and obviously, NO would not install it.

The options as I see them:
1. Installed with sane defaults - nothing required it's a part of BL
2. Ask if the user wants it installed, with sane defaults
3. Ask if the user wants it installed, with no configs (user knows it's there and needs configuring).
4. Leave it uninstalled.

tknomanzr · 2017-08-19 00:01:35

I would offer unattended-upgrades with configuration as an option in bl-welcome. Then implement a conky notification as a less intrusive option by default. We could either go the route that S11 took and just list the number of available updates, or include the package list as I did. I could even implement an arg parser that would allow the user to choose just the number or the number plus the list when calling the script. This would allow for either barebones or a more informative output as desired without having to write another script.

I would rewrite the script though, and call the apt update command prior to running apt list --upgradable. At the moment, I have pushed that off as a systemd timer and service. I find that can cause some minor sync issues between the info presented in conky and what one would see in the terminal. The key here though is to not call the update very frequently (once or twice a day should be enough for Stable branch) to save stress on Debian's servers/mirrors. My main reasoning for running the update via systemd timers was more as a learning lesson. In retrospect, it just does not make sense for this script. I will try to find a few quiet moments to rewrite the script with an arg parser and dump the systemd unit files, if there is interest in presenting the info in a conky. Also, note that backports have strange effects on apt list --upgradable, causing the count it returns to be off.

As far as unattended-upgrades, I can think of machines I would like to have that on -- machines I install BL on because they are too old to run Windows 10 or machines I run BL on that I don't use regularly. Therefore, the option to turn it on for some machines would be nice but I would also settle for a searchable forum post if need be. I just would not want that on my daily driver. I can speak from experience when I say that a failure in the middle of an update can wreak havoc on an install. Imagine a dist-upgrade involving a couple of hundred packages and your liquid cooler dies in the middle of the dist-upgrade. It was a huge mess and exposed some fairly serious logic flaws in my btrfs backup scripts. (I had failed to take a full backup so the snapshots I was taking after any apt-get action were useless.)

At any rate, I will work on the script some either this weekend or early next week and get it posted.

Sector11 · 2017-08-19 01:12:42

^ Two thumbs up! Looking forward to it.

johnraff · 2017-08-19 02:52:29

Perhaps I should clarify:

johnraff wrote:

Perhaps these alternatives:
1) Put an option in bl-welcome to install and configure unattended-upgrades.

So u-u would not be installed by default, only if a user ran bl-welcome and answered "yes" when asked. (So this is not the option KrunchTime had already expressed an opinion on.) People like KT who don't run bl-welcome would never see it.

( I would in fact recommend running bl-welcome on a new install, even if answering "No" to all the options, except apt-get up{date,grade}. There might be things we throw in there that got left out of the iso, for example, or bugs that need fixing. There's nothing of that nature atm, but for example an apt/sources.list error was fixed that way some time ago, and at the time of the "Deuterium" point release bl-welcome offered to upgrade existing users' configs. )

Now here, I'm not talking about unattended-upgrades, I'm talking about a notification system to inform the user when upgrades are available:

2) Use tknomanzr's script to check for available updates and notify the user - enabled by default...
3) ... or via a bl-welcome question.

So option 3) would mean the notifications had to be enabled via bl-welcome.

#1 2017-08-17 03:33:21

Ship unattended-upgrades with BunsenLabs?

#2 2017-08-17 03:48:57

Re: Ship unattended-upgrades with BunsenLabs?

#3 2017-08-17 04:46:57

Re: Ship unattended-upgrades with BunsenLabs?

#4 2017-08-17 06:05:25

Re: Ship unattended-upgrades with BunsenLabs?

#5 2017-08-17 06:33:22

Re: Ship unattended-upgrades with BunsenLabs?

#6 2017-08-17 07:00:26

Re: Ship unattended-upgrades with BunsenLabs?

#7 2017-08-17 08:41:49

Re: Ship unattended-upgrades with BunsenLabs?

#8 2017-08-17 08:59:13

Re: Ship unattended-upgrades with BunsenLabs?

#9 2017-08-17 14:39:43

Re: Ship unattended-upgrades with BunsenLabs?

#10 2017-08-17 16:15:42

Re: Ship unattended-upgrades with BunsenLabs?

#11 2017-08-17 16:26:04

Re: Ship unattended-upgrades with BunsenLabs?

#12 2017-08-17 16:48:33

Re: Ship unattended-upgrades with BunsenLabs?

#13 2017-08-17 17:00:25

Re: Ship unattended-upgrades with BunsenLabs?

#14 2017-08-17 17:06:25

Re: Ship unattended-upgrades with BunsenLabs?

#15 2017-08-18 07:08:38

Re: Ship unattended-upgrades with BunsenLabs?

#16 2017-08-18 08:43:10

Re: Ship unattended-upgrades with BunsenLabs?

#17 2017-08-18 19:01:27

Re: Ship unattended-upgrades with BunsenLabs?

#18 2017-08-19 00:01:35

Re: Ship unattended-upgrades with BunsenLabs?

#19 2017-08-19 01:12:42

Re: Ship unattended-upgrades with BunsenLabs?

#20 2017-08-19 02:52:29

Re: Ship unattended-upgrades with BunsenLabs?

Board footer