Subject: Re: [bug#67497] [PATCH] Multiple deploy hooks in certbot service

From: Carlo Zancanaro <[email-masked]>
Date: Tue, 18 Feb 2025 11:00:34 +1100

Given this thread came up on guix-devel, and I use certbot and have
opinions, I thought I might chime in on this.

On Sat, Dec 16 2023, Bruno Victal wrote:
> As Arun pointed out, I don't think multiple deploy hooks would be
> adding value here.

I disagree. I think adding multiple deploy hooks would be adding value,
even beyond just reducing syntactic overhead (which is valuable itself).
Having a list of hooks has two benefits that I can see:

1. A list of hooks can be introspected by Scheme code, which lets us
write code to manipulate certbot-configuration objects. In particular,
it would make it easier to write code to add hooks without accidentally
duplicating existing hooks, and it would make it possible to write code
to remove hooks. I could easily see this being used in an enhancement to
the certbot-service-type extension mechanism where multiple services
extending certbot-service-type could be combined into a single
certificate (where the domains match, and whatnot).

2. A list of hooks makes it easier to read your configuration, and makes
it obvious that we're intending to support small, specific, deploy
hooks. This is a social argument, rather than a technical one. Even with
no change in expressive power, our interfaces do communicate how we
intend for them to be used. Having a list communicates "we expect each
hook to do one thing", which feels good to me.

At the very least, even if we don't go with list of deploy-hooks, we
could get some improvement by having an official gexp helper
"invoke-all" which calls invoke on each of its gexp arguments in
turn. This would be more generally useful for gexp composition, but then
it would also be less obvious than a deploy-hooks list (unless you're
already very familiar with gexps).

> What would be interesting though is adding service-extensions support
> for certbot-service-type.

I'm not entirely sure what you mean by this. certbot-service-type
already supports extensions?

On Sat, Dec 16 2023, Bruno Victal wrote:
> [...] for the record mine looks like this:
>
> --8<---------------cut here---------------start------------->8---
> (program-file "certbot-hook.scm"
>   ;; source-module-closure not used here because at the time of writing
>   ;; (gnu services herd) only uses Guile modules.
>   (with-imported-modules '((gnu services herd))
>     #~(begin
>         (use-modules (gnu services herd))
>         (with-shepherd-action 'nginx ('reload) result result)
>         (restart-service 'dovecot)
>         (restart-service 'smtpd))))
> --8<---------------cut here---------------end--------------->8---

As a bit of fun: do you know the difference between this hook, and the
equivalent using multiple --deploy-hook arguments? Error handling and
logging. With multiple deploy-hooks, I believe Cerbot will always run
all of them, and will report errors for each of them individually. An
error restarting dovecot shouldn't prevent smtpd from restarting, but in
your gexp it would (although I'm not actually sure how herd reports
errors here - my point is more general than this specific example).

The more we ask people to plumb things together themselves, the more we
ask them to decide themselves about error handling and logging. Which
means that error handling and logging will be an afterthought at best.
If you want to put things in one gexp you still can, but making it the
only option leaves less room for Certbot to "add value" in handling
these things for us.

Carlo