Enable users thanks to userborn #266
Conversation
|
Great stuff! I have some minor questions, maybe we can have a chat tomorrow? |
|
This might be an issue though: https://github.com/nikstur/userborn/blob/main/rust%2Fuserborn%2Fsrc%2Fmain.rs#L129-146 |
I agree. I am not sure I 100% understand how userborn handles "impure" users/groups, I am trying to get a better understanding. |
|
I have just realized that we end with a broken /etc/passwd (as we don't have /run/current-system [yet?]): |
There is an equivalent directory, but not the same because we want to support running system manager on nixos (mainly for easier testing). |
|
Interesting, I wonder where this thing is set in the module system. I wouldn't expect this to be hardcoded neither in userborn or in the users module, will check. |
To this point, this is correct. I just pushed a commit with a failing test case that covers this issue. I also have a modification of userborn for which the test case succeeds, that I'll be submitting today upstream. |
To this point, I see that we can change the |
|
Userborn change that introduces stateful users is submitted upstream: nikstur/userborn#36 |
Eval works. Work done until now: - add missing `system.etc` and `systemd.sysusers` options. - vendored nixpkgs/nixos/modules/config/users-groups.nix and comment `boot.initrd` and `environment.profiles` configs. - import user ids and userborn modules from nixpkgs. Currently failing on: vm-test> [2025-08-26T09:45:23Z INFO system_manager::activate::etc_files] Done vm-test> [2025-08-26T09:45:23Z INFO system_manager::activate] Activating tmp files... vm-test> /etc/tmpfiles.d/home-directories.conf:1: Failed to resolve user 'zimbatm': No such process Most probably because we don't create the users/group before trying to create tmpfiles. This PR is based on #258 because `user-groups.nix` and `userborn.nix` depend on `system.activationScripts`.
This new test impurely add a new user to the system and verifies that the user is not garbage collected by userborn.
This reverts commit 461de1a.
Add a stub option for system.activationScripts.users to satisfy nixos/modules/services/system/userborn.nix dependency without importing the full activationScripts module.
Check that user created outside of userborn is not locked on deactivation, while userborn-managed users are locked.
mutable users handling has been merged into userborn with nikstur/userborn#38 This commit update system-manager to use the new userborn features and properly sequence userborn execution during activation and deactivation. System manager ensure users exist before tmpfiles runs and managed accounts are locked on deactivation. Activation changes: - Restart userborn.service after daemon-reload but before tmpfiles - Use restart (not start) because userborn is a oneshot service with RemainAfterExit=true - start on an already-active service is a no-op Deactivation changes: - Move user locking logic from Nix shell script to Rust engine - Add users.rs module with lock_managed_users() that calls userborn with empty config to lock previously managed accounts - Set USERBORN_MUTABLE_USERS=true so only managed users are locked, not stateful users created outside userborn - Create top-level deactivate.rs module for cleaner API naming
|
Thank you @jfroche for getting this past the finish line! I had a read at the code, looks good + test are passing! |
Note: This is still a WIP
Essentially, we load the userborn module, and add the
sysinit-reactivationtarget in a similar manner to NixOS. We restart that target at the beginning of the activation.I also tried stripping the activationScripts feature from this PR but without much success so far.