Let's Encrypt and Nginx – State of the art secure web deployment
1–10 of 85 posts
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#2Ewwww, that renewCerts.sh is pretty crappy. Who the hell is going to check the /var/log/letsencrypt/renew.log everyday to see if renewing failed?
Could not they do something nicer with systemd and email?
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#3Ewwww, that renewCerts.sh is pretty crappy. Who the hell is going to check the /var/log/letsencrypt/renew.log everyday to see if renewing failed? Could not they do something nicer with systemd and email?
The default behaviour of cron is to email the user if a job finishes with a non-zero exit code, which seems to apply here in case of renewal failure.
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#4Just using caddy server seems a lot simpler...
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#5Ewwww, that renewCerts.sh is pretty crappy. Who the hell is going to check the /var/log/letsencrypt/renew.log everyday to see if renewing failed? Could not they do something nicer with systemd and email?
The default behaviour of cron is to email the user if a job finishes with a non-zero exit code, which seems to apply here in case of renewal failure.
But is not the default account that it would email root? I run Debian and almost never log in as root. Would all admin sudoers receive the email?
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#6Earlier quoted context omitted.
The default behaviour of cron is to email the user if a job finishes with a non-zero exit code, which seems to apply here in case of renewal failure.
But is not the default account that it would email root? I run Debian and almost never log in as root. Would all admin sudoers receive the email?
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#7Isn't running this as a `@daily` CRON job too much? I thought Let's Encrypt certs were good for 3 months? Why not @monthly or months 0,2,4,6,8,10 ?
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#8Isn't running this as a `@daily` CRON job too much? I thought Let's Encrypt certs were good for 3 months? Why not @monthly or months 0,2,4,6,8,10 ?
If something breaks, you might as well find out about it as soon as possible. That way you have the full 90 days to figure it out at your leisure, instead of 60 or 30.
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#9Isn't running this as a `@daily` CRON job too much? I thought Let's Encrypt certs were good for 3 months? Why not @monthly or months 0,2,4,6,8,10 ?
If something breaks, you might as well find out about it as soon as possible. That way you have the full 90 days to figure it out at your leisure, instead of 60 or 30.
Right. Also, I just saw that `letsencrypt-auto renew` will only issue new certs if < 30 days left on current cert.
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#10Earlier quoted context omitted.
But is not the default account that it would email root? I run Debian and almost never log in as root. Would all admin sudoers receive the email?
http://www.cyberciti.biz/faq/linux-unix-crontab-change-mailt...
So the default behavior is to only email root unless crontab is edited, therefore most people would never receive an email (in case of renew failure), if they only followed the instructions given.
Otherwise mail is sent to the owner of the crontab.