I have just had to get my hands dirty, with apt-listbugs.

According to This Posting, I have installed ‘unattended-upgrades‘ on the computer I name ‘Phoenix’, and I have also installed ‘apt-listbugs‘, as an insurance policy against ‘unattended-upgrades‘ auto-installing defective packages.

This has always posed the question of what will happen in practice, if ‘apt-listbugs‘ “pins” certain packages, thus having stopped them, but if the update-procedure needs to be reactivated later, manually. I have never had to act in this matter yet, while instead, there was one recorded occasion, on which upgrades did not take place on one day, but took place again a day later, automatically.

But just today I needed to override what ‘apt-listbugs‘ had done, manually. In particular, the question exists, of how one can get apt-listbugs to unpin an upgrade which was once scheduled, so that we can do the upgrade later, and so that we can see what apt-listbugs had to say about it.

By default, if we then simply type in ‘apt-get upgrade‘, nothing happens.

As it turns out, there is a single file named ‘/etc/apt/preferences.d/apt-listbugs‘, which we need to delete, before we can restart an upgrade process.

After I did this, my ‘apt-get upgrade‘ took place normally again, and I got to see what the error was, over which ‘apt-listbugs‘ had stopped the unattended upgrade today.

Dirk

 

Unattended Upgrades Did Not Run This Morning.

I previously wrote about the Debian package ‘unattended-upgrades’ Here. This morning however, this system did not install any upgrades, almost as if it had not run. Yet, I found no changes to any of the relevant configuration files. But I do have a tentative explanation as to why, maybe, this package did not run as usual.

When I prompted my KDE desktop tool to do the pending upgrades – that tool having been named “Tasker” in some versions of KDE, it showed that there was an upgrade pending for the package “Wireshark”. What I dimly seem to recall, is that the previous version of Wireshark had a severe bug. It is entirely possible that the unattended upgrades did not run this time, because I also have installed ‘apt-listbugs’.

If this supposition was true, then today would have been the first demonstration, of how this package will prevent an unattended upgrade from running. If true, this would come as a relief, because I previously had the fear that although this package would prevent a potentially damaging upgrade, it might also corrupt the state of ‘apt-get’. Apparently it will not. Let us keep our fingers crossed.

Dirk

 

How to Set Up Unattended Upgrades under Linux

I have a Debian / Jessie Linux system, with KDE 4 as my desktop manager. I have set up unattended upgrades on this machine, and would like to share with my community, the best way to do so.

Even though KDE possesses a feature called “Apper”, I do not recommend that we use this in order to perform unattended upgrades. The reason has to do with how Apper fails to deal with authentication properly.

In preparation, I would recommend that people install the package

apt-get install apt-listbugs

What this package will do is to query the Debian bug lists for any package, prior to upgrading or installing it. If the known bug-level exceeds a certain threshold, ‘apt-listbugs’ will ask the user for confirmation interactively, before installing the package. This inserts a hook into the package installation routine, which will also be invoked by unattended upgrades.

apt-listbugs is to be configured in the file

/etc/apt/apt.conf.d/10apt-listbugs

The critical line here is the one that reads

AptListbugs::Severities “critical,grave,serious”;

As the severity level which should be stopped. For a list of available severity levels, read ‘man apt-listbugs’. I found that the default was adequate. If the severity level is set too low, this mechanism will be triggered too often, but if it allows bugs to be installed which are too severe, the automated upgrades will do so.

I have not spent time pondering on how to straighten out an apt-get cache, if the apt-listbugs mechanism was triggered by a batch operation, but suspect that doing so would be easier, than to deal with installed, severe bugs. I.e., this mechanism has been triggered on my machine, only by manual installation of packages. I keep it as a precaution, that will also work with ‘unattended-upgrades’.

Finally, we can install

apt-get install unattended-upgrades

This package is first to be enabled in this file

/usr/share/unattended-upgrades/20auto-upgrades

And then configured in this file

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

It is important that this package not be left at its default configuration! Please read each entry in this file, and consider what settings are appropriate. Mainly, the bundled blacklist is not adequate. Further, while to have upgrades installed may be fine, to allow your system to reboot afterward might not be fine.

And one reason for this could be, that we have a desktop manager running, which will not end the session cleanly, if the system command ‘/sbin/reboot’ is simply given. And ‘unattended-upgrades’ will use this command, in complete disregard for what desktop manager is being used.

Therefore, all packages should be identified, which when upgraded will also require a reboot, such as

Kernel Images

Kernel Header Files

Graphics Drivers

etc., etc., etc.. And then having forbidden those, the automatic reboot feature should, in my opinion, be disabled as well.

Under KDE 4, Apper will next show me which packages have not been upgraded yet, so that I may do so through Apper if I like, at which point I can manage the procedure as well. And I expect that Apper will also show me any dialogs which ‘apt-listbugs’ might display.

This system has been working splendidly for me, since June 2, 2015. I have no complaints.

Dirk

(Edit 03/14/2016 : ) Apparently, there was a crucial configuration step, which I forgot to mention, because I had forgotten setting it up. It is necessary to create a configuration file within ‘/etc/apt/apt.conf.d‘ . This config file may be named like so: ‘02periodic‘ . In my case, this file actually enables the service with the following content:


// Enable automatic upgrades of security packages

APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";