Partly fixes <https://issues.guix.gnu.org/55848>. Reported by Tom Fitzhenry <tom@tom-fitzhenry.me.uk>. * hydra/modules/sysadmin/honeycomb.scm (honeycomb-system): Add 'substitute-urls' to 'cuirass-remote-worker-configuration'. * doc/cuirass.org (Connect an external machine): Likewise.
4.3 KiB
Cuirass manual is available here. Here are a few notes relative to its integration.
Berlin
Cuirass is running on the Berlin build farm. It is configured to use the remote build mode. Around 30 machines, accessible on Berlin local network are running Cuirass workers. Those machines are named hydra-guix-101 to hydra-guix-129. Their architecture is x86_64-linux, but they are also configured to emulate builds on other architectures.
Other machines such as the Overdrives are not physically located on the Berlin
build farm but, are still accessible via Wireguard on the 10.0.0.0/24
local
network. The next section describes how to add a new external machine.
External machines
Machine | Address | Contact |
---|---|---|
overdrive1 | 10.0.0.3 | Ludovic Courtès |
dover | 10.0.0.4 | Andreas Enge |
guix-x15 | 10.0.0.5 | Simon Josefsson |
guix-x15b | 10.0.0.6 | Simon Josefsson |
guixp9 | 10.0.0.7 | Tobias Geerinckx-Rice |
pankow | 10.0.0.8 | Ricardo Wurmus |
kreuzberg | 10.0.0.9 | Ricardo Wurmus |
grunewald | 10.0.0.10 | Ricardo Wurmus |
bayfront | 10.0.0.11 | Andreas Enge |
jade | 10.0.0.12 | Chris Marusich |
Connect an external machine
- Install Guix System on the external machine. The Wireguard and Cuirass
worker services must be properly configured. The
(sysadmin overdrive)
module can be used as an example. The Cuirass worker service should look like:
(service cuirass-remote-worker-service-type
(cuirass-remote-worker-configuration
(workers 2)
(server "10.0.0.1:5555") ;berlin
(substitute-urls '("http://10.0.0.1"))
(systems '("armhf-linux" "aarch64-linux"))))
The server field contains the Cuirass remote-server running on Berlin address. It must not be changed.
The systems must be adjusted to the external machine supported architectures, emulated or not.
(service wireguard-service-type
(wireguard-configuration
(addresses (list "10.0.0.x/32"))
(peers
(list (wireguard-peer
(name "peer")
(endpoint "ci.guix.gnu.org:51820")
(public-key "wOIfhHqQ+JQmskRS2qSvNRgZGh33UxFDi8uuSXOltF0=")
(allowed-ips '("10.0.0.1/32"))
(keep-alive 25)))))
The only field to be edited in the Wireguard service is the addresses
field. It is the address of the new external machine on the Wireguard
subnet. An available address must be picked, see the External machines
section above. This section must be updated accordingly.
The keep-alive at 25 secondes is important if the remote machine is sitting behind a NAT. More details in the "NAT and Firewall Traversal Persistence" section of the Wireguard quick start guide.
- Add the external machine Wireguard public key on Berlin. The new external machine public key can be obtained this way:
guix environment --ad-hoc wireguard-tools -- sudo -E wg
The wireguard-service-type
of berlin.scm file must be updated
accordingly, by adding a new wireguard-peer
this way;
(wireguard-peer
(name "new-machine")
(public-key "public-key")
(allowed-ips '("10.0.0.x/32")))
- Add the external machine Guix signing key to
hydra/keys/guix/berlin
directory. See this page for more information. - Make sure that the UDP port
51820
that is used by Wireguard is accessible on the external machine. You might need to configure your ISP router NAT table accordingly. You can check that the external machine is accessible from berlin by running:
ssh 10.0.0.x
The external machine should eventually appear here and start building some packages.