[Top][All Lists]

[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

> 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!  ;-)


reply via email to

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