> Please note that this specification assumes that JSON numbers may cover the full integer range of -2^63 … 2^64-1 without loss of precision (i.e. INT64_MIN … UINT64_MAX). Please read, write and process user records as defined by this specification only with JSON implementations that provide this number range.
I don’t understand the obsession with systemd managing everything. I do not want it to manage my logs, NTP, DNS resolution, and I sure as hell don’t want it to manage /home.
I'm proud of my former distant coworker Russ Allbery resigned from Debian over systemd. It was shoved down most distro's throats, often with illiberal force over the objections of wiser elders and more experienced SA's.
It's easy to understand: RH is IBM which in turn is same business owners as MS and Apple so they preparing to destroy Linux, making it not a Windows or mainframes killer. Positioning... Holds even if systemd started before RH buyout.
Works becouse RH is or was main developping force in open source. Ubuntu or SUSE or Debian or EU are just joke in software development. And RH [management] goes rogue... Think: back to pre-POSIX UNIX wars...
You can't use d-bus for this because d-bus isn't available early enough, relies on user accounts, and can't enumerate through large sets of objects with optional filtering they had to create and invoke the completely separate "Varlink." Which is _closer_ to the traditional Unix/Plan9 service model without actually achieving it meaningfully.
The infamous part of d-bus, that it helps inject arbitrary binary payloads into existing text protocols, is now reversed in varlink, it takes what should be arbitrary binary payloads (user records, certificates, etc..) and instead forces you to manage them as JSON objects. Signing and conveying signatures for this object are predictably painful.
"The signature section contains one or more cryptographic signatures of a reduced version of the user record. This is used to ensure that only user records defined by a specific source are accepted on a system, by validating the signature against the set of locally accepted signature public keys. The signature is calculated from the JSON user record with all sections removed, except for regular, privileged, perMachine. Specifically, binding, status, signature itself and secret are removed first and thus not covered by the signature. This section is optional, and is only used when cryptographic validation of user records is required (as it is by systemd-homed.service for example)."
This all seems very brittle and I don't see the kinds of testing that would project confidence in this system. Good luck to all who use this and trust it.
For those curious about systemd-homed, lwn had a writeup about a discussion in Fedora about it which provides a good summary of the pros and cons of systemd-homed.
It seems to be that a lot of what systemd is doing (over and above being 'just' an init system) seems to be focused on standalone systems.
And that's fine and all for some folks, but for those of us sysadmin-ing servers/VMs, it's all sorts of annoying that these sub-systems exist for dynamic environments (laptops using networkd/resolvd/etc to handle moving around), but I just want my system to be static and not have (e.g.) resolv.conf futzed around with (I've taken to doing a chattr +i on the file quite often).
> (I've taken to doing a chattr +i on the file quite often)
That requires ext4 AFAIK, whereas many systems use XFS, BTRFS, or ZFS. I've done this as well on several files I don't want mucked with, when I can't simply disable the systemd daemons. For me, ext4 works best.
Their docs don't even mention homes mounted over NFS, or LDAP managed users. This is the same sort of pathetically marginal garbage that damns Snaps, which somehow think that large environments put all user directories in /home - even that that is NOT a standard and doesn't scale worth a damn.
Systemd is a curse, the TRON MCP that doesn't even seem have a system for alternate solutions to compete. Before systemd we saw a more lively environment of alternatives for each service area, but systemd strangles this with a collection of mediocrities, and lack of foresight.
Looking through the doc at https://systemd.io/HOME_DIRECTORY/ shows a entire webpage built of ideas many would rightfully reject, some defy standards, some defy common sense, and best practices, fail to scale, add arbitrary constraints, or have other problems.
I've been a sysadmin at large sites before. systemd-homed looks a lot like unusable trash.
12 comments
[ 3.5 ms ] story [ 40.4 ms ] threadWait, so.. not javascript?
As someone unfamiliar with systemd-homed, I have a very basic question: why would someone want (or not want) to do this?
Works becouse RH is or was main developping force in open source. Ubuntu or SUSE or Debian or EU are just joke in software development. And RH [management] goes rogue... Think: back to pre-POSIX UNIX wars...
You can't use d-bus for this because d-bus isn't available early enough, relies on user accounts, and can't enumerate through large sets of objects with optional filtering they had to create and invoke the completely separate "Varlink." Which is _closer_ to the traditional Unix/Plan9 service model without actually achieving it meaningfully.
The infamous part of d-bus, that it helps inject arbitrary binary payloads into existing text protocols, is now reversed in varlink, it takes what should be arbitrary binary payloads (user records, certificates, etc..) and instead forces you to manage them as JSON objects. Signing and conveying signatures for this object are predictably painful.
"The signature section contains one or more cryptographic signatures of a reduced version of the user record. This is used to ensure that only user records defined by a specific source are accepted on a system, by validating the signature against the set of locally accepted signature public keys. The signature is calculated from the JSON user record with all sections removed, except for regular, privileged, perMachine. Specifically, binding, status, signature itself and secret are removed first and thus not covered by the signature. This section is optional, and is only used when cryptographic validation of user records is required (as it is by systemd-homed.service for example)."
This all seems very brittle and I don't see the kinds of testing that would project confidence in this system. Good luck to all who use this and trust it.
https://lwn.net/Articles/995915/
And that's fine and all for some folks, but for those of us sysadmin-ing servers/VMs, it's all sorts of annoying that these sub-systems exist for dynamic environments (laptops using networkd/resolvd/etc to handle moving around), but I just want my system to be static and not have (e.g.) resolv.conf futzed around with (I've taken to doing a chattr +i on the file quite often).
That requires ext4 AFAIK, whereas many systems use XFS, BTRFS, or ZFS. I've done this as well on several files I don't want mucked with, when I can't simply disable the systemd daemons. For me, ext4 works best.
All three of these support immutable files:
* https://man.archlinux.org/man/xfs.5.en#FILE_ATTRIBUTES
* https://man.archlinux.org/man/btrfs.5.en#Attributes
* 2016 OpenZFS bug where it was broken and fixed: https://github.com/openzfs/zfs/pull/5486
F*k systemd, and systemd-homed along with it.
Their docs don't even mention homes mounted over NFS, or LDAP managed users. This is the same sort of pathetically marginal garbage that damns Snaps, which somehow think that large environments put all user directories in /home - even that that is NOT a standard and doesn't scale worth a damn.
Systemd is a curse, the TRON MCP that doesn't even seem have a system for alternate solutions to compete. Before systemd we saw a more lively environment of alternatives for each service area, but systemd strangles this with a collection of mediocrities, and lack of foresight.
Looking through the doc at https://systemd.io/HOME_DIRECTORY/ shows a entire webpage built of ideas many would rightfully reject, some defy standards, some defy common sense, and best practices, fail to scale, add arbitrary constraints, or have other problems.
I've been a sysadmin at large sites before. systemd-homed looks a lot like unusable trash.
</tirade>