I sympathize with your approach (I, too, have been supplementing Certbot with self-signed certs for some time).
What would also be cool is not to have `certbot-service-type` depend on `nginx-service-type` in the first place. So that one can more easily use another HTTP server. It can of course be achieved with `remove-service-extensions` from `(gnu services)`, it's just less elegant than having it supported directly. Perhaps some variant of the "dependency inversion principle" would fit here? How about the following set of service types? - certbot-tool-service-type — does what `certbot-service-type` used to do until now except it doesn't extend `nginx-service-type` and can itself be extended with not just `<certificate-configuration>`s but also `<certbot-configuration>` - certbot/nginx-service-type — takes in `<certbot-configuration>`, extends both `certbot-tool-service-type` and `nginx-service-type` - certbot/httpd-service-type — takes in `<certbot-configuration>`, extends both `certbot-tool-service-type` and `httpd-service-type` - certbot-service-type — deprecated, functions as an alias for `certbot/nginx-service-type` Your proposals are of course useful as well, regardless of this being done Best :) Wojtek -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Wed, 31 Jan 2024 08:48:54 +1100 Carlo Zancanaro <ca...@zancanaro.id.au> wrote: > Hi Felix, > > On Tue, Jan 30 2024, Felix Lechner wrote: > > On Tue, Jan 30 2024, Carlo Zancanaro wrote: > >> certbot can't produce certificates without a functional nginx > > > > Yes, it can. The option is called --standalone. [1] > > You are correct, of course. If I had been more precise I would > have said "with our current configuration, certbot can't produce > certificates without a functional nginx". > > > Maybe another way to bootstrap the certificates would be to hold > > off on starting Nginx or Apache until all certificates are > > obtained? > > This could work, but I see a few downsides. > > As Clément has already mentioned, this would make nginx dependent > on certbot. This causes problems for servers disconnected from the > general internet, but it also shifts complexity into the nginx > service without much benefit over the patch series I'm proposing. > We'd need to add more configuration on the nginx side to control > whether to delay startup based on whether we actually want > certificates. This would delay the startup of the whole nginx > process, even if some server configurations don't require new > certificates. > > For renewal, we would also have two options: (1) use --standalone, > and require a period of downtime for our web server; or (2) use > --webroot, and maintain two code paths for the two cases. I think > it's a bad idea for Guix to make a decision that requires downtime > of user systems if there's an alternative, so I don't like (1). > Maintaining two "similar but different" code paths for (2) doesn't > seem like a clear advantage over the patch series I'm proposing. > > > Anyway, that's what I do manually. > > I use the DNS challenge type, with hooks which automatically > create/remove DNS records. This solves all the problems I'm > bringing up (i.e. doesn't require nginx, doesn't involve downtime, > has a single code path), but I don't think Guix can assume that > all users have the ability to do this. My aim with this patch > series is to make the default certbot configuration work for the > common case of a simple web server, without manual intervention. > > Carlo >
pgpSZ531cwTun.pgp
Description: OpenPGP digital signature
