[nSLUG] More `systemd` ... `homed`?

Joel Maxwell jaymax at runbox.com
Thu Apr 30 23:44:04 ADT 2020

Hi all, hope you are managing well with shelter-in-place.

I encountered an article today, and I hope to refrain from strong
reactions while I add a few thoughts below.

I'll start by agreeing that `systemd` has benefit - maybe not well seen
from free software enthusiasts, however since the big drive for Linux
(and the userspace that follows) comes from the enterprise, `systemd`
has seen a lot of acceptance for being a "one stop shop" for server
configuration, monitoring, and problem solving.

Journalist Bryan Lunduke has joked about `systemd` for violating the
UNIX philosophy "do one thing and do it well" as it becomes much more
than an initialization daemon. Although, I would counter that argument
with the existence of `Emacs` (the editor that does everything but be
an editor). ;^)

Anyway, I am rather divided with this new component, `homed`. Seems
like there is great potential for fine-tuned permissions for a large
mount-point (ala MS Active Directory) - nested group memberships, for
example, in this:

> That record will contain all user information such as username, group
membership, and password hashes.

It's not really useful outside of large organizations however. Even in
the mid-scale, if you want UID's to be consistent across multiple
systems and not use a particular product, it seems a bit trivial to
devote one system for all new users and have scripts to reserve that
username to the same UID across the rest. For individuals, there are no
concerns even present since most of us would just be using UID 1000
across several computers anyway.

> So, for the simple act of logging in, three mechanisms are required
(systemd, /etc/shadow, /etc/passwd). This is inefficient, and
Poettering has decided to make a drastic change.

If two files and a daemon is inefficient, the proposed replacement by
using a JSON file, a greater selection of tools to manage that JSON
file, and a daemon (or two?) for the bulk of end-users likens to a Rube
Goldberg machine.

I feel there is some consideration lacking in this (aside from how key-
based remote access will be broken with the current re-implementation), 
and while I don't want to see a huge split in system initialization for
the enterprise from closer-to-bare installs (because the latter will
likely be neglected), the wheel seems to be re-invented significantly
enough where you "try to buy an FM radio but the only options are all-
in-one entertainment centres with the first year of a Spotify
subscription bundled in for no added cost".

I can only imagine the most agreeable middle ground is to split
`systemd` into their components - since right now it appears while it
is made up of several packages, those packages are heavily inter-
dependent. Having the ability to use some `systemd` components (init,
journald) but not others (logind, homed) - be it through a clean
replacement or shim+legacy - it should provide more choice in the
matter than the current all (`systemd` ecosystem) or nothing
(`SysV`+legacy) approach. 

Joel Maxwell

More information about the nSLUG mailing list