Setup behind nginx

Troubleshooting
1

Looking a way to setup mattermost behind nginx and in docker

As nginx redirect to mattermost, when signin the address used is the docker address instead of the external ip address.

There was a Domain parameter in config.json which is not valid any more. We used it to configure the public ip address.

Any other way to do the configuration ?

Thanks for your help.

Jean-Yves

2

Hi Jean-Yves,

You should not need to do any configuration of Domain if you are using the latest from master. There where a number of issues related to signin and incorrect links which should be fixed in the latest build from master.

If you want to wait for a release that fixes these issues, 0.6.0 is going to be released soon.

Let me know if you require any more assistance.

Christopher

3

Hi Chrisopher,

Already using the last version from github (updated yesterday).
I explain the problem. We have a lab with an external Ip address, mattermost is inside a VM with a private Ip address, nginx is doing the translation. As soon as we want to login, we are redirected to the internal Ip which is not accessible. Hope this will clarify.

4

Is this after a team is already setup and your trying to login? What exact URL are you seeing the problem with?

Internally we run everything through an amazon load balancer which should work similarly.

5

I’m experiencing this also. When I hit the IP of the server for the first time nginx is serving the signup form fine. Entering my e-mail address lands me on http://localhost::8065/signup_team_complete/?d=etc…

Looking into this myself now too. I’ll post a solution if I resolve it.

6

Hi,
With v1 it works right out the box. My nginx config is as follows:

upstream mattermost_proxy {
  server 192.168.10.10:8065;
}

server {
  listen       443;
  server_name  chat.example.com;

  ssl on;
  ssl_certificate      /etc/nginx/ssl/server.crt;
  ssl_certificate_key  /etc/nginx/ssl/commercial.key;

  ssl_session_cache shared:SSL:1m;
  ssl_session_timeout  5m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

  location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://mattermost_proxy;
  }

  location /api/v1/websocket {
    proxy_pass http://mattermost_proxy;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }

  client_max_body_size 4G;
  keepalive_timeout 10;
}

Websocket requires the special config as documented here: https://www.nginx.com/blog/websocket-nginx/

7

I’m running into the same problem. Digging a bit further into it (with firebug on firefox) I was able to see that the page comes back correctly, but the HTML contains a line at the very end that (I believe) triggers the buggy redirect. These are the last 4 lines of it:

<script>
	window.setup_home_page({"TeamURL":"https://hdblx086:49181/myteam","Title":"My Team- Home"});
  </script>
</body>
</html>

where ‘hdblx’ corresponds to the URL I’m using to proxy the requests to in my nginx setup. In principle my setup looks like that of ‘pbruna’. I have no clue why mattermost inserts this redirect, but maybe someone know how to provide a proper nginx directive for telling mattermost what the effectively used URL is.I would have guessed that “proxy_set_header” does the job, but maybe it isn’t.

8

Looks like nginx isn’t settings the host properly. Can you confirm you have a line like proxy_set_header Host $http_host; in your nginx config.

9

wow, you made my day! (sorry for the late reply).
I accidently used

proxy_set_header X-Forwarded-Host $http_host

and that didn’t work. Replacing ‘X-Forwarded-Host’ with ‘Host’ was the solution. Wonderful!