Installare Mattermost Omnibus su Ubuntu 20.04 LTS

Perché scegliere l’Omnibus su Ubuntu 20.04 LTS

Se devi mettere in piedi Mattermost in fretta ma senza improvvisare, il pacchetto Omnibus è la strada più lineare: porta con sé i componenti necessari, riduce il numero di pezzi da allineare a mano e rende più semplice il ciclo di aggiornamento. Su Ubuntu 20.04 LTS funziona bene, a patto di trattarlo come un servizio di produzione e non come un’app da test in VM.

La scelta tecnica vera non è “installo o no”, ma dove vuoi concentrare la complessità. Con Omnibus la sposti sul package management e sulla configurazione del servizio; in cambio eviti di assemblare a mano web server, runtime, database e dipendenze. Per un’istanza singola, o per una prima fase di adozione, è un compromesso sensato.

Qui sotto trovi una procedura pensata per un server Ubuntu 20.04 LTS pulito, con accesso root o sudo, hostname già deciso e DNS sotto controllo. Se uno di questi punti non è vero, conviene fermarsi prima di aprire porte o installare pacchetti.

Prerequisiti che conviene chiudere prima dell’installazione

Prima di toccare il sistema, verifica tre cose: nome host corretto, risoluzione DNS funzionante e risorse minime ragionevoli. Mattermost non è leggero come una landing page: anche con pochi utenti, CPU, RAM e storage vanno dimensionati con margine. Per un’istanza base, 2 vCPU e 4 GB di RAM sono un punto di partenza, non un target di lungo periodo.

Se prevedi accesso pubblico, prepara anche il certificato TLS. L’Omnibus può gestire parte della terminazione HTTPS, ma in molti ambienti è più pulito mettere Mattermost dietro un reverse proxy già standardizzato. Se hai già Nginx o Apache con policy consolidate, non c’è motivo di cambiare architettura solo perché il pacchetto lo consente.

Controlla i prerequisiti minimi con questi comandi:

lsb_release -a
hostnamectl
free -h
df -h /
ss -lntp

Esito atteso: Ubuntu 20.04 LTS, hostname coerente con il DNS, memoria libera sufficiente per l’installazione e nessun conflitto evidente sulle porte che userai per web e proxy. Se il disco di sistema è già saturo, fermati: installare prima e pulire dopo è il modo migliore per ritrovarti con un servizio instabile.

Scelta dell’architettura: standalone o dietro reverse proxy

La decisione più utile da prendere subito è questa: esporre direttamente Mattermost oppure metterlo dietro un reverse proxy. Per ambienti reali, la seconda opzione è quasi sempre preferibile. Ti consente di centralizzare TLS, HSTS, redirect, limiti di upload e log di accesso, senza legare la vita del servizio a una configurazione web specifica dell’applicazione.

Con reverse proxy puoi anche cambiare certificati, policy TLS e routing senza toccare l’app. Se l’istanza cresce, questa separazione evita che un aggiornamento dell’app rompa il front-end pubblico. L’Omnibus resta il motore applicativo; il bordo HTTP lo governi con lo stack che già conosci.

Se invece sei in un contesto molto piccolo, con test interni o rete chiusa, puoi iniziare con l’esposizione diretta e spostarti poi dietro proxy. La condizione è una sola: lasciare traccia chiara della scelta, così da non dover ricostruire a posteriori dove termina il TLS e dove passa il traffico applicativo.

Installazione del pacchetto Omnibus

Il flusso più pulito è aggiungere il repository ufficiale, aggiornare l’indice pacchetti e installare Mattermost Omnibus. I dettagli del repository possono cambiare nel tempo, quindi conviene verificare sempre la documentazione del vendor prima di copiare e incollare URL vecchi. Qui l’obiettivo è mostrare il processo, non fissare un endpoint che domani potrebbe essere spostato.

Una sequenza tipica è questa:

sudo apt update
sudo apt install -y curl gnupg ca-certificates
# aggiunta repository Mattermost Omnibus: verifica l'URL ufficiale corrente prima dell'uso
# esempio di flusso generale:
# curl -fsSL <repo-key-url> | sudo gpg --dearmor -o /usr/share/keyrings/mattermost.gpg
# echo "deb [signed-by=/usr/share/keyrings/mattermost.gpg] <repo-url> focal main" | sudo tee /etc/apt/sources.list.d/mattermost.list
sudo apt update
sudo apt install -y mattermost

Se il pacchetto non viene trovato, non forzare repository generici o mirror non verificati. Il controllo corretto è confrontare il file di sorgente APT in ``, verificare la chiave usata con `apt-key` non è più una buona pratica sui sistemi nuovi, e confermare che la release sia davvero supportata per la tua build. Se il repository non è pronto per focal, il problema non è il server: è il canale di distribuzione.

Dopo l’installazione, controlla che il servizio esista e sia abilitato:

systemctl status mattermost --no-pager
systemctl is-enabled mattermost
journalctl -u mattermost -n 50 --no-pager

Esito atteso: servizio presente, abilitato all’avvio e senza errori immediati nei log. Se il servizio parte e poi si ferma, la diagnosi va fatta sui log prima di cambiare configurazione a caso. Gli errori di bootstrap sono quasi sempre più informativi di quanto sembri.

Configurazione iniziale: database, URL e file di servizio

La configurazione iniziale è il punto in cui si fanno gli errori che poi costano tempo. L’elemento più importante è l’URL canonico dell’istanza: se Mattermost viene pubblicato con un nome host, quello deve essere coerente con il certificato, con il reverse proxy e con i link generati dall’app. Un mismatch qui produce problemi sottili: login che rimbalzano, web socket instabili, redirect strani.

Il file da verificare è in genere `config.json` oppure un file equivalente gestito dal pacchetto Omnibus. Non conviene editarlo a mano senza backup. Prima fai una copia, poi applica una variazione minima e controllabile.

sudo cp /opt/mattermost/config/config.json /opt/mattermost/config/config.json.$(date +%F).bak
sudo grep -n 'SiteURL\|ListenAddress\|DriverName' /opt/mattermost/config/config.json

Le tre aree da controllare sono: `SiteURL`, backend database e indirizzo di ascolto. Se il pacchetto usa database interno per default, valutalo solo per test o installazioni piccole. In produzione, un database esterno ben monitorato è più facile da gestire e da salvare. Se scegli PostgreSQL esterno, verifica subito connettività, credenziali e versione supportata.

Un controllo rapido del database, se è remoto, può essere questo:

psql -h <db-host> -U <db-user> -d <db-name> -c 'select version();'

Se usi MySQL/MariaDB, il test equivalente è la connessione e una query banale. Il punto non è “vedere se risponde”, ma scoprire subito se hai problemi di autenticazione, TLS o versioni incompatibili. Far emergere questi errori prima dell’avvio evita di inseguire log ambigui lato applicazione.

Avvio del servizio e verifica funzionale

Dopo la configurazione, riavvia il servizio e verifica che esponga la porta prevista. Non limitarti a `systemctl start`: controlla anche socket, risposta HTTP e log applicativi. Una service unit verde non significa che l’app sia davvero pronta a servire utenti.

sudo systemctl restart mattermost
sudo systemctl status mattermost --no-pager
sudo ss -lntp | grep -E '(:8065|:80|:443)'
curl -I http://127.0.0.1:8065

Se la risposta locale è 200, hai almeno validato processo e listener. Se ricevi 502 dietro proxy, il problema è nella catena tra proxy e backend: porta sbagliata, upstream non raggiungibile, permessi socket o time-out. In quel caso non toccare subito l’applicazione; verifica prima il bordo HTTP.

Per una validazione più completa, apri l’interfaccia web e verifica tre cose: login, caricamento della dashboard e invio di un messaggio in un canale di test. La presenza della UI non basta; i websocket devono restare stabili e i messaggi devono transitare senza errori intermittenti.

Reverse proxy: Nginx come bordo pulito

Con Nginx davanti, la configurazione resta semplice e leggibile. L’idea è terminare TLS sul proxy e inoltrare verso l’istanza Mattermost in locale o su rete privata. Questo ti dà un punto unico dove applicare header di sicurezza, limiti di upload e regole di accesso.

Un blocco di base può essere questo, con i dovuti adattamenti al tuo dominio e al certificato:

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

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

    ssl_certificate     /etc/letsencrypt/live/chat.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/chat.example.com/privkey.pem;

    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:8065;
        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_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Il limite di upload va deciso in base all’uso reale, non a sensazione. Se i team allegano immagini o file di progetto, 50 MB può essere poco. Se invece vuoi ridurre l’impatto di upload eccessivi, tienilo stretto e documenta il limite agli utenti. Il punto è che il valore deve essere coerente tra proxy e applicazione.

Dopo il reload di Nginx, verifica con un test HTTP e con il browser. Se compare un errore 400/403/502, guarda prima i log del proxy e poi quelli dell’app. Il layer che scrive l’errore è quasi sempre quello che ti dà la pista giusta.

Hardening minimo che vale davvero la pena fare

La sicurezza va trattata come parte dell’installazione, non come lavoro di rifinitura. Il minimo sindacale è limitare le porte esposte, tenere il sistema aggiornato, non usare account amministrativi condivisi e proteggere il segreto del database. Se il file di configurazione contiene credenziali, i permessi devono essere coerenti con il principio del privilegio minimo.

Controlla le porte aperte dal server:

ss -tulpn
ufw status verbose

Se usi UFW, l’idea è semplice: apri solo SSH, HTTP e HTTPS se servono davvero, e tieni chiuso tutto il resto. Non esporre direttamente il backend se il proxy fa già il suo lavoro. Ogni porta aperta in più è una variabile operativa e una superficie di attacco in più.

Per gli aggiornamenti, non rimandare troppo. Mattermost e i componenti di sistema vanno mantenuti in una finestra regolare, con backup prima del cambio e una procedura di verifica dopo. Un upgrade fatto bene è noioso: backup, installazione, test, controllo log. Se invece è “clicco e vedo”, stai semplicemente spostando il rischio in avanti.

Backup e rollback: la parte che salva la giornata

Prima di qualsiasi modifica seria, salva almeno configurazione e database. Senza rollback, un errore banale può trasformarsi in ore di fermo. Per Mattermost, il backup utile è quello che ti permette di tornare a uno stato coerente: file di configurazione, dati applicativi e dump del database.

Un esempio di flusso minimo, da adattare al tuo motore SQL:

sudo cp -a /opt/mattermost/config /root/mattermost-config-backup-$(date +%F)
pg_dump -h <db-host> -U <db-user> <db-name> > mattermost-$(date +%F).sql

Il rollback più semplice, se qualcosa va storto dopo una modifica di configurazione, è ripristinare il file salvato e riavviare il servizio. Se invece hai toccato database o schema, il rollback va testato prima in un ambiente separato: ripristino alla cieca in produzione è una scommessa, non una procedura.

Problemi tipici e come leggerli senza perdere tempo

Quando l’installazione sembra fatta ma l’app non parte, i casi ricorrenti sono pochi. Il primo è il database non raggiungibile o autenticazione errata. Il secondo è un URL canonico sbagliato che manda in crisi redirect e sessioni. Il terzo è il proxy configurato male, spesso con websocket non inoltrati correttamente.

La logica di diagnosi è sempre la stessa: prima il layer, poi l’errore. Se il servizio è attivo ma `curl -I http://127.0.0.1:8065` fallisce, il problema è sotto o dentro l’app. Se la risposta locale c’è ma il dominio pubblico no, guarda DNS, proxy e certificato. Se il dominio risponde ma il login non regge, sospetta `SiteURL` o header mancanti.

Per evitare tentativi casuali, tieni a portata questi controlli rapidi:

journalctl -u mattermost -n 100 --no-pager
journalctl -u nginx -n 100 --no-pager
curl -I https://chat.example.com

Se vedi errori ricorrenti di timeout verso il database, non alzare subito i timeout dell’app. Prima misura latenza, stato del motore SQL e saturazione risorse. Cambiare parametri senza capire perché il backend è lento serve solo a mascherare il problema.

Verifica finale dell’istanza e criteri di accettazione

Una volta completata l’installazione, l’istanza è da considerare pronta solo se superi una check-list minima: il servizio resta attivo dopo il reboot, l’URL pubblico risponde con TLS valido, il login funziona, i messaggi passano e i log non mostrano errori continui. Tutto il resto è contorno.

Puoi sintetizzare il controllo così:

systemctl is-active mattermost
systemctl is-active nginx
curl -kI https://chat.example.com

Se questi tre punti sono verdi, hai una base solida. A quel punto ha senso passare a backup automatici, monitoring, alerting e policy di upgrade. Prima no: prima serve un servizio che stia in piedi e che sia comprensibile da chi lo dovrà mantenere tra sei mesi.

Assunzione operativa: il server è dedicato o comunque ha risorse sufficienti per Mattermost, DNS e TLS sono già sotto controllo, e il database esterno è preferibile in produzione.