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.
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.
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, ...).
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.
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...
#!/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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:
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.
@internationils commented on GitHub (Jan 2, 2017):
https://github.com/lukas2511/dehydrated/issues/316 would be resolved by this as well.
@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_certhook, it has all the information you'll probably ever want to mail to yourself about your new certificates.@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.
@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, ...).
@rpv-tomsk commented on GitHub (Jan 29, 2017):
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_dehydratedhook will not make tool worse.@lukas2511 commented on GitHub (Jan 29, 2017):
I'm not entirely sure what the
done_dehydratedhook should be supposed to do, I added aexit_hookfor 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...
@rpv-tomsk commented on GitHub (Feb 3, 2017):
Thanks for 'exit_hook'.
I`m using it this way (hook.sh):
I don't want
nginx reloadfor each certificate renewed in batch.Thanks again.