Andreas Enge <andr...@enge.fr> 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’.