From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#20381: Interacting with a remote daemon Date: Fri, 10 Jul 2015 19:48:50 +0200 Message-ID: <87h9pbaoot.fsf@gnu.org> References: <87a8y3q84k.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDcR3-00055m-3m for bug-guix@gnu.org; Fri, 10 Jul 2015 13:50:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDcR1-0003Kh-0R for bug-guix@gnu.org; Fri, 10 Jul 2015 13:50:05 -0400 Received: from debbugs.gnu.org ([140.186.70.43]:44949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDcR0-0003Jk-UA for bug-guix@gnu.org; Fri, 10 Jul 2015 13:50:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZDcR0-0000Wn-G3 for bug-guix@gnu.org; Fri, 10 Jul 2015 13:50:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: (Ricardo Wurmus's message of "Fri, 10 Jul 2015 12:42:57 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Ricardo Wurmus Cc: 20381@debbugs.gnu.org Ricardo Wurmus 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 =E2=80=98/gnu=E2=80=99 (with $localstatedir set to =E2=80=98/gnu/= var=E2=80=99) is mounted as > read-write I executed this: > > /root/.guix-profile/bin/socat TCP4-LISTEN:9999 UNIX:/gnu/var/guix/dae= mon-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=3D$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 =E2=80=9Cguix=E2=80=9D command available on cluster nodes I j= ust installed > it into my default user profile as =E2=80=98~/.guix-profile/bin/guix=E2= =80=99. The > problem with this is that profile commands don=E2=80=99t work as the regu= lar > =E2=80=9Cguix=E2=80=9D package as installed with $localstatedir set to = =E2=80=98/var=E2=80=99. This can > be fixed, of course, (e.g. by creating a slightly different =E2=80=9Cguix= =E2=80=9D > package with the appropriate configure flags set) but it=E2=80=99s 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=E2=80=99s 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=E2=80=99s profile by creati= ng a > local account with the appropriate uid. The only problem would be with =E2=80=98guix package=E2=80=99, which you ha= ven=E2=80=99t mentioned yet. :-) For =E2=80=98guix package=E2=80=99 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 =E2=80=9Cguix=E2=80=9D remo= tely through an > SSH connection, because with socat the =E2=80=9Cguix=E2=80=9D command can= actually be > used to spawn a new local shell with =E2=80=9Cguix environment=E2=80=9D, = which is very > useful. I don=E2=80=99t think this would work if =E2=80=9Cguix=E2=80=9D = were just run > remotely. (Please correct me if I=E2=80=99m wrong about this.) Indeed, that would only allow you to spawn a shell on the machine where the =E2=80=98guix=E2=80=99 command is executed (which, in your case, is not= a compute node AIUI.) I think we should have a =E2=80=9CCluster Setup=E2=80=9D section in the man= ual to explain all this. Would you like to give it a try? Ludo=E2=80=99.