nixos/userborn: introduce config.services.userborn.static mode

[valpackett]

For embedded appliance-style applications, we would like to avoid the ~100ms boot time hit that comes from running userborn or sysusers by pre-baking the final password files directly into the system closure.

Turns out, userborn is trivial to run at build time instead of boot time, so let's introduce a new "baked" mode that directly places the files into an immutable /etc.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[nikstur]

This is generally a bad idea.

You can only sensible allocated UIDs impurely, i.e. when the system is running because you always need to have the state of the password files (i.e. from users changing between generations).

The only situation where this mode is acceptable is if you never change users during the entire lifetime of the system, i.e. when you do not switch generations but delete and re-create the entire image for an update.

Otherwise it's potentially dangerous because of UID/GID re-use. Please see this part of the Userborn readme for an example of why UID/GID re-use is bad.

If you're thinking of the acceptable use-case describe above, we need to make this very clear and point out the pitfalls in the docs. I'd also prefer if this mode was called static because baked is not very descriptive IMO.

[valpackett]

Yes, by "embedded appliance-style applications" I mean systems that don't use NixOS generations at all. We're currently doing this for application VMs that are built with raw nix build and are entirely stateless.

What would be a good assertion for "generations / typical nixos management aren't used"?

Yeah, I thought about static being an alternative name, will rename.

[inthesquarehole]

Yes, by "embedded appliance-style applications" I mean systems that don't use NixOS generations at all. We're currently doing this for application VMs that are built with raw nix build and are entirely stateless.

What would be a good assertion for "generations / typical nixos management aren't used"?

Assert that nixos-rebuild{,-ng} shouldn't be installed.

[nikstur]

Yes, by "embedded appliance-style applications" I mean systems that don't use NixOS generations at all. We're currently doing this for application VMs that are built with raw nix build and are entirely stateless.
What would be a good assertion for "generations / typical nixos management aren't used"?

Assert that nixos-rebuild{,-ng} shouldn't be installed.

You could do that via system.switch.enable.

EDIT: Please note, however, that this doesn't solve all cases. When you build an image based system and update it with systemd-sysupdate for example, you should still not use the static mode. However, I think, this assert would be good enough to prohibit most frivolous use.

[nikstur]

Please add test for this. Otherwise it's very hard to maintain long-term.

[valpackett]

Is one test sufficient or should there be variants for mutable/immutable /etc and users?

[nikstur]

Is one test sufficient or should there be variants for mutable/immutable /etc and users?

One is fine for now.

Thank you for the work! Definitely an interesting use case. I appreciate the benchmarking that you have done beforehand.

[nikstur]

Do you want to add yourself here?

[valpackett]

eh, don't think it would necessary..