[Certbot-dev] Hook Directories
bmw at eff.org
Tue Sep 19 16:05:05 PDT 2017
This conversation was continued offline, but I'm happy to continue to
discuss this or other approaches if anyone else is interested.
On 09/19/2017 02:14 PM, Jacob Hoffman-Andrews wrote:
> 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