Hi!
* Julien Cristau <jcristau@debian.org> [2017-11-22 12:16:05 +0100]:
> [not speaking for DSA as a whole so there may be other ideas/concerns]
>
> On 11/22/2017 01:38 AM, Nicolas Dandrimont wrote:
> > I've been working on integrating the setup/teardown of the streaming network
> > with our ansible repository and here are the things that would be useful:
> >
> > 1/ DNS updates
> >
> > We would like to be able to update DNS entries for a subtree of debconf.org to
> > accommodate dynamic cloud instances. Our previous setup used video.debconf.org,
> > but we would like to move *streaming* to *.live.debconf.org, which will allow
> > video.debconf.org to be reused for a static documentation / video player /
> > streaming player website. Could we enable the videoteam user on vittoria (or
> > another role user) to do so?
>
> Is the idea to have DNS updates triggered automatically or by humans?
> If the former, I wonder if using a third party DNS provider's API would
> be better than direct git commits to our repo. We recently got access
> to netnod's API thing, so that might be an option (haven't played with
> it yet). Something like route53 might be another. If updates would be
> triggered by humans then we could give those users access to the zone.
Having it controlled by humans through your git repo now (so we're sure we can
have things set up for the miniconf without poking you too much), and scripting
an external API during our sprint so we can have a turn-key setup for future
events sounds like a fair compromise.
I propose the following zones:
- live.debconf.org controlled through git by {olasd@d.o, ivodd@d.o, stefanor@d.o}
- live-test.debconf.org to be set up to be handled by an external API
Once the external API has been tested we can switch that over.
> > 2/ Cloud instance spin-up/teardown
> >
> > I've written a small set of python3 scripts using the DigitalOcean API to
> > setup/teardown machines; As this needs an API key for our DigitalOcean account,
> > we would like to allow a role user to run the scripts on vittoria. Ideally this
> > role user would also be able to run ansible to set the machines up after they
> > spin up. If you think that's sensible I'll provide you with an update to the
> > debian.org metapackages for the needed dependencies.
> >
> Sounds fine to me.
Ack.
> > 3/ TLS certificate distribution for the streaming network
> >
> > Our streams are now fully HTTPS. During DebConf17, we used certbot to generate
> > certificates manually on one of the machines (with the http-01 challenge) and
> > then used ansible to push the private and public keys to the rest of the mirror
> > network.
> >
> > Would it be possible to integrate ourselves in your letsencrypt setup, having a
> > way to provide the aforementioned videoteam role user with the tls key/cert
> > pair for pushing to the streaming network through ansible?
> >
> I don't think that's a good way to go, our setup works for
> puppet-managed hosts but sending out keys to the world seems a bit ick.
>
> What are the actual requirements here? If you have access to the DNS
> zone per 1) above, would handling dns-01 challenge yourselves work just
> as well?
We need:
- a TLS certificate pair for https on the streaming backend, with SAN
backend.live.debconf.org
- TLS certificate pairs for https on the streaming frontends, with SANs
<vmname>.live.debconf.org and {an,as,eu,na,oc,sa}.live.debconf.org
(geographic redirects).
Plugging ourselves into your certificate machinery was less work for us (in
concrete terms, it would just be a matter of making the certificate pair
available to the video-ansible role user on vittoria), and allows you to
tighten down certificate issuance for debconf.org as you see fit.
If we're getting direct control of the DNS zone, we can certainly generate
certificates ourselves, using the dns-01 or http-01 challenge on the end
machines, if you're fine with it.
Thanks!
--
Nicolas Dandrimont
"sic transit discus mundi"
(From the System Administrator's Guide, by Lars Wirzenius)
Attachment:
signature.asc
Description: PGP signature