Adding an offline page when rebuilding

sam · June 4, 2016, 12:20pm

Personally if I wanted the best experience

I would add an haproxy in tcp mode container to farm reqs to either online/offline container
have the nginx offline container mount the same SSL volume so you don’t need to fuss with running lets encrypt in cron and simply have existing template run it
have a data container so I can bootstrap while online

nginx proxying to nginx is tricky to get right, for example the setup here is restricting uploads to 2 megs, but plenty of other caveats

fefrei · June 4, 2016, 12:41pm

Why is that? I have a super similar setup running in production, and just successfully uploaded a 10 MB file to it.

sam · June 4, 2016, 12:57pm

Correction, 20mb but really you want to set that to 0

fefrei · June 4, 2016, 1:01pm

Good suggestion, I’ve done that.
(I also made the post a wiki post.)

sam · June 4, 2016, 1:05pm

Honestly, I would be significantly less worried about this stuff if the offline/proxy app was running in a container, so much less error prone

I worry that there is way too many manual steps here and underlying versions are unknown

fefrei · June 4, 2016, 1:08pm

You may be right – but to my defense: We’ve been recommending a setup like this for running other sites on the same host for two years now.

sam · June 4, 2016, 1:11pm

In my defence that howto is using “listen spdy” which kind of proves my point

github.com

discourse/discourse_docker/blob/master/templates/web.ssl.template.yml#L21


       listen 80;
       return 301 https://$$ENV_DISCOURSE_HOSTNAME$request_uri;
     }
     server {
- replace:
   hook: ssl
   filename: "/etc/nginx/conf.d/discourse.conf"
   from: /listen 80;\s+gzip on;/m
   to: |
     listen 443 ssl http2;
     ssl_protocols TLSv1.2;
     ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA;
     ssl_prefer_server_ciphers on;
     ssl_ecdh_curve secp384r1:prime256v1;


     ssl_certificate /shared/ssl/ssl.crt;
     ssl_certificate_key /shared/ssl/ssl.key;


     ssl_session_tickets off;
     ssl_session_timeout 1d;
     ssl_session_cache shared:SSL:1m;

Cc @riking

codinghorror · June 6, 2016, 8:11am

So it looks like @sam is pretty strongly opposed to the current approach, and looking at how difficult it is to get a newly compiled Nginx on Ubuntu 14.04 with OpenSSL 1.0.2 support (absolutely required for http/2 to work), I tend to agree. @mpalmer says Ubuntu 14 will never get a new version of OpenSSL in any form via apt-get, and 1.0.1 is end of life in December of this year.

(Is it possible to copy the nginx binary from Ubuntu 16 to Ubuntu 14? Does that work? That might be simplest, if it does…)

Anyway, it looks like we need another container here, a container that holds Nginx to do the routing and so on.

mpalmer · June 6, 2016, 9:14am

Doesn’t look like it; the package dependency for, ironically, libssl1.0.0 is the sticking point. It might work, if the ABI extensions in libssl1.0.0 aren’t relied upon, but it’d be a risky thing to try in general. I recommend a separate nginx-only container.

codinghorror · June 9, 2016, 11:42pm

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 · June 10, 2016, 8:12am

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:

github.com

omniauth/omniauth/blob/1cc1cf4b2821a7d2a4a376a5ca93c61b6bd8b5f1/lib/omniauth/strategy.rb#L499




  protected


    def merge_stack(stack)
      stack.inject({}) do |a, e|
        a.merge!(e)
        a
      end
    end


    def ssl?
      request.env['HTTPS'] == 'on' ||
        request.env['HTTP_X_FORWARDED_SSL'] == 'on' ||
        request.env['HTTP_X_FORWARDED_SCHEME'] == 'https' ||
        (request.env['HTTP_X_FORWARDED_PROTO'] && request.env['HTTP_X_FORWARDED_PROTO'].split(',')[0] == 'https') ||
        request.env['rack.url_scheme'] == 'https'
    end
  end
end

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 · June 17, 2016, 9:32pm

@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:

Home page of site in one window, in anon mode
/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 · June 17, 2016, 8:05pm

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 · June 17, 2016, 8:06pm

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 · June 17, 2016, 8:10pm

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 · October 13, 2016, 6:00am

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;  # &lt;-- 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 · October 13, 2016, 6:14am

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

Harkirat_Singh · October 13, 2016, 7:29am

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

fefrei · October 13, 2016, 7:45am

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

Harkirat_Singh · October 13, 2016, 8:01am

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

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?