Adding an offline page when rebuilding

(EW 👌) #41

I’m running Ubuntu 14.04, do you think that Nginx we installed here is supporting http2 ?
Could be this change a help to show the offline page while rebuilding?

PS: Sorry I hadn’t a chance too look at the logs at /var/log/nginx/ as you’d asked. As you may saw I’m facing some other serious problems :frowning: soon I look at it and will come back to you.

(Felix Freiberger) #42

I’m not sure – and I don’t think I have a 14.04 instance lying around to test. But you can easily try it: Add http2 to the listen block, und service reload nginx. If it errors out, it isn’t supported :slight_smile:

(EW 👌) #43

You were right. I had one mistakes in Nginx config. I just fixed it and now the offline page working like charm. Thank you a lot :champagne:

(EW 👌) #44

For Info: I just had a chance to try it with my 14.04 Ubuntu. It’s not supported. Nginx failed to reload.

(Jeff Atwood) #45

Hmm, wait, @sam complained this turns off http2. But, I upgraded to Ubuntu 16.04 and then changed this line:

listen 443 ssl; listen [::]:443 ssl;


listen 443 ssl http2; listen [::]:443 ssl http2;

And it seems to pass http/2 through fine now?

(Rafael dos Santos Silva) #46

Yeah, on 16.04 nginx can do http2.

(Felix Freiberger) #47

I’ve slightly worded down the warning in the initial post to reflect this. Thanks for confirming, @codinghorror and @Falco!

(Jeff Atwood) #48

6 posts were split to a new topic: Let’s Encrypt won’t renew with offline page

(Hosein Naseri) #49

Can you clarify the purpose of adding this header here? It seems it has conflict with embedding comments.

(Felix Freiberger) #50

No sense at all, at least now, since Discourse returns its own header. I’ll remove it from the howto. Thanks for reporting this!

Let's Encrypt won't renew with offline page
(RoldanLT) #51

Hi, with the recent version of discourse is this still needed?
Any downside/disadvantage of using this approach?

Why not modify directly the Nginx built in/default with discourse/docker to specify error pages?

(Matt Palmer) #52

Because the container needs to running in order to serve pages, and the point of this configuration is to serve an error page when the Discourse app container isn’t running.

(Hosein Naseri) #53

When you define the ssl_ciphers in nginx like what is proposed here, then your instance doesn’t support TLSv1 and TLSv1.1 anymore. Or at least not in my situation.

(Felix Freiberger) #54

True that, so you could simplify the configuration by removing the outdated protocols. I’ll do that, thanks!

(Bhanu Sharma) #55

I had a Question!!

will using https:// instead of http:// in the above url break or else create any complication into the setup?

(Felix Freiberger) #56

Why would you want to do that? This traffic never touches the network, there is no reason for HTTPS here.
In this setup, HTTPS is provided entirely by the outer Nginx instance :slight_smile:

(Bhanu Sharma) #57

I asked that because in such a case with wordpress, using a https proxy for a http site will mess up a lot of thing even if one has got site working on both if the url is left http then there are a lot of content warnings at times so I was just curious to know.

anyway thanks for clarification.

(Felix Freiberger) #58

This is taken care of by the headers set by Nginx, especially X-Forwarded-Proto: It tells Discourse that the user-facing protocol is HTTPS :slight_smile:

(Bhanu Sharma) #59

So necessarily it won’t matter if http or https is used in this configuration? right?

Ps: sorry for a noob question, I don’t really know much about http headers

(Felix Freiberger) #60

If you follow the instructions in the original post, this should work out :+1: