From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Using a shared Guix store (was RE: [Bio-packaging] testing out guix) Date: Wed, 24 Jun 2015 21:57:59 +0200 Message-ID: <87oak4zxo8.fsf@gnu.org> References: <877fr0i0kl.fsf@mdc-berlin.de> <3784bfce22f4406f8ee2d3affda0474c@exchsrv2.sgc.loc> 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]:40739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7qoS-0006zs-8t for guix-devel@gnu.org; Wed, 24 Jun 2015 15:58:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7qoP-0000Um-2B for guix-devel@gnu.org; Wed, 24 Jun 2015 15:58:24 -0400 In-Reply-To: <3784bfce22f4406f8ee2d3affda0474c@exchsrv2.sgc.loc> (Malcolm Cook's message of "Fri, 19 Jun 2015 17:48:55 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: "Cook, Malcolm" Cc: Guix-devel , 'Pjotr Prins' , "'bio-packaging@mailman.open-bio.org'" Hi, "Cook, Malcolm" skribis: >> > Can anyone elaborate a little on what are the obstacles to having >> > `/gnu` mounted read-write network wide? >>=20 >> Yes, the primary problem is that the daemon assumes that it is the only = thing >> writing to the store and the localstatedir. Any modification of profile= s and >> the store goes through the daemon. >> > If so, might this be mitigated using a variant off of "Using the >> > Offload Facility" >> > (http://www.gnu.org/software/guix/manual/guix.html#Daemon-Offload- >> Setu >> > p) in which builds would still be offloaded (and thus subject to >> > coordination), with the elimination of the need for " Missing >> > prerequisites for the build are copied over SSH to the target machine, >> > which then proceeds with the build; upon success the output(s) of the >> > build are copied back to the initial machine" since they would be done >> > through the shared file system? >>=20 >> Something like that has been suggested before: if the daemon were to >> accept authenticated connections from the outside rather than to just li= sten >> on a local socket we could have remote guix clients connecting to the ce= ntral >> daemon. > > Hmm. So, for now, I could just teach users to, i.e., `ssh ${USER}@${GUIX= _HOST} /path/to/guix package -r lua -i guile guile-cairo` and contrive fo= r GUIX_HOST to be defined for them. > > Or, wrap it up even further, and contrive for everyone to have the follow= ing in their env: > > alias guixpkg=3D'ssh ${USER}@${GUIX_HOST} /path/to/guix package' > > ?? That=E2=80=99s a possibility. Another one, which I think Ricardo has been investigating lately, would be to have users manage their profiles via the Web user interface, guix-web: . (The video has a demo starting at around 23mn.) >> Currently our users are okay with that, probably to a large part because= they >> are not yet aware of all the features of Guix. They are only used to >> management by sysadmins or manual compilation, so they are not >> inconvenienced. >>=20 >> Ultimately, the correct fix is to allow remote guix clients to communica= te with >> a central guix daemon. The daemon does not even need to be aware of >> remote connections if guix clients can transparently connect via SSH and= send >> RPCs to the socket. This is not yet implemented. > > Sounds great. On the roadmap? Definitely. There are details to be sorted out (SSH vs. plain old socket), but we should discuss it and =E2=80=9Cget it done.=E2=80=9D Thanks for your feedback, Ludo=E2=80=99.