all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: swedebugia <swedebugia@riseup.net>
To: 31825@debbugs.gnu.org, maxim.cournoyer@gmail.com, ludo@gnu.org
Subject: bug#31825: guix offload fails with guix-authenticate error
Date: Wed, 20 Jun 2018 05:54:44 +0200	[thread overview]
Message-ID: <FA68E4DB-4C0B-4680-915C-4D1CCB5989A4@riseup.net> (raw)
In-Reply-To: <87vaae40wh.fsf@gmail.com>

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

Hi

On June 20, 2018 5:01:02 AM GMT+02:00, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>Hi!
>
>ludo@gnu.org (Ludovic Courtès) writes:
>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> 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 

[-- Attachment #2: Type: text/html, Size: 5049 bytes --]

  reply	other threads:[~2018-06-20  3:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14  3:54 bug#31825: guix offload fails with guix-authenticate error Maxim Cournoyer
2018-06-14 22:08 ` Ludovic Courtès
2018-06-18  2:31   ` Maxim Cournoyer
2018-06-18  8:32     ` Ludovic Courtès
2018-06-19  2:35       ` Maxim Cournoyer
2018-06-19  9:28         ` Ludovic Courtès
     [not found]           ` <871sd354mb.fsf@gmail.com>
2018-06-19 14:49             ` Ludovic Courtès
2018-06-20  3:01               ` Maxim Cournoyer
2018-06-20  3:54                 ` swedebugia [this message]
2018-06-22  2:13                   ` Maxim Cournoyer
2018-06-20 14:06                 ` Ludovic Courtès
2020-02-22  5:18                   ` Maxim Cournoyer
2021-08-08  4:09                     ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FA68E4DB-4C0B-4680-915C-4D1CCB5989A4@riseup.net \
    --to=swedebugia@riseup.net \
    --cc=31825@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.