[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix binary tarball
From: |
Ludovic Courtès |
Subject: |
Re: Guix binary tarball |
Date: |
Fri, 15 May 2015 19:14:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Andreas Enge <address@hidden> skribis:
> - The files all have owner nixbld and group nixbld, whereas on my own machine,
> they are either both root (for /var/guix, /root and /store) or user root,
> group guix-builder (for /gnu/store). As that user and group do not exist
> on the target system, the numerical values 30000 and 30001 are used instead.
> Would it be possible to create the tarball with the correct file owner?
> One would then need to modify the documentation, since one needs to first
> create the guix-builder group and add root to it _before_ unpacking the
> tarball, so that the correct owner will be chosen instead of the numerical
> value.
Argh, good point. Yes, it would be possible to use the “guix-builder”
user and group names.
I’ve deployed the tarball before on a machine and didn’t notice that
because it Just Worked. I guess the reason is that 30000 and 30001 work
as long as guix-build{,er} are the first system group and user accounts
created on the system.
What were the symptoms on your machine? Did guix-build{,er} turn out
to have different UID/GID?
> - The tarball also contains /, /root and /var. When unpacking it, the owner
> and permissions are changed on the system.
Oops, indeed.
> As a consequence, we could not ssh into the machine any more
> (!).
I don’t see how this could happen.
> Could these directories be left out of the tarball and only their
> contents be kept in?
No. Maybe we can fix it by using two tar invocations with different
--owner.
> Another point, which might simply lead to modifications in the documentation:
>
> - /root/.guix-profile does not need to be accessed by a normal user. I think
> that it is better to do
> # cd /usr/local/bin
> # ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix
> instead of
> # ln -s /root/.guix-profile/bin/guix
> This unravels one layer of symbolic links, and does not force to change
> the permissions of /root.
OK, patch welcome. :-)
A couple of days earlier would have been even better, but thanks for the
detailed feedback! ;-)
Ludo’.