From: Wojtek Kosior via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>
To: Carlo Zancanaro <carlo@zancanaro.id.au>
Cc: Felix Lechner <felix.lechner@lease-up.com>,
46961@debbugs.gnu.org, clement@lassieur.org, brice@waegenei.re,
guix-devel@gnu.org
Subject: Re: [PATCH v2 0/4] Make certbot play more nicely with nginx
Date: Wed, 31 Jan 2024 01:04:12 +0100 [thread overview]
Message-ID: <20240131010412.299d6a03.koszko@koszko.org> (raw)
In-Reply-To: <87r0hyphni.fsf@zancanaro.id.au>
[-- 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 --]
next prev parent reply other threads:[~2024-01-31 0:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1706098718.git.carlo@zancanaro.id.au>
2024-01-30 13:26 ` [PATCH v2 0/4] Make certbot play more nicely with nginx Carlo Zancanaro
2024-01-30 13:26 ` bug#46961: " Carlo Zancanaro
2024-01-30 14:49 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-01-30 21:48 ` Carlo Zancanaro
2024-01-31 0:04 ` Wojtek Kosior via Development of GNU Guix and the GNU System distribution. [this message]
[not found] ` <875xzanaer.fsf__22488.5524179385$1706626282$gmane$org@lease-up.com>
2024-01-30 19:39 ` bug#46961: " Clément Lassieur
2024-04-13 1:17 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-04-14 11:42 ` Carlo Zancanaro
2024-04-14 13:51 ` Carlo Zancanaro
2024-04-14 16:25 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-01-30 13:26 ` [PATCH v2 1/4] services: certbot: Symlink certificates to /etc/certs Carlo Zancanaro
2024-01-30 13:26 ` [PATCH v2 2/4] services: certbot: Create self-signed certificates before certbot runs Carlo Zancanaro
2024-01-30 13:26 ` [PATCH v2 3/4] services: certbot: Add a default deploy hook to reload nginx Carlo Zancanaro
2024-01-30 13:26 ` [PATCH v2 4/4] services: certbot: Add one-shot service to renew certificates Carlo Zancanaro
2024-01-30 13:26 ` bug#46961: " Carlo Zancanaro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240131010412.299d6a03.koszko@koszko.org \
--to=guix-devel@gnu.org \
--cc=46961@debbugs.gnu.org \
--cc=brice@waegenei.re \
--cc=carlo@zancanaro.id.au \
--cc=clement@lassieur.org \
--cc=felix.lechner@lease-up.com \
--cc=koszko@koszko.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).