Feature idea: hook directory #139

New Issue

2025-12-29T00:25:43+01:00

adam commented

2025-12-29 00:25:43 +01:00

Originally created by @ChristianTacke on GitHub (Sep 8, 2016).

Using hooks with letsencrypt.sh is a really useful thing!

In a more complex scenario, one starts to have multiple hooks (deploying challenge to the web server, depoloying certs, restarting server…). Handling this in one big script can become confusing or even unmaintainable.

Idea: Run multiple scripts in a directory (like with the config directory). In fact my current main hook script has a call to "run-parts" in it to run the scripts in a directory. But maybe this wants to be integrated?

I am unsure, on how this relates to the hook-chain feature and how this works out for checking that a hook is available to deploy dns-01 challenges. This should be discussed, if there is interest in including this feature.

Originally created by @ChristianTacke on GitHub (Sep 8, 2016). Using hooks with letsencrypt.sh is a really useful thing! In a more complex scenario, one starts to have multiple hooks (deploying challenge to the web server, depoloying certs, restarting server…). Handling this in one big script can become confusing or even unmaintainable. Idea: Run multiple scripts in a directory (like with the config directory). In fact my current main hook script has a call to "run-parts" in it to run the scripts in a directory. But maybe this wants to be integrated? I am unsure, on how this relates to the hook-chain feature and how this works out for checking that a hook is available to deploy dns-01 challenges. This should be discussed, if there is interest in including this feature.

adam closed this issue

2025-12-29 00:25:43 +01:00

adam commented

2025-12-29 00:25:43 +01:00

@lukas2511 commented on GitHub (Sep 29, 2016):

I don't think it's worth the trouble, whoever needs this can easily build a simple wrapper using run-parts or whatever is available. If you want you can create a wiki-page for an example script, but having it as part of the main script... na..

@lukas2511 commented on GitHub (Sep 29, 2016): I don't think it's worth the trouble, whoever needs this can easily build a simple wrapper using run-parts or whatever is available. If you want you can create a wiki-page for an example script, but having it as part of the main script... na..

adam commented

2025-12-29 00:25:44 +01:00

@ChristianTacke commented on GitHub (Oct 12, 2016):

Well, why do you have a conf.d then? The admin could have written the 'for i in conf.d/*.conf; do source "$i"; done' into the main conf also?

@ChristianTacke commented on GitHub (Oct 12, 2016): Well, why do you have a conf.d then? The admin could have written the 'for i in conf.d/*.conf; do source "$i"; done' into the main conf also?

adam commented

2025-12-29 00:25:44 +01:00

@lukas2511 commented on GitHub (Oct 17, 2016):

The conf.d was mainly for package maintainers who ship a default config which can be changed in conf.d files. Yea it wasn't really necessary, but removing it now would also be bad, but I want to avoid adding more things that aren't necessary.

@lukas2511 commented on GitHub (Oct 17, 2016): The `conf.d` was mainly for package maintainers who ship a default config which can be changed in `conf.d` files. Yea it wasn't really necessary, but removing it now would also be bad, but I want to avoid adding more things that aren't necessary.

adam commented

2025-12-29 00:25:44 +01:00

@ChristianTacke commented on GitHub (Oct 17, 2016):

Well, I think, hook.d is most interesting to packagers as well.
See for example: https://bugs.debian.org/827371

And it might be helpful to have a consistent hook.d experience, especially concerning the chain feature of hooks.

@ChristianTacke commented on GitHub (Oct 17, 2016): Well, I think, `hook.d` is most interesting to packagers as well. See for example: https://bugs.debian.org/827371 And it might be helpful to have a consistent hook.d experience, especially concerning the chain feature of hooks.

adam commented

2025-12-29 00:25:45 +01:00

@gfarrell commented on GitHub (Nov 15, 2016):

Just to add my tuppence worth: I'm using a cloudflare hook for dns-01 verification, but also need to restart my nginx server once it's successful. I don't want to pollute the cloudflare hook with this because I have many machines and not all of them run an nginx instance, but all of them use cloudflare for verification. Having a directory of hooks would make this a lot easier!

(Or just the ability to have multiple hooks, is this possible?)

@gfarrell commented on GitHub (Nov 15, 2016): Just to add my tuppence worth: I'm using a cloudflare hook for dns-01 verification, but also need to restart my nginx server once it's successful. I don't want to pollute the cloudflare hook with this because I have many machines and not all of them run an nginx instance, but all of them use cloudflare for verification. Having a directory of hooks would make this a lot easier! (Or just the ability to have multiple hooks, is this possible?)

adam commented

2025-12-29 00:25:45 +01:00

@catvec commented on GitHub (Mar 28, 2017):

I made a wiki page showing how to use multiple hooks

@catvec commented on GitHub (Mar 28, 2017): [I made a wiki page showing how to use multiple hooks](https://github.com/lukas2511/dehydrated/wiki/Example:-Using-multiple-hooks)

adam commented

2025-12-29 00:25:45 +01:00

@kousu commented on GitHub (Apr 11, 2021):

I'm not a packager but I am a sysadmin using config management, which is basically the same thing, and I think this is a good idea. I can't isolate my daemons that use SSL from each other if I'm using dehydrated without this. It's okay to manually do something with run-parts or just paste together all your hooks into one script like in the wiki, but the manual labour becomes unmaintainable past two or three servers.

I'm working on a package at https://github.com/kousu/dehydrated-hooks to make a consistent way to interact with hooks, like @ChristianTacke suggested! So far it's installable on Debian. I haven't given it a workout yet but, if you're interested, give it a shot and give me some feedback.

🦆

@kousu commented on GitHub (Apr 11, 2021): I'm not a packager but I am a sysadmin using config management, which is basically the same thing, and I think this is a good idea. I can't isolate my daemons that use SSL from each other if I'm using `dehydrated` without this. It's okay to manually do something with `run-parts` or just paste together all your hooks into one script like in [the wiki](https://github.com/dehydrated-io/dehydrated/wiki/Example:-Using-multiple-hooks/fdf054d3de0d99d6b9df6ec543a198d4b9711de1), but the manual labour becomes unmaintainable past two or three servers. I'm working on a package at https://github.com/kousu/dehydrated-hooks to make a consistent way to interact with hooks, like @ChristianTacke suggested! So far it's installable on Debian. I haven't given it a workout yet but, if you're interested, give it a shot and give me some feedback. :duck:

adam commented

2025-12-29 00:25:45 +01:00

@kousu commented on GitHub (Apr 12, 2021):

I've come up with an argument against: the whole design of letsencrypt assumes that there are wide windows of time involved, so maybe it's better to just use cron for everything you might do with deploy-cert. Certs are supposed to be renewed 30 days in advance, maybe 29 or 28 days if something glitches out, which means it's no problem if your daemons use the old certs for a while. For example, put

# /etc/cron.d/nginx
30 2 * * * systemctl reload nginx

# /etc/cron.d/lockdown-keyfile
# opensmtpd refuses to use a cert that's not 0400 root:root; but other apps like radicale *require* 0440 root:ssl-cert
30 2 * * * cp /var/lib/dehydrated/certs/privkey.pem /var/lib/dehydrated/certs/privkey.locked.pem && chmod 400 /var/lib/dehydrated/certs/privkey.locked.pem

Plus, this is more fiable because a failure in one hook can't (or at least is a lot less likely to) wreck the others -- and if it does, it will just try again in 24 hours. Because polling is more expensive but more reliable than eventing.

I guess this isn't such an issue with deploy-challenge and clean-challenge; but I can't think of a use case where you need multiple hooks for those. Maybe if you want to use HTTP-01 for some domains and DNS-01 for others? But...why?

What I do think would be useful would be separating the 3 kinds of hooks into separate files so they can be managed orthogonally, and I've done that in https://github.com/kousu/dehydrated-hooks.

@kousu commented on GitHub (Apr 12, 2021): I've come up with an argument against: the whole design of letsencrypt assumes that there are wide windows of time involved, so maybe it's better to just use cron for everything you might do with `deploy-cert`. Certs are supposed to be renewed 30 days in advance, maybe 29 or 28 days if something glitches out, which means it's no problem if your daemons use the old certs for a while. For example, put ``` # /etc/cron.d/nginx 30 2 * * * systemctl reload nginx ``` ``` # /etc/cron.d/lockdown-keyfile # opensmtpd refuses to use a cert that's not 0400 root:root; but other apps like radicale *require* 0440 root:ssl-cert 30 2 * * * cp /var/lib/dehydrated/certs/privkey.pem /var/lib/dehydrated/certs/privkey.locked.pem && chmod 400 /var/lib/dehydrated/certs/privkey.locked.pem ``` Plus, this is more fiable because a failure in one hook can't (or at least is a lot less likely to) wreck the others -- and if it does, it will just try again in 24 hours. Because polling is more expensive but more reliable than eventing. I guess this isn't such an issue with `deploy-challenge` and `clean-challenge`; but I can't think of a use case where you need multiple hooks for those. Maybe if you want to use HTTP-01 for some domains and DNS-01 for others? But...why? What I do think would be useful would be separating the 3 kinds of hooks into separate files so they can be managed orthogonally, and I've done that in https://github.com/kousu/dehydrated-hooks.

adam commented

2025-12-29 00:25:45 +01:00

@kousu commented on GitHub (Apr 20, 2021):

I've given my package a workout. It works: https://github.com/kousu/dehydrated-hooks/releases/tag/1.0.0. But I still think you should probably just use cron.

@kousu commented on GitHub (Apr 20, 2021): I've given my package a workout. It works: https://github.com/kousu/dehydrated-hooks/releases/tag/1.0.0. But I still think you should probably just use cron.

adam referenced this issue

2025-12-29 01:28:42 +01:00

[PR #139] [MERGED] Skip non-folder entries on cleanup. #731

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#139