Avatar, Site Logos, and Cert Errors

support
#35

This has a whole bunch of implications beyond what you’ve just written that I’ll have to investigate–we could have started there. :wink:

Immediate questions:

  1. In app.yml change default listening port to 8080?
  2. What about SSL 443? Leave 443?
  3. Remove the redirect on 80 from Nginx server block?
  4. Does #3 matter if I’m just changing the proxy_pass on the internal side? Probably not? I’m just re-routing to 8080?
  5. The biggest question: why? Why would this make a difference, changing to 8080 from 80?
  6. Keep all other Templates active? Just comment out socketed?

Thanks for your help, and patience.

#36

That’s your preference, I wrote it as an example. You can also choose to expose 80.

There is no benefit or sense in enabling ssl on a local network

That has to exist.

server {
    listen 80;
    server_name discourse.example.com;
    return 301 https://example.com$request_uri;
}

That’s exactly what’s happening, You’re forwarding all requests being received by your proxy/ingress to an internal backend on port 8080 (i.e. discourse)

Answered in #1 it was a personal preference, feel free to use whichever port you fancy.

You particularly don’t need anything that has to do with sockets or ssl on the internal server. SSL should be properly terminated on the reverse-proxy.

NB: most of it is a personal preference based on deployment for customers.

#37

Okay. Thanks for comments.

Here is my Nginx server block, FYI:

server {
# ssl
listen 443 ssl http2;
listen [::]:443 ssl http2;

   server_name discourse.mobiusnode.io;

   location / {
           #http trafic
           proxy_pass http://192.168.86.108;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header Host $http_host;
           proxy_http_version 1.1;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto https;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection "upgrade";

   }

ssl on;
ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # managed by Certbot
ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # managed by Certbot

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

add_header Strict-Transport-Security "max-age=63072000;";
ssl_stapling on;
ssl_stapling_verify on;

client_max_body_size 0;

}

server {
if ($host = discourse.mobiusnode.io) {
return 301 https://$host$request_uri;
} # managed by Certbot

listen 80;
listen [::]:80;

server_name discourse.mobiusnode.io;
return 404; # managed by Certbot

}

#38

The behaviour I am experience is under those conditions above.

Beginning of app.yml looks like this:

## this is the all-in-one, standalone Discourse Docker container template
##
## After making changes to this file, you MUST rebuild
## /var/discourse/launcher rebuild app
##
## BE *VERY* CAREFUL WHEN EDITING!
## YAML FILES ARE SUPER SUPER SENSITIVE TO MISTAKES IN WHITESPACE OR ALIGNMENT!
## visit http://www.yamllint.com/ to validate this file as needed

templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

## which TCP/IP ports should this container expose?
## If you want Discourse to share a port with another webserver like Apache or nginx,
## see https://meta.discourse.org/t/17247 for details
expose:
- "80:80" # http
- "443:443" # https

params:
db_default_text_search_config: "pg_catalog.english"

## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "1024MB"

## can improve sorting performance, but adds memory usage per-connection
#db_work_mem: "40MB"

## Which Git revision should this container use? (default: tests-passed)
#version: tests-passed

#39

You are connecting to port 80 on the second nginx, so it thinks you’re connecting to http and not https.

Try to find the X-Forwarded-Proto in the inner nginx and change proxy_set_header X-Forwarded-Proto $thescheme; to proxy_set_header X-Forwarded-Proto https;

or forward your traffic to https proxy_pass https://192.168.86.108

3 Likes
#40

This part needs to be changed

#41

What does the log/production.log (in the running docker) say when you try to log in with failure (hence with force_https=true) ?

#42

@RGJ – I like your solution! Do I force-https with the last suggestion? RE proxy_pass https.
EDIT: I get a 502 if all I do is use proxy_pass https://192.168.86.108
EDIT2: I concealed 80 on Discourse via app.yml and it was still broke–I just re-read your post, does the Discourse container possess it’s own instance of Nginx? So, in effect, I am passing a proxy to a proxy? Sorry, I am really confused at this point.

#43

@itsbhanusharma do I comment out 80:80 #http and use @RGJ’s advise to proxy_pass https?

#44

Why aren’t you following the supported process for multisite here? You’re effectively reinventing a very fragile wheel.

1 Like
#45

So many links have been provided now, @Stephen-- that I am at a loss to make sense of it all. I thought I was following supported processes. Are the comments above not supported? :pensive:

#46

Yes because you weren’t using force_https, hence the #unsupported-install tag above. If you deviate from a supportable track then you won’t receive much assistance.

Start here:

There’s a separate guide to handle SSL encapsulation with multisite.

#47

So, does the standard container only run http? How is what I am trying to do multi-site? I’m not attempting to host multiple domains? I have a single domain. Can you please clarify how that addresses my issue?

#48

What did you mean by:

I’ve setup Discourse servers in a about 5 instances now and all seem to be exhibiting odd behaviour; not sure if it is indeed a Bug or if anyone else has experience same.

#49

Independent infrastructures, not in anyway connected to one another.
But all with very similar settings as per above.

#50

So why is nginx proxying the host at all? What else is happening on the machines?

#51

We have several VM’s that are not exposed externally, the traffic is routed through the proxy (is exposed externally), to the Discourse VM internally. Similar situation in each of the separate installs. Does that clarify?

#52

Not really, but one way or another this is technical pain you’re just going to have to live with. It’s impossible to comment on whether there’s a better approach when the use case and topology is so ambiguous.

2 Likes
#53

I believe the right *mix of solutions was as follows:

As per @itsbhanusharma:
EDIT /var/discourse/containers/app.yml and amend ports to some custom, I used:

- "8080:80" #http
- "4343:443" #https

Did a ./launcher rebuild app

I then modified our externally accessible proxy to forward requests on 80/443 to http://internal_ip:8080

After a sudo nginx -t and sudo systemctl restart nginx I logged into https://discourse.mobiusnode.io server (which was still exhibiting the issues above) and enabled force_https, at which point it appears all is working.

I am now going to reproduce this on the remaining servers/infrastructures.

#54

Attached is an icognito window of login to site with SSL key active, images, appear, etc.

Screen Shot 2020-05-25 at 2.35.36 PM
Screen Shot 2020-05-25 at 2.35.36 PM3456×3010 1.13 MB