cron output suggestion #178

New Issue

adam · 2025-12-29T00:26:40+01:00

adam commented

2025-12-29 00:26:40 +01:00

Originally created by @internationils on GitHub (Jan 2, 2017).

I just got through https://github.com/lukas2511/dehydrated/issues/47 and have a suggestion.

I agree that doing detailed message and log handling in the script is difficult, as many people have different opinions and needs for the messages. Would it be possible to have a 'done' hook that gets called with the exit status and unchanged / changed as a parameter?

Then the (cron) logging would work as follows:

cron job writes a logfile wherever (can decide to /dev/null it, tee it, pipe it to a log, whatever)
final hook gets the exit status and action status and can decide to mail the log, do nothing, or whatever

The only question is if there need to be two hooks: done_domain and done_dehydrated, with one being called when each domain is done with result and action for each domain, and the other with the success / fail result for all domains (when processing multiples) and the action (unchanged / changed). This seems like it would keep the dehydrated script simple (only the exit code and action need to be tracked), and the users can do whatever they need in the hook.

Originally created by @internationils on GitHub (Jan 2, 2017). I just got through https://github.com/lukas2511/dehydrated/issues/47 and have a suggestion. I agree that doing detailed message and log handling in the script is difficult, as many people have different opinions and needs for the messages. Would it be possible to have a 'done' hook that gets called with the exit status and unchanged / changed as a parameter? Then the (cron) logging would work as follows: - cron job writes a logfile wherever (can decide to /dev/null it, tee it, pipe it to a log, whatever) - final hook gets the exit status and action status and can decide to mail the log, do nothing, or whatever The only question is if there need to be two hooks: done_domain and done_dehydrated, with one being called when each domain is done with result and action for each domain, and the other with the success / fail result for all domains (when processing multiples) and the action (unchanged / changed). This seems like it would keep the dehydrated script simple (only the exit code and action need to be tracked), and the users can do whatever they need in the hook.

adam closed this issue

2025-12-29 00:26:40 +01:00

adam commented

2025-12-29 00:26:41 +01:00

@internationils commented on GitHub (Jan 2, 2017):

https://github.com/lukas2511/dehydrated/issues/316 would be resolved by this as well.

@internationils commented on GitHub (Jan 2, 2017): https://github.com/lukas2511/dehydrated/issues/316 would be resolved by this as well.

adam commented

2025-12-29 00:26:41 +01:00

@lukas2511 commented on GitHub (Jan 29, 2017):

I don't really see the point in this, if you want mail with log on errors there are already a lot of tools out there that do exactly this (e.g. http://habilis.net/cronic/), and there are similar tools that will look for certain keywords in the output.
Also if you want to get notified on changed certificates you could as well do that in the deploy_cert hook, it has all the information you'll probably ever want to mail to yourself about your new certificates.

@lukas2511 commented on GitHub (Jan 29, 2017): I don't really see the point in this, if you want mail with log on errors there are already a lot of tools out there that do exactly this (e.g. http://habilis.net/cronic/), and there are similar tools that will look for certain keywords in the output. Also if you want to get notified on changed certificates you could as well do that in the `deploy_cert` hook, it has all the information you'll probably ever want to mail to yourself about your new certificates.

adam commented

2025-12-29 00:26:41 +01:00

@rpv-tomsk commented on GitHub (Jan 29, 2017):

Sometimes sysadmins don't want to use many tools for one task, and prefer to use one tool.

@rpv-tomsk commented on GitHub (Jan 29, 2017): Sometimes sysadmins don't want to use _many_ tools for one task, and prefer to use one tool.

adam commented

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

@lukas2511 commented on GitHub (Jan 29, 2017):

Most of the time it's better to have multiple tools each doing one job really good instead of having one tool that does everything okayish. And the moment you are running dehydrated in cron to send an email you are already using a ton of tools, each one doing more or less one job (openssl, curl, sendmail/postfix, crond, bash, mktemp, diffutils, ...).

@lukas2511 commented on GitHub (Jan 29, 2017): Most of the time it's better to have multiple tools each doing one job really good instead of having one tool that does everything okayish. And the moment you are running dehydrated in cron to send an email you are already using a ton of tools, each one doing more or less one job (openssl, curl, sendmail/postfix, crond, bash, mktemp, diffutils, ...).

adam commented

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

@rpv-tomsk commented on GitHub (Jan 29, 2017):

Most of the time it's better to have multiple tools each doing one job really good instead of having one tool that does everything okayish

Nobody here is asking about "please create nice logging for us, so tool would show its output only when problem exists" to match principle "no news are good news". People understand complexity of this task and do not prefer "okayish" solution.

But adding three lines of code calling done_dehydrated hook will not make tool worse.

@rpv-tomsk commented on GitHub (Jan 29, 2017): > Most of the time it's better to have multiple tools each doing one job really good instead of having one tool that does everything okayish Nobody here is asking about "please create nice logging for us, so tool would show its output only when problem exists" to match principle "no news are good news". People understand complexity of this task and do not prefer "okayish" solution. But adding three lines of code calling `done_dehydrated` hook will not make tool worse.

adam commented

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

@lukas2511 commented on GitHub (Jan 29, 2017):

I'm not entirely sure what the done_dehydrated hook should be supposed to do, I added a exit_hook for a different use-case, which gets executed if the script ran fine without any issues, is that what you want?

I mean you can't really do anything in there except for maybe a few more cleanup tasks, if it is called you basically just know that everything went fine, but you already know that because the exit code will be 0...

@lukas2511 commented on GitHub (Jan 29, 2017): I'm not entirely sure what the `done_dehydrated` hook should be supposed to do, I added a `exit_hook` for a different use-case, which gets executed if the script ran fine without any issues, is that what you want? I mean you can't really do anything in there except for maybe a few more cleanup tasks, if it is called you basically just know that everything went fine, but you already know that because the exit code will be 0...

adam commented

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

@rpv-tomsk commented on GitHub (Feb 3, 2017):

Thanks for 'exit_hook'.

I`m using it this way (hook.sh):

#!/bin/bash

if [ ${1} == "deploy_cert" ]; then
  touch ${BASEDIR}/.service-nginx-reload
fi

if [ ${1} == "exit_hook" ]; then
  if [ -r "${BASEDIR}/.service-nginx-reload" ]; then
      rm "${BASEDIR}/.service-nginx-reload"
      service nginx reload
  fi
fi

I don't want nginx reload for each certificate renewed in batch.

Thanks again.

@rpv-tomsk commented on GitHub (Feb 3, 2017): Thanks for 'exit_hook'. I`m using it this way (hook.sh): ``` #!/bin/bash if [ ${1} == "deploy_cert" ]; then touch ${BASEDIR}/.service-nginx-reload fi if [ ${1} == "exit_hook" ]; then if [ -r "${BASEDIR}/.service-nginx-reload" ]; then rm "${BASEDIR}/.service-nginx-reload" service nginx reload fi fi ``` I don't want `nginx reload` for each certificate renewed in batch. Thanks again.

adam referenced this issue

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

[PR #223] [CLOSED] fix mktemp arg quoting #759

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#178