I’ve installed Discourse via Docker on a Ubuntu as mentioned in Set up Discourse in the cloud in under 30 minutes. The site works from localhost (ssh & port forward via putty). I’m trying to see if SSL is the reason I’m unable to access the site outside localhost via Virtual Machine’s Public IP Address or domain name (via ‘A’ records). So, here is what I’m trying to do to enable Let’s Encrypt.
cybersathya@Vaaithaaforum:/var/discourse$ sudo ./discourse-setup
Ports 80 and 443 are free for use
The configuration file containers/app.yml already exists!
. . . reconfiguring . . .
Saving old file as app.yml.2017-10-13-002911.bak
Found 3GB of memory and 1 physical CPU cores
setting db_shared_buffers = 768MB
setting UNICORN_WORKERS = 2
LET’S ENCRYPT cannot work if their servers cannot access your host by name.
Unless you think you know why this naive check failed, DO NOT USE Let’s Encrypt.
(A typical reason for failure is an AWS server with an elastic IP.)
You should probably answer “n” at the next prompt and disable Let’s Encrypt.
I have Discourse on an Azure Ubuntu VM and it worked like a charm with no hassles.
First set it up WITHOUT Lets Encrypt. Make sure that you can access the site over straight HTTP.
Then modify app.yaml to include Lets Encrypt and rebuild.
From your error messages, it looks like you have not opened the EndPoint to the public IP address. That’s why Lets Encrypt is not finding the public IP.
I’m saying that the discourse site works ONLY from local host (127.0.0.1:8000), when tunneling is done with PuTTy, and not from the Virtual Machine’s IP Address. Infact, I’m not able to figure-out how to run Discourse outside local host.
Scratch your VM, start a new one, do it vanilla without other configurations.
You can add your configuration changes later on and rebuild.
And, do yourself a favor, use the fastest CPU VM you can afford during setup. It should only be a few days, but it saves you heaps of time waiting for a rebuild (which can take up to 15 min).
And do not go below 2GB of RAM, thus do not use things like A0.
I’m able to reach the site via domain name now, after port forwarding 443 & 80.
How do we go with SSL now?
rerunning discourse-setup is getting this error.
Checking your domain name . . .
WARNING:: forum.vaaithaa.com does not appear to resolve to 10.0.0.4.
LET’S ENCRYPT cannot work if their servers cannot access your host by name.
Unless you think you know why this naive check failed, DO NOT USE Let’s Encrypt.
(A typical reason for failure is an AWS server with an elastic IP.)
You should probably answer “n” at the next prompt and disable Let’s Encrypt.
You’ve demonstrated that you know that the address used to access your host is not 10.0.0.4, so it would seem that you know why this naive check failed.
Still, this remains confusing to people and the set of people who are confused by this naive check is growing, especially with people increasingly using Azure.
I’ll try to either make the check more robust or tone down the language to make it less scary sometime soon.
I’ve used nc and curl to check whether http://hostname and http://hostname:443 actually connect to that host. I think they’ll give fewer false fails on the check and the “it’s broken” language is toned down a bit.
