bug#31825: guix offload fails with guix-authenticate error

[swedebugia]

Hi

On June 20, 2018 5:01:02 AM GMT+02:00, Maxim Cournoyer 
 wrote:
>Hi!
>
>l...@gnu.org (Ludovic Courtès) writes:
>
>> Maxim Cournoyer  skribis:
>>
>>> Attached is the log for the offloading machine.
>>>
>>> From what I can see, the guix-daemon is trying to find the
>authorized
>>> key in /etc/guix/acl, but the key is added by Guix to
>>> /usr/local/etc/guix/acl...
>>
>> Hmm you may be using two different ‘guix’ commands no?
>>
>>> 2. The error message should capture the complete error output to
>ease
>>> debugging: we can see the useful message "25056 write(2, "guix
>>> authenticate: error: error: unauthorized public key: (public-key \n
>(ecc
>>> \n  (curve Ed25519)\n  (q
>>>
>#EEA139318243D36EB4C728DB96856AB15C47AB64C765FA134CCFB12444B82A7C#)\n
>>> )\n )\n", 176) = 176" in strace. Had I seen this from the start, we
>>> would have saved some debugging time :).
>>
>> I agree.
>>
>>> I could work around the issue by copying manually the authorized key
>>> sexp to /etc/guix/acl; I now see:
>>>
>>> guix offload: testing 1 build machines defined in
>'/etc/guix/machines.scm'...
>>> guix offload: '192.168.1.105' is running guile (GNU Guile) 2.2.3
>>> guix offload: Guix is usable on '192.168.1.105' (test returned
>"/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
>>> sending 1 store item to '192.168.1.105'...
>>> exporting path
>`/gnu/store/np9jwqvxjvasz41nrrh6g3gyn4rpkscw-export-test'
>>> guix offload: '192.168.1.105' successfully imported
>'/gnu/store/np9jwqvxjvasz41nrrh6g3gyn4rpkscw-export-test'
>>> retrieving 1 store item from '192.168.1.105'...
>>> guix offload: error: build failed: implementation cannot deal with >
>32-bit integers
>>
>> The log has this:
>>
>> 10529 write(4, "atad\0\0\0\0\0\200\0\0\0\0\0\0", 16) = 16
>> 10529 read(4,
>"W\1\0\0\0\0\0\0\1\0\0\0\0\0\0\0\r\0\0\0\0\0\0\0nix-archive-1\0\0\0\1\0\0\0\0\0\0\0(\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0type\0\0\0\0\7\0\0\0\0\0\0\0regular\0\10\0\0\0\0\0\0\0contents\23\0\0\0\0\0\0\000192.168.1.105-83353\0\0\0\0\0\1\0\0\0\0\0\0\0)\0\0\0\0\0\0\0NIXE\0\0\0\0007\0\0\0\0\0\0\0/gnu/store/wf774mzvfjpw306y5x06wid80d9k90qq-import-test\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0(protocol-error
>1 \"getting status of `/etc/guix/signing-key.sec': Aucun fichier ou
>dossier de ce "..., 32768) = 352
>>
>> Again the error should be reported…
>
>Yes, this error was totally wrong, thanks for pointing it out. The
>actual error was the 192.168.1.105 offload machine not finding the key
>at /etc/guix/singning-key.sec (since it using the prefix
>/usr/local/etc/guix for some reason).
>
>I just did:
>
>--8<---cut here---start->8---
>sudo cp /usr/local/etc/guix/signing* /etc/guix/
>--8<---cut here---end--->8---
>
>And it is now working. Ouf!
>
>Summarizing this adventure:
>
>0) Make sure your .bashrc doesn't exit early when it is executed in
>non-interactive mode (as is the case in Ubuntu).
>
>1) Make sure the guix-authenticate program is available on the host as
>well as the offload machines, by installing guix (guix package -i guix)
>in the corresponding user profiles and sourcing
>$HOME/guix.profile/etc/profile in the ~/.bashrc.
>
>2) Make sure all your guix-daemons are configured to use /etc/guix as
>their sysconfdir, as Guix offload currently seems hardcoded to only
>look
>things under /etc/guix.
>
>3) Don't trust any errors output by guix offload ;)
>
>It'd be nice if this was as simple as setting up a Jenkins node... You
>tell Guix which machine you want to use and give it SSH access, and it
>does the required setup without having the user messing around with
>keys
>and what not.
>
>But I'm seeing far ahead. For now, we could start by adding some points
>to the `guix offload` info manual. Then we can try to modify the code
>to
>better capture the error messages. 
>
>I'll start with the documentation.
>
>Thank you,
>
>Maxim

Good job hunting the bug. 
Are you going to report a new bug about incorrect or insufficient error 
messages? 
Thanks for the summary. 
-- 
Cheers Swedebugia 

bug#31907: New users get wrong/old profile path to guix after reconfiguring

[swedebugia]

Hi

Steps to reproduce:
Install 0.14
Init system with user a
Login root
Guix pull
Make sure it has right paths to .config/guix/current
Reconfigure with new user b
Reboot
Login user b

When logging in slim? populates the dot-files and a  .guix-profile is created 
with path to old guix. No .config/guix/current exist. 
-- 
Cheers Swedebugia 

bug#31825: guix offload fails with guix-authenticate error

[Maxim Cournoyer]

Hi!

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

> Maxim Cournoyer  skribis:
>
>> Attached is the log for the offloading machine.
>>
>> From what I can see, the guix-daemon is trying to find the authorized
>> key in /etc/guix/acl, but the key is added by Guix to
>> /usr/local/etc/guix/acl...
>
> Hmm you may be using two different ‘guix’ commands no?
>
>> 2. The error message should capture the complete error output to ease
>> debugging: we can see the useful message "25056 write(2, "guix
>> authenticate: error: error: unauthorized public key: (public-key \n (ecc
>> \n  (curve Ed25519)\n  (q
>> #EEA139318243D36EB4C728DB96856AB15C47AB64C765FA134CCFB12444B82A7C#)\n
>> )\n )\n", 176) = 176" in strace. Had I seen this from the start, we
>> would have saved some debugging time :).
>
> I agree.
>
>> I could work around the issue by copying manually the authorized key
>> sexp to /etc/guix/acl; I now see:
>>
>> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
>> guix offload: '192.168.1.105' is running guile (GNU Guile) 2.2.3
>> guix offload: Guix is usable on '192.168.1.105' (test returned 
>> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
>> sending 1 store item to '192.168.1.105'...
>> exporting path `/gnu/store/np9jwqvxjvasz41nrrh6g3gyn4rpkscw-export-test'
>> guix offload: '192.168.1.105' successfully imported 
>> '/gnu/store/np9jwqvxjvasz41nrrh6g3gyn4rpkscw-export-test'
>> retrieving 1 store item from '192.168.1.105'...
>> guix offload: error: build failed: implementation cannot deal with > 32-bit 
>> integers
>
> The log has this:
>
> 10529 write(4, "atad\0\0\0\0\0\200\0\0\0\0\0\0", 16) = 16
> 10529 read(4, 
> "W\1\0\0\0\0\0\0\1\0\0\0\0\0\0\0\r\0\0\0\0\0\0\0nix-archive-1\0\0\0\1\0\0\0\0\0\0\0(\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0type\0\0\0\0\7\0\0\0\0\0\0\0regular\0\10\0\0\0\0\0\0\0contents\23\0\0\0\0\0\0\000192.168.1.105-83353\0\0\0\0\0\1\0\0\0\0\0\0\0)\0\0\0\0\0\0\0NIXE\0\0\0\0007\0\0\0\0\0\0\0/gnu/store/wf774mzvfjpw306y5x06wid80d9k90qq-import-test\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0(protocol-error
>  1 \"getting status of `/etc/guix/signing-key.sec': Aucun fichier ou dossier 
> de ce "..., 32768) = 352
>
> Again the error should be reported…

Yes, this error was totally wrong, thanks for pointing it out. The
actual error was the 192.168.1.105 offload machine not finding the key
at /etc/guix/singning-key.sec (since it using the prefix
/usr/local/etc/guix for some reason).

I just did:

--8<---cut here---start->8---
sudo cp /usr/local/etc/guix/signing* /etc/guix/
--8<---cut here---end--->8---

And it is now working. Ouf!

Summarizing this adventure:

0) Make sure your .bashrc doesn't exit early when it is executed in
non-interactive mode (as is the case in Ubuntu).

1) Make sure the guix-authenticate program is available on the host as
well as the offload machines, by installing guix (guix package -i guix)
in the corresponding user profiles and sourcing
$HOME/guix.profile/etc/profile in the ~/.bashrc.

2) Make sure all your guix-daemons are configured to use /etc/guix as
their sysconfdir, as Guix offload currently seems hardcoded to only look
things under /etc/guix.

3) Don't trust any errors output by guix offload ;)

It'd be nice if this was as simple as setting up a Jenkins node... You
tell Guix which machine you want to use and give it SSH access, and it
does the required setup without having the user messing around with keys
and what not.

But I'm seeing far ahead. For now, we could start by adding some points
to the `guix offload` info manual. Then we can try to modify the code to
better capture the error messages. 

I'll start with the documentation.

Thank you,

Maxim

bug#26353: GuixSD /tmp cleaner fails to clean when Umlauts like "ä" are used in filenames

[Ludovic Courtès]

Nils Gillmann  skribis:

> Danny Milosavljevic transcribed 249 bytes:
>> > The problem of how to deal with file name encoding has been discussed on
>> > the Guile side so hopefully the next release in the 2.2 series will have
>> > a solution for this.
>> 
>> Hmm, any news on this?  I've again got some immortal files in /tmp ...
>
> Did it ever work for you? I can't recall a single time in my years with
> GuixSD when /tmp was cleaned. It was only when I started reading more
> system specific code that I found out that the lack of /tmp cleaning
> on shutdown is not a default.

This bug report is about the specific case where it doesn’t work.  :-)

Ludo’.

bug#26353: GuixSD /tmp cleaner fails to clean when Umlauts like "ä" are used in filenames

[Nils Gillmann]

Danny Milosavljevic transcribed 249 bytes:
> > The problem of how to deal with file name encoding has been discussed on
> > the Guile side so hopefully the next release in the 2.2 series will have
> > a solution for this.
> 
> Hmm, any news on this?  I've again got some immortal files in /tmp ...

Did it ever work for you? I can't recall a single time in my years with
GuixSD when /tmp was cleaned. It was only when I started reading more
system specific code that I found out that the lack of /tmp cleaning
on shutdown is not a default.

bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix

[myglc2]

Hi Ludo’,

On 06/17/2018 at 22:53 Ludovic Courtès writes:

> Hello,
>
> Mark H Weaver  skribis:
>
>> I should emphasize that when running Guix this way, if you wish to avoid
>> running 'guix pull', it's important to always keep at least one
>> known-good development environment for Guix saved as a GC root.  Toward
>> that end, when I run "guix environment guix" to update my development
>> environment profile, I make sure to preserve my previous profile as a GC
>> root until I'm confident that my new profile is working.
>
> The “make as-derivation” command aims to help with this bootstrapping
> problem: given an already installed Guix, it builds your checkout and
> its dependencies like ‘guix pull’ would do.  Thus, you can run:
>
>   $(make as-derivation)/bin/guix environment guix

Nice! This is news to me. Thank you for pointing it out.

Does 'make as-derivation' set the "current" symlink normally set by
'guix pull'?

TIA - George

bug#31786: 'pre-inst-env guix --version' is not updated by new commits"

[myglc2]

On 06/16/2018 at 00:24 Ricardo Wurmus writes:

> Ricardo Wurmus  writes:
>
>>> Proposed (revised) footnote:
>>>
>>> (3) The Guix version in the Guix build is set by './bootstrap'. Thus,
>>> the version reported by './pre-inst-env guix --version' is not updated
>>> by subsequent 'git pull; make' steps. To update the version (and rebuild
>>> everything), use 'git clean -dfx; ./bootstrap; ./configure; make'.
>>
>> I’m wary of adding this for similar reasons that Ludo wrote earlier.  In
>> my opinion this ends up cluttering the manual with notes and what I
>> consider to be only tangentially relevant for readers of the manual.
>
> An alternative might be to change the output of “guix --version” in the
> presence of GUIX_UNINSTALLED, which is set by “pre-inst-env”.  This
> could be a simple change in “show-version-and-exit” that would use
> something other than “%guix-version” when GUIX_UNINSTALLED is set.
>
> What do others think?
>
> --
> Ricardo

I like it.

bug#31825: guix offload fails with guix-authenticate error

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Attached is the log for the offloading machine.
>
> From what I can see, the guix-daemon is trying to find the authorized
> key in /etc/guix/acl, but the key is added by Guix to
> /usr/local/etc/guix/acl...

Hmm you may be using two different ‘guix’ commands no?

> 2. The error message should capture the complete error output to ease
> debugging: we can see the useful message "25056 write(2, "guix
> authenticate: error: error: unauthorized public key: (public-key \n (ecc
> \n  (curve Ed25519)\n  (q
> #EEA139318243D36EB4C728DB96856AB15C47AB64C765FA134CCFB12444B82A7C#)\n
> )\n )\n", 176) = 176" in strace. Had I seen this from the start, we
> would have saved some debugging time :).

I agree.

> I could work around the issue by copying manually the authorized key
> sexp to /etc/guix/acl; I now see:
>
> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
> guix offload: '192.168.1.105' is running guile (GNU Guile) 2.2.3
> guix offload: Guix is usable on '192.168.1.105' (test returned 
> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
> sending 1 store item to '192.168.1.105'...
> exporting path `/gnu/store/np9jwqvxjvasz41nrrh6g3gyn4rpkscw-export-test'
> guix offload: '192.168.1.105' successfully imported 
> '/gnu/store/np9jwqvxjvasz41nrrh6g3gyn4rpkscw-export-test'
> retrieving 1 store item from '192.168.1.105'...
> guix offload: error: build failed: implementation cannot deal with > 32-bit 
> integers

The log has this:

--8<---cut here---start->8---
10529 write(4, "atad\0\0\0\0\0\200\0\0\0\0\0\0", 16) = 16
10529 read(4, 
"W\1\0\0\0\0\0\0\1\0\0\0\0\0\0\0\r\0\0\0\0\0\0\0nix-archive-1\0\0\0\1\0\0\0\0\0\0\0(\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0type\0\0\0\0\7\0\0\0\0\0\0\0regular\0\10\0\0\0\0\0\0\0contents\23\0\0\0\0\0\0\000192.168.1.105-83353\0\0\0\0\0\1\0\0\0\0\0\0\0)\0\0\0\0\0\0\0NIXE\0\0\0\0007\0\0\0\0\0\0\0/gnu/store/wf774mzvfjpw306y5x06wid80d9k90qq-import-test\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0(protocol-error
 1 \"getting status of `/etc/guix/signing-key.sec': Aucun fichier ou dossier de 
ce "..., 32768) = 352
--8<---cut here---end--->8---

Again the error should be reported…

HTH,
Ludo’.

bug#31611: Add a property in packages to refresh to a specific version

[Marius Bakke]

Hartmut Goebel  writes:

> Am 29.05.2018 um 01:26 schrieb Marius Bakke:
>> Can we simply patch the KDE importer to stick with 5.12 for now?
>
> Not a good solution IMHO. For now I can also use "guix download"as a
> work-around This is not comfortable, but avoids having a forgotten
> "feature" in the code.

I'm not convinced that adding a property to some 80 packages is better
than patching the importer.  To me this problem seems very
importer-specific (knowing what releases are considered LTS).

As a middle ground, perhaps we could add a "--select" argument to guix
import, e.g: "--select=REGEXOnly consider versions matching REGEX".


signature.asc
Description: PGP signature

bug#31786: 'pre-inst-env guix --version' is not updated by new commits"

[Ricardo Wurmus]

Ricardo Wurmus  writes:

>> Proposed (revised) footnote:
>>
>> (3) The Guix version in the Guix build is set by './bootstrap'. Thus,
>> the version reported by './pre-inst-env guix --version' is not updated
>> by subsequent 'git pull; make' steps. To update the version (and rebuild
>> everything), use 'git clean -dfx; ./bootstrap; ./configure; make'.
>
> I’m wary of adding this for similar reasons that Ludo wrote earlier.  In
> my opinion this ends up cluttering the manual with notes and what I
> consider to be only tangentially relevant for readers of the manual.

An alternative might be to change the output of “guix --version” in the
presence of GUIX_UNINSTALLED, which is set by “pre-inst-env”.  This
could be a simple change in “show-version-and-exit” that would use
something other than “%guix-version” when GUIX_UNINSTALLED is set.

What do others think?

--
Ricardo

bug#31890: [bug#31893] [PATCH] gnu: elfutils: Update to 0.172.

[Marius Bakke]

Vagrant Cascadian  writes:

> The attached patch updates elfutils to the current version released
> earlier this month, fixing https://debbugs.gnu.org/31890 on aarch64.

Pushed as 59cf90ee4beab37169790a5925d0899170c9cb88, thank you!


signature.asc
Description: PGP signature

bug#31895: [cuirass] temporary network problems are fatal

[Ricardo Wurmus]

This is not correct.  An unfortunate coincidence in log rotation made it
seem as if Cuirass froze after the error, but it actually kept on going.

Sorry for the noise!

--
Ricardo

bug#31814: setuid programs are not first in PATH

[Clément Lassieur]

Ludovic Courtès  writes:

> Hello,
>
> Clément Lassieur  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>> diff --git a/gnu/system.scm b/gnu/system.scm
>>> index 7cb12a827..d367307a2 100644
>>> --- a/gnu/system.scm
>>> +++ b/gnu/system.scm
>>> @@ -616,9 +616,6 @@ unset PATH
>>>  GUIX_PROFILE=/run/current-system/profile ; \\
>>>  . /run/current-system/profile/etc/profile
>>>  
>>> -# Prepend setuid programs.
>>> -export PATH=/run/setuid-programs:$PATH
>>> -
>>>  # Since 'lshd' does not use pam_env, /etc/environment must be explicitly
>>>  # loaded when someone logs in via SSH.  See .
>>>  # We need 'PATH' to be defined here, for 'cat' and 'cut'.  Do this before
>>> @@ -645,6 +642,9 @@ do
>>>fi
>>>  done
>>>  
>>> +# Prepend setuid programs.
>>> +export PATH=/run/setuid-programs:$PATH
>>> +
>>>  # Arrange so that ~/.config/guix/current/share/info comes first.
>>>  export INFOPATH=\"$HOME/.config/guix/current/share/info:$INFOPATH\"
>>
>> Yes this sounds good.
>
> Pushed as a854525a34c42622a3945ffeb36781ae48a8267e.

Thank you!

Clément

bug#31895: [cuirass] temporary network problems are fatal

[Ricardo Wurmus]

Cuirass does not recover gracefully when it encounters network errors:

--8<---cut here---start->8---
2018-06-18T06:15:56 fatal: uncaught exception 'git-error' in 'build' fiber!
2018-06-18T06:15:56 exception arguments: (#< code: -1 message: 
"failed to connect to git.savannah.gnu.org: Connection timed out" class: 2>)
In ice-9/boot-9.scm:
829:9  5 (catch _ _ # ?)
   751:25  4 (dispatch-exception 0 git-error (#< code: -?>))
In cuirass/utils.scm:
169:8  3 (_ _ #< code: -1 message: "failed to connect?>)
In ice-9/boot-9.scm:
829:9  2 (catch #t # ?)
In cuirass/utils.scm:
   170:22  1 (_)
In unknown file:
   0 (make-stack #t)
ERROR: In procedure make-stack:
Throw to key `git-error' with args `(#< code: -1 message: "failed to 
connect to git.savannah.gnu.org: Connection timed out" class: 2>)'.
--8<---cut here---end--->8---

It should report the error and try again later.

--
Ricardo

bug#31814: setuid programs are not first in PATH

[Ludovic Courtès]

Hello,

Clément Lassieur  skribis:

> Ludovic Courtès  writes:

[...]

>> diff --git a/gnu/system.scm b/gnu/system.scm
>> index 7cb12a827..d367307a2 100644
>> --- a/gnu/system.scm
>> +++ b/gnu/system.scm
>> @@ -616,9 +616,6 @@ unset PATH
>>  GUIX_PROFILE=/run/current-system/profile ; \\
>>  . /run/current-system/profile/etc/profile
>>  
>> -# Prepend setuid programs.
>> -export PATH=/run/setuid-programs:$PATH
>> -
>>  # Since 'lshd' does not use pam_env, /etc/environment must be explicitly
>>  # loaded when someone logs in via SSH.  See .
>>  # We need 'PATH' to be defined here, for 'cat' and 'cut'.  Do this before
>> @@ -645,6 +642,9 @@ do
>>fi
>>  done
>>  
>> +# Prepend setuid programs.
>> +export PATH=/run/setuid-programs:$PATH
>> +
>>  # Arrange so that ~/.config/guix/current/share/info comes first.
>>  export INFOPATH=\"$HOME/.config/guix/current/share/info:$INFOPATH\"
>
> Yes this sounds good.

Pushed as a854525a34c42622a3945ffeb36781ae48a8267e.

Thanks,
Ludo’.

bug#31825: guix offload fails with guix-authenticate error

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hello,
>>
>> Maxim Cournoyer  skribis:
>>
>>> maxim@apteryx ~$ guix offload test
>>> guix offload: testing 1 build machines defined in 
>>> '/etc/guix/machines.scm'...
>>> guix offload: '192.168.1.105' is running guile (GNU Guile) 2.2.3
>>> guix offload: Guix is usable on '192.168.1.105' (test returned 
>>> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
>>> sending 1 store item to '192.168.1.105'...
>>> exporting path `/gnu/store/smgzvgc9krglk0mjpcscg5450l05w4dg-export-test'
>>> guix offload: error: build failed: program `guix-authenticate' failed
>>> with exit code 1
>>
>> On closer inspection, it looks like it may be ‘guix-authenticate’ on
>> “apteryx” that fails.  This could happen if there’s no signing key, for
>> instance, but you said there’s one, so I don’t know.
>>
>> Could you attach strace to guix-daemon on “apteryx” and run “guix
>> offload test” again?
>>
>> Use something like:
>>
>>   # strace -p $(pidof guix-daemon) -f -s 345 -o /tmp/log
>>
>> and then:
>>
>>   # guix offload test
>
> I've ran exactly those commands, and this produced the log attached
> (half a megabyte of text!). I looked at it but I can't seem to see
> what's wrong in there. I hope your trained eyes can see differently!

I don’t see “program `guix-authenticate' failed”, and indeed ‘guix
authenticate’ exits with code 0 (indicating success.)

Are you still getting the error above?

If so it may be that my diagnostic was wrong and that the authentication
failure happens on the other machine.  Could you strace guix-daemon on
that other machine similarly?

However, note that the log ended up containing a copy of your secret
key, /etc/guix/signing-key.sec; sorry for not thinking about this
before.  So once we’re done debugging, you should consider throwing away
that key and re-running “guix archive --generate-key”.  In the next
strace log you send, you might want to remove the private key (look for
an sexp starting with “(private-key …”).

Thanks,
Ludo’.