bug#20381: Interacting with a remote daemon

[ludo@gnu.org (Ludovic Courtès)]

Ricardo Wurmus <ricardo.wurmus@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’.