Nginx site config for Mattermost and websockets

Community Support Web
1

Hi guys,

has anybody set up Mattermost on a Hestia CP controlled server?

Mattermost is an opensource Slack alternative using websockets. For testing I installed it on an ISPconfig server and it worked but due to some incomprehensible reasons I don’t get it done with Hestia.

Indeed Mattermost is running, I can reach it on browser and I can log in but then a very strange behaviour begins which I don’t want to explain further here because it might not be connected with Hestia.

But for debugging process I would please you to have a look at my Nginx site config to ensure that it’s not a problem of websockets, Nginx or php.

What I have done:

I created a subdomain with Hestia panel as user “user” with webtemplate: default and backend template PHP-FPM:default, and activated SSL support.

Since adding the necessary config with a simple nginx.hsts.conf* file didn’t work I deleted most parts in the original nginx.conf and added the Mattermost recommended code.

So, my /home/user/conf/web/mattermost.mydomain.com/nginx.conf looks like that:

upstream backend {
    server 127.0.0.1:8065;
    keepalive 32;
}

proxy_cache_path /var/cache/nginx/mattermost levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off;

server {
    listen      45.157.xxx.xxx:80;
    server_name mattermost.mydomain.com ;
    return 301 https://$server_name$request_uri;
}

server {
    listen      45.157.xxx.xxx:443 ssl http2;
    server_name mattermost.mydomain.com ;

    ssl_certificate      /home/user/conf/web/mattermost.mydomain.com/ssl/mattermost.mydomain.com.pem;
    ssl_certificate_key  /home/user/conf/web/mattermost.mydomain.com/ssl/mattermost.mydomain.com.key;
    ssl_stapling on;
    ssl_stapling_verify on;

   location ~ /api/v[0-9]+/(users/)?websocket$ {
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       client_max_body_size 50M;
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       client_body_timeout 60;
       send_timeout 300;
       lingering_timeout 5;
       proxy_connect_timeout 90;
       proxy_send_timeout 300;
       proxy_read_timeout 90s;
       proxy_pass http://backend;
   }

   location / {
       client_max_body_size 50M;
       proxy_set_header Connection "";
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       proxy_read_timeout 600s;
       proxy_cache mattermost_cache;
       proxy_cache_revalidate on;
       proxy_cache_min_uses 2;
       proxy_cache_use_stale timeout;
       proxy_cache_lock on;
       proxy_http_version 1.1;
       proxy_pass http://backend;
       }
}

I guess most of the original “location” directives and logging directories are not necessary, but I am a bit unsure about this “fastcgi” parameter from the original config:

fastcgi_pass unix:/run/php/php7.3-fpm-mattermost.mydomain.com.sock;

Is it needed to run the site properly? Did I forget something important?

Thanks a lot.
Nifoco

Hestia 1.1.1
Nginx with FPM (no Apache installed)
MySQL
Debian 10.3

2

haven’t used mattermost itself yet, but looks interesting… maybe I give it try on the weekend. so far I installed quite a lot alongside hestia already and used nginx just as reverse proxy with a sub-domain for ssl and created a db etc.

so I guess essentially the same thing, you are trying here, just for other things (redmine f.i.) :man_shrugging:t2: :grin:

your approach looks fine so far, obviously I would not change the config file that way for a later production use, as hestia overwrites it everytime you touch the settings in the panel. however to find a working config it might be okay for staging purposes to do it directly in there.

from the install requirements on the mattermost guide there is just a database needed, no php at all. you should therefore not need the fastci_pass directive.

the ‘very strange behaviour’ sounds suspicious… a guess into the blue would be “caching issues” as there is a specific rule regarding that in your config.

also the cross-origin/sameorigin topic could be an issue, sometimes browsers complain if the directives for that are doubled in the proxy chain…

as said just guessing around, hope it helps. might have to check that self hosted slack alternative later though…

1 Like
3

Falzo, you made my day, you set me on the right track:

The “strange behaviour” (“teams” show up even deleted, MM doesn’t stop reminding me to set up “email notification” even I’ve done this twice, after logging in MM doesn’t show the chat but searching and searching…) has something to do with cache or proxy settings.

When setting up Hestia it changes the main nginx conf /etc/nginx/nginx.conf and adds some cache and proxy parameters. Some of them obviously fight against the Mattermost settings.

I commented out all these parameters in /etc/nginx/nginx.conf and Mattermost runs like a charm. Hurrah!

## Proxy settings
    #proxy_redirect                  off;
    #proxy_set_header                Host $host;
    #proxy_set_header                X-Real-IP $remote_addr;
    #proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;
    #proxy_pass_header               Set-Cookie;
    #proxy_buffers                   32 4k;
    #proxy_connect_timeout           30s;
    #proxy_read_timeout              300s;
    #proxy_send_timeout              180s;

## Cache settings
    #proxy_cache_path /var/cache/nginx levels=2 keys_zone=cache:10m inactive=60m max_size=1024m;
    #proxy_cache_key "$host$request_uri $cookie_user";
    #proxy_temp_path  /var/cache/nginx/temp;
    #proxy_ignore_headers Expires Cache-Control;
    #proxy_cache_use_stale error timeout invalid_header http_502;
    #proxy_cache_valid any 1d;

Very likely you can keep the proxy settings and must only do something with cache settings, but it’s to early to claim that.

Next step is now to find out what s really responsible for the “strange behaviour” to keep most of these parameters which I think Hestia added with good cause.

2 Likes
4

awesome! happy to see you figured a way to move forward :wink:

5

Maybe you find a more elegant solution than simply commenting out the Nginx “cache” settings if you give Mattermost a try.

Nginx “proxy” settings can stay activated as it turned out. I removed all my # and haven’t get issues by now.