From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:5f26::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id sIvWFSQme2WSvgAAkFu2QA (envelope-from ) for ; Thu, 14 Dec 2023 16:58:28 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id iJUlEiQme2U7oQAAqHPOHw (envelope-from ) for ; Thu, 14 Dec 2023 16:58:28 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="PeXUc8Y/"; spf=pass (aspmx1.migadu.com: domain of "guix-science-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-science-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1702569508; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=8gdS8c9+k1Wq6oD6yqrQmGJTGFTibx75XGuNS8/2+PA=; b=s71sCQQi3DNQsZ+chRucV/4LS11ldr3m+GcaCD/l9MhAUXMAMndlNrYXpOTN5lOWZYXfQc JKVialoDkH/x6dBaJbYpaX5WITn52MHJCNOlQC7tLu/ymkbo+wACr++KO38ytxGxqOJLOp o6eetR1r7/WD36mBSHnagMeZZc7TpBd7gkED89IKlAm0/VIwRimdylZPz9L/baENP87fqo A9DuLllqpj1I+5qHM72q1YqDnkAJ91mPXqXnc+MBCRc3sr3N/wC3AhY+UNw3I39TEZwV8z eLb8BAuVjY8DfBtQy3mEqzpth38cLuOzmDFz9it/apoiQ2b5Ze/24enBsQs4qw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1702569508; a=rsa-sha256; cv=none; b=DVv6Rs3xTHzoLpyxSSzCu5bwZZ0sR60NJPVw6CvmpeF2imwOVPMMpIRh1VM2X1k/8071he ppwGOC1P3H3gUgeFshfFyU9RE8UyAOVNU/tEOlcCokqUlflmiLj63qV6jqgZymPNpd8c9I PE8npHpsPdbnuSkv5qG0n1wmJB4pIDB/nvBl6Fcv9qjLOMU0iR7Ys+zSPCvvLp67WxRUpi V0rm0pYtQgi88Nm/h36MBBS5Yp5Nss+0u9e13qJ859bEZXE8hA0IXy8VCTvmkq6UC1jbYo JmHAll3dCwgYmj0SfDyvTOB/RC5doGikp3HQ1471EeGr2YGar2ZdGLHypq164Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="PeXUc8Y/"; spf=pass (aspmx1.migadu.com: domain of "guix-science-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-science-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id EFDF913FAB for ; Thu, 14 Dec 2023 16:58:27 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rDo67-0001Rz-RL; Thu, 14 Dec 2023 10:58:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rDo65-0001Ql-6h; Thu, 14 Dec 2023 10:58:01 -0500 Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rDo62-0007UC-Mi; Thu, 14 Dec 2023 10:58:00 -0500 Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-28aeb049942so1758186a91.2; Thu, 14 Dec 2023 07:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702569477; x=1703174277; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8gdS8c9+k1Wq6oD6yqrQmGJTGFTibx75XGuNS8/2+PA=; b=PeXUc8Y/4QQTwEA6RJMO1PzE8toJW+p91QtE8Yi5MuLKud/wn/IeF8zbyjh+dwNUa6 wy0uyJKCPhA+XaMZI73MBf3GBspXRCCefwjnhE86AHi/8S/5Bv1Uts62G6JAxcwmF+3E RP9NPFhPdev+7fWwSxZA96BSXHj3bN6NNNGIZ7ovtr15jQP/N4GpgjBSwveNGTh0O1dw 8nsrw/VXZQ7dBUZSFC7gBUdrSA/1XXk7ZTEadMQmtvD1Q+ejge8E6oGoHnt8B7MPeHP0 M18NGdOIIF47IItcKdP95tNJBi/Dm06W7gvnjX+V0YwKV0JuzUDvZLAEbPGjNW6K0bD9 7/wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702569477; x=1703174277; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8gdS8c9+k1Wq6oD6yqrQmGJTGFTibx75XGuNS8/2+PA=; b=sQ4Y56Ho2Dnr74w1EkcNtWfpRjYz3fv3jr5AhNwO4Xl97dn3viTrXqFDAmV4Gckyk4 4m+I5aXprmhLib/pZA9h0/JLXxaEE95B4ebbb1Jn7A+FyLjuPqB1A5/+wLBgAtpZe4BK UI3nXUKEt35p4VlXClbiX7QF+J1QR42BmMSi2yjuPbtQvGkLYdLrgtBfRxpYMYhnE6Zy iqPnOHDJNYFmLYk8ovzkLaxZwOa3rU89TA+r43Yv7ZOsZuEu6sT0DCefd9wySW75cNd8 DyfpaSpjb4MGcxQmulIPXsuvErG6OXilVbDu9A8V/KZfSKrVNzJIz9I0toq/GI+ey6cF KhFg== X-Gm-Message-State: AOJu0YwpKniGRcwmCYRhuDx5mfTecTwHoU07NOFUt0/UDOpVHLobYx2Y IXKFpls465J0gYSTr8dduI6dQif9AGNFTw0OgTIjJj8PA3g= X-Google-Smtp-Source: AGHT+IEsevMHs+scnyPVEAB28KVvK6bNKp6BO0jOtTbWZ2jmbG7jxjmFsFwFVgYIdPzI5+oNB6ADkS/0M54jtnKxzY4= X-Received: by 2002:a17:90a:72c4:b0:28b:cef:3ad3 with SMTP id l4-20020a17090a72c400b0028b0cef3ad3mr681591pjk.23.1702569476485; Thu, 14 Dec 2023 07:57:56 -0800 (PST) MIME-Version: 1.0 References: <87pm00mxkg.fsf@lease-up.com> <87plz8alhc.fsf@mdc-berlin.de> In-Reply-To: From: "Etienne B. Roesch" Date: Thu, 14 Dec 2023 15:57:45 +0000 Message-ID: Subject: Re: guix on nfs based systems To: Pierre-Antoine Bouttier Cc: Ricardo Wurmus , Felix Lechner , help-guix@gnu.org, guix-science@gnu.org Content-Type: multipart/alternative; boundary="000000000000d9f780060c7a5843" Received-SPF: pass client-ip=2607:f8b0:4864:20::1032; envelope-from=etienne.roesch@gmail.com; helo=mail-pj1-x1032.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-science@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-science-bounces+larch=yhetil.org@gnu.org Sender: guix-science-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.51 X-Spam-Score: -9.51 X-Migadu-Queue-Id: EFDF913FAB X-Migadu-Scanner: mx12.migadu.com X-TUID: CKX9dQzIQ47s --000000000000d9f780060c7a5843 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oops, my bad, I seemed to have hit Reply, instead of Reply-all. Here is the follow up to that email: *Etienne B. Roesch > 3:42=E2=80=AFPM (12 minutes ago) to Pierre-Antoine* Merci Pierre-Antoine ! :) It sounds like you also made the conscious choice of using guix shells, instead of profiles. Why is that? I am guessing profiles have a more widespread impact on what's available to the user, modifying paths and so on, whereas shells would be more contained and short-lived, and therefore "safer" for users? I'll have to write documentation and train users either way ;) Etienne *Pierre-Antoine Bouttier 3:47=E2=80=AFPM (7 minutes ago) to me* > Merci Pierre-Antoine ! :) My pleasure :) > It sounds like you also made the conscious choice of using guix shells, instead of profiles. > Why is that? Because > I am guessing profiles have a more widespread impact on what's available to the user, > modifying paths and so on, whereas shells would be more contained and short-lived, and > therefore "safer" for users? ;) Yes, indeed, the isolated and self-contained aspect of guix shell avoid to mess with environment variables. And it=E2=80=99s far more easier, in a reproducibility point of view, with manifest.scm and channels.scm to explain to users how to work with guix time-machine and guix shell. But, our users can use guix profile (and some of them don=E2=80=99t hold ba= ck). P-A On Thu, Dec 14, 2023 at 3:33=E2=80=AFPM Pierre-Antoine Bouttier < Pierre-Antoine.Bouttier@univ-grenoble-alpes.fr> wrote: > Hi Etienne, > > The issue with profiles you are mentioning is interesting; I haven't quit= e > thought it through yet. I think I would personally want users to be able = to > create profiles (for reproducibility reasons) but I guess it would work t= he > same way with guix shells built from manifests, maybe slightly less easy = to > interact with, I don't know. > > > As part of the support team in a HPC center that provides guix command to > our users to set up their software environments, we advice them to use gu= ix > shell rather than guix profile and most of them are pretty happy with tha= t. > Obviously, you need to write a good documentation :) > > My 2 cents > P-A > --- > Pierre-Antoine Bouttier > CNRS Research Engineer > Dir. Adj. UAR GRICAD > > GriCAD - https://gricad.univ-grenoble-alpes.fr/ > Batiment IMAG > CS 40700 > 38058 Grenoble CEDEX 9 > > +33 4 57 42 18 66 > > Le 14 d=C3=A9c. 2023 =C3=A0 16:28, Etienne B. Roesch a > =C3=A9crit : > > Thanks a ton! > > I think we've arrived at the limit of how I understand the daemon to work= , > and GUIX_DAEMON_SOCKET. I think I understand that you are using a single > node (hpc of sort I imagine), where users create sessions, and within whi= ch > you provide the guix command, having set up GUIX_DAEMON_SOCKET to a > unix-domain socket (to that same node / itself). That makes total sense i= n > the context of the single node. Did I get that right? > > I think what we are aiming for, in our case (where users each have their > own nodes as it were, only sharing network drives), is providing the guix > command on each node, set up with GUIX_DAEMON_SOCKET connecting with ssh = to > a master node with a daemon, that itself would have access to the same > network drives. > > > Etienne > > On Thu, Dec 14, 2023 at 2:48=E2=80=AFPM Ricardo Wurmus < > ricardo.wurmus@mdc-berlin.de> > wrote: > > > "Etienne B. Roesch" writes: > > Hiccups: we provide home dirs as nfs drives through the network. Using > > guix, we are thinking of creating one nfs drive, shared by all > > users, to contain /var/guix and /gnu/store, symlinked from /. > As I understand, that should work, until a user decides to run "guix gc" > > (which would clear wrongly assumed unused profiles) or maybe > > until a user decides to launch several vms (which is theoretically > > possible, but doesn't happen often). > > I would strongly discourage the use of profiles in users=E2=80=99 home > directories. When introducing Guix we now only demo =E2=80=9Cguix shell= =E2=80=9D, which > is preferrable in most cases. =E2=80=9Cguix gc=E2=80=9D is problematic w= hen profile > links are in locations that the daemon cannot read. > > Efraim suggested using a shared daemon ssh-ing GUIX_DAEMON_SOCKET. We > would probably run this on a separate vm. We are however unsure how it > would behave when /var/guix/daemon-socket/socket is itself on an nfs. > > > We only export /var/guix/profiles, not anything else in /var/guix. > Using GUIX_DAEMON_SOCKET with a network port (make =E2=80=9Cguix-daemon= =E2=80=9D listen > on that port) is all we ever needed. > > -- > Ricardo Wurmus > > System administrator > BIMSB - Scientific Bioinformatics Platform > Max Delbrueck Center for Molecular Medicine > > email: ricardo.wurmus@mdc-berlin.de > tel: +49 30 9406 1796 > > > --000000000000d9f780060c7a5843 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oops, my bad, I seemed to have hit Reply, instead of Reply= -all.

Here is the follow up to that email:
Etienne B. Roesch <etienne.roesch@gmail.com> 3:42=E2=80=AFPM (12 minutes ago) to = Pierre-Antoine

Merci Pierre-Antoine ! :)

It sounds like y= ou also made the conscious choice of using guix shells, instead of profiles= . Why is that? I am guessing profiles have a more widespread impact on what= 's available to the user, modifying paths and so on, whereas shells wou= ld be more contained and short-lived, and therefore "safer" for u= sers?

I'll have to write documentation and train users either wa= y ;)

Etienne


Pierre-Antoi= ne Bouttier 3:47=E2=80=AFPM (7 minutes ago) to me

> Merci Pie= rre-Antoine ! :)

My pleasure :)

> It sounds like you also = made the conscious choice of using guix shells, instead of profiles.
<= div>> Why is that?

Because=C2=A0

> I= am guessing profiles have a more widespread impact on what's available= to the user,
> modifying paths and so on, whereas shells woul= d be more contained and short-lived, and
> therefore "saf= er" for users?

;)

Yes, indeed, the isolated and self-con= tained aspect of guix shell avoid to mess with environment variables. And i= t=E2=80=99s far more easier, in a reproducibility point of view, with manif= est.scm and channels.scm to explain to users how to work with guix time-mac= hine and guix shell.

But, our users can use guix profile (and some = of them don=E2=80=99t hold back).

P-A

On Thu, Dec 14, 2023= at 3:33=E2=80=AFPM Pierre-Antoine Bouttier <Pierre-Antoine.Bouttier@univ-grenobl= e-alpes.fr> wrote:
Hi Etienne,=C2=A0

The issue with profiles you are mentioning is interesting; I have= n't quite
thought it through yet. I think I would personally want us= ers to be able to
create profiles (for reproducibility reasons) but I gu= ess it would work the
same way with guix shells built from manifests, ma= ybe slightly less easy to
interact with, I don't know.

As part of the support team in a HPC center that provides= guix command to our users to set up their software environments, we advice= them to use guix shell rather than guix profile and most of them are prett= y happy with that.=C2=A0
Obviously, you need to write a good docu= mentation :)

My 2 cents
P-A
<= div style=3D"line-break:after-white-space">
---
Pierre-Antoine Bouttier
= CNRS Research Engineer
Dir. Adj. UAR GRICAD

GriCAD - https://gricad.uni= v-grenoble-alpes.fr/
Batiment IMAG
CS 40700
38058 Grenoble CED= EX 9

+33 4 57 42 18 =C2=A066

Le 14 d=C3=A9c. 2023 =C3=A0 16:28, = Etienne B. Roesch <etienne.roesch@gmail.com> a =C3=A9crit :

Thanks a ton!

I think we've arrived at the limit of how I under= stand the daemon to work,
and GUIX_DAEMON_SOCKET. I think I understand t= hat you are using a single
node (hpc of sort I imagine), where users cre= ate sessions, and within which
you provide the guix command, having set = up GUIX_DAEMON_SOCKET to a
unix-domain socket (to that same node / itsel= f). That makes total sense in
the context of the single node. Did I get = that right?

I think what we are aiming for, in our case (where users= each have their
own nodes as it were, only sharing network drives), is = providing the guix
command on each node, set up with GUIX_DAEMON_SOCKET = connecting with ssh to
a master node with a daemon, that itself would ha= ve access to the same
network drives.


Etienne

On Thu, = Dec 14, 2023 at 2:48=E2=80=AFPM Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de&= gt;
wrote:


"Etienne B. Roesch&= quot; <eti= enne.roesch@gmail.com> writes:

Hicc= ups: we provide home dirs as nfs drives through the network. Using
guix, we are thinking of creating one nfs drive, shared by all
<= blockquote type=3D"cite">users, to contain /var/guix and /gnu/store, symlin= ked from /.
As I understand, that should work, until a user decides to r= un "guix gc"
(which would clear wrongly assumed u= nused profiles) or maybe
until a user decides = to launch several vms (which is theoretically
possible, but= doesn't happen often).

I would strongly discourage the use of p= rofiles in users=E2=80=99 home
directories.=C2=A0 When introducing Guix = we now only demo =E2=80=9Cguix shell=E2=80=9D, which
is preferrable in m= ost cases. =C2=A0=E2=80=9Cguix gc=E2=80=9D is problematic when profile
l= inks are in locations that the daemon cannot read.

Efraim suggested using a shared daemon ssh-ing GUIX_DAEMON_SOCKET= . We
would probably run this on a separate vm. We are however unsure how= it
would behave when /var/guix/daemon-socket/socket is itself on an nfs= .

We only export /var/guix/profiles, not anything else = in /var/guix.
Using GUIX_DAEMON_SOCKET with a network port (make =E2=80= =9Cguix-daemon=E2=80=9D listen
on that port) is all we ever needed.
<= br>--
Ricardo Wurmus

System administrator
BIMSB - Scientific B= ioinformatics Platform
Max Delbrueck Center for Molecular Medicine
email: = ricardo.wurmus@mdc-berlin.de
tel: =C2=A0=C2=A0+49 30 9406 1796

= --000000000000d9f780060c7a5843--