Re: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Wojtek Kosior via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3985 bytes --]

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 <carlo@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
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]