Hi Ludo, thanks for your speedy reply!
For this reason, the signing key of the machine where ‘guix deploy’
runs, which is under /etc/guix/signing-key.pub, must be authorized on
the remote machine. This is a one-time setup you need to do manually:
Thank you, I will try this. I knew about this step, but didn't think I
had to do it. From "invoking guix deploy":
Do note that you first need to generate a key pair on the coordinator
machine to allow the daemon to export signed archives of files from
the store (see Invoking |guix archive|
<https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-archive.html>),
though this step is automatic on Guix System:
# guix archive --generate-key
Each target machine must authorize the key of the master machine so
that it accepts store items it receives from the coordinator:
# guix archive --authorize < coordinator-public-key.txt
I took this to mean that the trust step would be automated, but I guess
it just means that generating the signing key is automated. I do have
ssh access to the remote, so I guess it would be safe for that step to
be automatic. I originally tried the following snippet:
λ. ssh root@2001:4d78:630:d0:3::1 "guix archive --authorize" <
/etc/guix/signing-key.pub
guix archive: warning: replacing symbolic link /etc/guix/acl with a
regular file
hint: On Guix System, add all `authorized-keys' to the `guix-service-type'
service of your `operating-system' instead.
and if I go to the remote server I can indeed see the key in /etc/guix/acl.
root@minimal-guix-hosting-com ~# cat /etc/guix/acl
(acl
(entry
(public-key
(ecc
(curve Ed25519)
(q #10539EDF38DB50288DD75D6AD36D8E44B1C08B4CF4A630CC33BE0D395ECFA5F9#)
)
)
(tag
(guix import)
)
)
(entry
(public-key
(ecc
(curve Ed25519)
... more keys
However I still get "unauthorized key" in this case. If instead I add my
local key automagically with the following procedure:
(define (add-deploy-machine os)
(let ((%authorized-keys
(cons (local-file "/etc/guix/signing-key.pub"))))
(modify-service os guix
(authorized-keys %authorized-keys))))
everything works perfectly - I get a completely successful deployment
and everything seems to be updated correctly. The file /etc/guix/acl on
the service appears to now be a symlink with the same content as the
plain file before. This was surprising - I expected the "hint" to mean
"it's easier to do it this other way, but what you did will still work".
I wonder why you’re seeing new generations being created on the target
machine. Could it be that you tried with (build-locally? #f) at one
point?
I definitely have been changing build-locally between #t and #f. However
I have also definitely seen new generations created while the reported
error happens (and with build-locally? #t). For example (without
changing the deploy script) I did a test deployment overnight, and I can
see the generation with guix system describe and guix system
list-generations. It was described as the current generation. However,
the deployment did not look like it worked completely - the deployed
configuration mentioned wireguard for example, but wireguard was not
available as a service (and it is now that the deployment has completed
successfully).
I am now unstuck - thank you for your help. It's not clear to me whether
guix is behaving the way it's intended or not, but the fix is actually
very easy once you know what to do. It might be nice to have a snippet
in the manual about exactly how to use modify-services in this case, if
it is indeed expected to work this way.
Best wishes,
Dan
