i just read through the notes you provided... sounds really cool 👍

systemd-sysusers isn't nearly as feature filled as our perl scripts... but most of that gap magically goes away with /etc as an overlayfs - awesome stuff!

@nikstur - is there anywhere i can keep up to date on the developments mentioned in that pad? i would love to follow along with what y'all are working on there... 🤩

@aanderse I'll list all the associated PRs in the Pad. Otherwise, you can just follow my Nixpkgs activity I guess :D

Broken by d43e323

Broken by d43e323

What exactly is broken?

It is now impossible to enable sysusers on a system that has "normal users", meaning that any system that uses perlless activation and/or immutable /etc will fail to build.

It is now impossible to enable sysusers on a system that has "normal users", meaning that any system that uses perlless activation and/or immutable /etc will fail to build.

They were not actual normal users because their uids was < 1000. So the "normal users" were a lie.

Not if the uid was set manually, which was the case in my configuration.

Irrespective of any workarounds, systemd-sysusers is not designed to create "normal" users. This PR makes this explicit.

However, there is another solution to this problem. Once #332719 is merged, you can use Userborn to manage your users without Perl.

It is still the case that before d43e323, upon setting systemd.sysusers.enable = true; my configuration built and activated without issue; I did not notice any problems with UID assignment or password changes because, due to using a tmpfs as /, my configuration had set the UID explicitly and set the user's password using the initialHashedPassword option. After d43e323, my config did not build anymore and I needed to spend an hour tracking down a chain of poorly documented changes that had caused it.

(I was not present in whatever discussions led to this change; it feels like the general assumption is that I should have known this would happen.)

I would like to request the following changes to the assertion added in d43e323 to avoid unexpectedly breaking people's configs with no warning:

• if possible, a stopgap solution: make the assertion conditional on all normal users' options being compatible with sysusers, such as using only initialHashedPassword or equivalent and setting the UID explicitly.
• a better error message that explains what happened and what needs to be changed.

I would like to request the following changes to the assertion

I'll happily review a PR.

Please understand, however, that my focus going forward will be Userborn as that's the solution to systemd-sysusers limitations.

it feels like the general assumption is that I should have known this would happen

With experimental features some breakage unfortunately has to be expected.