~/.config/guix/current

~/.config/guix/current

[Mikhail Kryshen]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

Hi,

Is there some reason why "guix pull" keeps profile symlinks in
~/.config/guix instead of under /var/guix/profiles?

I'm looking into installing Guix on multiple computers with shared user
accounts and /home on NFS.  So far the possibilities seem to be:

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?
   
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.

Can/should this be fixed?

Another question is why ~/.config/guix/current/etc/profile does not
define all necessary environment variables (PATH is there, but no
INFOPATH, GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH)?  It would be
convenient to source it in .bash_profile the same way as normal
guix-profile instead of defining all necessary variables explicitly.

[1] https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/

-- 
Mikhail

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: ~/.config/guix/current

[Ludovic Courtès]

Hello Mikhail,

Mikhail Kryshen <mikhail@kryshen.net> skribis:

> Is there some reason why "guix pull" keeps profile symlinks in
> ~/.config/guix instead of under /var/guix/profiles?

It’s mostly because it takes less code to do it this way.  :-)
This was briefly discussed during the submission of this patch series.

> I'm looking into installing Guix on multiple computers with shared user
> accounts and /home on NFS.  So far the possibilities seem to be:
>
> 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] https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/

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.”

Writing the profile to /var/guix/profiles would indeed solve this
specific issue.

> 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.

Option b) causes all the issues you mention, and this is not specific to
the new ‘guix pull’ (you had similar issues with ~/.config/guix/latest
before, for instance.)

> Can/should this be fixed?

We can do it.  In fact my take on this was to keep it simple for now,
and to adjust if/when someone reports a need for this—which I think you
just did.  :-)

> Another question is why ~/.config/guix/current/etc/profile does not
> define all necessary environment variables (PATH is there, but no
> INFOPATH, GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH)?  It would be
> convenient to source it in .bash_profile the same way as normal
> guix-profile instead of defining all necessary variables explicitly.

The reason it doesn’t define INFOPATH for example is because INFOPATH
“belongs” to Texinfo, and Texinfo is not in that profile; similarly for
GUILE_LOAD_PATH.

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.

Thanks for your feedback,
Ludo’.

Re: ~/.config/guix/current

[Mikhail Kryshen]

[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]

Ludovic Courtès <ludovic.courtes@inria.fr> 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] https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/
>
> 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.

Btw, is option a) possible on GuixSD?


>> 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.

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 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

Thank you, 
Mikhail

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: ~/.config/guix/current

[Ludovic Courtès]

Hello Mikhail,

Mikhail Kryshen <mikhail@kryshen.net> skribis:

> Ludovic Courtès <ludovic.courtes@inria.fr> 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] https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/
>>
>> 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.

Thanks,
Ludo’.

Re: ~/.config/guix/current

[Mikhail Kryshen]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

>> Btw, is option a) possible on GuixSD?
>
> I think so.  Why wouldn’t it?

It looks like /gnu/store is needed early to boot the system.

Can you hint on how to configure GuixSD with /gnu/store on NFS?

> 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.

Thanks!  I think I'll try to experiment with a) a bit first.

-- 
Mikhail

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: ~/.config/guix/current

[Ludovic Courtès]

Mikhail Kryshen <mikhail@kryshen.net> skribis:

> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>
>>> Btw, is option a) possible on GuixSD?
>>
>> I think so.  Why wouldn’t it?
>
> It looks like /gnu/store is needed early to boot the system.

Oh right, I thought you were referring to the configuration of the
master node.

The compute nodes would need to be able to mount /gnu/store early at
boot over NFS, and I think that’s doesn’t work right now on GuixSD.
I’m not sure exactly what’s missing.

Ludo’.

Store on NFS (was Re: ~/.config/guix/current)

[Mikhail Kryshen]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> Oh right, I thought you were referring to the configuration of the
> master node.

Concerning the master node, is there a way to specify NFS exports in
GuixSD OS configuration?

> The compute nodes would need to be able to mount /gnu/store early at
> boot over NFS, and I think that’s doesn’t work right now on GuixSD.
> I’m not sure exactly what’s missing.

I see in grub.cfg, that the kernel and initrd are loaded from the store,
so it must be available to the bootloader.  Would it be possible to
combine local and remote stores after boot with overlayfs and ensure
that all necessary items are written to the local store at "system
reconfigure" (maybe have a local guix daemon manage the local store for
"system reconfigure")?

-- 
Mikhail

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Store on NFS (was Re: ~/.config/guix/current)

[Ludovic Courtès]

Mikhail Kryshen <mikhail@kryshen.net> skribis:

> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>
>> Oh right, I thought you were referring to the configuration of the
>> master node.
>
> Concerning the master node, is there a way to specify NFS exports in
> GuixSD OS configuration?

You’d have to extend ‘etc-service-type’ to provide a /etc/exports file,
along these lines:

  (simple-service 'etc-exports etc-service-type
                  `(("exports" ,(plain-file "exports" "…"))))

>> The compute nodes would need to be able to mount /gnu/store early at
>> boot over NFS, and I think that’s doesn’t work right now on GuixSD.
>> I’m not sure exactly what’s missing.
>
> I see in grub.cfg, that the kernel and initrd are loaded from the store,
> so it must be available to the bootloader.  Would it be possible to
> combine local and remote stores after boot with overlayfs and ensure
> that all necessary items are written to the local store at "system
> reconfigure" (maybe have a local guix daemon manage the local store for
> "system reconfigure")?

Yes, that sounds like a reasonable option.

You can probably add to the ‘file-systems’ field a declaration of the
overlayfs and mark it with (needed-for-boot? #f).  We need to experiment
with this!

HTH,
Ludo’.