[Certbot-dev] Hook Directories

Jacob Hoffman-Andrews jsha at eff.org
Tue Sep 19 14:14:20 PDT 2017

On 09/18/2017 06:11 PM, Brad Warren wrote:
> 1. This approach causes fragmentation between different distros as how
> the users can/should use hooks varies. While we can only do so much to
> prevent this, we'd like to prevent there being significant differences
> in how you use Certbot on different systems. We've been having package
> maintainers hold off on adding something like this to their packages so
> a change could be landed in our git repo and everyone could benefit.

I'm mostly familiar with the Debian/Ubuntu style run-parts foo.d
approach. How do other distributions approach this question?

> 2. There are also the problems mentioned in my previous email about the
> INI file. These are that these values currently override any hooks
> defined per lineage (rather than getting run in addition to those hooks)
> and they are also run for the "certonly" and "run" subcommands rather
> than just "renew".

It seems like the precedence should be flipped, and flags defined in
per-lineage renewal configs should override the global defaults. This
makes it easier to say "this certificate is for software X, and only
software X should be reloaded on renewal." Otherwise every piece of
software that potentially uses certificates will always get reloaded on
every renewal, which may cause unnecessary load spikes at renewal time.

> I think it depends. If Certbot has a consistent default where hook
> directories could be found, a developer or packager building around
> Certbot can probably assume their hooks should be placed at a specific
> location. In theory, the distro may have changed Certbot's default
> directory locations, but we've never seen this in practice.

If a packager is building around Certbot, the location of the hook
directories will be defined by their OS. For packages installed with
"make install", or "pip install", I think they generally don't know
enough about their environment to be willing to install a hook into
/etc/letsencrypt/hooks.d/, even if Certbot defaults to that. Do we have
statements of interest from developers who want their "make install",
"pip install", or equivalent install steps to install such hooks?

More information about the Certbot-dev mailing list