## Why I Am Happy, that my Computers Are Working Again

The recent power failures left me in quite a state of distress, not knowing what the fate of my computers would be.

The computer acting as my Web server, ‘Phoenix’ is a Linux computer, running a “Debian” version of Linux, and a flavor of that, which is “Kanotix / Spitfire” . After the second power interruption this morning, ‘Phoenix’ was actually easier to restart fully, than my Windows 7 machine ‘Mithral’ was. This was somewhat reassuring, since ‘Mithral’ has stronger hardware, and since If the software on ‘Mithral’ was ever permanently messed up, I could in fact try to resurrect it by installing Linux on it. It seems that Linux was after all more stable than Windows.

But what happened to ‘Phoenix’ was also better than a scenario would have been, which I had running through my head between 7h30 this morning and 12h00, the time at which I got ‘Phoenix’ running again.

I had had the scenario in my head, that ‘Phoenix’ could have started to perform an ‘unattended upgrade’, at the moment the power went off, a coincidence which I would have been unaware of.

Luckily, this was not what happened.

But had this happened, my own version of what would have gone wrong differs slightly from the official version, according to which the package manager would simply have gotten jammed in some locked state.

There happen to be other power-users, who complain on the Kanotix user forum, that they had been running a lengthy upgrade while their power was strangely cut. Those people ask for Expert support in unjamming their package manager, which more detached people on the forum give advice on how to do.

According to me, they had such a hard time unjamming their package manager, because this is not all that was wrong with their computers. According to me, those users suffered from two problems at once: A jammed package manager, plus A corrupted file system.

I had a vision of having to approach the Kanotix user forum with the familiar line, ‘An upgrade was running, when the plug was pulled.’ But luckily, no upgrade was running at that time…

…And, there is a specific reason why No Unattended Upgrades Were Running. After I rebooted ‘Phoenix’ successfully, I performed the upgrades manually, which were to have run, just to confirm that my package manager still works 100% .

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

This package is first to be enabled in this file

And then configured in this file

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

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";