-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
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
Make a configuration management tool based on Nix to manage User Profiles. #4594
Conversation
[x] NixOS independanant user services(that also work on osx) similar to On Sun, Oct 19, 2014 at 7:50 PM, Nicolas B. Pierron <
-----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFEY1PEBCADPOfERF2wo4qeoq9L1m2z4pKfWqNd4B6BsoFUWPNd7BXmY+9JG |
This is what is implied by mocking NixOS / NixUp in the other, such as a module can work for both. If a module is really modular, and all the needed dependencies are implemented, then this should not be a problem. I am trying to make NixUP modules as modular as possible, by avoiding the mistake I made in NixOS. |
@nbp that sounds really cool and i would really really like to have nixos services modular. Currently i'm trying to use nixos services in docker, but there's currently really no usefull and modular way to use them with docker's model of one service per container. Is there any way i can help you out with that? |
@offlinehacker , as soon as the mock is in place on both sides, the best way would be to add a NixUP back-end to program / services which can support it. One easy way to contribute would be to add a user.resourceFiles where we have environment.etc definitions. |
This is great! It will require some documentation though. |
@nbp I will do this asoap for modules, when schema will be defined, i need this support especially for docker containers and also user services. Are you planning to place all config files from etc to users home, i assume there should be some other folder for etc files. |
I do not intend to share a common option declaration between the 2, as it does not make sense the use "environment.etc" for the resource files of the user. I think that such factorization makes sense once we noticed it in multiple modules, and then we can discuss about a proper name for it. I do not exclude the fact that we would see emerge a common abstraction layer above NixUP & NixOS, typically for services. I just prefer to ignore it for the time being and focus on making good bases for NixUP. The module system gives us a lot of flexibility to build abstractions, so I am not worried about working this way. |
Seems reasonable and I don't see problematic writing modules for both
|
I love the name and I think I love the concept but I'm not sure yet what the concept is 😁. What I do wonder though, is if this is even remotely ready for inclusion into the tree. There are a couple of proposals for declarative user spaces, like #4493 and http://lists.science.uu.nl/pipermail/nix-dev/2014-October/014659.html (which I really like, basically modules are instantiated into services and grouped into environments and then NixOS or NixUP (or Docker or whatever) are responsible for running the environment). Perhaps it would be better to flesh out NixUP some more in a separate repo that users can clone? I for one will try NixUP out-of-tree right now 🍻. |
Another proposal is embedded in comments: #4493 (comment) It sounds somewhat similar to the boxes. In general, I think it's really cool to think of system configuration as a collection of environments to be run. |
When talk with @civodul about 'user services' for Guix today[0], NixUP is a modules-powered derivation having the activate script! [0] https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00698.html |
Yes, this is exactly the same idea as behind NixOS, and Guix (I guess).
Except the login shell, and the activation script, I would not expect any. |
I will make service abstraction layer on nixup, that nixos systemd will be able to reuse. Do you think this is a good way to go? I really need service abstraction layer for user services and docker services, everything else are just hacks to adapt systemd interface for other process managers(docker, supervisord). The idea is to port all relevant services from nixos to nixup and then reuse these in nixos. |
Btw, nixup kinda has two menings, Nix User Profiles and Nix Upstart :D |
Ping? :) |
I am currently doing some clean-up on NixOS, mostly as a way to try a way to include similar work as this one in NixOS (such as within extraUsers). So far you can already use this branch, but the commands might be a bit raw as you would have to basically type manually what is done by nixos-rebuild — without the nix update. I will have to get back to it, and think more on how to make a command line tool which is both similar to
|
👍 |
Does this actually need NixOS? It seems like anything that can run Nix could have its user profiles managed this way. |
@copumpkin good point |
This pull request is made to bootstrap a variant of NixOS, which is dedicated at managing the home directory of users. This new project is called NixUP (Nix User Profile), and the goals are the following:
users.extraUser.<name?>