[bug#43155] [PATCH] hydra//build-machines: Update childhurd-net-options for secret-service.

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Ludovic Courtès writes:
>
> Hi!
>
>> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>>
>>> With bug https://bugs.gnu.org/43106 just closed we now have a nice way
>>> to inject secrets into the Childhurds.
>>>
>>> Using the attached patch, which needs a fresh pull and reconfigure on
>>> berlin (at least the nodes 101,102 that run Childhurds), we can create a
>>> tree of childhurd secrets like so
>>>
>>> /etc/childhurd/etc/guix/signing-key.pub
>>> /etc/childhurd/etc/guix/signing-key.sec
>>> /etc/childhurd/etc/ssh/ssh_host_ed25519_key
>>> /etc/childhurd/etc/ssh/ssh_host_ecdsa_key
>>> /etc/childhurd/etc/ssh/ssh_host_ed25519_key.pub
>>> /etc/childhurd/etc/ssh/ssh_host_ecdsa_key.pub
>>>
>>> ...and then we should be able to start offloading builds for the Hurd.
>>
>> Yup!  Probably we’ll create /etc/childhurd/HOST for each VM, so we also
>> need to adjust <hurd-vm-configuration> accordingly, right?
>
> Yes, we can add something like
>
>       (secret-root (format #f "/etc/childhurd/~a" id))
>
> to the
>
>     (service hurd-vm-service-type
>         (hurd-vm-configuration
>           ...

Sounds good.

> (i'm a bit curious, though, why we would want to differentiate between
> childhurds, they can be all identical?)

Well, dunno if it really matters for our specific use case, but it seems
“cleaner” to me to give each childhurd its identity.  OTOH, these are
VMs and they run on the same physical machine, so…

>> (I realize that the current code will silently keep going if we forget
>> to put the secret files in place; IOW, the service config doesn’t show
>> the files we intended to push as secrets.  Oh well, we’ll see that
>> later.)
>
> Yes, I guess that's a feature -- "you" can start it once, then do
> something like
>
>     mkdir -p /etc/childhurd/etc
>     scp -r childhurd:/etc/guix /etc/childhurd/etc
>     scp -r childhurd:/etc/ssh /etc/childhurd/etc

Right, that can be convenient.  OTOH, from the perspective of having
declarative OS configs, it’s not great because this aspect of the config
are left out.  But maybe that’s an issue we can have if/when we
generalize ‘secret-service-type’.

>>> (I guess we then also need to add a cuirass jobs for the Hurd?)
>>
>> Yes, or maybe just change ‘systems’ in the Cuirass specs for
>> ‘guix-master’, but then it’ll try to build everything for GNU/Hurd,
>> which doesn’t sound like a great idea for now.
>
> I agree, not much sense in that yet.
>
>> Perhaps we can simply add a separate jobset pulling from ‘master’ but
>> building only for i586-gnu and only the “core” package set?
>
> Hmm, why can't I find the definition of "core"?.  Anyway, It would be a
> great first step to build (everything needef for) "hello", after that we
> want to have/try "guile-3.0" and possibly "guix".

Sure.  The “core” subset is defined in (gnu ci).

>>>>From 6d1c388ed82c260af27b556c0677e780ee410b05 Mon Sep 17 00:00:00 2001
>>> From: "Jan (janneke) Nieuwenhuizen" <janneke@gnu.org>
>>> Date: Tue, 1 Sep 2020 16:31:42 +0200
>>> Subject: [PATCH] hydra//build-machines: Update childhurd-net-options for
>>>  secret-service.
>>> Content-Transfer-Encoding: 8bit
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> * hydra/modules/sysadmin/build-machines.scm (berlin-new-build-machine-os)
>>> [childhurd-net-options]: Include secret-service local QEMU forwarding.
>>> Use variables from (gnu services virtualization).
>>
>> LGTM, thanks!
>
> Great, pushed to guix-maintenance as 04c0fc1ea110b82d6180bbc1b2f895e55e746cd8

Thanks!

Ludo’.