Idea: Only print certs actually being renewed #372

Open
opened 2025-12-29 01:23:51 +01:00 by adam · 6 comments
Owner

Originally created by @ToeiRei on GitHub (Aug 15, 2018).

Having dehydrated run as a cron script, I'd suggest an option which prints out stuff only when things went wrong or certificates got renewed to keep cron-mails at minimum.

Originally created by @ToeiRei on GitHub (Aug 15, 2018). Having dehydrated run as a cron script, I'd suggest an option which prints out stuff only when things went wrong or certificates got renewed to keep cron-mails at minimum.
Author
Owner

@dennisschuerholz commented on GitHub (Aug 29, 2018):

As I have the same requirement I did an unclean implementation of such an option: dennisschuerholz/dehydrated@6647aaf09f

If I have more time to work on it I could possibly do some PR-ready version of this, as I'm not quite happy with the "solution" I've chosen so far. But as it fulfills my needs at the moment I will leave it like this.

@dennisschuerholz commented on GitHub (Aug 29, 2018): As I have the same requirement I did an unclean implementation of such an option: dennisschuerholz/dehydrated@6647aaf09fc96d96afab0f2123d8db315983a570 If I have more time to work on it I could possibly do some PR-ready version of this, as I'm not quite happy with the "solution" I've chosen so far. But as it fulfills my needs at the moment I will leave it like this.
Author
Owner

@alainwolf commented on GitHub (Sep 7, 2018):

My cronjob calls dehydrated like this:

/usr/local/bin/dehydrated --cron --keep-going | logger -t dehydrated --priority user.info

I only get a mail if something goes wrong (stderr), but I still can go and take a look what was happening in syslog, regradless if there where errors or not:

$ journalctl -t dehydrated --since '24h ago'

Advantage over modifying dehydrated:
This solution does not only cover dehydrated itself, but also the output of any hook scripts called by your installation.

Personally I don't want to know which certs have been renewed, since dehydrated manages a lot of certs for me. But if I would want to get notified about them, I would add something like the following to my hook chain:

...
deploy_cert() {
    local DOMAIN="${1}" 
    echo "$DOMAIN" >> /tmp/newcerts
}
...
exit_hook() {
    if [[ -f "/tmp/newcerts" ]]; then
        cat /tmp/newcerts | mail -s "Certficates Issued" "webmaster@example.net"
        rm /tmp/newcerts
    fi
}
...

But it might be be better to monitor the certificate transparency logs instead. https://crt.sh/ offers RSS feeds for any domain. E.g. https://crt.sh/atom?q=dehydrated.io

@alainwolf commented on GitHub (Sep 7, 2018): My cronjob calls dehydrated like this: ``` /usr/local/bin/dehydrated --cron --keep-going | logger -t dehydrated --priority user.info ``` I only get a mail if something goes wrong (stderr), but I still can go and take a look what was happening in syslog, regradless if there where errors or not: ``` $ journalctl -t dehydrated --since '24h ago' ``` ***Advantage over modifying dehydrated:*** This solution does not only cover dehydrated itself, but also the output of any hook scripts called by your installation. Personally I don't want to know which certs have been renewed, since dehydrated manages a lot of certs for me. But if I would want to get notified about them, I would add something like the following to my [hook chain](https://github.com/lukas2511/dehydrated/blob/master/docs/examples/hook.sh): ``` ... deploy_cert() { local DOMAIN="${1}" echo "$DOMAIN" >> /tmp/newcerts } ... exit_hook() { if [[ -f "/tmp/newcerts" ]]; then cat /tmp/newcerts | mail -s "Certficates Issued" "webmaster@example.net" rm /tmp/newcerts fi } ... ``` But it might be be better to monitor the certificate transparency logs instead. https://crt.sh/ offers RSS feeds for any domain. E.g. https://crt.sh/atom?q=dehydrated.io
Author
Owner

@alainwolf commented on GitHub (Sep 7, 2018):

See also duplicate issues #455, #378, #331 and #47

@alainwolf commented on GitHub (Sep 7, 2018): See also duplicate issues #455, #378, #331 and #47
Author
Owner

@ap commented on GitHub (Jun 16, 2019):

I think the ideal would be to accumulate log messages silently at first and only output them once something noteworthy happens. That way, if nothing interesting happens, nothing is output, so no mail is sent, but if something does happen, you get the full usual log.

Errors would obviously always count as noteworthy. There could be a switch for whether renewals (and maybe other stuff) counts as noteworthy too.

@ap commented on GitHub (Jun 16, 2019): I think the ideal would be to accumulate log messages silently at first and only output them once something noteworthy happens. That way, if nothing interesting happens, nothing is output, so no mail is sent, but if something does happen, you get the full usual log. Errors would obviously always count as noteworthy. There could be a switch for whether renewals (and maybe other stuff) counts as noteworthy too.
Author
Owner

@eengstrom commented on GitHub (Dec 4, 2020):

I had been thinking along the same lines as the OP (and other issues), but I've come around to really like @alainwolf's answer using logger. For those who care, I use a slightly different form now, which shunts both STDOUT and STDERR, keeping STDERR output to then be emailed. e.g.:

(/opt/dehydrated/dehydrated -c -g | logger -t dehydrated -p local7.info) 2>&1 | logger -t dehydrated -p local7.error -s

YMMV.

@eengstrom commented on GitHub (Dec 4, 2020): I had been thinking along the same lines as the OP (and other issues), but I've come around to really like @alainwolf's answer using logger. For those who care, I use a slightly different form now, which shunts both STDOUT and STDERR, keeping STDERR output to then be emailed. e.g.: ``` (/opt/dehydrated/dehydrated -c -g | logger -t dehydrated -p local7.info) 2>&1 | logger -t dehydrated -p local7.error -s ``` YMMV.
Author
Owner

@penguineer commented on GitHub (Jul 6, 2022):

I have the same problems. Logs are not my preferred solution - in case of a cert change I would like to have an email so that I am aware in case something else goes wrong. (I could set this up via log analysis, but it seems to be an unnecessary complicated implementation of a -q switch.)

If there are no individual hooks, counting the lines works, as in https://github.com/penguineer/ansible-role-dehydrated_cron/blob/main/templates/dehy-wrap.sh.j2

Obviously this is also a very naive solution. Looking to improve on that landed me here.

Ideally there would be a return code for "everything is fine but at least one of the certs changed" or a switch to only output changed certs to stdout.

@penguineer commented on GitHub (Jul 6, 2022): I have the same problems. Logs are not my preferred solution - in case of a cert change I would like to have an email so that I am aware in case something else goes wrong. (I could set this up via log analysis, but it seems to be an unnecessary complicated implementation of a `-q` switch.) If there are no individual hooks, counting the lines works, as in https://github.com/penguineer/ansible-role-dehydrated_cron/blob/main/templates/dehy-wrap.sh.j2 Obviously this is also a very naive solution. Looking to improve on that landed me here. Ideally there would be a return code for "everything is fine but at least one of the certs changed" or a switch to only output changed certs to stdout.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#372