Error in discourse-setup around handling of Lets Encrypt


(Philip Colmer) #1

Running discourse-setup on an AWS instance results in the following error occurring:

Checking your domain name . . .
./discourse-setup: line 37: [: too many arguments
-----------------------------------------
blah.example.com does not resolve to 172.30.1.83.
IT IS ALMOST CERTAINLY A BAD IDEA TO TURN ON LET'S ENCRYPT!!
Unless you know why this check failed, DO NOT USE Let's Encrypt.

That error is reasonably easy to fix - line 37 is using single [ but changing it to [[ and ]] fixes the “too many arguments” error but not the resolving problem.

For my host, I’ve CNAMEd blah.example.com (not the real server name!) to the underlying ec2 host name rather than the raw IP address. The bash variable RESOLVED_IP therefore doesn’t get set to just the IP address, it gets set to something like:

ec2-52-90-11-22.compute-1.amazonaws.com. 123.123.123.123

where the last bit (123.123.123.123) is the actual IP address of the host and what RESOLVED_IP needs to be set to.

My bash skills aren’t up to fixing that bit, otherwise I would and then submit a pull request but hopefully there is enough information there to help someone fix it.


(Jay Pfaffman) #2

I really need to fix the first problem.

You know why if prints the warning about the ip address. It says to ignore the warning if you know why the test is failing. I’ll look at tweaking the language and perhaps using some what is my ip service.


(Philip Colmer) #3

The challenge with using an external “what is my IP” service is that AWS (and, I think, Azure and probably other hosting services) use NAT, so the IP address on the server won’t match the public IP address. Amazon solve this problem in DNS by ensuring that AWS servers will (except for certain situations) get the internal IP address returned from DNS rather than the public one.

I suspect that this isn’t a hosting issue, per se, but the result of me using CNAME instead of an A record. I prefer to use CNAME for the AWS instances because then DNS almost becomes self-documenting in terms of tracking which of our services are on AWS.

The script needs to be able to parse the output from dig more carefully. I will see if I can come up with a fix but, as I noted, I’m not a scripting expert … I might be able to find one :slight_smile:


(Philip Colmer) #4

@pfaffman It looks like the simplest change to the second problem is to replace:

local RESOLVED_IP=`dig +short $1`

with

local RESOLVED_IP=`dig +short $1 | tail -1`

This will ensure that the final answer from dig, which should be the actual IP address, is what is then used by the rest of the script.


(Jay Pfaffman) #5

Fixed and merged:

  • the inexcusable error with the missing quotes.
  • Let’s Encrypt warning more gentle, for example, includes: “(A typical reason for failure is an AWS server with an elastic IP.)” to make it clearer that you just might know what you’re doing.
  • makes a backup fail of app.yml.
  • Will now recover if someone deleted LETSENCRYPT_ACCOUNT_EMAIL by hand.

(Darryl Bresland) #6

Late to the party here but I’m having similar issues.

  • Amazon Linux with EIP
  • DNS pointing at EIP

The problem for me is with the IP check:

local IP=`$IFCONFIG $IFACE|grep  "inet addr:" |cut -d":" -f 2|cut -d" " -f1|head -1`
local RESOLVED_IP=`dig +short $1`

IP resolves to the local IP of the instance, e.g. 10.0.2.127.
RESOLVED_IP looks up the DNS so obviously resolves to the public IP of the instance.
These two are never going to be the same in mine so it fails the check and won’t setup.

Why is it trying to compare local IP with public IP? Does the IP assignment with ifconfig manage to get the public IP address of the instance for others or what is the actual intent here?

When I try to install on a fresh default install using Amazon linux and skip HTTPS / letsencrypt setup, it always redirects http to https so I cant test it properly on http. The IP works but the hostname always redirects http to https even though this is not enabled in the settings and I’ve done a brand new install without trying to enable https at all.


(Jay Pfaffman) #7

It is a warning. You understand why the warning does not apply to you, so you should ignore the warning.

If you can suggest language that says to ignore the warning that you would understand, I welcome your suggestion.


(Jeff Atwood) #8