Add an offline page to display when Discourse is rebuilding or starting up

[codinghorror (Jeff Atwood)]

This change seems to cause problems with https redirects for logins, too – even with use https (force https) checked. After instituting the nginx outer layer with https, I had to:

• enable http return URL for Google logins
• enable http return URL for GitHub logins

Otherwise you get errors, e.g.

(github) Authentication failure! redirect_uri_mismatch: OmniAuth::Strategies::OAuth2::CallbackError, redirect_uri_mismatch | The redirect_uri MUST match the registered callback URL for this application. | https://developer.github.com/v3/oauth/#redirect-uri-mismatch

These are problems I didn’t have when the site was using Let’s Encrypt inside the container…

[fefrei (Felix Freiberger)]

I tried to research that and think this is a Discourse bug.

Enabling use https should cause Discourse to only use HTTPS URLs, but neither the Github authenticator, the Google authenticator nor their superclass inspect this site setting. Omniauth tries to detect SSL like this:

https://github.com/intridea/omniauth/blob/1cc1cf4b2821a7d2a4a376a5ca93c61b6bd8b5f1/lib/omniauth/strategy.rb#L499

Adding

proxy_set_header X-Forwarded-Proto $scheme;

to the nginx configuration might work around that, but I’m not sure this is passed on by Discourse’s internal nginx and cannot test that right now.

I do know that SSO is not affected.

[codinghorror (Jeff Atwood)]

@fefrei I am not sure this is needed, because I just rebuilt talk.commonmark.org using the standard web updater. I had two browser windows open:

1. Home page of site in one window, in anon mode
2. /admin/upgrade rebuild process going in one window

I mashed f5 like an insane in window #1 and at no point during the rebuild was the site unavailable to me as an anonymous user hitting the homepage. Screenshot proof:

So… if there is never an outage during a typical web update… is this complex hack really needed?

[fefrei (Felix Freiberger)]

This is in place to serve a message during rebuilding and the following boot-up – web upgrades should always be fine

(It may not be worth it for a stable stock site. I think it’s definitely worth it if you either already have to use a nginx reverse proxy for another reason, or if you rebuild often, e.g. to install or uninstall plugins.)

[codinghorror (Jeff Atwood)]

There is some stuff I don’t like about this

• it is quite complex
• it screws up http/2 completely (unless you are on Ubuntu 16)
• it does not help in the typical update case only in the rare full rebuild case

[fefrei (Felix Freiberger)]

it is quite complex

I agree, as long as this is the only reason for a front-end nginx instance.

If you need to have that for some other reason, you can start with the Create an error page section – the rest is really straightforward. (And if you need to set up a front-end nginx, I think these steps are easier to follow than these instructions.)

[Harkirat_Singh]

@fefrei

While we’re here, we’ll configure Nginx to redirect all requests to HTTPS, and to allow requesting a free certificate from letsencrypt:

server {
        listen 80; listen [::]:80;
        server_name discourse.example.com;  # <-- change this

        location /.well-known/acme-challenge/ {
                root /var/www;
        }

        location / {
                return 301 https://$host$request_uri;
        }
}

Should I delete the rest of the template already included in /etc/nginx/sites-available/default

[fefrei (Felix Freiberger)]

Yes!
Thanks for pointing this out, I updated my post to be more clear in this aspect.

[Harkirat_Singh]

To make the cert auto renew in Ubuntu 14.04 LTS, I did this:

cd /etc/cron.daily
nano letsencrypt-renew

Would this also work with 16.04 LTS? Because I don’t think I need to install certbot-auto in 16.04 LTS.

[fefrei (Felix Freiberger)]

The howto was created with 16.04, so my steps should match exactly

[Harkirat_Singh]

The howto was created with 16.04, so my steps should match exactly

I can understand that… but in your post you said:

You must set a reminder run to letsencrypt renew before your cert expires in three months. For tips on automating this, see the certbot documentation.

So I wanted to know from @codinghorror if the auto renew steps he added would work with 16.04LTS?

@fefrei Can you guide me on how to auto renew without certbot-auto?

[Harkirat_Singh]

For tips on automating this, see the certbot documentation.

Now I feel stupid… let me check the documentation

[fefrei (Felix Freiberger)]

@Harkirat_Singh

@fefrei Can you guide me on how to auto renew without certbot-auto?

I use this simple shell script, run by cron:

#!/bin/bash
letsencrypt renew
/usr/sbin/service nginx reload

[Harkirat_Singh]

This basically means that you are renewing the certificate everyday, right?

[jomaxro (Joshua Rosenfeld)]

No it doesn’t. Cron jobs don’t have to be daily - you can pick any time period that you want.

[fefrei (Felix Freiberger)]

certbot renew only processes certs it deems due for renewal. I run this script weekly, which effectively renews every two months or so.

[Harkirat_Singh]

you mean letsencrypt renew

[fefrei (Felix Freiberger)]

True that – the client is being renamed to certbot, so I’m mixing them up all the time because the name depends on your distribution and version…

[ljpp]

Slightly off-topic, but if you use CloudFlare’s DNS you will get an offline page and a cached version of your site provided by them, without even touching your Discourse setup.

[ewanly (EW 👌)]

I did followed your @fefrei instructions and everything working fine. Thanks to your well documentation . When I stop discourse I’m getting my special error page. But when I’m rebuilding discourse I’m getting the default 404 error page!.

Is there is anything I could do yet to fix this?