[Certbot-dev] Hook Directories

[Brad Warren]

On 09/18/2017 05:00 PM, Jacob Hoffman-Andrews wrote:
>
> Could this be solved instead by having a global config for Certbot that
> sets default values for certain flags? For instance, right now
> --renew-hook defaults to the empty string. But what if an OS packager
> could default it to "run-parts /etc/ssl/renew-hooks.d/" ? The global
> defaults approach would also be a nice solution to the question about
> log rotation defaults, since OS packagers that know there is a logrotate
> config could set the --max-log-backups flag appropriately.
There may be some issues with precedence between this file and the CLI
(see https://github.com/bw2/ConfigArgParse/issues/58), otherwise, I
think we already have this with Certbot's global configuration file
documented at
https://certbot.eff.org/docs/using.html#configuration-file. I referred
to this as the INI file in my initial email.

Assuming something like this is what you had in mind, there are two
inconveniences with this approach:

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.
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".

In a very similar vein though, one of the alternative suggestions I made
to members of the Certbot team who were interested in this issue was to
change Certbot's behavior so hook values provided on the command line or
in a global config file are run in addition to any hooks defined per
lineage when using the "renew" subcommand. Using this approach, the
crontab provided by the distro can define hooks on the command line
using run-parts and problem 2 is solved. This means allowing Certbot
hook usage to be complicated by problem 1 though.
>
> I think this only works if the package is part of an OS, and so the
> package maintainer knows exactly where to put the hooks. So I think the
> idea above would also work for this case.
>
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 Certbot does not have this functionality itself though and we leave
defining the location of these directories to the distro, I think you're
right that people don't have a system agnostic way to do this.