Adding an offline page when rebuilding

Maybe we just implemented the offline page because we started using the upgrade procedure »stop container, git pull, launcher rebuild« after being hit by things like [1,2,3] for a few times actually.

Maybe something changed on the robustness of killing PostgreSQL if it wouldn’t shutdown in time to run through the upgrade process smoothly.

Either way, the online upgrade (again) worked well for us when giving it another shot right now. So, nevermind and sorry for the noise.

[1] Discourse stuck on "Currently Upgrading"
[2] Upgrade failed due to unclean database shutdown
[3] Upgrade failed due to unclean database shutdown II

3 Likes

That’s a bit confusing, since what follows is a guide for installing and configuring nginx outside the container.

In any case, today I realized an additional benefit of this external nginx configuration: If you are used to seeing IP addresses 127.0.0.1 or your docker address (probably starting with 172.) as a registration or login IP address, it may have been because IPv6 traffic being forwarded into the container did not carry its IPv6 address along with it, unlike IPv4. With this configuration, you will now see correct IPv6 addresses instead of local addresses.

In other words, this configuration is essentially required for correct function of a useful administrative tool on the increasingly-IPv6 internet. (In the US, this includes lots of mobile traffic.)

4 Likes

Thanks for this very helpful guide! A couple of comments:

I think sudo apt-get install letsencrypt has been replaced with sudo apt-get install certbot. Running the former, I get the notice Note, selecting 'certbot' instead of 'letsencrypt'

A friend noticed that Facebook sharing of the site showed a preview of “301 moved permanently”.

Edit: I had originally replaced the location / section of the port 80 server block with the location / section of the port 443 server block. But I think that’s redundant. Instead I just deleted the port 80 server block, which served as a redirect block, and added:

    listen [::]:80;
    listen 80;

in the appropriate section of the main server block.

I also enabled https redirect (not sure if that’s necessary) from within Discourse settings.

That fixed the issue with FB sharing, and it does seem as though regular HTTP requests are being redirected to HTTPS. If there is another or better method, please let me know.

2 Likes

Thanks for the tutorial, it’s great. Now my 502 page looks much better.
In my practical case I have to add the nginx configuration to the /etc/nginx/sites-enabled/discourse.conf file.
I have successfully installed Discouse after nginx is running wordpress.

2 Likes

I ran into the problem of nginx not knowing about the renewed cert because it wasn’t restarted as installed following this guide. For me, the solution was:

systemctl edit certbot

Then I added the two lines:

[Service]
ExecStartPost=/bin/systemctl reload nginx

Or, on a system where I’m using a separate mail-receiver container that also shares the cert from the system,

[Service]
ExecStartPost=/bin/systemctl reload nginx
ExecStartPost=/bin/sh -c 'cd /var/discourse && ./launcher restart mail-receiver'
3 Likes

Thanks for the tutorial, which works quite fine for me.

I was just wondering: If the for example googlebot sees that error page - would it know that this is a temporary page? Or do we need to send some kind of Error Code to make it aware of the temporary nature of the change?

I would rather not see google delete all indexing done to my forum because of a more fancy error page…

1 Like

Google should see the 500/502 as a sign to ‘come back later’. As long as your site isn’t being rebuilt too regularly you should have no problems.

I’ve been running my forum behind nginx for a long time now and it has not had an adverse affect on ranking.

4 Likes

Okay, I was unsure if 502 is still being sent.

1 Like