From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cook, Malcolm" Subject: RE: Using a shared Guix store (was RE: [Bio-packaging] testing out guix) Date: Wed, 8 Jul 2015 18:03:35 +0000 Message-ID: <1436378615368.30302@stowers.org> References: <877fr0i0kl.fsf@mdc-berlin.de> <3784bfce22f4406f8ee2d3affda0474c@exchsrv2.sgc.loc> <87oak4zxo8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCthB-0005H9-4O for guix-devel@gnu.org; Wed, 08 Jul 2015 14:03:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCth6-0005XX-0z for guix-devel@gnu.org; Wed, 08 Jul 2015 14:03:45 -0400 In-Reply-To: <87oak4zxo8.fsf@gnu.org> Content-Language: en-US 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: =?Windows-1252?Q?Ludovic_Court=E8s?= Cc: Guix-devel , 'Pjotr Prins' , "'bio-packaging@mailman.open-bio.org'" Hi!=0A= =0A= > >> > Can anyone elaborate a little on what are the obstacles to having=0A= > >> > `/gnu` mounted read-write network wide?=0A= > >>=0A= > >> Yes, the primary problem is that the daemon assumes that it is the=0A= > >> only thing writing to the store and the localstatedir. Any=0A= > >> modification of profiles and the store goes through the daemon.=0A= > >> > If so, might this be mitigated using a variant off of "Using the=0A= > >> > Offload Facility"=0A= > >> > (http://www.gnu.org/software/guix/manual/guix.html#Daemon-=0A= > Offload-=0A= > >> Setu=0A= > >> > p) in which builds would still be offloaded (and thus subject to=0A= > >> > coordination), with the elimination of the need for " Missing=0A= > >> > prerequisites for the build are copied over SSH to the target=0A= > >> > machine, which then proceeds with the build; upon success the=0A= > >> > output(s) of the build are copied back to the initial machine"=0A= > >> > since they would be done through the shared file system?=0A= > >>=0A= > >> Something like that has been suggested before: if the daemon were to= =0A= > >> accept authenticated connections from the outside rather than to just= =0A= > >> listen on a local socket we could have remote guix clients connecting= =0A= > >> to the central daemon.=0A= > >=0A= > > Hmm. So, for now, I could just teach users to, i.e., `ssh=0A= > ${USER}@${GUIX_HOST} /path/to/guix package -r lua -i guile guile-cairo`= =0A= > and contrive for GUIX_HOST to be defined for them.=0A= > >=0A= > > Or, wrap it up even further, and contrive for everyone to have the=0A= > following in their env:=0A= > >=0A= > > alias guixpkg=3D'ssh ${USER}@${GUIX_HOST} /path/to/guix package'=0A= > >=0A= > > ??=0A= > =0A= > That=92s a possibility.=0A= =0A= Thanks for the confirmation. I'm thinking of trying this for the "short te= rm" - unless Ricardo's efforts bear fruit sooner.=0A= =0A= > Another one, which I think Ricardo has been investigating lately, would b= e to=0A= > have users manage their profiles via the Web user interface,=0A= > guix-web: . (The video=0A= > 01__GNU_Guix__The_Emacs_of_Distros.webm>=0A= > has a demo starting at around 23mn.)=0A= =0A= Hmm, it is not clear to me how this would play out in a multi-user environm= ent. Having a web server that could alter per-user profiles sounds like a = recipe for more confusion, rather than a solution.=0A= =0A= In any case, in my opinion, it would be a mistake to have depend on another= tool (such as guix-web, or something similar) to implement functionality t= hat could not be gained at using command-line guix. Don't you agree?=0A= =0A= > >> Currently our users are okay with that, probably to a large part=0A= > >> because they are not yet aware of all the features of Guix. They are= =0A= > >> only used to management by sysadmins or manual compilation, so they=0A= > >> are not inconvenienced.=0A= > >>=0A= > >> Ultimately, the correct fix is to allow remote guix clients to=0A= > >> communicate with a central guix daemon. The daemon does not even=0A= > >> need to be aware of remote connections if guix clients can=0A= > >> transparently connect via SSH and send RPCs to the socket. This is no= t yet=0A= > implemented.=0A= > >=0A= > > Sounds great. On the roadmap?=0A= > =0A= > Definitely. There are details to be sorted out (SSH vs. plain old socket= ), but=0A= > we should discuss it and =93get it done.=94=0A= =0A= Are there any signposts on this road-map emerging? Is there any way I can = help, such as review proposals for how the CLI would work, I'd be happy to = chip in. Not ready to start slinging guile though. Maybe later (the old l= isper in me revels at the thought).=0A= =0A= > Thanks for your feedback,=0A= > Ludo=92.=0A= =0A= Thanks for GUIX!=0A= =0A= ~Malcolm=