-
-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: per user activation #1016
Fix: per user activation #1016
Conversation
Following on from #1017 (comment): The original sin, as I see it, is the dependence of activation on the identity of the activating user. Everything will get better (consistency with NixOS, coherent model as a system manager, boot‐time activation, multi‐user systems, …) if we eliminate that. The whole concept of Although I think we’re in complete agreement about the desirable end state, I’m not minded to go with the approach you have here, because it’s a breaking change that doesn’t directly address the root of the problem. Of course, the problem is that addressing the root of the problem is hard. Just ripping out user activation is easy; I have a branch from 2023 lying around that simply migrates uses of The problem, of course, is the part where we rip out functionality that probably the majority of existing nix-darwin configurations use! We need a migration plan. Thankfully, I have one. Unfortunately, it’s a little fussy, the first step can’t be done by an external contributor, and I’ve not been great at doing the time management to get around to putting it into practice. All of this should be written up in more detail and put in an issue rather than being left as a PR comment, but I’ve left this long enough so I want to fill you in on my thinking even if it’s rough. I’m grateful for your offer to help out with the roadmap and hopefully we can actually get started on this soon! For the longest time I was blocked on the fact that there are a lot of moving parts here, the desired end result will inevitably involve breaking existing user configurations, and there are other things we should really fix along the way so that users don’t have to do multiple mass migrations of their configuration. However, talking on Matrix (
At that point, we will have a system with a nicer architecture but an interface that is still confused and somewhat more obviously silly than before. At that point, the task becomes getting rid of There may be some of them that it makes particular sense for us to keep under For modules that just set up a launchd user agent or similar, we could just migrate For that, here’s my thinking:
As you can see, getting to an actually good end‐state here without making people rewrite their entire configurations is… kind of tricky. But just getting rid of user activation and allowing forward‐thinking people to avoid all the stuff we need to change is quite practical, and I will try to get around to doing that soon. Discussing and collaborating on the rest of the owl is definitely something I’m interested in and I’d appreciate your thoughts on the plan in general! |
@emilazy thank you for the detailed comment with your thoughts on this matter. I think a lot of this makes sense. You are certainly right. The first step, regardless of the design choices, should be in getting release branches done. Any changes to user activation should be built on a stable foundation where users can pin their systems to some level of expectation. The idea to create a temporary I think everything else you wrote looks solid and well thought out too. As a still fresh user, I certainly don't have much more to add in this topic and can only thank you for indulging me in my curiosity and desire to build something better. My only hope is that one day mainline nix-darwin will have closer parity to NixOS whereby multi-user configurations are more achievable without resorting to custom forks. I think your plan could get us closer, and from its results I think we could use it as a base to introduce other changes to items like user management that I mention in #1017. I'll go ahead and close this PR since it seems irrelevant given the plan you provided and the incompatibility this PR has to that approach. |
Would partially solve some of the issues around per user activation scripts (ex: #554). Summary of the issue is that
system.defaults
does not get applied to other users on activation. This is because each call todefaults write
must be done by each user for the preferences to actually apply (i.e. root/admin cannot call this on their behalf). The only solution is to run each of thedefaults write
calls withsudo -u
for each configurable user (those within/Users
) to ensuresystem.defaults
are actually applied on the whole system for all users. Note: this means the user runningdarwin-rebuild
must also be in sudoers and capable of usingsudo -u
for each user.I think the real solution for per user scripts is the one discussed elsewhere (ex: #96) and remove them entirely in favor of home-manager. Until that happens though, this is the only method I know to fix activation in a multi-user system for configs that should be applied to all users.