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:
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.
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.
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
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.
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.
