A bug was reported in the Discourse Docker setup script, where discourse-setup incorrectly relies on the “addr:” pattern in ipconfig output to determine the IP address. This caused installation failures on systems where the output format differs, such as Debian GNU/Linux 9.0 “stretch”. tomreyn suggested using ip -f inet addr show $IFACE | grep -Po 'inet \K[\d.]+' | head -n1 instead. pfaffman mentioned that the code has been updated to use curl and nc for domain name resolution and port checking. After updating to the latest commit, tomreyn found the installer script to be improved, but noted that it may not work in load balancing scenarios. pfaffman agreed that this scenario is not supported by the current implementation. The issue has been marked as solved by tomreyn.
I previously posted this on the GitHub issue tracker which has now been removed (including my post), so I’m posting it here again.
On a Debian GNU/Linux 9.0 “stretch” VM runing in a KVM environment, the output of the ipconfig command does not return a string containing a pattern such as
inet addr:123.123.123.123
but just
inet 123.123.123.123
As a result, discourse-setup sets the IP variable to an empty string and the installation fails with
mydomain.net does not appear to resolve to .
A better approach would be to use something similar to
ip -f inet addr show $IFACE | grep -Po 'inet \K[\d.]+' | head -n1
Have you done a git pull recently? That code has changed and now uses curl and nc to attempt to see that the domain name hits the current server and the port is open.
I had not done a git pull on the docker setup script recently. I am one of those backward people who appreciate versioned releases of software and frown at developers who only support the latest git commit. (I do not know nor claim whether this is the case for the Discourse Docker installer, yet, though it is the first impression I got).
Indeed the installer script looks much better on the latest commit and should work with single server installations. It would not reliably work in a load balancing scenario where HTTP(S) requests to a single IP address may end up on different servers to the backend (LB pool). But I do not know whether this scenario is even supported at this time.
I don’t think that acme would work in that scenario, but in any case, if you’re capable of doing that kind of work, you can probably crank up vim and edit the file by hand.
It also won’t work if you use a domain name that resolves only from inside the container.
Not for the Contribute > Bug category, but you should be able to mark it as solved now. I can’t since it’s not my question and I’m not an admin/moderator.