Hi Ludo! ludo@gnu.org (Ludovic Courtès) writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> ludo@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? Yes. > 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 …”). Oh, thanks for letting me know. I will recreate both keys when we're done. 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... So, the original two issues: 1. `guix offload' doesn't seem to honor nixConfDir (which the daemon on the offload machine knows as "/usr/local/etc/guix"). 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 :). What do you think? I could work around the issue by copying manually the authorized key sexp to /etc/guix/acl; I now see: --8<---------------cut here---------------start------------->8--- 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 --8<---------------cut here---------------end--------------->8--- This appear to be caused by the 'apteryx' GuixSD machine where I run 'guix offload test'. I've attached another strace output capturing this. Thanks! Maxim