Update to ‘polkit’ and ‘libpolkit’ today.

Modern Linux computers, that have a considerable GUI, also have a feature called ‘polkit’. The purpose of this feature is not hard to understand. There exist certain operations which require ‘root’ privileges on a Linux computer, but actual users run Graphical User Interfaces, in ‘user mode’, i.e, without elevated privileges. Usually, Linux users want to be able to do such things as to install and update packages, which requires ‘root’ privileges, but want to be able to do so using the GUI. And so the way the feature ‘polkit’ is organized, there exists a daemon running as user ‘root’, which can among other things update packages, and there exists another daemon running as the specific user, which makes requests to the ‘root’ polkit daemon, to update packages. The root daemon carries out the requested action.

This arrangement may seem to make more sense for Ubuntu, where there is no such thing in a pronounced way, as ‘root’, as there is under Debian. But even some Debian setups have partial Ubuntu installs running, and many Debian users also like the ease, of being able to install a package, just by clicking on it, and then, by convincing the ‘root’ polkit daemon, that the user in question is privileged enough to do so.

Well today, my two Debian / Jessie systems, which I name ‘Phoenix’ and ‘Klystron’, have received routine updates to the polkit packages themselves. But the rather unbalanced, immediate result of this is, that on both these computers, the user-space daemon is still running the old binary, from before the update, while a new ‘root’ daemon has been launched, as part of the update. The two versions of ‘polkit’ running on both these computers, may or may not continue to be compatible with each other.

If they should turn out to be incompatible, then in the very near future I’ll need to reboot both computers as well, which could therefore also lead to brief downtime for this blog.

I’m keeping my fingers crossed, that the new service may be running in a way that remained compatible, with the old client.



MySQL Server Update Today, No Downtime

I use the home-computer I name ‘Phoenix’ as my Web-server. This means that I’m always looking for ways to complete routine system updates, without wanting my server to go offline, as my server going offline would also mean, that for several minutes, my site is not accessible to the public. My server would go offline for a few minutes, if I simply needed to reboot it.

Today came another time, when an update to my MySQL (Database-) Server became due. I have two instances of MySQL running:

  1. As a system process, which serves my Web-site and blog,
  2. As a user-process, which serves the desktop-PIM-daemon also known as “Akonadi”.

Simply having installed the MySQL update, will assure that the system-process is also restarted. But it will not assure, that the user-process is also restarted.

In such cases, what I can often do, is, after the update is finished, Log Out my user-session, and Log it back In. Doing so does not fully reboot the computer, but just restarts the user-space processes, which make up my session, including Akonadi, and including that MySQL user-process.

Today, after the update itself, I performed such a log-out-followed by the log-in. What this means is that my Web-site should have remained accessible the whole time. Yay!

This was the last time, I had accomplished the same thing.



Routine WordPress Update Today.

One of the facts which I’ve written about often, is that I host my site, and therefore my blog, on my private computer at home, named ‘Phoenix’.

One advantage this gives me, is the ability to program my Web-server in any way I please. When people subscribe to Web-hosting services, unless they are subscribing to a Virtual Private Server, they receive whatever set of server-side resources their hosting service is willing to offer them. This way, I get to install those myself.

The WordPress blogging engine of this blog, is similar to ‘WordPress.org‘, but is actually a version, the core files of which are managed by the Debian Package Maintainers. This WordPress installation just received an update this morning, to version ‘4.1+dfsg-1+deb8u16′. One detail which is tricky in my case, about receiving updates to the core-files via the package-manager, is that I nevertheless subscribe to plug-ins, from WordPress.org. Therefore, If I did not manage the application of the package-update correctly, I could end up with a mess on my hard drive, since what most Debian package maintainers expect, is for their users to receive all updates to their software, from them.

I’m happy to say that this update seems to have taken place smoothly, and in a way that respects the arrangement of files which I have between core files, maintained by Debian, and plug-in files, maintained by me.

All systems are go, and there was no appreciable downtime.