Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> skribis: > I just tried the socat idea[1] with some success. > > On the guix-builder host where guix-daemon is running and the NFS share > holding ‘/gnu’ (with $localstatedir set to ‘/gnu/var’) is mounted as > read-write I executed this: > > /root/.guix-profile/bin/socat TCP4-LISTEN:9999 > UNIX:/gnu/var/guix/daemon-socket/socket > > On a cluster node where /gnu is mounted read-only I ran this: > > socat UNIX-LISTEN:/home/rwurmus/foo TCP4:guix-builder:9999 & > export GUIX_DAEMON_SOCKET=$HOME/foo > > At this point I could use > > guix build hello > guix environment hello > > which is really great!
Excellent, thanks for testing! > To make the “guix” command available on cluster nodes I just installed > it into my default user profile as ‘~/.guix-profile/bin/guix’. The > problem with this is that profile commands don’t work as the regular > “guix” package as installed with $localstatedir set to ‘/var’. This can > be fixed, of course, (e.g. by creating a slightly different “guix” > package with the appropriate configure flags set) but it’s still a minor > annoyance. 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).) > 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. > I prefer the socat approach over just running “guix” remotely through an > SSH connection, because with socat the “guix” command can actually be > used to spawn a new local shell with “guix environment”, which is very > useful. I don’t think this would work if “guix” were just run > remotely. (Please correct me if I’m wrong about this.) Indeed, that would only allow you to spawn a shell on the machine where the ‘guix’ command is executed (which, in your case, is not a compute node AIUI.) I think we should have a “Cluster Setup” section in the manual to explain all this. Would you like to give it a try? Ludo’.