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

 

Print Friendly, PDF & Email

The Opus En Ligne Card Reader

On the Island Of Montreal, one very common means of paying both the bus fares and subway trips – which we call “The Metro” – is by way of an “Opus” chip-card, which is NFC-enabled, which means that we wave it in front of a terminal located in the front of the bus, or at gates which lead into our Metro Stations. But, it used to beĀ  hassle for me that I still needed to go to a licensed store counter, to have my Opus Card recharged every month, and to pay actual money there.

The STM – which is the public transit organization responsible here – took the trendy step of offering tech-savvy riders the option, of buying a card reader which we can plug in to a USB port, and which we can use to recharge this transit card online.

I’ve used mine twice now. The only real drawback is the fact that once we’ve received our card reader, we need to download the device driver online if we’re using Windows 7.

But aside from that I feel comfortable using it, especially when the weather outside is snow and sleet, and it’s not convenient for me to go to a designated location to have it recharged. I even happen to be especially sensitive, to the thought that a chip-card might move or wiggle in its slot while being used – at restaurants or stores. Surprisingly, that thought doesn’t bother me when I’m recharging my Opus Card at home. Mind you, if we have this service done, it’s contactless, while at home, we need to insert the card into its reader and make use of its contacts.

I don’t really understand, why there was a business review somewhere, which explained the obviousness of how that concept could never have caught on. BTW, the “STM” is not a for-profit organization. I’m assuming that that article was written, by a financial expert who never tried to use the product himself.

The only external reference to this gadget I can find in the short term is this one:

http://www.cbc.ca/news/canada/montreal/stm-opus-recharger-quickly-becomes-target-of-social-media-mockery-1.3145399

So it seems then, that I’m not in step with the social media?

Dirk

 

Print Friendly, PDF & Email

I’ve Upgraded my Permalinks.

There was a subject in Web-hosting, which I was not even aware of until recently. Often, when a site offers URLs to the browser, those URLs contain a question-mark, followed by variables and values, such as Posting Numbers. Those question-marks explicitly invoke a CGI script on the server, which in this case is written in PHP.

Well as long as that’s happening, the URLs are not fully ‘permalinks’. Full permalinks are URLs which seem to extend beyond the real file system with slashes, and which the Web site rewrites in-place, when the browser requests them, to translate them into CGI-calls. This requires a server module to be loaded, which in the case of Apache is named ‘mod_rewrite.c’ , and of course it requires that the rules for doing so be defined, before the CGI script is even invoked.

Until very recently it was not really necessary for the links on my blog to be of that type. But what I’ve just done in the past few days, was make the site multilingual. And since this relies on machine translations, this can look very ugly to search engines. So with my new rewrite rules, the German translation of my site is virtually at

dirkmittler.homeip.net/blog/de

And the French version is at

dirkmittler.homeip.net/blog/fr

That way the search engines can keep them all nice and tidy, even though those are the derived ones.

And naturally, from about 14h30 through 15h00 today, clicking on the actual, new permalinks also caused some 404 Errors, until I got all that sorted out, which it should be by now. If people are having later problems with the new permalinks, please leave me a Comment about it…

Dirk

 

Print Friendly, PDF & Email