I am new to Discouse and got stuck during the installation. I built an Ubuntu Server 18.04 virtual machine, then roughly followed the installation instructions.
When I say roughly, I mean rather than the cloud server, I am using the Ubuntu Server. I did not install Docker, but rather let discourse-setup install it for me. Also, I don’t have a mail server setup yet, though provided reasonable answers to the setup process. Not sure if this is the show stopper here. DNS is all in place and the server has a statically assigned IP address.
After the bootstrapping, when I browse to the server’s FQDN, I get the “Welcome to nginx!” page, rather than the “Congratulations, you installed Discourse!” page.
This installation is for a lab-environment and will not be publicly accessible.
The only way to see that page is if you’ve directed DNS to the wrong server, or NGINX is outside the container, occupying port 80 and preventing the container from responding.
If I point my web browser directly at the server’s IP address, I also get the Nginx welcome page.
When SSHed to the Ubuntu server: marc@community:~$ locate nginx /var/discourse/image/base/install-nginx marc@community:~$
In addition, while on the Ubuntu server: sudo find / -iname "*nginx*"
…lots of files under /var/lib/docker/overlay2… /var/discourse/image/base/install-nginx /var/discourse/shared/standalone/letsencrypt/deploy/nginx.sh /var/discourse/shared/standalone/log/var-log/nginx
If docker was listening on :80, which any successful install would achieve (and require for nginx inside the container to see anything) you would see:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
docker-pr 890 root 4u IPv6 961922 0t0 TCP *:http (LISTEN)
If nginx isn’t installed outside the container, and Docker isn’t listening on that port, then the only other way to be seeing the nginx welcome page is a network misconfiguration.
Looks like you are right. Output from running nmap on my laptop to the server’s IP address:
Starting Nmap 7.01 ( https://nmap.org ) at 2020-04-10 23:34 AEST
Nmap scan report for community.aureus-group-sb.com (192.168.12.35)
Host is up (0.0010s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
MAC Address: 0C:8B:FD:CD:AF:EB (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds
Remember, a network issue could be, but isn’t limited to:
Policy on the VM blocking access (ufw or similar)
Policy on the virtual server blocking access (network mode not configured correctly)
Policy on the network not configured correctly (ACLs between subnets)
DNS incorrectly configured
It’s only a Discourse problem if none of the above are true. You’re following the standard install, but by your own admission you’re installing in an environment which is by no means standard.
If your organization can spend the $5/mo, it may be cheaper just in terms of your time to put this in the cloud and limit the cloud VPS firewall to only serve pages back to your environment.
At the moment I am mainly in it for the learning aspect of getting this setup. Once I have that under control, we will certainly look at hosting options.
Looking at the network aspects you listed,
ufw is inactive and iptables is running: I have made no changes to the default installation of Ubuntu server.
** Looking at the iptables configuration, the input chain has a policy to accept all and so does the output chain. The forward chain has some docker related references (see below).
The VM’s only vNIC is configured in Bridged mode–connecting directly to the physical network.
The laptop I am working from and the VM are on the same subnet.
I am not sure what the exact requirements for DNS are. I tried to find those specifications, but was unable to find a definitive document. As far as DNS is concerned though, I can ping the server by name, FQDN and IP address. I am not sure if anything else needs to be in place relating to DNS.
What network policy exists between the VM and the outside world?
If the git pull succeeded, and you were able to run discourse-setup, would anything have prevented it from connecting to GitHub to download the content of the container?
If the server isn’t accessibly addressable Let’s Encrypt would fail, so did you alter the YML to disable HTTPS?
The VM can connect to the internet and there are no restrictions on it accessing GitHub. While running discourse-setup, I left the option Let’s Encrypt account email? (ENTER to skip) [me@example.com]: blank.
Leaving that field blank means you won’t be alerted about certificate problems, it doesn’t prevent the container from attempting to enable Let’s Encrypt.
Ok so we’ve highlighted some larger problems, but they don’t relate to the OP. You have nginx on your network somewhere throwing up a page, but by your testing on the virtual machine you don’t have nginx installed or docker listening.
Once you figure out how that’s happening step two will be to correctly configure the YML file. For now you need to find the source of that page.
Here is what I have learned. If I shutdown the server, I cannot ping it (IP address, name and FQDN). When I browse to the IP address, I get a standard “Unable to connect” page from Firefox.
I am therefore concluding that I don’t have an IP address conflict.
After powering up the VM, I am now also unable to connect with my browser, getting the standard “Unable to connect” page again. The behavior is now in line with what we expected from the lsof -i:80 output.