Ludovic Courtès <[email protected]> writes: > What about installing Guix in /gnu/bin (say) and sharing it over NFS? > > I would avoid installing Guix in a profile, because if things go wrong, > you may find yourself unable to do anything. In practice, you can > always roll-back by hand (it’s simply a matter of switching the > profiles/per-user/$USER symlink), but still. > >> It would be great if $localstatedir could be overridden at runtime or >> if it could default to whatever the daemon uses. > > Actually it can be overridden via the intentionally-undocumented > NIX_STATE_DIR environment variable (see (guix config).)
Oh, nice. Installing Guix somewhere into /gnu is actually a pretty good idea. I’ll try that and play with NIX_STATE_DIR as well. >> This would probably work fine if I limited the socket forwarding to just >> the cluster nodes, because only there user ids are guaranteed to be >> correct (not on workstations). On workstations that are not centrally >> managed this will not work, as the user ids could be arbitrary and it >> would thus allow anyone to change anyone else’s profile by creating a >> local account with the appropriate uid. > > The only problem would be with ‘guix package’, which you haven’t > mentioned yet. :-) For ‘guix package’ to work, > /gnu/var/guix/profiles/per-user must be shared read-write (over NFS) > with correct UID mapping. Correct. I haven’t tried ‘guix package’ at all because I just assumed it would work. > I think we should have a “Cluster Setup” section in the manual to > explain all this. Would you like to give it a try? Sounds like a good idea. I can give it a try but I’ll be on vacation for a while and can only get around to writing in a couple of weeks. But I think I’m a good candidate for drafting this section, given that I’ve got a cluster to play with :) Thanks for your helpful recommendations! ~~ Ricardo
