[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: piece of mind (Re: Moderated posts?)

I have a similar lack of  awareness and/or understanding about all of
> the *kit packages / projects / tools / what-have-you, actually; I'm
> not positive I even know how many there are, much less all of their
> names.

This should help:

Put yourself in the position of someone writing a "desktop" system for Linux and the BSDs. You've reached the part where you're writing a "control panel" gadget for allowing system administrators (and appropriately privileged users) to manage things like the system time, the hostname, the default locale, and so forth; and another "computer management" gadget for letting the desktop user see who is logged on where and suchlike. It's a right old mess. You have to determine not only what kernel you are running on but what distribution you are running on, and access different things in different places. You could find yourself variously having to make your programs read and parse /etc/locale.conf, /etc/default/locale, /etc/sysconfig/i18n, /etc/sysconfig/language, or /etc/sysconf/i18n, for just one example. Then there are things like fundamental differences in the utmpx binary logs (The BSDs have revamped theirs and got rid of some stuff.), the system account database (It's an actual database on most BSDs.), the naming systems for virtual console devices, subtle differences in configuration file syntax (to some, a configuration file may be a shell script that sets shell variables, to others, it's a list of key=value pairs), ...

Enter the "kits", twice since renamed.

Skipping a lot of history, such as where ConsoleKit begat systemd-logind became logind for one, what we have now is a suite of remote procedure calls that your gadgets can call. There's a "hostname" API, a "timedate" API, a "locale" API, and a "login" API. They're a whole bunch of RPC calls that are made using an inter-process communication system known as the "desktop bus", D-Bus. (D-Bus, in its turn, is built on top of sockets. It has all of the usual RPC "stuff" that has been done several times before, such as marshalling and unmarshalling, mechanisms for rendezvous between clients and servers, and API definitions. It incorporates a security system to allow servers to restrict access to certain RPC functions to only suitably privileged clients.)

* http://freedesktop.org/wiki/Software/systemd/hostnamed/
* http://freedesktop.org/wiki/Software/systemd/timedated/
* http://freedesktop.org/wiki/Software/systemd/localed/
* http://freedesktop.org/wiki/Software/systemd/logind/

These RPCs are supplied by server daemons, that communicate with client programs (e.g. the aforementioned gadgets) over D-Bus. The operating system specific stuff, such as exactly what configuration file contains the static hostname on the system, is intended to be contained within these server daemons. All that a client knows is that it makes the "set the static hostname" RPC call, and some server does the necessary work whatever that is. The Debian systemd package comes with its own implementation of these server daemons. Contrary to the recommendation of the GNOME people almost three years ago, but in line with what the systemd people prefer, on Debian they aren't packaged separately and are indivisible from the remainder of the package.

* https://mail.gnome.org/archives/distributor-list/2012-January/msg00003.html

This is what three years' worth of hoo-hah has, at its root, all been about: a packaging decision. I'm not going to summarize or re-hash the hoo-hah here. Suffice it to say that there are both engineering rationales and socio-political rationales for the decision, and the major problem is logind, the systemd server daemon that provides the "login" API. Even though the other three somewhat are (modulo the fact that they all pick the particular choices of configuration file locations that match what other programs in the systemd package, such as systemd-machine-id-setup, use), logind is not at all severable from the rest of the systemd package, because the operating-system specific underpinnings of it (These daemons are intended to be abstracting a whole bunch of operating-system-specific non-portable stuff, remember.) target a Linux system that is running the systemd daemon and its ancillary daemons and utilities. Naturally enough.

The systemd versions of these daemons are not the only ones in existence. A chap with the unlikely name of Ian Kremlin, for one, is in the process of writing his own implementations of these four daemons, speaking the same RPC APIs over D-Bus but having the operating-system specific underpinnings that are suitable for the BSDs. This a good thing from the point of view of keeping the protocol specifications honest (as a heterogeneous set of implementations often does), and it is an example of what the GNOME people and the systemd people expected: a separate suite of operating-system-specific daemon programs for each operating system flavour, with hidden-from-clients inner workings that use whatever is actually appropriate for that operating system.

* http://undeadly.org/cgi?action=article&sid=20140915064856&mode=expanded&count=12
* https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary

(You may remember that I said that a good question to ask was whether systembsd's last modification date really was March 1973, a while back. Now you know why. He was of course no doubt testing his timedated. It gave me a small chuckle.)

However, again the stumbling block is logind. He hasn't got very far with it yet. (It's by the largest of the four APIs.) Even if he does, the whole point of these programs is that they provide a generic layer on top of the BSD-specific; and the BSDs don't work the same as Linux.

The final thing to cover is what the "login" API does. Aside from being the largest of the APIs, it's also the least obvious from its name. To understand it, one has to understand that the systemd/Freedesktop people have constructed a whole abstraction based upon their notion of "multi-seat Linux" (a concept that used to be called "multi-head", and before that, in the days of actual terminals connected to computers, "multi-user"). It has notions of "seats", "sessions", and "users"; which I'm not going to detail here.

* http://freedesktop.org/wiki/Software/systemd/multiseat/

It didn't help ConsoleKit that, in addition to being a fashion victim with its name, it followed long standing Open Source Software tradition.

* http://freedesktop.org/software/ConsoleKit/doc/ConsoleKit.html#id312255

The "multi-seat"'s raison d'être (glossing over some detail) is that the existing abstractions don't extend well to allowing multiple users to log in using the same collection of physical hardware and share the hardware amongst themselves as the currently "active" user changes; as well as facilitating the prevention of users from being able to access hardware, that isn't assigned to their login session, simply because they happen to have logged on locally on a "console". And one of the ironies of the people who wail on about how the systemd people are copying Windows NT is that the route that they've gone down with this is fundamentally different in one major respect to how Windows NT deals with exactly the same problem. (Reducing complexity and a lot of background to two sentences: Windows NT uses nonce SIDs, modifies process tokens, and uses largely fixed object ACLs. The "multi-seat Linux" system uses fixed process credentials and varies the device permissions/ACLs.)

The "login" API, previously provided by programs called systemd-logind and ConsoleKit and now provided (in the systemd package at least) by a program called simply logind, allows one to query and manipulate all of this "seat", "session", and "user" stuff, again with a view to writing client applications such as the "computer management" gadget tools in a desktop. Which leads to a final part of the hoo-hah fuel: In the systemd package there are tools named "hostnamectl", "timedatectl", "localectl", and "loginctl". Supposedly, these are such client applications, that speak to the RPC API. By their very natures, therefore, they should be easily severable from the systemd package; a "guaranteed stable interface" sits between each of them and the operating-system-specific daemons that do the actual grunt work. But they are not separately packaged in Debian.

* http://freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/
* http://freedesktop.org/software/systemd/man/hostnamectl.html
* http://freedesktop.org/software/systemd/man/timedatectl.html
* http://freedesktop.org/software/systemd/man/localectl.html
* http://freedesktop.org/software/systemd/man/loginctl.html

Reply to: