|
|
Subscribe / Log in / New account

systemd 245 released

Systemd 245 is out. As usual, the list of new features is long; perhaps the one that has gained the most attention is systemd-homed:

A small new service systemd-homed.service has been added, that may be used to securely manage home directories with built-in encryption. The complete user record data is unified with the home directory, thus making home directories naturally migratable.

There is also a new database for holding user and group data and a systemd-repart tool for the management of partitions on storage-devices at boot time.


From:  systemd tag bot <donotreply-systemd-tag-AT-refi64.com>
To:  systemd-devel-AT-lists.freedesktop.org
Subject:  systemd 245 released
Date:  Fri, 06 Mar 2020 12:37:08 +0000
Message-ID:  <20200306123708.1.E4C205A2BFD878E7@refi64.com>
Archive-link:  Article

🎆 A new, official systemd release has just 🎉 been 🎊 tagged đŸŸ. Please download the tarball here:

        https://github.com/systemd/systemd/archive/v245.tar.gz

Changes since the previous release:

        * A new tool "systemd-repart" has been added, that operates as an
          idempotent declarative repartitioner for GPT partition tables.
          Specifically, a set of partitions that must or may exist can be
          configured via drop-in files, and during every boot the partition
          table on disk is compared with these files, creating missing
          partitions or growing existing ones based on configurable relative
          and absolute size constraints. The tool is strictly incremental,
          i.e. does not delete, shrink or move partitions, but only adds and
          grows them. The primary use-case is OS images that ship in minimized
          form, that on first boot are grown to the size of the underlying
          block device or augmented with additional partitions. For example,
          the root partition could be extended to cover the whole disk, or a
          swap or /home partitions could be added on first boot. It can also be
          used for systems that use an A/B update scheme but ship images with
          just the A partition, with B added on first boot. The tool is
          primarily intended to be run in the initrd, shortly before
          transitioning into the host OS, but can also be run after the
          transition took place. It automatically discovers the disk backing
          the root file system, and should hence not require any additional
          configuration besides the partition definition drop-ins. If no
          configuration drop-ins are present, no action is taken.

        * A new component "userdb" has been added, along with a small daemon
          "systemd-userdb.service" and a client tool "userdbctl". The framework
          allows defining rich user and group records in a JSON format,
          extending on the classic "struct passwd" and "struct group"
          structures. Various components in systemd have been updated to
          process records in this format, including systemd-logind and
          pam-systemd. The user records are intended to be extensible, and
          allow setting various resource management, security and runtime
          parameters that shall be applied to processes and sessions of the
          user as they log in. This facility is intended to allow associating
          such metadata directly with user/group records so that they can be
          produced, extended and consumed in unified form. We hope that
          eventually frameworks such as sssd will generate records this way, so
          that for the first time resource management and various other
          per-user settings can be configured in LDAP directories and then
          provided to systemd (specifically to systemd-logind and pam-system)
          to apply on login. For further details see:

          https://systemd.io/USER_RECORD
          https://systemd.io/GROUP_RECORD
          https://systemd.io/USER_GROUP_API

        * A small new service systemd-homed.service has been added, that may be
          used to securely manage home directories with built-in encryption.
          The complete user record data is unified with the home directory,
          thus making home directories naturally migratable. Its primary
          back-end is based on LUKS volumes, but fscrypt, plain directories,
          and other storage schemes are also supported. This solves a couple of
          problems we saw with traditional ways to manage home directories, in
          particular when it comes to encryption. For further discussion of
          this, see the video of Lennart's talk at AllSystemsGo! 2019:

          https://media.ccc.de/v/ASG2019-164-reinventing-home-direc...

          For further details about the format and expectations on home
          directories this new daemon makes, see:

          https://systemd.io/HOME_DIRECTORY

        * systemd-journald is now multi-instantiable. In addition to the main
          instance systemd-journald.service there's now a template unit
          systemd-journald@.service, with each instance defining a new named
          log 'namespace' (whose name is specified via the instance part of the
          unit name). A new unit file setting LogNamespace= has been added,
          taking such a namespace name, that assigns services to the specified
          log namespaces. As each log namespace is serviced by its own
          independent journal daemon, this functionality may be used to improve
          performance and increase isolation of applications, at the price of
          losing global message ordering. Each instance of journald has a
          separate set of configuration files, with possibly different disk
          usage limitations and other settings.

          journalctl now takes a new option --namespace= to show logs from a
          specific log namespace. The sd-journal.h API gained
          sd_journal_open_namespace() for opening the log stream of a specific
          log namespace. systemd-journald also gained the ability to exit on
          idle, which is useful in the context of log namespaces, as this means
          log daemons for log namespaces can be activated automatically on
          demand and will stop automatically when no longer used, minimizing
          resource usage.

        * When systemd-tmpfiles copies a file tree using the 'C' line type it
          will now label every copied file according to the SELinux database.

        * When systemd/PID 1 detects it is used in the initrd it will now boot
          into initrd.target rather than default.target by default. This should
          make it simpler to build initrds with systemd as for many cases the
          only difference between a host OS image and an initrd image now is
          the presence of the /etc/initrd-release file.

        * A new kernel command line option systemd.cpu_affinity= is now
          understood. It's equivalent to the CPUAffinity= option in
          /etc/systemd/system.conf and allows setting the CPU mask for PID 1
          itself and the default for all other processes.

        * When systemd/PID 1 is reloaded (with systemctl daemon-reload or
          equivalent), the SELinux database is now reloaded, ensuring that
          sockets and other file system objects are generated taking the new
          database into account.

        * systemd/PID 1 accepts a new "systemd.show-status=error" setting, and
          "quiet" has been changed to imply that instead of
          "systemd.show-status=auto". In this mode, only messages about errors
          and significant delays in boot are shown on the console.

        * The sd-event.h API gained native support for the new Linux "pidfd"
          concept. This permits watching processes using file descriptors
          instead of PID numbers, which fixes a number of races and makes
          process supervision more robust and efficient. All of systemd's
          components will now use pidfds if the kernel supports it for process
          watching, with the exception of PID 1 itself, unfortunately. We hope
          to move PID 1 to exclusively using pidfds too eventually, but this
          requires some more kernel work first. (Background: PID 1 watches
          processes using waitid() with the P_ALL flag, and that does not play
          together nicely with pidfds yet.)

        * Closely related to this, the sd-event.h API gained two new calls
          sd_event_source_send_child_signal() (for sending a signal to a
          watched process) and sd_event_source_get_child_process_own() (for
          marking a process so that it is killed automatically whenever the
          event source watching it is freed).

        * systemd-networkd gained support for configuring Token Bucket Filter
          (TBF) parameters in its qdisc configuration support. Similarly,
          support for Stochastic Fairness Queuing (SFQ), Controlled-Delay
          Active Queue Management (CoDel), and Fair Queue (FQ) has been added.

        * systemd-networkd gained support for Intermediate Functional Block
          (IFB) network devices.

        * systemd-networkd gained support for configuring multi-path IP routes,
          using the new MultiPathRoute= setting in the [Route] section.

        * systemd-networkd's DHCPv4 client has been updated to support a new
          SendDecline= option. If enabled, duplicate address detection is done
          after a DHCP offer is received from the server. If a conflict is
          detected, the address is declined. The DHCPv4 client also gained
          support for a new RouteMTUBytes= setting that allows to configure the
          MTU size to be used for routes generated from DHCPv4 leases.

        * The PrefixRoute= setting in systemd-networkd's [Address] section of
          .network files has been deprecated, and replaced by AddPrefixRoute=,
          with its sense inverted.

        * The Gateway= setting of [Route] sections of .network files gained
          support for a special new value "_dhcp". If set, the configured
          static route uses the gateway host configured via DHCP.

        * New User= and SuppressPrefixLength= settings have been implemented
          for the [RoutingPolicyRule] section of .network files to configure
          source routing based on UID ranges and prefix length, respectively.

        * sd-bus gained a new API call sd_bus_message_sensitive() that marks a
          D-Bus message object as "sensitive". Those objects are erased from
          memory when they are freed. This concept is intended to be used for
          messages that contain security sensitive data. A new flag
          SD_BUS_VTABLE_SENSITIVE has been introduced as well to mark methods
          in sd-bus vtables, causing any incoming and outgoing messages of
          those methods to be implicitly marked as "sensitive".

        * sd-bus gained a new API call sd_bus_message_dump() for dumping the
          contents of a message (or parts thereof) to standard output for
          debugging purposes.

        * systemd-sysusers gained support for creating users with the primary
          group named differently than the user.

        * systemd-resolved's DNS-over-TLS support gained SNI validation.

        * systemd-growfs (i.e. the x-systemd.growfs mount option in /etc/fstab)
          gained support for growing XFS partitions. Previously it supported
          only ext4 and btrfs partitions.

        * The support for /etc/crypttab gained a new x-initrd.attach option. If
          set, the specified encrypted volume is unlocked already in the
          initrd. This concept corresponds to the x-initrd.mount option in
          /etc/fstab.

        * systemd-cryptsetup gained native support for unlocking encrypted
          volumes utilizing PKCS#11 smartcards, i.e. for example to bind
          encryption of volumes to YubiKeys. This is exposed in the new
          pkcs11-uri= option in /etc/crypttab.

        * The /etc/fstab support in systemd now supports two new mount options
          x-systemd.{required,wanted}-by=, for explicitly configuring the units
          that the specified mount shall be pulled in by, in place of
          the usual local-fs.target/remote-fs.target.

        * The https://systemd.io/ web site has been relaunched, directly
          populated with most of the documentation included in the systemd
          repository. systemd also acquired a new logo, thanks to Tobias
          Bernard.

        * systemd-udevd gained support for managing "alternative" network
          interface names, as supported by new Linux kernels. For the first
          time this permits assigning multiple (and longer!) names to a network
          interface. systemd-udevd will now by default assign the names
          generated via all supported naming schemes to each interface. This
          may be further tweaked with .link files and the AlternativeName= and
          AlternativeNamesPolicy= settings. Other components of systemd have
          been updated to support the new alternative names wherever
          appropriate. For example, systemd-nspawn will now generate
          alternative interface names for the host-facing side of container
          veth links based on the full container name without truncation.

        * systemd-nspawn interface naming logic has been updated in another way
          too: if the main interface name (i.e. as opposed to new-style
          "alternative" names) based on the container name is truncated, a
          simple hashing scheme is used to give different interface names to
          multiple containers whose names all begin with the same prefix. Since
          this changes the primary interface names pointing to containers if
          truncation happens, the old scheme may still be requested by
          selecting an older naming scheme, via the net.naming-scheme= kernel
          command line option.

        * PrivateUsers= in service files now works in services run by the
          systemd --user per-user instance of the service manager.

        * A new per-service sandboxing option ProtectClock= has been added that
          locks down write access to the system clock. It takes away device
          node access to /dev/rtc as well as the system calls that set the
          system clock and the CAP_SYS_TIME and CAP_WAKE_ALARM capabilities.
          Note that this option does not affect access to auxiliary services
          that allow changing the clock, for example access to
          systemd-timedated.

        * The systemd-id128 tool gained a new "show" verb for listing or
          resolving a number of well-known UUIDs/128bit IDs, currently mostly
          GPT partition table types.

        * The Discoverable Partitions Specification has been updated to support
          /var and /var/tmp partition discovery. Support for this has been
          added to systemd-gpt-auto-generator. For details see:

          https://systemd.io/DISCOVERABLE_PARTITIONS

        * "systemctl list-unit-files" has been updated to show a new column
          with the suggested enablement state based on the vendor preset files
          for the respective units.

        * "systemctl" gained a new option "--with-dependencies". If specified
          commands such as "systemctl status" or "systemctl cat" will now show
          all specified units along with all units they depend on.

        * networkctl gained support for showing per-interface logs in its
          "status" output.

        * systemd-networkd-wait-online gained support for specifying the maximum
          operational state to wait for, and to wait for interfaces to
          disappear.

        * The [Match] section of .link and .network files now supports a new
          option PermanentMACAddress= which may be used to check against the
          permanent MAC address of a network device even if a randomized MAC
          address is used.

        * The [TrafficControlQueueingDiscipline] section in .network files has
          been renamed to [NetworkEmulator] with the "NetworkEmulator" prefix
          dropped from the individual setting names.

        * Any .link and .network files that have an empty [Match] section (this
          also includes empty and commented-out files) will now be
          rejected. systemd-udev and systemd-networkd started warning about
          such files in version 243.

        * systemd-logind will now validate access to the operation of changing
          the virtual terminal via a PolicyKit action. By default, only users
          with at least one session on a local VT are granted permission.

        * When systemd sets up PAM sessions that invoked service processes
          shall run in, the pam_setcred() API is now invoked, thus permitting
          PAM modules to set additional credentials for the processes.

        * portablectl attach/detach verbs now accept --now and --enable options
          to combine attachment with enablement and invocation, or detachment
          with stopping and disablement.

        Contributions from: AJ Bagwell, Alin Popa, Andreas Rammhold, Anita
        Zhang, Ansgar Burchardt, Antonio Russo, Arian van Putten, Ashley Davis,
        Balint Reczey, Bart Willems, Bastien Nocera, Benjamin Dahlhoff, Charles
        (Chas) Williams, cheese1, Chris Down, Chris Murphy, Christian Ehrhardt,
        Christian Göttsche, cvoinf, Daan De Meyer, Daniele Medri, Daniel Rusek,
        Daniel Shahaf, Dann Frazier, Dan Streetman, Dariusz Gadomski, David
        Michael, Dimitri John Ledkov, Emmanuel Bourg, Evgeny Vereshchagin,
        ezst036, Felipe Sateler, Filipe Brandenburger, Florian Klink, Franck
        Bui, Fran Dieguez, Frantisek Sumsal, Greg "GothAck" Miell, Guilhem
        Lettron, Guillaume Douézan-Grard, Hans de Goede, HATAYAMA Daisuke, Iain
        Lane, James Buren, Jan Alexander Steffens (heftig), Jérémy Rosen, Jin
        Park, Jun'ichi Nomura, Kai Krakow, Kevin Kuehler, Kevin P. Fleming,
        Lennart Poettering, Leonid Bloch, Leonid Evdokimov, lothrond, Luca
        Boccassi, Lukas K, Lynn Kirby, Mario Limonciello, Mark Deneen, Matthew
        Leeds, Michael Biebl, Michal KoutnĂœ, Michal Sekletár, Mike Auty, Mike
        Gilbert, mtron, nabijaczleweli, NaĂŻm Favier, Nate Jones, Norbert Lange,
        Oliver Giles, Paul Davey, Paul Menzel, Peter Hutterer, Piotr Drąg, Rafa
        Couto, Raphael, rhn, Robert Scheck, Rocka, Romain Naour, Ryan Attard,
        Sascha Dewald, Shengjing Zhu, Slava Kardakov, Spencer Michaels, Sylvain
        Plantefeve, Stanislav Angelovič, Susant Sahani, Thomas Haller, Thomas
        Schmitt, Timo SchlĂŒĂŸler, Timo Wilken, Tobias Bernard, Tobias Klauser,
        Tobias Stoeckmann, Topi Miettinen, tsia, WataruMatsuoka, Wieland
        Hoffmann, Wilhelm Schuster, Will Fleming, xduugu, Yong Cong Sin, Yuri
        Chornoivan, Yu Watanabe, Zach Smith, Zbigniew Jędrzejewski-Szmek, Zeyu
        DONG

        – Warsaw, 2020-03-06
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


to post comments

systemd 245 released

Posted Mar 6, 2020 23:16 UTC (Fri) by warrax (subscriber, #103205) [Link] (44 responses)

I'm surprised at the lack of vitriol or even comments... but maybe that's just because it's the weekend?

Anyway, I welcome the world of Linux into (marginally) better user management... as it has been in the rest of the civilized OS'es since about 2000? I suppose the choice of mounting in /home/$USER is just as much a product of that legacy... why the hell are programs still using absolute paths for almost all configuration? It's insane to not be able to move a home directory or change username without *everything* breaking.

systemd 245 released

Posted Mar 7, 2020 7:04 UTC (Sat) by amarao (subscriber, #87073) [Link] (16 responses)

I'm not really understand you. Home directory specified in /etc/passwd. It can be anywhere you like. /opt/foobar, /var/lib/myhome, etc.

systemd 245 released

Posted Mar 7, 2020 7:20 UTC (Sat) by sytoka (guest, #38525) [Link] (3 responses)

And crypt home per user isn't the job of a pam module ? pam is here for this kind of job ? Why put this in systemd ?

systemd 245 released

Posted Mar 7, 2020 12:35 UTC (Sat) by pbonzini (subscriber, #60935) [Link]

The daemon provides (via D-Bus) the interfaces to create, remove, change or inspect home directories. It is integrated with both PAM and NSS.

systemd 245 released

Posted Mar 7, 2020 15:58 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (1 responses)

systemd-homed manages the home dirs, and is hooked into the login process via a PAM module pam_systemd_home. This separation of work is done to make things robust since abnormal session termination can be handled cleanly: we don't have to rely on the session process to eventually call the PAM session close handler to unmount the homedir, but ca just watch the session from the outside catching abnormal session termination asynchroniusly.

Its also a lot nicer to separate the mounting and stuff into a process with minimal privs, since doing device mgmt and all that stuff from inside PAM hooks (and thus arbitrary session programs such as sshd) is security-wise ugly.

Long story short: we are a PAM module primarily too, we just separate out its backend into a small daemon for robustness and security reasons.

systemd 245 released

Posted Mar 9, 2020 13:09 UTC (Mon) by zwol (guest, #126152) [Link]

> we don't have to rely on the session process to eventually call the PAM session close handler to unmount the homedir, but ca just watch the session from the outside catching abnormal session termination asynchroniusly.

I am quite looking forward to throwing away the shell script I had to write last week to deal with pam_mount and pam_systemd getting invoked in the wrong order on logout.

systemd 245 released

Posted Mar 7, 2020 12:33 UTC (Sat) by pizza (subscriber, #46) [Link] (11 responses)

Many (most?) applications still do not rely on $HOME, instead hardcoding absolute paths in config files and stuff like that.

Even stuff that does generally utilizes $HOME typically has some corner cases that misbehave. (I'm looking at you, everything-by-Xilinx...)

systemd 245 released

Posted Mar 7, 2020 15:05 UTC (Sat) by dezgeg (subscriber, #92243) [Link] (10 responses)

Can you give some examples? I have used plenty of both desktop and command line apps on university desktop machines and on shell servers, with $HOME very often not in /home but under some NFS mount.

And furthermore this does not seem a likely issue to me, because getting the real home directory is actually _easier_ than assuming it is /home/$USER...

systemd 245 released

Posted Mar 10, 2020 9:34 UTC (Tue) by abo (subscriber, #77288) [Link] (9 responses)

I've never seen anything hardcode "/home/$USER" rather than "$HOME", but I've seen plenty of cases where this path gets stored somewhere which makes moving the home directory to a different location difficult. I suspect that was the actual complaint.

systemd 245 released

Posted Mar 15, 2020 14:33 UTC (Sun) by cortana (subscriber, #24596) [Link]

May I introduce you to the revolding Aruba VIA VPN client...

systemd 245 released

Posted Mar 15, 2020 15:18 UTC (Sun) by pizza (subscriber, #46) [Link] (3 responses)

yep, to this day if you export a design in Xilinx Vivado, you'll get a 100K-line tcl file that has $projhome, quasi-relative $HOME/path/to/project, and absolute /path/to/home/user/whatever/path/to/project in it.

Makes it a royal PITA to properly version control a project that multiple folks (or even multiple simultaneous work areas) need to interact with.

systemd 245 released

Posted Mar 16, 2020 11:35 UTC (Mon) by cortana (subscriber, #24596) [Link] (2 responses)

Could be a job for a clean & smudge filter that does a find/replace for certain known paths with tokens on 'git-add' and undoes it with 'git-checkout'.

I remain astounded that so much expensive "Enterprise" software is of such poor quality!

systemd 245 released

Posted Mar 16, 2020 12:16 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

In my experience, the more expensive the software, the worse it is to use and administer.

Compared to the likes of Cadence tools, Xilinx is problem-free nirvana..

systemd 245 released

Posted Apr 6, 2020 18:21 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I wonder why that is...Maybe the more expensive the software, the more likely it is niche, and the less usability and customer appeal are major design factors instead of base functionality, and the more likely the end user can afford technical support (self support or dedicated sysadmins) to deal with the gap. Low margin software that has to appeal to a wider more competitive base needs to be easier to use and maintain (in general) to beat the competition, high margin low competition software doesn't.

systemd 245 released

Posted Mar 19, 2020 12:46 UTC (Thu) by mgedmin (subscriber, #34497) [Link] (3 responses)

I've had the misfortune to discover recently that Canonical's snap packaging format (or, rather, the tools for using it) assume user home directories are always /home/$USER (with /root as the only allowed exception) and fail in mysterious ways when that happens not to be the case.

https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1867921

systemd 245 released

Posted Mar 19, 2020 19:56 UTC (Thu) by madscientist (subscriber, #16861) [Link] (2 responses)

The bug description and responses aren't clear. They seem to say that /home/foo which is a symlink to something else is not supported, which is not the same thing that you're claiming here. Maybe it really doesn't work to move your home directory but that's not exactly what the linked bug report says.

If you were to edit /etc/passwd and change your home directory to be the correct path /home-ssd/foo rather than the symlink, does it still fail?

systemd 245 released

Posted Mar 19, 2020 21:31 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

The original issue was due the "official" home directory being a symlink, but the responses suggest that only home directories of the form /home/$LOGNAME (or /root) are supported, with support for arbitrary other paths being a possible future enhancement. The recommended workaround was not the obvious change in /etc/passwd but rather bind-mounting the actual home directory to /home/$LOGNAME.

The description about the eventual fix including automatic bind-mounts of home directories at /var/home/$LOGNAME strongly suggests that the snapd maintainers would prefer to maintain a rigid pattern of some fixed prefix plus a username rather than granting confined applications direct access to arbitrary home directory paths read from /etc/passwd.

systemd 245 released

Posted Mar 20, 2020 11:13 UTC (Fri) by mgedmin (subscriber, #34497) [Link]

Yep! I've updated my home directory in /etc/passwd and snaps still fail to run (with a "cannot create user data directory: /home-ssd/mg/snap/ripgrep/8: Permission denied" error).

systemd 245 released

Posted Mar 7, 2020 10:09 UTC (Sat) by oldtomas (guest, #72579) [Link]

You're surprised? I'm glad.

In the meantime, things have cooled a bit down.

There are those who still consider systemd a bad idea -- without accusing those working on it of "betraying the UNIX ideals" or "being spies sent by Microsoft" or something.

Then there are those who consider systemd the best thing since sliced bread without accusing its opponents of being "just resistant to change" or "anti-vaxxers" or something.

This is, IMO, a Good Thing. Regardless of what side I (personally) stand on.

systemd 245 released

Posted Mar 7, 2020 15:54 UTC (Sat) by BirAdam (guest, #132170) [Link] (25 responses)

Don’t get me wrong, a lot of features of SystemD are great... I just kind of wonder why these are all under the same project banner. What in the world should link journaling and init? Or link home directories, file system expansion and networking? I just don’t see why systemd should keep expanding scope and function. Linux is not BSD. We don’t dev the whole OS as a single unit or even in one repo. I personally like that. When things break, or a project goes the wrong way, I have drop in replacements.

I suppose it could be that they all work together in some ways? I dunno. I don’t get it. I am not a systemd fan anyway, but I don’t hate it. I use it at work and it works well enough so whatever.

I like homed. Sounds convenient, but I don’t get why this is part of my init/journal/boot/network/etc. nor do I get why all those things are mixed up together.

systemd 245 released

Posted Mar 7, 2020 16:12 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (23 responses)

i'll bite. You ask about many things, i'll just focus on the first you issue you raise: the connection between logging and service mgmt. Its actually an obvious one i think: we need to connect stdout/stderr of services to a logging service. Thus logging setup becomes a very core part of service mgmt, the are closely intertwined early on. Now you could say: add an interface to to rsyslogd to hook up stdout/stderr of services with. However this is highly problematic, because of cyclic deps: pid1 itself wants to log to syslog and all services do too, but if syslog itself is a service then we first have to make the logger a bit special since it becomes an implied dep of everything else, but not itself; and pid1 becomes both manager of and client to the syslog daemon, and that's highly probelmatic, due to deadlocks (remember, logging is generally done synchronously, i.e. glibc syslog() blocks). Moreover this means logging becomes an early boot services, heck even an initrd service, and needfvzo be one of the first services running at all.

Thus: the relationship between a logger and a service manager are special and tight. Its a lot easier to develop them aligned to each other because of this, since we need to constantly keep all those potential deadlocks in mind caused by this special relationship.

(There are plenty of other reasons too btw: we wanted "systemctl status" to show log output, but we cannot do that with classic syslog really and the bsd syslog proto is not something that can be tought something like that sanely)

Now, you can say: who needs stdout/stderr logging, sysv didnt have it either, but thats just means you stop solvong the problem here since stdout/stderr logging is actually much more common than syslog() logging.

systemd 245 released

Posted Mar 7, 2020 19:39 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (22 responses)

Which common service does not support logging to syslog? In my experience with Docker it was often non-trivial to configure a service to log to stderr. For example, a service could support logging to a file besides syslog. Then to run it in a Docker container hacks like running a cat from a named pipe had to be used.

Also it is harder to log to stderr than to syslog the moment the service starts running child processes. I even suspect if not for the Docker not having syslog many services would still not bother with stderr logging.

systemd 245 released

Posted Mar 7, 2020 21:07 UTC (Sat) by vadim (subscriber, #35271) [Link] (4 responses)

Shell scripts, for instance. A number of applications written in Java.

I find it really nice that anything you want can be a service and get its output logged.

systemd 245 released

Posted Mar 8, 2020 15:25 UTC (Sun) by ibukanov (subscriber, #3942) [Link] (3 responses)

The logger utility takes care of logging for shells. In fact the moment a shell script starts running background jobs it is easier to use the logger than stderr to get nice separated logs with proper level annotations. Java is different beast with no native support for syslog unless one uses UDP. But then java foo.bar |& logger takes care of it as well.

And by insisting on stderr log one immediately misses levels unless one starts to use <> annotations which looks more like an afterthought.

systemd 245 released

Posted Mar 8, 2020 20:47 UTC (Sun) by rodgerd (guest, #58896) [Link]

Ahh yes, Java to syslog. A great way to lose all your debug information.

systemd 245 released

Posted Mar 10, 2020 11:32 UTC (Tue) by MarcB (subscriber, #101804) [Link] (1 responses)

There also things like runtime errors or exceptions in Perl and other run times that where virtually invisible with explicit logging. Logging STDERR catches them perfectly.

systemd 245 released

Posted Mar 11, 2020 8:20 UTC (Wed) by darwi (subscriber, #131202) [Link]

Libraries and language runtimes sometimes print warning/diagnosis messages to stderr. I know that they shouldn't, but catching all of those in the systemd journal made debugging a lot of system-wide problems much easier.

Very recent example: "journalctl --user" shows a number of fontconfig errors in my system due to a buggy font installation. They would've never been catched without the journal (or running the GUI application from the command-line by chance).

systemd 245 released

Posted Mar 7, 2020 21:17 UTC (Sat) by josh (subscriber, #17465) [Link] (15 responses)

Every service shouldn't have its own configuration and code for logging; that should be configurable in a central standardized way.

Every service shouldn't have its own code to daemonize; the service manager should handle that.

Every service shouldn't have its own code to handle respawning (or to configure whether it should respawn or stop); the service manager should handle that.

systemd 245 released

Posted Mar 7, 2020 21:54 UTC (Sat) by BirAdam (guest, #132170) [Link] (14 responses)

I would add: if it’s a systemd/Linux only service then you’d be correct. If, however, I am working on a daemonized proprietary piece of software that runs on AIX, BSD, and Linux... then this is totally wrong. I then want it to be able to be decoupled from things that break UNIX conventions. This is also why I kind of hate that RHEL doesn’t have an easy path away from systemd for mixed enterprise environments but ... oh well.

systemd 245 released

Posted Mar 8, 2020 7:24 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Put the legacy UNIX crap in a wrapper that runs your code. It can be a stand-alone executable or #define-based conditional code.

systemd 245 released

Posted Mar 8, 2020 10:16 UTC (Sun) by jrigg (guest, #30848) [Link] (5 responses)

> legacy UNIX crap

Is this kind of terminology really necessary?

systemd 245 released

Posted Mar 8, 2020 17:02 UTC (Sun) by Wol (subscriber, #4433) [Link] (4 responses)

I'm sorry, but I don't consider Unix "well designed". It was thrown together to make a system that could play games, and it won because it was (a) cheap (aka "free"), and (b) good enough.

Imho, having had experience of rather more than just Unix and DOS/Windows, the basic design of Unix is crap. Windows, thanks to the NT rewrite, has grown up a lot. Linux needs to ditch POSIX and become Unix-ng.

Systemd is actually a big step down that path. It has been *designed* to be consistent, coherent, and has a very clear focus. Okay, real life intervenes and few things actually achieve their design goals, but we need a fundamental change of attitude to drag Unix/linux kicking and screaming into the 21st century! Unfortunately, there are far too many dinosaurs who don't want anything to change.

Okay, I'm guilty of moaning at change a lot - the perils of getting older - but the changes I don't like are when changes are forced on me for no reason I can discern. If you're going to change things, try and hide them from me! But junking a pile of design-free junk for something that has actually had some proper thought put in to it - count me in!!!

Cheers,
Wol

systemd 245 released

Posted Mar 8, 2020 17:28 UTC (Sun) by tzafrir (subscriber, #11501) [Link]

There is no real POSIX service definition. A service init script needs to be written carefully and installed separately for all of those various operating systems.

A basic Systemd service is much simpler to write, install and debug than a System-V service script on Linux.

Unix won because it was free? It is to laugh.

Posted Mar 9, 2020 17:59 UTC (Mon) by brouhaha (subscriber, #1698) [Link] (2 responses)

and it won because it was (a) cheap (aka "free"), and (b) good enough.

I agree with "good enough", but not with "cheap".

Original Unix (from AT&T, not the post-1993-anything-that-meets-the-spec-can-be-called-Unix) was EXPENSIVE during the entire peirod that it was "winning". It was only relatively cheap for university licenses. Starting around 1977 (IIRC), AT&T sold commercial licenses for 6th Edition for $20,000, and increased the license fees substantially for 7th Edition, System III, then System V. The cost of a System V license was originally $43,000, and increased further with late releases.

The System V sublicense binary-only fee dropped to around $100 in high volumes, but that was only the fee that the licensee paid to AT&T or USL, and the actual price for the end customer license was usually much higher, or was bundled into system costs.

Unix won because it was free? It is to laugh.

Posted Mar 10, 2020 17:05 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

But an alternative would be your own proprietary OS... And THAT was be even more expensive.

Unix won because it was free? It is to laugh.

Posted Mar 10, 2020 18:20 UTC (Tue) by brouhaha (subscriber, #1698) [Link]

No, the alternative was generally the hardware vendor's proprietary OS, and it was usually LESS expensive. You typically bought the hardware, got the vendor's OS bundled, and then had to buy an expensive Unix license. You paid more to run Unix, at least as far as the actual software cost went. (This obviously wasn't the case for systems that only ran Unix and had no proprietary OS, but those came later.)

It's possible that the TCO of the system running Unix might have ended up being less, but that would be hard to determine. I'm just talking about the licensing cost.

Unix was neither free nor cheap until BSD 4.3 or later.

systemd 245 released

Posted Mar 8, 2020 9:38 UTC (Sun) by mezcalero (subscriber, #45103) [Link] (1 responses)

I personally subscribe strongly to the idea that there shouldnt be a race to the bottom but one to the top. I.e. if some system you care about lacks features you want to use and that make life more worthwile, then use them and look for a way to gracefully fall back on those simpler systems, but dont limit yourself to the worse system right away. That just means your stuff in the end is worse than it could be for everyone.

systemd 245 released

Posted Mar 9, 2020 16:51 UTC (Mon) by ms-tg (subscriber, #89231) [Link]

Hi Lennart, as a reader I just wanted to pop in and thank you for all your important work, and also thank you for sharing your thoughts here in this forum that I can easily read.

> I personally subscribe strongly to the idea that there shouldnt be a race to the bottom but one to the top. I.e. if some system you care about lacks features you want to use and that make life more worthwile, then use them and look for a way to gracefully fall back on those simpler systems, but dont limit yourself to the worse system right away. That just means your stuff in the end is worse than it could be for everyone.

I've observed that personally, in conversations folks suspicious or hostile to systemd whom I generally respect technically, an area of concern that is often raised is precisely: "is systemd designed and implemented to *gracefully fall back on those simpler systems*"?

In terms of clarity of message, I wonder how much might be achieved simply by announcing broadly and clearly -- I could imagine a "FALLBACKS_POLICY.md" in the codebase for example -- that systemd does in fact hold "graceful fallbacks on simpler systems" as a design goal, and here's a how that works in practice for recent features, and examples where it is traded off against for good reasons?

(this is just two cents here, feel free to ignore)

systemd 245 released

Posted Mar 8, 2020 20:46 UTC (Sun) by rodgerd (guest, #58896) [Link] (3 responses)

> things that break UNIX conventions.

Ah yes, the well-known UNIX conventions shared between AIX and BSD.

systemd 245 released

Posted Mar 9, 2020 11:53 UTC (Mon) by magfr (subscriber, #16052) [Link]

Yes, like AIX servicectl that clashes just as badly as systemd module files with the System V start script model, but in a different way.

systemd 245 released

Posted Mar 9, 2020 16:14 UTC (Mon) by SEJeff (guest, #51588) [Link] (1 responses)

I for one loved binaries or symlinks to binaries like /etc/ping. Who needs the File Hierarchy Standard when you can just put all of /usr/bin in /etc? Much easier IMO /s.

systemd 245 released

Posted Mar 14, 2020 21:16 UTC (Sat) by nix (subscriber, #2304) [Link]

That would be because /sbin is relatively new, and in Unixes of the vintage we're talking about, /etc *was* where all the system-admin stuff went, both binaries and config files.

systemd 245 released

Posted Mar 11, 2020 22:57 UTC (Wed) by da4089 (subscriber, #1195) [Link]

I think it's increasingly clear that Linux is no longer Unix.

Various Unixes managed to largely co-evolve from the early 80's to the mid-90's, but they slowly drifted apart. Even quite early, the BSD vs. SysV schism became an issue. Later on, Sun, in particular, added features that extended what people understood as "Unix", although many of these were adopted by other vendors, harking back to early times when code and ideas were more freely shared. But in its later years, Solaris began growing features that were not widely adopted, and perhaps to a lesser extent, other Unix variants did too. AIX, HP/UX, OSF, macOS ... as time moved on, their unique approaches, especially to the administrative tools and databases, gradually diverged.

In more recent times, Linux became very much the dominant Unix variant -- more so than Solaris ever was -- and the BSDs and commercial Unixes have either failed to "keep up" or deliberately chosen not to follow many of the changes in Linux. For those who view Linux as a Unix, this is quite jarring. For those who view Linux as an independent operating system, it's a sign of health.

systemd 245 released

Posted Mar 8, 2020 9:34 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

System services are any processes running with system privs. And that includes stuff like cronjobs, backup scripts and so on, i.e. all the stuff that isnt a carefully written C daemon (or other high-level, i.e. non-shell langauge). And even stuff that is written in a highlevel language sometimes doesnt do syslog because people are lazy and prefer printf or use a language with no syslog abstraction. I.e. all that stuff that typically isnt packaged up nicely by a distro as an RPM/DEB but all the other stuff the admins add and what they usually actually want to run.

systemd 245 released

Posted Mar 10, 2020 23:19 UTC (Tue) by jgg (subscriber, #55211) [Link]

I think decades of experience show us that the model of "open source some 1000's of lines niche module in its own tar.gz" doesn't work. Having large umbrella packages take ownership over the code, where a long term group of people can maintain it, in some integrated fashion works much better.

1) The large group deals with all the drudgery. Get it in the distros, watch over coverity, make releases, update for new compilers, new gblic, handle generic security audits, run a CI, run the repos, etc, etc.

2) A large group with a 'style' can direct the architecture and design of the small contributions efficiently. This never happens when people just open source some small thing

3) A large group is more likely attract contribution. If systemd was split into 100 githubs nobody would ever do a 'tree wide' quality/security improvement on every one. Contribution is easier if it is one target, with a understood contribution flow, with many people participating.

4) Small projects are usually abandoned by the author in a few years. ie I 've written pam modules that are in the distros 20 years ago. No idea who is maintaining them now, but they are still in the distros because they were rolled into libpam-modules.

5) A modern package, in a distro, is actually quite complicated. GNU hello world is pretty much a poster child for this syndrome. By the time you have auto*, gettext, NEWS README, etc, it is a already major undertaking. Umbrella packages provide all this, often done by people who actually know how. This lowers the bar to actually get something novel into end-users hands.

The fact systemd hoovered up all the endless tiny packages, all of which were largely abandoned, had bad/outdated design elements/coding practices and instead provided a comprehensive solution, in a single 'style' is great.

systemd 245 released

Posted Mar 7, 2020 5:49 UTC (Sat) by josh (subscriber, #17465) [Link] (1 responses)

Personally, I'm most excited about systemd-repart, for cases like "grow the root filesystem to fill its partition". That's helpful in a cloud environment, if you have a tiny system image and want to create a large storage volume from it.

systemd 245 released

Posted Mar 12, 2020 7:07 UTC (Thu) by smurf (subscriber, #17840) [Link]

You need it just as much on any Raspberry Pi-style computer ever (write 1.5GB boot image onto 32GB SD card, reboot three times until you have successfully resized the thing).

systemd 245 released

Posted Mar 7, 2020 7:01 UTC (Sat) by amarao (subscriber, #87073) [Link] (5 responses)

Homes does the stuff I've done for years for my home. I've been using luks for home volume, where key is stored on root device, encrypted by user password. Decryption happens via pam-exec and soms ugly bash. Root itself is encrypted, so to get to home one need to supply 'root volume password' at boot and user password at login. Additionally, second key slot for home volume is a join of root password and user password (in case root volume become corrupted or die away).

I think homed would do the same but better.

... And I really will appreciate if they can combine suspend with dropping encryption key from memory (ask user password after resume, decrypt volume back).

systemd 245 released

Posted Mar 7, 2020 16:15 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (4 responses)

Yes, we already support flushing out the luks key from memory on suspend. But gdm needs some love before this can be exposed in GNOME, as they need to run the lock screen as separate user, so that it can continue running when the user's home is locked.

systemd 245 released

Posted Mar 7, 2020 21:18 UTC (Sat) by josh (subscriber, #17465) [Link] (1 responses)

Does it need to run as a separate user, or could it just use mlockall?

systemd 245 released

Posted Mar 8, 2020 9:42 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

mlockall doesnt work. For gdm to work you need a whole bunch of processes to stay alive, it basically runs a more or less complete GNOME session, and you couldnt possibly call mlockall() in all of them. More importantly these open all kinds of files all the time at various times, and only a few of them are mmaped. mlockall() only applies to memory mapped stuff, hence is generall not sufficient.

systemd 245 released

Posted Mar 8, 2020 4:14 UTC (Sun) by HelloWorld (guest, #56129) [Link] (1 responses)

Why does gdm need to mess around in the user's home directory when it's just sitting there waiting for the user to enter their password?

systemd 245 released

Posted Mar 9, 2020 13:06 UTC (Mon) by zwol (guest, #126152) [Link]

It doesn't; it needs to mess around in *its own* home directory (usually /var/lib/gdm). Which it can perfectly well do as its own uid, and does, when nobody's logged in yet. If I understand mezcalero correctly, it's just that right now, the screen locker runs as the logged-in user instead of the dedicated greeter user, and that can and will be fixed.

(Bonus: this will fix a design error that jwz has been complaining about for over a decade, where you can bypass authentication if you find a hole in one of the many libraries that the GNOME screen locker uses to process keyboard input.)

systemd 245 released

Posted Mar 7, 2020 8:35 UTC (Sat) by niner (subscriber, #26151) [Link] (1 responses)

Reading through the Changes list, there's an incredible number of "oh, this might come in handy" moments. And that's just for one release. Makes me wonder, how many useful features I've missed out on by not reading the full Changes for every release.

systemd 245 released

Posted Mar 7, 2020 13:20 UTC (Sat) by zuki (subscriber, #41808) [Link]

The NEWS file is prepend-only, it goes back all the way to version 38; just keep reading. The only problem is that it's 10524 lines currently, so that might take a while ;)

systemd 245 released

Posted Mar 7, 2020 14:22 UTC (Sat) by kjp (guest, #39639) [Link]

I love the website look.

systemd 245 released

Posted Mar 7, 2020 14:56 UTC (Sat) by beagnach (guest, #32987) [Link] (5 responses)

There is a lot to like here. I do system administration only sporadically so I always feel I'm only scratching the surface of what systemd can do and I'm often pleasantly surprised by some functionality that makes a task easier.

But....
What bothers me is the lack of insight into modularity.

The lwn comments have seen years of repeated accusations of systemd having an 'everything including the kitchen sink" approach and endless reassurances that it is implemented as a suite of services and components.

This may be true but from what i can tell it's a suite of highly interdependent, tightly coupled services, with poor visibility into the dependency graph and poor support for swapping in third party components.

For example
> The [userdb] framework allows defining rich user and group records in a JSON format... Various components in systemd have been updated to process records in this format, including systemd-logind and pam-systemd.

So does this mean that system-logind and pam-systemd now depend on the userdb component? And also on systemd-userdb.service? Or can they use the data format independently of these?

The wider issue is that modularity requires more than just the systemd ecosystem operating as a suite of services.

1: The dependencies must be fully documented so that informed choices can be made about the parts that are wanted, and the costs of omitting unwanted parts.

2 graceful fallbacks are required so that if a component or service is disabled the system will use e.g. the hitherto standard Linux mechanisms for access to use configuration data.

3 the system should allow for easy configuration of which components to disable with, preferably, good logging about any loss of functionality - e.g. `systemd is operating with userdb disabled - some security features relating to user accounts will not be available`

From what I can tell (and I'm hoping to be corrected on this) currently systemd is not very amenable to modularity because

1 there are a lot of cross-dependencies between services and components - more of a dependency bush than a dependency tree, making it hard to understand what can and can't be safely turned off

2 everything is enabled by default and there is little support upstream for running with things disabled...

3 ... meaning that fallbacks are often not implemented or well tested

4 and the system is not very informative about what to expect if certain components are turned off - functionality can be degraded or silently fail with little or no notification to the user

The bigger issue is that it's currently all or nothing. If I don't like how systemd is managing users, or network configuration, or whatever can I safely turn that part off?

More importantly can I implement my own service? I think this is the most important question. Are all these components and services cross dependant at a source code level? Or do they use well defined interfaces to interact (file system, sockets, whatever)

systemd 245 released

Posted Mar 7, 2020 16:27 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (1 responses)

The userdb stuff is both an internal api of systemd and an external one. The former is always there, cannot be compiled out, and is not much visible. The latter is implemented in a tiny service systemd-userbdd.service ( which just exposes the internal api via varlink ipc). This part can be turned off.

NSS compat is provided both ways: components can implement just nss or just userdb or both. Regardless which of these three options they go for the users/groups they provide or consume are always of the same global set.

So, if you turn off/don't install systemd-userdbd then you want get the external inzerface for the userdb stuff, that's all, internally systemd works the same way regardless.

In general, in systemd all components are optional, except for pid1, journald and udevd (the latter is not used when an OS is run in a container since device mgmt is not virtualized on Linux, which means a working container system may just have two of the three mentioned services and still be complete). With userdbd and homed this hasnt changed.

Long story short, the internal deps are not complex, components that can be enabled/disabled in the build system are mostly orthogonal.

systemd 245 released

Posted Mar 14, 2020 21:26 UTC (Sat) by nix (subscriber, #2304) [Link]

In general, in systemd all components are optional, except for pid1, journald and udevd (the latter is not used when an OS is run in a container since device mgmt is not virtualized on Linux, which means a working container system may just have two of the three mentioned services and still be complete). With userdbd and homed this hasnt changed.
One nice side-effect of containers is that because they run with almost nothing, this means the "simple systemd" case of turning almost everything non-systemd-core off is routinely tested and doesn't rust. Turning other random subsets off... well, there are lots of independently-disableable components, so the state space is pretty huge by now: I suspect most of the possible combinations have not only never been tested but never been used by anyone in the history of the universe. :)

systemd 245 released

Posted Mar 9, 2020 13:43 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

> If I don't like how systemd is managing users, or network configuration, or whatever can I safely turn that part off?

AFAIK, distros still default to their own mechanisms for these two specific things. I have to move *to* systemd-networkd and *off* of NetworkManager in Fedora manually, for example.

> More importantly can I implement my own service?

I assume you're referring to a `systemd-foo` service here, not as an author to a `.service` file. I'd start looking at this page: https://systemd.io/PORTABILITY_AND_STABILITY/

systemd 245 released

Posted Mar 9, 2020 13:55 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

>> If I don't like how systemd is managing users, or network configuration, or whatever can I safely turn that part off?
> AFAIK, distros still default to their own mechanisms for these two specific things. I have to move *to* systemd-networkd and *off* of NetworkManager in Fedora manually, for example.

That's an important point -- Systemd's many "use it or not, it's optional" features are largely targeted at distribution makers, not end-users. If your distro uses mechanism X to manage users or network configuration or whatever, it's going to be a major PITA to move to mechanism Y -- whether nor not X or Y involves systemd.

systemd 245 released

Posted Mar 9, 2020 15:25 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

The nice thing about systemd is that my knowledge for Debian and Fedora is very similar now. I know how to setup systemd-networkd for myself and that is distro-agnostic (module package names, but that's trivial comparatively). The differences are just in how to get the distro mechanisms to stop doing their thing instead (usually just a package set/glob removal).

systemd 245 released

Posted Mar 8, 2020 18:12 UTC (Sun) by vadim (subscriber, #35271) [Link] (6 responses)

Say, when are we getting systemd-authd (a hypothethical replacement for PAM)?

I think one of the big issues today with Linux is that some things like authentication aren't compartmentalized well enough yet. This makes it hard to sandbox things because PAM is a shared library that works with the permissions of the process that uses it. If authentication operated as a service, it could be strictly confined, and communicate with user applications that wouldn't need special privileges.

systemd 245 released

Posted Mar 9, 2020 13:12 UTC (Mon) by zwol (guest, #126152) [Link]

With my libxcrypt maintainer hat on, I have a bunch of design notes for a hypothetical 'privilege separated password authentication daemon' and the main thing stopping me from moving forward with it (well, aside from time and funding issues) is I honestly can't tell how alive of a project PAM is. Anyway, if you're interested in this please drop me a line (zackw at panix dot com).

systemd 245 released

Posted Mar 9, 2020 18:18 UTC (Mon) by raven667 (subscriber, #5198) [Link] (4 responses)

For the common use cases it seems that extending sssd might make sense, if it doesn't already support local /etc/{passwd,groups} files, so that the PAM client library just needs to talk to the local daemon and doesn't need to load anything of consequence into the applications address space. What that doesn't cover is the long tail of PAM modules that exist, for 2FA and other purposes, that would still need a place to run, some sort of PAM daemon that loads whatever libraries are designed for PAM but provides an IPC mechanism wrapping its entire API that the user application would normally use. I don't know what the details are, but I don't know that someone has already written such a thing so it's either not something that has gotten any attention because the status quo works well enough for most, or is fairly difficult and no one has been brave enough to touch the problem.

systemd 245 released

Posted Mar 9, 2020 18:40 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Ideally NSS and PAM should be unified in one such daemon. And it really does look like a job for systemd.

systemd 245 released

Posted Mar 9, 2020 23:58 UTC (Mon) by Fowl (subscriber, #65667) [Link] (2 responses)

Maybe we should call it "LSA" to make NT users feel at home ;)

systemd 245 released

Posted Mar 10, 2020 0:22 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Not quite yet. We also need LPC (aka Bus-1).

systemd 245 released

Posted Mar 11, 2020 0:25 UTC (Wed) by sorpigal (guest, #36106) [Link]

Maybe call it factotum by analogy with Plan9.


Copyright © 2020, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds