guix-science
[Top][All Lists]
Advanced

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

Re: Introducing Guix to HPC at my institution


From: Ludovic Courtès
Subject: Re: Introducing Guix to HPC at my institution
Date: Mon, 29 Mar 2021 14:03:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi Sébastien,

Sébastien Lerique <sl@eauchat.org> skribis:

> It turns out the HPC cluster I have access to has user namespaces
> activated \o/, so I'm looking into getting things running as an 
> unpriviliged user to show other people how useful Guix can be (before
> approaching higher levels in the administration).

Good!

> and am now following Guix's binary installation inside a user
> namespace. After decompressing the binary distribution of guix 
> inside `~/local-guix`, my naïve next step was `unshare -mrf chroot
> ~/local-guix 
> gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16/bin/bash`.

Instead of installing the “regular” binary tarball inside a namespace,
it might be easier to create a tarball like so:

  guix pack -RR -S /bin=bin -S /etc=etc guix bash

… and to unpack the resulting tarball.

>From there, you can run ./bin/sh to get a shell that “sees” /gnu/store.
You can then run:

  . ./etc/profile

And then, you should be able to run the daemon, like so:

  export GUIX_STATE_DIRECTORY=$HOME/.local/var/guix
  guix-daemon --disable-chroot &

(Adapted from
<https://lists.gnu.org/archive/html/guix-devel/2018-05/msg00139.html>.)

Does that work for you?

> But my knowledge of linux namespaces is hindering my next steps :). A
> few questions:
>
> - after setting $GUIX_PROFILE and sourcing
>   `/root/.config/guix/current`, running `guix` warns with:
>
>  GC Warning: pthread_getattr_np or pthread_attr_getstack failed   for
> main thread
>  GC Warning: Couldn't read /proc/stat
>
>  The first warning I don't know what to do with. About the   second:
> should I be binding `/proc` somehow?

Yes, you should expose /proc.  The wrappers created by ‘guix pack -RR’
in the example above bind-mount everything + /gnu/store, such that you
can’t tell the difference.

> - is it possible to create build users inside the user-namespaced
>   chroot?

No: you still have a single UID at hand, so there’s no way to allocate
new ones.

> - last but not least, how would I go about sharing this setup with
>   other users on the cluster? Ideally I would like to have a 
>  non-priviliged build daemon that other users can call on. (Is   there
> such a thing as kernel group namespaces?)

It’s not really sharable.  To share it, you would need some sort of a
shared trusted “proxy”; that’s precisely what guix-daemon is in normal
multi-user setups.

HTH!

Ludo’.



reply via email to

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