[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ~/.config/guix/current

From: Ludovic Courtès
Subject: Re: ~/.config/guix/current
Date: Thu, 12 Jul 2018 10:26:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hello Mikhail,

Mikhail Kryshen <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>>> a) master node running guix-daemon [1]
>>>    - will "guix gc" destroy guix/current profiles if /home is not
>>>    mounted on the master node?  What if some users have local
>>>    home directories and some are on nfs?
>>> [1] 
>> This is what I would recommend, and as the post suggests, you’ll have to
>> make sure home directories are visible to guix-daemon, which means
>> having them mounted on the master node.
>> If you don’t do that, there’s a risk that user-pulled Guixes will be
>> reclaimed prematurely, simply because the GC won’t see that they are
>> still “live.”
> But ~root is local on each machine, so root-pulled Guix will still not
> be protected from gc.

True, but in this configuration, only the root account of the master
node really matters, and it’s protected from GC.

> Btw, is option a) possible on GuixSD?

I think so.  Why wouldn’t it?

>>> b) guix-daemon on every computer
>>>    - then /gnu/store and /var/guix/profiles will by local and user
>>>    profiles can be different on every computer, but
>>>    ~/.config/guix/current will link to nonexistent store item if
>>>    "guix pull" was invoked by the same user on a different machine.
>> If this is a cluster, I would definitely recommend option a), which
>> provides a single world view, shared storage, etc.
> It's for GNU/Linux workstations in university labs.  I want to use Guix
> to provide additional software that is not available in required
> configuration in the host distro, and also give students an interesting
> environment to experiment.
> I decided for now to go with the option b) for performance and
> reliability.  My previous attempts to deploy large software packages on
> NFS (even with FS-Cache enabled) didn't work well.  Also, it may be
> possible to somehow exploit immutability of the store items to share and
> cache them more efficiently.

Yes, we use option a) on a cluster at Inria (and Roel and Ricardo have a
similar setup at their institutes), and it works pretty well.

>From a performance viewpoint, it’s important for the master node to have
the store on a local file system, so that things like GC and
deduplication run quickly enough—these would be slow over NFS.  For the
compute nodes, accessing packages over NFS is good enough.

> The computers periodically run "guix pull" as root and I want to make
> the updated Guix automatically available to all users, but
> /usr/local/bin/guix can't be linked to
> /root/.config/guix/current/bin/guix as the /root directory is normally
> not searchable by other users — another reason to keep pulled Guix
> profiles in /var.  I workaround this by having the script that runs
> "guix pull" to symlink /usr/local/bin/guix directly into the new profile
> in /gnu/store.

I see.  I’ll look into treating ~/.config/guix/current similarly to
~/.guix-profile.  That would help for a setup like yours.

>> I agree it would be useful (the way we do it on GuixSD is by having
>> /etc/profile define INFOPATH systematically, for instance), but there’s
>> no clear way to have ~/.config/guix/current/etc/profile define them
>> directly.
> It would be useful to have a similar script included in the guix package
> to be symlinked into host distro's /etc/profile.d

We could do that, though it wouldn’t help much: you’d have to add one
line to /etc/profile instead of adding two lines, essentially.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]