bug#20381: Interacting with a remote daemon

[Ricardo Wurmus]

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!

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.  It would be great if $localstatedir could be overridden at
runtime or if it could default to whatever the daemon uses.

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.

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.)

~~ Ricardo