mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
cron output #18
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dehnhard on GitHub (Dec 15, 2015).
I've seen in the code that this script prints output even if there is nothing to do.
I like my cron scripts to only print output (and thus sending an email notifying me) if there is an error. This could be controlled by a parameter (e.g. -q).
I am yet unsure about successful certificate renewal - maybe there could be another parameter if there is a message printed in that case.
@lukas2511 commented on GitHub (Dec 16, 2015):
In
311112654aI to get all error messages to stderr, so in theory you could just pipe stdout to /dev/null or something, and would still get messages on errors.I'll leave this ticket open since I think --quiet (-q) and --verbose (-v) options would be nice to have.
@germeier commented on GitHub (Dec 16, 2015):
My unsorted thoughts:
msg LOGLEVEL [-n] MESSAGE
=> I suggest to drop the default mode and revert the default to a short help message and run the script with "-c" from cron.
@fbender commented on GitHub (Dec 16, 2015):
I personally like to see a message after a successful
--cronrenewal, as well as a diagnostic message when the script did run but verified the certs are all still valid. So maybe reduce the messages but at least print a summary of the actions taken, e.g.@lukas2511 commented on GitHub (Dec 16, 2015):
@germeier:
i was thinking more about _debug, _info, _warn, _error functions, so it's a bit more readable than "msg 3 whatever", those can also handle writing to a logfile or whatever, and maybe should also format output so that every line begins with "$(date) WARN: ", "$(date) INFO: ", etc.
and i changed default command to help in
1ca883dee2@dehnhard commented on GitHub (Dec 17, 2015):
@lukas2511 Thanks for pointing out stderr/stdout. Although I am still in a process to decid which client to use on my server, this shell script looks good to me and the people friendly - so chances that I'll involve myself here are good.
I thought a bit more about the cron output and it occured to me that most scripts I know use the cron mail facility just for script errors and can additionally send customized mail messages or writes to a log. For example the excellent 'apticron', a cron script for debian updates, can be configured that it sends an email if there are pending updates - even with the changelog, if apt-listchanges is installed. Thats perfect for an admin to receive a mail, if and only if there is a new updateable package.
For letsencrypt.sh I imagine that it could have a configurable mail address to send mail with subject "Certification for domain x successfully renewed" or "Certification renewal failed for x" with details in the body. This way I could setup a mail filter to mark successes as read (I don't need to read them, but now they are present as a kind of history) and if there is an unread mail from this script I am alerted to look into it (which is not the case if every run creates a mail and I have to check each for errors). The standard mail for the cron output could then be reserved for actual runtime errors of the script itself.
How does that sound?
@lukas2511 commented on GitHub (Dec 17, 2015):
I don't want to implement mail functionality in this script, but it should be very easy to build a wrapper around this script to send some mails, either by parsing stdout&stderr or by checking for modifications in certs directory.
@fbender commented on GitHub (Dec 17, 2015):
Yeah this should be within the cron script that itself calls
letsencrypt.shand redirects STDERR & STDOUT to your mail template.@WhoHasMyUsername commented on GitHub (Jan 17, 2016):
Hi,
First; thanks for this script. Much cleaner and simpler and cronnable than the le client.
I would also like a -q | --quiet option. I understand the wrapper-approach but I think -q would be simpler. Am I correct in thinking the -q option is still on the table? I suppose the steps would be:
How about this?
@lukas2511 commented on GitHub (Jan 17, 2016):
Yes this will probably be done at some point.
@WhoHasMyUsername commented on GitHub (Jan 17, 2016):
Can I do this? I think my coding [quality] would at least be a start but I have never used github before.
@lukas2511 commented on GitHub (Jan 17, 2016):
Sure, you can have a go at this, I don't think anybody is working on this right now.
@WhoHasMyUsername commented on GitHub (Jan 18, 2016):
Hi, I've added the _msg function and loglevel variable, could you have a look sometime to see if this fits in? It works, i.e. using --quiet or -q silences all output if nothing is to be done.
I still need to add the _debug, _info, _warn, and _error functions I suggested above. I ran into issues with printf statements and the echo ... &>2 statements. I didn't touch the latter.
Let me know.
@lukas2511 commented on GitHub (Jan 19, 2016):
This whole thing gets a lot more complicated than i first thought...
The problem is that normally you wouldn't want to see lines like "Processing example.com" in your command output, because it may not be relevant, but it becomes relevant the moment something happens to that certificate.
That may be solved by actually including the certificate / domain names in every single line of output, but that would make this whole thing really ugly...
I'm thinking about ditching the idea about log-levels, because this makes it way to complicated...
@WhoHasMyUsername commented on GitHub (Jan 19, 2016):
Ok. I see your point.
Why not use exit codes? A wrapper can capture the output, and only when the exit code > 0, output the output so to speak.
Then again, a script to call a script is not really clean or uncomplicated. The whole (my) point of a bash script for Letsencrypt is automation. And from automation follows a fair requirement to only output messages when relevant.
@lukas2511 commented on GitHub (Jan 19, 2016):
There are already exit codes in place for error cases, and "0" should be returned on success.
You can easily set up a cron that only prints messages on errors, or grep for renewal statements or whatever... It's hard to do this in a clean way inside the script itself.
Yea sure it's great for automation if it would have that, but on the other hand it shouldn't be much work to build a wrapper for this job...
Maybe I'll add a wrapper to the repository at some point.
@WhoHasMyUsername commented on GitHub (Jan 19, 2016):
I meant adding exit code 2 for renewal, 3 for revoke, but on second thought this is rather unusual for bash scripts. I don't think grepping the output is a clean solution, btw.
Meanwhile, I'm extremely happy with the --quiet option in my fork. :-)
@germeier commented on GitHub (Jan 19, 2016):
Hi Lukas, hi all!
I have another suggestion for the handling of messages, see:
49c82ef56dI added logging to a logfile with different levels for logging (LOGLEVEL) and console output (MSGLEVEL). This way we can make our console output quiet but still have more information in the logfile.
For my usecase LOGLEVEL=3 and MSGLEVEL=2 should work nicely.
What do you think?
@WhoHasMyUsername commented on GitHub (Jan 19, 2016):
Fwiw, I think it's great.
@lukas2511 commented on GitHub (Jan 31, 2016):
@germeier but this doesn't solve the problem:
_info "Processing ${domain}"while having_error "ERROR: ${1}"would result in an error message without the name of the certificate@germeier commented on GitHub (Jan 31, 2016):
@lukas2511 How about writing messages below a specified log level to a temporary file and change the msglevel retroactively if the msglevel was reached? untested code:
6da372f76e@germeier commented on GitHub (Jan 31, 2016):
These lines obviously need to be switched. :)
@lukas2511 commented on GitHub (Feb 1, 2016):
Yes buffering the output and replaying it when necessary would work, but it seems ugly :-/
@ghost commented on GitHub (Feb 21, 2016):
I just wanted to say "me too".
Historically, cron scripts output nothing unless there is an error (which then gets emailed to root or a root alias).
My suggestion, is to send normal output to syslog (journal/systemd) and let the administrator handle it via the existing methods of log handling. I believe this method is more appropriate than creating your own log file, which we admins would have to keep track of and "logrotate" every now and then.
Thank you for this great script.
@Lukas0907 commented on GitHub (Mar 23, 2016):
I'm using chronic as a wrapper to this script (https://joeyh.name/code/moreutils/). It will output to stdout/stderr only, if the exit code is not 0. This way I'll get an email notification from cron only if an error occurs but not if everything worked as expected.
@WhoHasMyUsername commented on GitHub (Mar 23, 2016):
That's nice! I didn't know these tools existed. Learned something new.
Meanwhile, I get this, and only this when it's renewal time:
Van: root@example.com (Cron Daemon)
Onderwerp: Cron root@example.com /etc/letsencrypt.sh/letsencrypt.sh --cron --quiet
Datum: 19 maart 2016 03:00:47 CET
Aan: root@example.com
(Less than 30 days). Renewing!
Reload imap server
Reloading IMAP/POP3 mail server: dovecot.
Reload de mailserver
Reloading Postfix configuration...done.
@rossnick commented on GitHub (Apr 11, 2016):
@WhoHasMyUsername Where did you take the --quiet option to letsencrypt.sh ? I don't see it in the valid parameters. Also, count me in for this feature !
@lukas2511 commented on GitHub (Apr 12, 2016):
@rossnick
--quietdoesn't exist (yet). I'm still hoping on solving this problem at some point, but I still don't feel comfortable with any of the suggestions I got so far.@MEschenbacher commented on GitHub (Apr 14, 2016):
cronic is really the type of tool you want to use for this kind of issue. You should set up monitoring for certificate expiry anyways and therefore the regular output of letsencrypt.sh can be supressed unless an error occurs. I do not see a real need for a quiet option.
@rossnick commented on GitHub (Apr 14, 2016):
I understand, but for it to work, a different return code should be used is a certificat is renewed, which is not the case right now. WIthout that I doupt that cronic can't tell...
@WhoHasMyUsername commented on GitHub (Apr 14, 2016):
chronic is another tool (to maintain), afaik not installed by default.
-q or --quiet is imho not that outlandish an option.
@MEschenbacher commented on GitHub (Apr 15, 2016):
@rossnick why do you want to be notified when a certificate renewed successfully? One should set up proper monitoring for certificate lifetimes and not really care about letsencrypt.sh output unless it is erroneous.
I do not have a strong opinion on --quiet as long as the default behaviour is not changed.
@rossnick commented on GitHub (Apr 15, 2016):
Because on some servers, I don't want to restart/graceful apache unconditiionnaly. On other even a graceful restart is costly in term of load and cpu because of the heavy hits.
@MEschenbacher commented on GitHub (Apr 15, 2016):
I see. That's where the hooks come into play. See deploy_cert hook in which you can execute commands depending on the cert that has just been successfully deployed.
@rossnick commented on GitHub (Apr 19, 2016):
Oh ! Thanks @maxlin1990 I never tought of that... It'll be trivial to send an email with a hook script. I could then use a return code check to send an email if there's a problem...
@Aikhjarto commented on GitHub (May 16, 2016):
I like the idea of a "_msg" function instead of a plain "echo" as suggested by @WhoHasMyUsername
However, I don't like the idea of discarding a message because it makes problems hard to find.
I would like to suggest to make "_msg" send all output to a syslog facility instead of discarding it.
@rossnick commented on GitHub (May 16, 2016):
@Aikhjarto For my part, I ended up deploying cronic to all my servers, and used a hook script to send me an email whenever a cert is deployed. I now have much less noise from cron output, and it's viable for me that way.
@lukas2511 commented on GitHub (May 26, 2016):
I'm closing this issue. I think that using a wrapper is a lot more elegant than doing the logging inside the script itself.
@rpv-tomsk commented on GitHub (Feb 3, 2017):
Hi Lukas!
What do you think if some examples of cron setup will be added to Dehydrated documentation?
With suggestions to use one of (at least):
?
This can avoid of reporting new issues/PR like #331.