41–50 of 85 posts
The --webroot option doesn't work for my setup, so I need to shutdown nginx for 2-3 seconds and use the --standalone option. I set this as a CRON job that will run every two months. It's not elegant, but it's done. Here's the modified script using certonly and the --force-renew flag. #!/bin/bash # Force-renew the "Let's Encrypt" certificates for a given domain # Run this as root as a BI-MONTHLY cron job export DOMAIN…
Earlier 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?
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.
It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.
Unfortunately, it seems there's no secure way to fetch the key. The nginx team recommends one checks the "web-of-trust" to check if the key is signed by others.
Earlier quoted context omitted.
Unfortunately, it seems there's no secure way to fetch the key. The nginx team recommends one checks the "web-of-trust" to check if the key is signed by others.
Based on the PGP pathfinder here[0], it is likely this is a valid key. I'm only a few signatures away from this nginx signing key. [0] http://pgp.cs.uu.nl/
Earlier quoted context omitted.
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.
For local development, consider looking into devd ( https://github.com/cortesi/devd ). It's a single binary that supports things like livereload, network throttling, routing, and reverse proxying.
Earlier quoted context omitted.
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.
Lets encrypt fixes the encryption problem sure but does anyone else feel that all we really needed was really great documentation on what to do instead of an intrusive set of scripts?
It's made me think we should have a Swagger or API Blueprint of the spec on github that everyone can keep up to date. What do you think?
Lets encrypt fixes the encryption problem sure but does anyone else feel that all we really needed was really great documentation on what to do instead of an intrusive set of scripts?
Yes, the API documentation is lacking especially with what we've gotten used to from Swagger markup and Stripe's API doc style. I have scoured for such an easy breakdown and found none. As a result I actually just implemented a new, clear, client for LetsEncrypt and have been documenting as I go. It's made me think we should have a Swagger or API Blueprint of the spec on github that everyone can keep up to date. What…
The former is documented in the ACME specification[1], currently being worked on by the IETF. There are many low-level ACME libraries for basically every language[2], and a pretty decent guide on writing your own client as well[3].
[1]: https://ietf-wg-acme.github.io/acme/
[2]: https://github.com/letsencrypt/letsencrypt/wiki/Links#librar...
It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.
I'm looking at you Jenkins![0]
[0] https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenki...
It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.
I agree with your concern. As a temporary "workaround" I've updated the article with a SHA256 checksum of the key. I'll chase the Nginx team for serving this key over https