systemd 245 released
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 SekletaÌ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
Posted Mar 6, 2020 23:16 UTC (Fri)
by warrax (subscriber, #103205)
[Link] (44 responses)
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.
Posted Mar 7, 2020 7:04 UTC (Sat)
by amarao (subscriber, #87073)
[Link] (16 responses)
Posted Mar 7, 2020 7:20 UTC (Sat)
by sytoka (guest, #38525)
[Link] (3 responses)
Posted Mar 7, 2020 12:35 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link]
Posted Mar 7, 2020 15:58 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
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.
Posted Mar 9, 2020 13:09 UTC (Mon)
by zwol (guest, #126152)
[Link]
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.
Posted Mar 7, 2020 12:33 UTC (Sat)
by pizza (subscriber, #46)
[Link] (11 responses)
Even stuff that does generally utilizes $HOME typically has some corner cases that misbehave. (I'm looking at you, everything-by-Xilinx...)
Posted Mar 7, 2020 15:05 UTC (Sat)
by dezgeg (subscriber, #92243)
[Link] (10 responses)
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...
Posted Mar 10, 2020 9:34 UTC (Tue)
by abo (subscriber, #77288)
[Link] (9 responses)
Posted Mar 15, 2020 14:33 UTC (Sun)
by cortana (subscriber, #24596)
[Link]
Posted Mar 15, 2020 15:18 UTC (Sun)
by pizza (subscriber, #46)
[Link] (3 responses)
Makes it a royal PITA to properly version control a project that multiple folks (or even multiple simultaneous work areas) need to interact with.
Posted Mar 16, 2020 11:35 UTC (Mon)
by cortana (subscriber, #24596)
[Link] (2 responses)
I remain astounded that so much expensive "Enterprise" software is of such poor quality!
Posted Mar 16, 2020 12:16 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
Compared to the likes of Cadence tools, Xilinx is problem-free nirvana..
Posted Apr 6, 2020 18:21 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Posted Mar 19, 2020 12:46 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link] (3 responses)
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1867921
Posted Mar 19, 2020 19:56 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (2 responses)
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?
Posted Mar 19, 2020 21:31 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
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.
Posted Mar 20, 2020 11:13 UTC (Fri)
by mgedmin (subscriber, #34497)
[Link]
Posted Mar 7, 2020 10:09 UTC (Sat)
by oldtomas (guest, #72579)
[Link]
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.
Posted Mar 7, 2020 15:54 UTC (Sat)
by BirAdam (guest, #132170)
[Link] (25 responses)
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.
Posted Mar 7, 2020 16:12 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (23 responses)
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.
Posted Mar 7, 2020 19:39 UTC (Sat)
by ibukanov (subscriber, #3942)
[Link] (22 responses)
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.
Posted Mar 7, 2020 21:07 UTC (Sat)
by vadim (subscriber, #35271)
[Link] (4 responses)
I find it really nice that anything you want can be a service and get its output logged.
Posted Mar 8, 2020 15:25 UTC (Sun)
by ibukanov (subscriber, #3942)
[Link] (3 responses)
And by insisting on stderr log one immediately misses levels unless one starts to use <> annotations which looks more like an afterthought.
Posted Mar 8, 2020 20:47 UTC (Sun)
by rodgerd (guest, #58896)
[Link]
Posted Mar 10, 2020 11:32 UTC (Tue)
by MarcB (subscriber, #101804)
[Link] (1 responses)
Posted Mar 11, 2020 8:20 UTC (Wed)
by darwi (subscriber, #131202)
[Link]
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).
Posted Mar 7, 2020 21:17 UTC (Sat)
by josh (subscriber, #17465)
[Link] (15 responses)
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.
Posted Mar 7, 2020 21:54 UTC (Sat)
by BirAdam (guest, #132170)
[Link] (14 responses)
Posted Mar 8, 2020 7:24 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Posted Mar 8, 2020 10:16 UTC (Sun)
by jrigg (guest, #30848)
[Link] (5 responses)
Is this kind of terminology really necessary?
Posted Mar 8, 2020 17:02 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (4 responses)
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,
Posted Mar 8, 2020 17:28 UTC (Sun)
by tzafrir (subscriber, #11501)
[Link]
A basic Systemd service is much simpler to write, install and debug than a System-V service script on Linux.
Posted Mar 9, 2020 17:59 UTC (Mon)
by brouhaha (subscriber, #1698)
[Link] (2 responses)
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.
Posted Mar 10, 2020 17:05 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Mar 10, 2020 18:20 UTC (Tue)
by brouhaha (subscriber, #1698)
[Link]
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.
Posted Mar 8, 2020 9:38 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
Posted Mar 9, 2020 16:51 UTC (Mon)
by ms-tg (subscriber, #89231)
[Link]
> 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)
Posted Mar 8, 2020 20:46 UTC (Sun)
by rodgerd (guest, #58896)
[Link] (3 responses)
Ah yes, the well-known UNIX conventions shared between AIX and BSD.
Posted Mar 9, 2020 11:53 UTC (Mon)
by magfr (subscriber, #16052)
[Link]
Posted Mar 9, 2020 16:14 UTC (Mon)
by SEJeff (guest, #51588)
[Link] (1 responses)
Posted Mar 14, 2020 21:16 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Mar 11, 2020 22:57 UTC (Wed)
by da4089 (subscriber, #1195)
[Link]
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.
Posted Mar 8, 2020 9:34 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
Posted Mar 10, 2020 23:19 UTC (Tue)
by jgg (subscriber, #55211)
[Link]
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.
Posted Mar 7, 2020 5:49 UTC (Sat)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Mar 12, 2020 7:07 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Posted Mar 7, 2020 7:01 UTC (Sat)
by amarao (subscriber, #87073)
[Link] (5 responses)
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).
Posted Mar 7, 2020 16:15 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (4 responses)
Posted Mar 7, 2020 21:18 UTC (Sat)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Mar 8, 2020 9:42 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
Posted Mar 8, 2020 4:14 UTC (Sun)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Mar 9, 2020 13:06 UTC (Mon)
by zwol (guest, #126152)
[Link]
(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.)
Posted Mar 7, 2020 8:35 UTC (Sat)
by niner (subscriber, #26151)
[Link] (1 responses)
Posted Mar 7, 2020 13:20 UTC (Sat)
by zuki (subscriber, #41808)
[Link]
Posted Mar 7, 2020 14:22 UTC (Sat)
by kjp (guest, #39639)
[Link]
Posted Mar 7, 2020 14:56 UTC (Sat)
by beagnach (guest, #32987)
[Link] (5 responses)
But....
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
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)
Posted Mar 7, 2020 16:27 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
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.
Posted Mar 14, 2020 21:26 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Mar 9, 2020 13:43 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
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/
Posted Mar 9, 2020 13:55 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
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.
Posted Mar 9, 2020 15:25 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Mar 8, 2020 18:12 UTC (Sun)
by vadim (subscriber, #35271)
[Link] (6 responses)
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.
Posted Mar 9, 2020 13:12 UTC (Mon)
by zwol (guest, #126152)
[Link]
Posted Mar 9, 2020 18:18 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (4 responses)
Posted Mar 9, 2020 18:40 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Mar 9, 2020 23:58 UTC (Mon)
by Fowl (subscriber, #65667)
[Link] (2 responses)
Posted Mar 10, 2020 0:22 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Mar 11, 2020 0:25 UTC (Wed)
by sorpigal (guest, #36106)
[Link]
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
Wol
systemd 245 released
Unix won because it was free? It is to laugh.
and it won because it was (a) cheap (aka "free"), and (b) good enough.
Unix won because it was free? It is to laugh.
Unix won because it was free? It is to laugh.
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
What bothers me is the lack of insight into modularity.
> 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.
systemd 245 released
systemd 245 released
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
systemd 245 released
> 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.
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
systemd 245 released
Maybe call it factotum by analogy with Plan9.
systemd 245 released
