Welcome to nginx! after fresh installation

1marc1 · April 9, 2020, 12:41pm

Hi,

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.

Marc.

pfaffman · April 9, 2020, 12:47pm

Is nginx installed on the server? It shouldn’t be. But discourse-setup should have detected that. Are you sure that your DNS is correct?

1marc1 · April 9, 2020, 12:59pm

Nginx is not installed on the server. As far as DNS is concerned, I have an A record and PTR record for the server. What other requirements are there?

Marc.

Stephen · April 9, 2020, 2:42pm

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.

1marc1 · April 10, 2020, 1:30pm

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

Stephen · April 10, 2020, 1:29pm

Show us the result of:

lsof -i:80

1marc1 · April 10, 2020, 1:31pm

The command lsof -i:80 does not give any output.

Stephen · April 10, 2020, 1:34pm

Then nothing is listening on port 80?

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.

1marc1 · April 10, 2020, 1:35pm

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

Stephen · April 10, 2020, 1:40pm

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.

1marc1 · April 10, 2020, 1:54pm

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.

Stephen · April 10, 2020, 1:58pm

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?

1marc1 · April 10, 2020, 2:02pm

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.

I have not altered any YML files.

Stephen · April 10, 2020, 2:05pm

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.

1marc1 · April 10, 2020, 2:06pm

I was thinking the same. Let me do some digging to try and find out where that page is coming from.

1marc1 · April 10, 2020, 2:17pm

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.

1marc1 · April 10, 2020, 2:31pm

I had a look inside the container via docker exec -it <cont.id> /bin/bash and checked the output of ps aux. In there was the following line:

root 2030 0.2 0.0 2160 1328 ? Ss 14:10 0:01 runsv nginx

It therefore looks like nginx is running inside the container, however the output of nsenter -t 1446 -n netstat -plnt shows:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:3000          0.0.0.0:*               LISTEN      3606/unicorn master 
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      3590/postmaster     
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      3591/redis-server * 
tcp6       0      0 :::5432                 :::*                    LISTEN      3590/postmaster     
tcp6       0      0 :::6379                 :::*                    LISTEN      3591/redis-server *

Does that indicate that the container is not listening on port 80 and 443?

riking · April 22, 2020, 7:41pm

A post was split to a new topic: Getting ‘welcome to nginx’ instead of Discourse