From: Efraim Flashner <efraim@flashner.co.il>
To: "Etienne B. Roesch" <etienne.roesch@gmail.com>
Cc: help-guix@gnu.org, guix-science@gnu.org
Subject: Re: guix on nfs based systems
Date: Sun, 26 Nov 2023 09:33:45 +0200 [thread overview]
Message-ID: <ZWL02SOsX7l38AyM@3900XT> (raw)
In-Reply-To: <CAPX-MzDQFpfZsu8CRsxUL4M-xSYb13sxm1O4LVVHLPdPmLk6QA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3292 bytes --]
On Thu, Nov 23, 2023 at 09:41:56AM +0000, Etienne B. Roesch wrote:
>
> On Thu, Nov 23, 2023 at 6:32 AM Efraim Flashner <efraim@flashner.co.il>
> wrote:
>
> > On Wed, Nov 22, 2023 at 05:32:07PM +0000, Etienne B. Roesch wrote:
> > > Hi,
> > >
> > > I have been successful in convincing our IT dept to provide guix as
> > > standard on our vms and research clusters. We use this sophisticated
> > > platform that allows users to spawn a vm at will, and also use this
> > shared
> > > ldap user database to allow for people to log on from computers/terminals
> > > spread on campus. Home directories are basically pulled from the OS
> > (mostly
> > > ubuntu and centos) as a shared file system on the network, which then
> > > synchronises changes live. Practically, that means a user will find its
> > > desktop, preferences and files as they move to different computers.
> > >
> > > Theoretically, a user can connect to several computers at the same time,
> > > which can lead to conflict issues at times, e.g. firefox doesn't like
> > > parallel access to its preferences. I haven't fully tested it, but we
> > think
> > > that a guix profile is specific to a given computer, because of the way
> > it
> > > links to the store, which is (currently) local to the vm, which isn't
> > > ideal: the whole point of using vms is for users to kill them when they
> > > don't need them.
> > >
> > > What would be the recommended way of solving this? Has anybody had a
> > > similar situation?
> > > I am thinking we could either:
> > > - leave it as is, and train users to recreate their profiles whenever
> > they
> > > use a new vm/computer (after all, that's what guix is for) but it could
> > > take some time to recompile if binaries aren't available
> > > - maybe turn /gnu/store as a shared nfs folder
> >
> > CCing guix-science
> >
> > One thing we do on the small cluster at UTenn is /gnu and /var/guix (in
> > addition to the home directories) are exported across NFS and then any
> > profiles that are installed in the users' home directories have their
> > symlinks not dangling.
> >
> > I also have a snippet in my .profile to use GUIX_DAEMON_SOCKET to ssh
> > back to the head node to use the guix-daemon there, which keeps all the
> > guix stuff on one machine and easier to manage and make sure the same
> > software is available on all the machines.
> >
> Thanks! That's really helpful! How robust is your system to bandwidth
> fluctuations and network hiccups?
> How big is your store, /gnu, /var/guix?
>
> How many users do you have?
>
> Etienne
We have about a dozen users, with about 100GB for /gnu. It'd probably be
better with a larger store, but that's what we've partitioned for it.
/var/guix is rather small and not really worth worrying about.
We started with gigabit ethernet which seems to be fast enough for
accessing files from /gnu/store but could be faster when it comes to the
shared storage so we have a local scratch SSD on each system for local
files while doing computations.
--
Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-11-26 7:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPX-MzA5P1A8u8QbR-g-Lx4gONQ+o7mO1TZzhZ3UHh=KdUxhvw@mail.gmail.com>
2023-11-23 6:32 ` guix on nfs based systems Efraim Flashner
2023-11-23 9:41 ` Etienne B. Roesch
2023-11-26 7:33 ` Efraim Flashner [this message]
2023-12-14 14:41 ` Ricardo Wurmus
2023-11-23 13:03 ` Felix Lechner via
2023-11-23 13:03 ` Felix Lechner via Guix-Science
2023-11-24 18:08 ` Etienne B. Roesch
2023-11-26 7:36 ` Efraim Flashner
2023-12-13 10:17 ` Etienne B. Roesch
2023-12-14 14:46 ` Ricardo Wurmus
2023-12-14 15:28 ` Etienne B. Roesch
2023-12-14 15:33 ` Pierre-Antoine Bouttier
2023-12-14 15:33 ` Pierre-Antoine Bouttier
2023-12-14 15:57 ` Etienne B. Roesch
2023-12-14 19:35 ` [ext] " Ricardo Wurmus
2024-02-15 16:14 ` Simon Tournier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZWL02SOsX7l38AyM@3900XT \
--to=efraim@flashner.co.il \
--cc=etienne.roesch@gmail.com \
--cc=guix-science@gnu.org \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).