From: "Ludovic Courtès" <ludovic.courtes@inria.fr>
To: "Sébastien Lerique" <sl@eauchat.org>
Cc: guix-science@gnu.org, zimoun <zimon.toutoune@gmail.com>
Subject: Re: Introducing Guix to HPC at my institution
Date: Tue, 30 Mar 2021 09:21:09 +0200 [thread overview]
Message-ID: <87o8f1jee2.fsf@inria.fr> (raw)
In-Reply-To: <87blb1wgna.fsf@eauchat.org> ("Sébastien Lerique"'s message of "Tue, 30 Mar 2021 10:54:01 +0900")
Hi Sébastien,
Sébastien Lerique <sl@eauchat.org> skribis:
> On 29 Mar 2021 at 21:03, Ludovic Courtès <ludovic.courtes@inria.fr>
> wrote:
>
>> 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.
[...]
> Thanks! I `guix pack`'ed with a single -R since I shouldn't need
> PRoot, and had to add
>
> export GUIX_LOG_DIRECTORY=$HOME/.local/var/log
OK.
> to the environment setup in order to start guix-daemon. Then `guix
> install hello` warned at the beginning with
>
> user with UID 7352 not found
>
> and later failed with
>
> Backtrace:
> In ice-9/boot-9.scm:
> 1736:10 6 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
> 5 (apply-smob/0 #<thunk 7f5a32f85520>)
> In ice-9/boot-9.scm:
> 718:2 4 (call-with-prompt _ _ #<procedure
> default-prompt-handle…>)
> In ice-9/eval.scm:
> 619:8 3 (_ #(#(#<directory (guile-user) 7f5a32f88c80>)))
> In guix/ui.scm:
> 2164:12 2 (run-guix-command _ . _)
> In guix/scripts/offload.scm:
> 782:21 1 (guix-offload "x86_64-linux" "0" "1" "0")
> In unknown file:
> 0 (getpw 7352)
>
> ERROR: In procedure getpw:
> In procedure getpw: entry not found
Hmm could it be that nscd is not running, and that /etc/nsswitch.conf
specifies a “non-standard” NSS plugin, such as ‘sssd’?
https://guix.gnu.org/manual/en/html_node/Application-Setup.html#Name-Service-Switch-1
Does ‘guix install hello --no-offload’ work around the issue?
> Another problem appeared for substitutes (as 'guix install hello' was
> rebuilding the world):
>
> $ guix archive --authorize < \
> /gnu/store/xb4szjambyi52bpnkjv080g2mlfqqpp0-profile/share/guix/ci.guix.gnu.org.pub
> guix archive: error: mkdir: Permission denied
I guess it’s trying to write to /etc/guix. You probably need to set
GUIX_STATE_DIRECTORY=$HOME/.local/var/guix here.
> I quickly went through `guix/scripts/pack.scm` and
> `gnu/packages/aux-files/run-in-namespace.c` to try and understand
> what `guix pack -R` does, but it looks like I need to learn more about
> namespaces before I can digest that. My high-level understanding from
> poking around is that the binaries from `guix pack -R` run inside a
> namespace where /gnu is bind-mounted (along with /proc, /dev, /sys,
> ...), but the rest of the host filesystem is still available, and
> other host processes can also be seen. Then, anything I run from
> inside the `guix pack`'ed bash inherits that namespace, which is what
> makes guix-daemon work.
Correct!
> If this is incorrect, could you maybe give a high-level overview of
> what it does? The documentation is a bit scarce on the topic (or I
> didn't find it).
The design and implementation are documented in blog posts:
https://guix.gnu.org/en/blog/2018/tarballs-the-ultimate-container-image-format/
https://hpc.guix.info/blog/2020/05/faster-relocatable-packs-with-fakechroot/
> I'm also wondering why `guix-daemon` must be invoked with
> `--disable-chroot`. Doesn't that make the reproducibility
> guarantees more brittle (according to the docs)?
True, but I think (?) that’s currently unavoidable in this setup…
though I forget why. You might want to try without ‘--disable-chroot’.
> Ok. My use cases here are:
> - trying to provide a setup that others can more-or-less easily try
> out to get a feel for Guix on the HPC cluster (if possible without
> duplicating /gnu/store), thus creating interest and user support for
> later presenting the case to sysadmins / university administration;
Safe sharing among users is not possible without a daemon coordinating
accesses to the store and acting as a trusted proxy.
> - getting to know the exact requirements that I would have to
> convince sysadmins to agree to, with rationales/explanations for
> the hardest-to-obtain. Getting them to run guix-daemon as root is
> probably a lost case, so I'd like to explore everything else that is
> possible.
Yeah.
> So let's transform my two questions above into the two following:
>
> 1. what would be the list of requirements that explain why guix-daemon
> must run as root? What does each of those requirements accomplish?
I think this article remains relevant:
https://hpc.guix.info/blog/2017/09/reproducibility-and-root-privileges/
> 2. knowing that my environment has user namespaces (and knowing that
> that may not be enough), would it be possible to set up guix-daemon as
> non-root with the assistance of a sysadmin (so say with root access
> during setup), with build users and all, and have it provide identical
> guarantees to a guix-daemon running as root? If not, why not, and
> could we work around that?
Good question. It should be possible to make the daemon run as
non-root; that’s what the trick with the ‘guix pack -R’ wrapper should
achieve, but it could also be a built-in capability.
Food for thought!
Thanks,
Ludo’.
next prev parent reply other threads:[~2021-03-30 7:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 3:12 Introducing Guix to HPC at my institution Sébastien Lerique
2021-03-15 13:47 ` zimoun
2021-03-16 1:54 ` Sébastien Lerique
2021-03-16 8:06 ` zimoun
2021-03-16 9:05 ` Ludovic Courtès
2021-03-18 2:26 ` Sébastien Lerique
2021-03-26 8:22 ` Sébastien Lerique
2021-03-29 12:03 ` Ludovic Courtès
2021-03-30 1:54 ` Sébastien Lerique
2021-03-30 7:21 ` Ludovic Courtès [this message]
2021-03-31 5:23 ` Sébastien Lerique
2021-04-01 8:35 ` Ludovic Courtès
2021-04-01 14:34 ` Sébastien Lerique
2021-04-10 20:43 ` Ludovic Courtès
2021-04-12 1:21 ` Sébastien Lerique
2021-04-12 12:43 ` Ludovic Courtès
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=87o8f1jee2.fsf@inria.fr \
--to=ludovic.courtes@inria.fr \
--cc=guix-science@gnu.org \
--cc=sl@eauchat.org \
--cc=zimon.toutoune@gmail.com \
/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).