Ewwww, 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?
This sounds like a job for Dead Man's Snitch.
Let's Encrypt and Nginx – State of the art secure web deployment
11–20 of 85 posts
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#12Just using caddy server seems a lot simpler...
+1 for Caddy. I was using NGINX a long time, and wrote some similar scripts to make certificates for my web apps. After I switched to Caddy I had a 6x smaller config file, no more ln -s, and HTTPS without every having to think about it!
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#13I just use https://github.com/lukas2511/letsencrypt.sh/ single bash script.
Add a config.sh and setup nginx alias. Then just add domains to the domains.txt and have the script run via cron daily.
Finished
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#14Just using caddy server seems a lot simpler...
I'd never heard of Caddy, and it looks great! Thanks for giving me something to tinker with this weekend! :-)
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#15Earlier 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?
Without judgment intended, as a Linux sysadmin you should absolutely be monitoring mail to root. That is the standard place to deliver error output from unattended processes. You can easily /etc/alias it to something else if that's more convenient.
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#16Earlier quoted context omitted.
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.
If your server isn't set up to forward root's cron E-Mail to you you have bigger problems than your let's encrypt certs not renewing.
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#17Earlier quoted context omitted.
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.
cron error reporting via email is an established solution. Why reinvent the wheel?
I'd agree that a hint regarding MAILTO= in the crontab file would be neat.
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#18Earlier 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?
Getting off-topic here, but whenever I do a new Debian build one of the items on my checklist is to edit /etc/aliases to add either my actual login user or a real email address (depending on the server setup) as an alias for root.
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#19Earlier 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?
Without judgment intended, as a Linux sysadmin you should absolutely be monitoring mail to root. That is the standard place to deliver error output from unattended processes. You can easily /etc/alias it to something else if that's more convenient.
Sysadmin/Devops here. I send all root mail to Graylog.
Re: Let's Encrypt and Nginx – State of the art secure web deployment
#20Just using caddy server seems a lot simpler...
Neat, I like that when started with no arguments/config it just serves the files in the current directory, but then you can customize it from there.
I have "alias webserver='python -m SimpleHTTPServer'" in my shell config, but I think I'll switch to Caddy.