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
