Thanks for pointing this out, I updated my post to be more clear in this aspect.
Would this also work with 16.04 LTS? Because I don’t think I need to install
certbot-auto in 16.04 LTS.
The howto was created with 16.04, so my steps should match exactly
I can understand that… but in your post you said:
So I wanted to know from @codinghorror if the auto renew steps he added would work with 16.04LTS?
@fefrei Can you guide me on how to auto renew without
Now I feel stupid… let me check the documentation
I use this simple shell script, run by cron:
#!/bin/bash letsencrypt renew /usr/sbin/service nginx reload
This basically means that you are renewing the certificate everyday, right?
No it doesn’t. Cron jobs don’t have to be daily - you can pick any time period that you want.
certbot renew only processes certs it deems due for renewal. I run this script weekly, which effectively renews every two months or so.
Discourse embedding still has some bugs?
True that – the client is being renamed to
certbot, so I’m mixing them up all the time because the name depends on your distribution and version…
Slightly off-topic, but if you use CloudFlare’s DNS you will get an offline page and a cached version of your site provided by them, without even touching your Discourse setup.
I did followed your @fefrei instructions and everything working fine. Thanks to your well documentation . When I stop discourse I’m getting my special error page. But when I’m rebuilding discourse I’m getting the default 404 error page!.
Is there is anything I could do yet to fix this?
Wait, you should never get a 404. Can you post a screenshot of the error message? Does the error persist after rebuilding completes?
I’ll try to capture it for you with my second rebuild. But it is regular Nginx 404 error page, nothing special.
No. After the rebuild completed everything working as expected. I’m getting my Discourse site running fine.
I have no idea why this is happening
One of the first steps of rebuilding is to stop the container. Your nginx shouldn’t be able to distinguish rebuilding from a stopped container even if it wanted to…
Maybe a close look at nginx’s logs could shed some light onto this?
I think the logs on your host are most interesting – depending on your Linux distribution, they should be in
/var/log/nginx/ or a similar place.
I’ve updated the initial post to also recommend enabling
http2 in the nginx configuration.