Converting existing users to systemd-homed managed users
systemd.io
systemd.io
i'm not sure if that is what it does but I think that is a goal
Or… like iCloud? No on that last one, having Linux require some server seems to defeat the point. Why not a Mac then?
My interest is actually in the opposite direction; I want a single machine with all home directories on its own internal hard disk, but where each user encrypts their home directory separately. That's doable other ways, but homed could be a nice way to do it that works out of the box.
As mentioned, back in the day, you’d connect to a terminal server which would connect you to a random host. You’d login to that host (using a shared credential managed by yellow pages, maybe — this was pre-LDAP). Once logged in, something like mountd would mount your home directory from the NFS server and off you go.
Not a lot of these kinds of systems out there today. Curious how a modern one would be managed and secured.
I don’t run systemd at all, to be safe.
Meanwhile, I want to be able to mount my home directory on an external drive, and have it shared between systems without UID/GID hell.
And,
Have an encrypted home directory and boot the system and be able to enter my password with my keyboard which is connected to a thunderbolt dock during boot. Something which has been possible on Mac and windows for a decade or two.
Systemd-homed is the ONLY way to achieve these (and many others) in Linux.
Criticisms of systemd just because “it doesn’t smell like Unix” is all nice and fine, but ignores real quality of life and security features it provides. If you don’t have these usecases, you’re welcome to continue to ignore systemd, but some of us actually want these feature.
It absolutely is not. [Full] disk encryption has been fine for... at least 15 years, probably more. Sharing a home directory requires consistent UID/GID, but that's not hard even fully manually (which is fine if you're just one person).
Yes Linux has had FDE on for a long time, but with traditional FDE using LUKS etc, you cannot use accessories such as a thunderbolt keyboard during the boot process to enter the password to unlock the disk.
Which is a problem if you’re like me and want to just connect your Linux laptop to a thunderbolt dock and use the keyboard attached to it.
A problem which systemd-homed solves.
systemd has done leaps and bounds for making Linux platforms look reasonably manageable and standardized.
systemd has done leaps and bounds
As opposed to jumping between IRIX and AIX and Solaris? See Rosetta Stone for Unix:
* https://bhami.com/rosetta.html
* https://bhami.com/unix-rosetta.pdf
Wasn't one of the points of multiple distributions was to allow experimentation and allowing for different philosophies of doing things? If you're going to homogenize things what's the point of having multiple distributions in the first place?
> systemd has done leaps and bounds for making Linux platforms look reasonably manageable and standardized.
So I've gone from service foo start/stop (which also works on BSD) to systemctl foo start/stop. Yay! (Of course some distros use "ssh" and others "sshd", or "apache2" versus "httpd".)
Right, which is why Windows home edition is managed via GPO and iOS exposes the same APIs as macOS. /s
Different operating systems are different, even if they share a kernel.
Systemd kind of combs these all into one place so there's a single point of failure. Now there's just one of them, so it's DRY.
A single point of failure is… good?
(Or is your statement an example of Poe's law?)
The other “points of failure” you mention are all incredibly well-tested and battle-hardened.
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...
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).
My* only problem is that it's pretty good at what it does, and can be... more helpful than you might like at providing consistent global DNS resolution. For example, it's use over dbus makes processes in `netns`s susceptible to leaking DNS requests. Though arguably I should've been going more full-containery than just a netns maybe, given my expectations.
The number of ways and things that twiddle with /etc/resolv.conf nowadays is quite unreasonable.
Changing the IP address was also fairly simple in editing a file, but now there's networkd sometimes, and NetManager other times, and netplan too, and perhaps make sure your YAML file is indented with the right number of spaces in the right place…
In many years of daily-driving unix-likes and being an amateur and professional sysadmin, I think resolv.conf is the only time I've ever actually used `chattr +i`.
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
As someone unfamiliar with systemd-homed, I have a very basic question: why would someone want (or not want) to do this?
The big thing appears to be moving the user metadata into the home directory itself rather than it being around the system, and enabling home folder encryption, which has been like... a single button press feature on Windows since like Windows XP. Sounds like a step forward.
The same key which encrypts the volume decrypts the metadata, but they use different IVs.
You could assume that most systems the key would be secured with the TPM so this won't be much of a big deal to the user, but otherwise when they try to login it would prompt for this password first.
I'm not sure I understand the appeal. What does "putting user configuration inside the home directory" mean in this context? Is there a file with the UID, GIDs (primary, secondaries), GECOS, etc?
What is put inside the homedir?
* https://systemd.io/USER_RECORD/
You'll enjoy the bit about the umask. Yes, this is short on details of where all of the privileged and secret stuff lives.
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.
So structure it like that! Have a whole file that is signed or otherwise integrity-checked in its entirely. Have another file with fields that are per-(user,machine) and integrity-check that. “Integrity-check” means that you validate the binary contents of the file before you even attempt to parse it, and then you parse the literal bytes that you checked.
It’s not the nineties anymore, and architects should know better.
Wait, so.. not javascript?
Judging by the Qt source, if the internal JS runtime JSON parser is used then it will not support full range of 64-bit integers, since the double floating point type is used for any integers x where abs(x) > 1^^25.
Something like this, I think:
JSON.parse(
/* just a test input JSON */
`{"a": 1.1, "b": 22222222222222222222222222222222, "c": {"d": 999999999999999999999999}}`,
/* a reviver that returns BigInts, if it's an integer. */
(key, value, context) => {
if(typeof value === "number" && /^[0-9]+$/.test(context.source)) {
return BigInt(context.source);
} else {
return value;
}
}
);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>