Avatar, Site Logos, and Cert Errors

[markcichy (Mark)]

All of the “solutions” that have been presented do not fit my specific use case:

• Remote server (within the same network) – I believe all the examples assume Nginx is running on the same server as Discourse, I am using proxy_pass to hit another internal IP

Why have I done this? Higher security and dispersal of resources. It’s the same reason I split up services in two ways: by container and VM. The suggested docs seem to favour a condition where all services are running on the same server.

I would imagine that the conditions described above would be fairly common. If any of those can be used to accommodate a proxy_pass condition I am more than happy to augment my settings to suit. I just feel that providing a blanket “you’re on your own statement” because I am trying to avoid a ‘putting all my eggs in one basket’ scenario is a little unwarranted.

[itsbhanusharma (Bhanu Sharma)]

proxy_pass 192.168.20.10:8080

in discourse, expose 192.168.20.10:8080:80

remove the socketed template.

enable force_https

Profit.

[markcichy (Mark)]

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

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.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

In app.yml change default listening port to 8080?

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

@markcichy

What about SSL 443? Leave 443?

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

@markcichy

Remove the redirect on 80 from Nginx server block?

That has to exist.

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

@markcichy

Does #3 matter if I’m just changing the proxy_pass on the internal side? Probably not? I’m just re-routing to 8080?

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)

@markcichy

The biggest question: why? Why would this make a difference, changing to 8080 from 80?

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

@markcichy

Keep all other Templates active? Just comment out socketed ?

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.

[markcichy (Mark)]

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

}

[markcichy (Mark)]

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

[RGJ (Richard - DiscourseHosting.com)]

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

[itsbhanusharma (Bhanu Sharma)]

@markcichy

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

This part needs to be changed

[rossierd (Daniel Rossier)]

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

[markcichy (Mark)]

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

[markcichy (Mark)]

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

[Stephen]

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

[markcichy (Mark)]

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?

[Stephen]

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:

Multisite configuration with Docker

You may wish to host multiple domains on a singled Docker setup. To do so follow these instructions: We strongly recommend you run separate web and data containers The standalone container is extremely easy to configure, however has a couple of drawbacks You will need to stop your site when bootstrapping a new image You run through the db bootstrap only when needed Multisite is a fairly advanced topic, learn about hooks before attempting this. Understand hooks Discourse templates use pups, …

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

[markcichy (Mark)]

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?

[Stephen]

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.

[markcichy (Mark)]

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

[Stephen]

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

[markcichy (Mark)]

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?

[Stephen]

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.