Pack Your Bags – Systemd Is Taking You to a New Home | Hacker News Reader

Pack Your Bags – Systemd Is Taking You to a New Home

hackaday.com

14 pointsrolph14 comments

Actual spec for systemd-homed: https://github.com/poettering/systemd/blob/homed/docs/HOME_D...

"If the UID assigned to a user does not match the owner of the home directory in the file system, the home directory is automatically and recursively chown()ed to the correct UID."

I wish systemd fixed centralized UID/GID management first before trying to do this bit.

This seems like a terrible design decision. Whatever the desired semantics, the response to a detected inconsistency between a configuration file and the filesystem should not be to automatically and irreversibly change the filesystem.

Another WTF from that document: "It is recommended to bring the record into 'normalized' form (i.e. all objects should contain their fields sorted alphabetically by their key) before storing it there, though this is not required nor enforced."

??? Why? Will things break if I don't sort it alphabetically? If not, why recommend it? If so, why not enforce it? Nebulous half-specs like that are inevitable in systems which have evolved de-facto standards over decades, but why on Earth would you put one in a brand new spec document?

There are many other things in that document that make me scratch my head (non-user-modifiable files stored in the user's home directory?), but that's enough for one day I think...

If systemd is so bad, then why did it get made and broadly adopted? It seems like critics of systemd might make more progress if they admitted that there is more going on than an evil developer trying to sabotage everything good about Unix based systems.

The reason that distros have adopted it is because it makes their job easier, and they don't have to worry too much about the cost to the larger Linux world.

Despite short memory leading to white washing of systemd adoption history...

Systemd hot big adoption jump through a single project that's been essentially controlled by Red Hat for years: GNOME.

GNOME version 3.8 was broken if run without logind, which meant systemd. Officially the answer was that logind wasn't dependant on systemd. Unofficially the spec and docs were worse than MS' proprietary protocols, and most distro faced option between dropping GNOME or embracing systemd. Non Linux systems which were supported before were of course dropped totally. Canonical for short while tried to implement separate logind implementation - they gave up after short time. One OpenBSD developer spent years of time making GNOME post-3.8 usable without systemd again.

Meanwhile, it was known for 2~3 years that RHEL 7 and CentOS 7 will use systemd.

Essentially, Red Hat pulled an Embrace, Extend, Extinguish on other distro.

Red Hat makes money when people pay them for support. The harder Linux is to use, the better for them.

I think this goes a very long way towards explaining the current state of desktop Linux.

In Debian's case, wasn't it a decision by board members, and specifically not the community to add it as the default init? I heard that some people dislike it from a political stance, because the community didn't have a say.

Dupe of

https://news.ycombinator.com/item?id=21270861 https://news.ycombinator.com/item?id=21279720

What I don't get is why this needs to be tied to making the home dir a LUKS container.

Like why can't we just implement the part that doesn't involve solving the SSH issues and then add on the SSH fixes (which I don't believe are issues anyway?)

You're correct, they aren't issues. What's scary to me is someone is proposing to rewrite how home directories work in unix, and doesn't even know about AuthorizedKeysCommand in OpenSSH and is planning massive workarounds because of that.

Some of these downvoters on HN. I pointed out the SSH issues are already taken care of.

From the manpage: Specifies a program to be used to look up the user's public keys. The program must be owned by root, not writable by group or others and specified by an absolute path. Arguments to AuthorizedKeysCommand accept the tokens described in the TOKENS section. If no arguments are specified then the username of the target user is used. The program should produce on standard output zero or more lines of authorized_keys output (see AUTHORIZED_KEYS in sshd(8)). If a key supplied by AuthorizedKeysCommand does not successfully authenticate and authorize the user then public key authentication continues using the usual AuthorizedKeysFile files. By default, no AuthorizedKeysCommand is run.

I have only one problem with LUKS container home directories, in my eyes disk hardware is too flaky to handle fully encrypted filesystems.

I have no problems with encrypted files, but I am not waiting for access problems of my own stuff.

systemd-homed is a solution for NSA and secret companies, not for someone like me who has no problem with how things function today.

But I am afraid there is no opt out but only filosophy enforcement.

I will never use this but I don't mind that it's being made.

https://news.ycombinator.com/item?id=21270861

> At this point, it probably doesn’t matter anymore what he does next, haters gonna hate

Don’t bother thinking critically, anyone who thinks his ideas could be improved upon is just an angry graybeard. Who cares what they think?!

Reply on news.ycombinator.com