wande...@fastmail.fm:
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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543f091a.7050...@ntlworld.com
