Guix binary tarball

Guix binary tarball

[Andreas Enge]

Hello,

we just set up guix 0.8.2 via the binary tarball on a machine at work, and
experienced a few problems:

- 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.
- The tarball also contains /, /root and /var. When unpacking it, the owner
  and permissions are changed on the system. As a consequence, we could not
  ssh into the machine any more (!). Could these directories be left out of
  the tarball and only their contents be kept in?

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.

Andreas

Re: Guix binary tarball

[Ludovic Courtès]

Andreas Enge <andreas@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’.

Re: Guix binary tarball

[Andreas Enge]

On Fri, May 15, 2015 at 07:14:04PM +0200, Ludovic Courtès wrote:
> What were the symptoms on your machine?  Did guix-build{,er} turn out
> to have different UID/GID?

We did not try it; our first aim was to get back to sshing into the machine
(luckily, we still had a terminal open somewhere). Maybe guix would have
worked.

> > As a consequence, we could not ssh into the machine any more
> > (!).
> I don’t see how this could happen.

Try "chown 30000.30001 $HOME". Then ssh into the machine asks for the
passphrase instead of using the public-private key pair.

> > 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.

Well, you never know what permissions the directories have on the target
machine, and these are also changed. Maybe one needs to untar with particular
options.

Andreas

Re: Guix binary tarball

[Taylan Ulrich Bayırlı/Kammer]

Andreas Enge <andreas@enge.fr> writes:

>> > As a consequence, we could not ssh into the machine any more
>> > (!).
>> I don’t see how this could happen.
>
> Try "chown 30000.30001 $HOME". Then ssh into the machine asks for the
> passphrase instead of using the public-private key pair.

I believe this is because OpenSSH, being highly pedantic (I suppose
rightfully so), will refuse to acknowledge ~/.ssh/authorized_keys when
its owner or permissions are wrong.  (Or even merely the permissions on
$HOME?)

Additionally, it's a best-practice to disable password-authentication
for the root account in sshd_config (Debian 8 proposes it at least) to
prevent the chance of successful brute-force/dictionary attacks.

Together that would mean no root SSH access to the machine at all.

Taylan

Re: Guix binary tarball

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

>> > 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.
>
> Well, you never know what permissions the directories have on the target
> machine, and these are also changed. Maybe one needs to untar with particular
> options.

I looked in the GNU tar manual, and found this:

`--no-overwrite-dir'
     Preserve metadata of existing directories when extracting files
     from an archive.  *Note Overwrite Old Files::.

This might be exactly what we need.

      Mark

Re: Guix binary tarball

[Andreas Enge]

On Fri, May 15, 2015 at 07:14:04PM +0200, Ludovic Courtès wrote:
> > - The tarball also contains /, /root and /var. When unpacking it, the owner
> >   and permissions are changed on the system.
> No.  Maybe we can fix it by using two tar invocations with different
> --owner.

Hm. Then maybe the documentation should suggest the following?

cd /tmp
tar xf ...
chmod ... (optional if we have the correct owners in the tarball)
mv root/.guix-profile /root
mv var/guix /var
mv /gnu /

This would also mean that the user does not need to put so much trust into us
that the tarball does not replace vital parts of the system...

> > Another point, which might simply lead to modifications in the documentation:
> OK, patch welcome.  :-)

Sure, as soon as the final approach is fixed.

> A couple of days earlier would have been even better, but thanks for the
> detailed feedback!  ;-)

I thought it would avoid me to update the system immediately afterwards again
if I waited for 0.8.2 :-)  Actually, we have not yet tried how this
installation method interacts with "guix pull".

Andreas

Re: Guix binary tarball

[Ludovic Courtès]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> Additionally, it's a best-practice to disable password-authentication
> for the root account in sshd_config (Debian 8 proposes it at least) to
> prevent the chance of successful brute-force/dictionary attacks.

I think the default is to disable root login at all over SSH (that’s the
case with lshd), which is a good thing.

Ludo’.

Re: Guix binary tarball

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, May 15, 2015 at 07:14:04PM +0200, Ludovic Courtès wrote:
>> > - The tarball also contains /, /root and /var. When unpacking it, the owner
>> >   and permissions are changed on the system.
>> No.  Maybe we can fix it by using two tar invocations with different
>> --owner.
>
> Hm. Then maybe the documentation should suggest the following?

Sorry I was referring to the implementation, not to the extraction.

>> A couple of days earlier would have been even better, but thanks for the
>> detailed feedback!  ;-)
>
> I thought it would avoid me to update the system immediately afterwards again
> if I waited for 0.8.2 :-)

Heh.  :-)

> Actually, we have not yet tried how this installation method interacts
> with "guix pull".

It shouldn’t make any difference.

Thanks,
Ludo’.

Re: Guix binary tarball

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Andreas Enge <andreas@enge.fr> writes:
>
>>> > 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.
>>
>> Well, you never know what permissions the directories have on the target
>> machine, and these are also changed. Maybe one needs to untar with particular
>> options.
>
> I looked in the GNU tar manual, and found this:
>
> `--no-overwrite-dir'
>      Preserve metadata of existing directories when extracting files
>      from an archive.  *Note Overwrite Old Files::.

I experimentally determined that --no-overwrite-dir has no effect but
that --skip-old-files does what we need: ownership and permissions on
/var and /root are preserved, and files are extracted correctly in those
directories.  Hence 8c3a5d7.

Thanks,
Ludo’.

Re: Guix binary tarball

[Ludovic Courtès]

These commits address most of what you reported, I think:

175ced4 * install: Use the right user and group name for files in the binary tarball.
cfc149d * doc: Suggest the same build user and group names as on GuixSD.
d72d05f * doc: Better suggestion for the /usr/local/bin/guix symlink.

Feedback welcome!

Thanks,
Ludo’.

Re: Guix binary tarball

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> These commits address most of what you reported, I think:
>
> 175ced4 * install: Use the right user and group name for files in the binary tarball.
> cfc149d * doc: Suggest the same build user and group names as on GuixSD.
> d72d05f * doc: Better suggestion for the /usr/local/bin/guix symlink.

Sorry, I was confused; 175ced4 is amended by:

  01dbc7e * install: Files in the tarball are all root-owned.

Ludo’.

Re: Guix binary tarball

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

Hello,

thanks for the work; I would have proposed a patch, but thought the discussion
was not yet finished.

I am attaching an amended version of Sree's /etc/init.d/guixd with the new
group and build user names.

Andreas


[-- Attachment #2: guixd --]
[-- Type: text/plain, Size: 1380 bytes --]

#!/bin/sh

### BEGIN INIT INFO
# Provides: guix-daemon
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: starts the guix-daemon
# Description: starts guix-daemon using start-stop-daemon
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/bin/guix-daemon
DAEMON_OPTS="--build-users-group=guixbuild --cores=0"
NAME=guixd
DESC=guix-daemon

test -x $DAEMON || exit 0

set -e

. /lib/lsb/init-functions

case "$1" in
start)
echo -n "Starting $DESC: "
start-stop-daemon --start --background --make-pidfile \
--quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON -- $DAEMON_OPTS || true
echo "$NAME."
;;

stop)
echo -n "Stopping $DESC: "
start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON || true
echo "$NAME."
;;

restart|force-reload)
echo -n "Restarting $DESC: "
start-stop-daemon --stop --quiet --pidfile \
/var/run/$NAME.pid --exec $DAEMON || true
sleep 1
start-stop-daemon --start --background --make-pidfile \
--quiet --pidfile \
/var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS || true
echo "$NAME."
;;

status)
status_of_proc -p /var/run/$NAME.pid "$DAEMON" "$NAME" && exit 0 || exit $?
;;
*)
echo "Usage: $NAME {start|stop|restart|status}" >&2
exit 1
;;
esac

exit 0

Re: Guix binary tarball

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> thanks for the work; I would have proposed a patch, but thought the discussion
> was not yet finished.

Sorry, I did not want to pressure you, the discussion remains open
anyway.  :-)

> I am attaching an amended version of Sree's /etc/init.d/guixd with the new
> group and build user names.

Ah thanks.  What about adding it in the tree for installation in
$sysconfdir/init.d, and mention it in the manual?

If someone comes up with a .service file, we could also ship it.

Ludo’.

Re: Guix binary tarball

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> - The tarball also contains /, /root and /var. When unpacking it, the owner
>   and permissions are changed on the system. As a consequence, we could not
>   ssh into the machine any more (!). Could these directories be left out of
>   the tarball and only their contents be kept in?

The directories could indeed be left out.  I experimentally verified
that GNU tar will still create those directories if they don't already
exist, but will leave their ownership and permissions unmodified if they
do exist.

Here's a suggested patch:

--8<---------------cut here---------------start------------->8---
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 799851c..10fbfdd 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -71,7 +71,14 @@ under /root/.guix-profile where GUIX is installed."
           (with-directory-excursion %root
             (zero? (system* "tar" "--xz" "--format=gnu"
                             "--owner=root:0" "--group=root:0"
-                            "-cvf" #$output ".")))))
+                            "-cvf" #$output
+                            ;; Avoid adding /, /var, or /root to the tarball,
+                            ;; so that the ownership and permissions of those
+                            ;; directories will not be overwritten when
+                            ;; extracting the archive.
+                            "./root/.guix-profile"
+                            "./var/guix"
+                            "./gnu")))))
 
     (gexp->derivation "guix-tarball.tar.xz" build
                       #:references-graphs `(("profile" ,profile))
--8<---------------cut here---------------end--------------->8---

If we did this, then we could revert 8c3a5d7059 and avoid any use of
--skip-old-files.  I would be in favor of this.

What do you think?

      Mark

Re: Guix binary tarball

[Andreas Enge]

On Tue, May 19, 2015 at 07:03:57PM -0400, Mark H Weaver wrote:
> If we did this, then we could revert 8c3a5d7059 and avoid any use of
> --skip-old-files.  I would be in favor of this.
> 
> What do you think?

Sounds good, thanks for looking into this!

Andreas

Re: Guix binary tarball

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Andreas Enge <andreas@enge.fr> writes:
>
>> - The tarball also contains /, /root and /var. When unpacking it, the owner
>>   and permissions are changed on the system. As a consequence, we could not
>>   ssh into the machine any more (!). Could these directories be left out of
>>   the tarball and only their contents be kept in?
>
> The directories could indeed be left out.

Oh you mean the *parent* directories, right?  Sorry I hadn’t understood
that.

> I experimentally verified that GNU tar will still create those
> directories if they don't already exist, but will leave their
> ownership and permissions unmodified if they do exist.
>
> Here's a suggested patch:
>
> diff --git a/gnu/system/install.scm b/gnu/system/install.scm
> index 799851c..10fbfdd 100644
> --- a/gnu/system/install.scm
> +++ b/gnu/system/install.scm
> @@ -71,7 +71,14 @@ under /root/.guix-profile where GUIX is installed."
>            (with-directory-excursion %root
>              (zero? (system* "tar" "--xz" "--format=gnu"
>                              "--owner=root:0" "--group=root:0"
> -                            "-cvf" #$output ".")))))
> +                            "-cvf" #$output
> +                            ;; Avoid adding /, /var, or /root to the tarball,
> +                            ;; so that the ownership and permissions of those
> +                            ;; directories will not be overwritten when
> +                            ;; extracting the archive.
> +                            "./root/.guix-profile"
> +                            "./var/guix"
> +                            "./gnu")))))
>  
>      (gexp->derivation "guix-tarball.tar.xz" build
>                        #:references-graphs `(("profile" ,profile))
>
> If we did this, then we could revert 8c3a5d7059 and avoid any use of
> --skip-old-files.  I would be in favor of this.
>
> What do you think?

Yes, that’s even better, please commit and revert 8c3a5d7059.

Thanks!

Ludo’.

Re: Guix binary tarball

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Here's a suggested patch:
>>
>> diff --git a/gnu/system/install.scm b/gnu/system/install.scm
>> index 799851c..10fbfdd 100644
>> --- a/gnu/system/install.scm
>> +++ b/gnu/system/install.scm
>> @@ -71,7 +71,14 @@ under /root/.guix-profile where GUIX is installed."
>>            (with-directory-excursion %root
>>              (zero? (system* "tar" "--xz" "--format=gnu"
>>                              "--owner=root:0" "--group=root:0"
>> -                            "-cvf" #$output ".")))))
>> +                            "-cvf" #$output
>> +                            ;; Avoid adding /, /var, or /root to the tarball,
>> +                            ;; so that the ownership and permissions of those
>> +                            ;; directories will not be overwritten when
>> +                            ;; extracting the archive.
>> +                            "./root/.guix-profile"
>> +                            "./var/guix"
>> +                            "./gnu")))))
>>  
>>      (gexp->derivation "guix-tarball.tar.xz" build
>>                        #:references-graphs `(("profile" ,profile))
>>
>> If we did this, then we could revert 8c3a5d7059 and avoid any use of
>> --skip-old-files.  I would be in favor of this.
>>
>> What do you think?
>
> Yes, that’s even better, please commit and revert 8c3a5d7059.

Done.

I would advocate releasing 0.8.3 ASAP with these fixes, since the binary
installation method in 0.8.2 has such serious problems.

What do you think?

      Mark

Re: Guix binary tarball

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Here's a suggested patch:
>>>
>>> diff --git a/gnu/system/install.scm b/gnu/system/install.scm
>>> index 799851c..10fbfdd 100644
>>> --- a/gnu/system/install.scm
>>> +++ b/gnu/system/install.scm
>>> @@ -71,7 +71,14 @@ under /root/.guix-profile where GUIX is installed."
>>>            (with-directory-excursion %root
>>>              (zero? (system* "tar" "--xz" "--format=gnu"
>>>                              "--owner=root:0" "--group=root:0"
>>> -                            "-cvf" #$output ".")))))
>>> +                            "-cvf" #$output
>>> +                            ;; Avoid adding /, /var, or /root to the tarball,
>>> +                            ;; so that the ownership and permissions of those
>>> +                            ;; directories will not be overwritten when
>>> +                            ;; extracting the archive.
>>> +                            "./root/.guix-profile"
>>> +                            "./var/guix"
>>> +                            "./gnu")))))
>>>  
>>>      (gexp->derivation "guix-tarball.tar.xz" build
>>>                        #:references-graphs `(("profile" ,profile))
>>>
>>> If we did this, then we could revert 8c3a5d7059 and avoid any use of
>>> --skip-old-files.  I would be in favor of this.
>>>
>>> What do you think?
>>
>> Yes, that’s even better, please commit and revert 8c3a5d7059.
>
> Done.
>
> I would advocate releasing 0.8.3 ASAP with these fixes, since the binary
> installation method in 0.8.2 has such serious problems.
>
> What do you think?

Not sure if “serious” is appropriate (those who tested it a month ago
had no problems using it, despite the UID issue), but yes, we should aim
for a quick release.  This time, we need to get feedback /before/ the
release.  ;-)

I also want to fully understand the problem that Ricardo reported before
we release again.

Thanks,
Ludo’.

Re: Guix binary tarball

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]

Hi!

In context of
<http://news.gmane.org/find-root.php?message_id=%3C87lhg2je9j.fsf%40kepler.schwinge.homeip.net%3E>,
I'm now installing Guix (GNU Guix 0.8.2 Binary) for the first time.  I
noticed a few issues that have been raised in this thread already (I have
not yet read every message in detail); so I'm hijacking this thread but
will now just dump here what I wrote down during installation, and if
there remains anything still to be sorted out, we can work on that later.

<http://www.gnu.org/software/guix/download/>.

    $ wget 'ftp://alpha.gnu.org/gnu/guix/guix-binary-0.8.2.x86_64-linux.tar.xz' 'ftp://alpha.gnu.org/gnu/guix/guix-binary-0.8.2.x86_64-linux.tar.xz.sig'
    $ gpg --verify guix-binary-0.8.2.x86_64-linux.tar.xz.sig

<http://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html>.

    $ cd /
    $ sudo tar --skip-old-files -xJ < ~/tmp/guix/guix-binary-0.8.2.x86_64-linux.tar.xz

I'm not a fan of extracting tarballs inside populated directories; so I'm
in favor on the suggested change to extract inside a temporary directory,
and then move everything in place as a separate step.

    $ sudo ls -ld /root/.guix-profile /var/guix /gnu
    drwxr-xr-x 3 30001 30000 4096 Mai 14 10:36 /gnu
    lrwxrwxrwx 1 30001 30000   45 Mai 14 10:36 /root/.guix-profile -> /var/guix/profiles/per-user/root/guix-profile
    drwxr-xr-x 6 30001 30000 4096 Mai 14 10:36 /var/guix

Should the tarball be packed such that it uses UID:GID 0:0, which -- I
think? -- is always expected to map to root:root?  Which UID:GID should I
now chown the files to?

It's very common, but I don't think there's a hard requirement for the
root user's home directory to be /root.  Maybe instead of shipping it in
the tarball, the symbolic link should be created by an explicit command?

    $ sudo ln -sf /var/guix/profiles/per-user/root/guix-profile ~root/.guix-profile

<http://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html>.

    $ sudo groupadd --system guix-builder
    $ for i in `seq 1 10`; do sudo useradd -g guix-builder -G guix-builder -d /var/empty -s `which nologin` -c "Guix build user $i" --system guix-builder$i; done

Please describe why ten is a good amount of Guix build users.

For reference, the GID and UIDs this created on my system:

    $ getent group | grep -i guix
    guix-builder:x:998:guix-builder1,guix-builder2,guix-builder3,guix-builder4,guix-builder5,guix-builder6,guix-builder7,guix-builder8,guix-builder9,guix-builder10
    $ getent passwd | grep -i guix
    guix-builder1:x:999:998:Guix build user 1:/var/empty:/usr/sbin/nologin
    guix-builder2:x:998:998:Guix build user 2:/var/empty:/usr/sbin/nologin
    guix-builder3:x:997:998:Guix build user 3:/var/empty:/usr/sbin/nologin
    guix-builder4:x:996:998:Guix build user 4:/var/empty:/usr/sbin/nologin
    guix-builder5:x:995:998:Guix build user 5:/var/empty:/usr/sbin/nologin
    guix-builder6:x:994:998:Guix build user 6:/var/empty:/usr/sbin/nologin
    guix-builder7:x:993:998:Guix build user 7:/var/empty:/usr/sbin/nologin
    guix-builder8:x:992:998:Guix build user 8:/var/empty:/usr/sbin/nologin
    guix-builder9:x:991:998:Guix build user 9:/var/empty:/usr/sbin/nologin
    guix-builder10:x:990:998:Guix build user 10:/var/empty:/usr/sbin/nologin


Grüße,
 Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

/run/current-system (was: Guix binary tarball)

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

Hi!

On Sun, 07 Jun 2015 14:39:20 +0200, I wrote:
> In context of
> <http://news.gmane.org/find-root.php?message_id=%3C87lhg2je9j.fsf%40kepler.schwinge.homeip.net%3E>,
> I'm now installing Guix (GNU Guix 0.8.2 Binary) for the first time.  I
> noticed a few issues that have been raised in this thread already (I have
> not yet read every message in detail); so I'm hijacking this thread but
> will now just dump here what I wrote down during installation, and if
> there remains anything still to be sorted out, we can work on that later.

Another thing:

    $ guix --version
    warning: failed to install locale: Invalid argument
    guix (GNU Guix) 0.8.2
    [...]

strace:

    [...]
    open("/run/current-system/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    open("/gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 6
    fstat(6, {st_mode=S_IFREG|0444, st_size=2492, ...}) = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcb7c680000
    read(6, "# Locale name alias data base.\n#"..., 4096) = 2492
    read(6, "", 4096)                       = 0
    close(6)                                = 0
    munmap(0x7fcb7c680000, 4096)            = 0
    open("/run/current-system/locale/de_DE.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    open("/run/current-system/locale/de_DE/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    open("/run/current-system/locale/de.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    open("/run/current-system/locale/de/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    brk(0x2b5f000)                          = 0x2b5f000
    write(2, "warning: ", 9)                = 9
    write(2, ["failed to install locale: "]
    [...]
    write(2, "Invalid argument", 16)        = 16
    write(2, "\n", 1)                       = 1
    [...]

The system doesn't have /run/current-system.

    $ strings /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/libc.so.6 | grep current-system
    /run/current-system/locale
    /run/current-system/locale/locale-archive

Assuming (based on a quick web search) that /run/current-system is a
NixOS/Guix thing, and assuming that the GNU Guix 0.8.2 Binary tarball
that I downloaded simply (and reasonably) does not include locale
information, this warning then is not to be worried about.

I have not yet researched how /run/current-system is supposed to be set
up.


Grüße,
 Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Guix binary tarball

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

Hi, Thomas!

Thomas Schwinge <thomas@codesourcery.com> skribis:

> I'm not a fan of extracting tarballs inside populated directories; so I'm
> in favor on the suggested change to extract inside a temporary directory,
> and then move everything in place as a separate step.

OK.  I had come to the conclusion that yes, doing it in two steps is
reasonable, but it’s the user’s choice, and I wondered whether
describing the additional steps in the manual would make things look
more complicated than they are.  WDYT?

>     $ sudo ls -ld /root/.guix-profile /var/guix /gnu
>     drwxr-xr-x 3 30001 30000 4096 Mai 14 10:36 /gnu
>     lrwxrwxrwx 1 30001 30000   45 Mai 14 10:36 /root/.guix-profile -> /var/guix/profiles/per-user/root/guix-profile
>     drwxr-xr-x 6 30001 30000 4096 Mai 14 10:36 /var/guix
>
> Should the tarball be packed such that it uses UID:GID 0:0, which -- I
> think? -- is always expected to map to root:root?

Yes, it was fixed in 01dbc7e.

> Which UID:GID should I now chown the files to?

root:root.

> It's very common, but I don't think there's a hard requirement for the
> root user's home directory to be /root.  Maybe instead of shipping it in
> the tarball, the symbolic link should be created by an explicit command?
>
>     $ sudo ln -sf /var/guix/profiles/per-user/root/guix-profile ~root/.guix-profile

Yes, why not.  What do people think?

> <http://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html>.
>
>     $ sudo groupadd --system guix-builder
>     $ for i in `seq 1 10`; do sudo useradd -g guix-builder -G guix-builder -d /var/empty -s `which nologin` -c "Guix build user $i" --system guix-builder$i; done
>
> Please describe why ten is a good amount of Guix build users.

I’ve added this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 382 bytes --]

--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -478,6 +478,9 @@ Bash syntax and the @code{shadow} commands):
 @end example
 
 @noindent
+The number of build users determines how many build jobs may run in
+parallel, as specified by the @option{--max-jobs} option
+(@pxref{Invoking guix-daemon, @option{--max-jobs}}).
 The @code{guix-daemon} program may then be run as @code{root} with:

[-- Attachment #3: Type: text/plain, Size: 46 bytes --]


Thanks for providing feedback!

Ludo’.

Re: /run/current-system

[Ludovic Courtès]

Thomas Schwinge <thomas@codesourcery.com> skribis:

>     $ guix --version
>     warning: failed to install locale: Invalid argument
>     guix (GNU Guix) 0.8.2
>     [...]

The fix is to install a locale package and define LOCPATH accordingly:

  http://lists.gnu.org/archive/html/guix-devel/2015-05/msg00282.html

/run/current-system exists on GuixSD (but obviously not on other
systems).  It contains the “system profile”, and in particular contains
the locale data specified in the OS configuration (see
<http://www.gnu.org/software/guix/manual/html_node/Locales.html>.)

Thanks,
Ludo’.

Re: Guix binary tarball

[Alex Kost]

Ludovic Courtès (2015-06-07 19:14 +0300) wrote:

> Thomas Schwinge <thomas@codesourcery.com> skribis:
>
>> I'm not a fan of extracting tarballs inside populated directories; so I'm
>> in favor on the suggested change to extract inside a temporary directory,
>> and then move everything in place as a separate step.
>
> OK.  I had come to the conclusion that yes, doing it in two steps is
> reasonable, but it’s the user’s choice, and I wondered whether
> describing the additional steps in the manual would make things look
> more complicated than they are.  WDYT?

I agree with Thomas.  I believe it would be better to split this step.
(OTOH a user who installs Guix should probably know what to do with a
tarball without additional documentation)

[...]
>> It's very common, but I don't think there's a hard requirement for the
>> root user's home directory to be /root.  Maybe instead of shipping it in
>> the tarball, the symbolic link should be created by an explicit command?
>>
>>     $ sudo ln -sf /var/guix/profiles/per-user/root/guix-profile ~root/.guix-profile
>
> Yes, why not.  What do people think?

I totally agree, I think there is no need to put "/root" into the
tarball, and to add this step instead.

-- 
Alex

Re: Guix binary tarball

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-06-07 19:14 +0300) wrote:
>
>> Thomas Schwinge <thomas@codesourcery.com> skribis:
>>
>>> I'm not a fan of extracting tarballs inside populated directories; so I'm
>>> in favor on the suggested change to extract inside a temporary directory,
>>> and then move everything in place as a separate step.
>>
>> OK.  I had come to the conclusion that yes, doing it in two steps is
>> reasonable, but it’s the user’s choice, and I wondered whether
>> describing the additional steps in the manual would make things look
>> more complicated than they are.  WDYT?
>
> I agree with Thomas.  I believe it would be better to split this step.
> (OTOH a user who installs Guix should probably know what to do with a
> tarball without additional documentation)

Done in 5dc4296.

>>> It's very common, but I don't think there's a hard requirement for the
>>> root user's home directory to be /root.  Maybe instead of shipping it in
>>> the tarball, the symbolic link should be created by an explicit command?
>>>
>>>     $ sudo ln -sf /var/guix/profiles/per-user/root/guix-profile ~root/.guix-profile
>>
>> Yes, why not.  What do people think?
>
> I totally agree, I think there is no need to put "/root" into the
> tarball, and to add this step instead.

Done in 7acd343.

Thanks!

Ludo’.