Come installare Mattermost Omnibus su Ubuntu 20.04 LTS

Su Ubuntu 20.04 LTS, Mattermost Omnibus è una scelta sensata quando vuoi un’installazione abbastanza ordinata da gestire, ma senza costruire a mano ogni pezzo dello stack. Il pacchetto porta con sé servizio applicativo, dipendenze e una struttura coerente per aggiornamenti e backup. Il punto non è “farlo partire”: il punto è farlo partire bene, con rete, database, TLS e storage impostati in modo prevedibile.

Prima di iniziare conviene chiarire l’obiettivo operativo: una singola VM o un singolo server dedicato, con accesso HTTPS dall’esterno e storage locale affidabile. Se ti serve scalabilità orizzontale, alta disponibilità o integrazione con un database gestito, l’approccio cambia e l’Omnibus va valutato con attenzione. Qui restiamo su un’installazione classica, adatta a un deployment singolo, con controlli concreti dopo ogni passaggio.

Prerogative reali: cosa deve esserci prima del pacchetto

Non partire dall’installazione se non hai già deciso quattro cose: nome host pubblico, porta esposta, backend database e modalità TLS. Mattermost si appoggia bene a un FQDN stabile, ad esempio chat.example.it, e soffre quando si improvvisa con IP temporanei o DNS non allineati. Se il sito o il servizio devono stare dietro un reverse proxy, definiscilo prima; se invece vuoi che Omnibus gestisca anche il TLS, verifica subito che la porta 443 sia libera.

Controlla anche le risorse minime. Per un’istanza piccola, 2 vCPU e 4 GB di RAM sono un pavimento realistico; sotto, inizi a vedere latenza nelle code, soprattutto se il database è sullo stesso host o il server ospita altro. Il disco deve essere persistente e con margine: log, allegati e database crescono più in fretta di quanto sembri nei primi giorni.

Se hai già un database PostgreSQL esterno, bene: spesso è la scelta più pulita. Se no, l’Omnibus può gestire una configurazione locale, ma il confine tra applicazione e persistenza va tenuto sotto controllo con backup e restore verificati. Non dare per scontato che “installato” significhi “recuperabile”.

Verifica iniziale dell’host Ubuntu 20.04

Prima di installare, fai un controllo base dello stato del sistema. Non è formalità: ti evita di diagnosticare come “problema Mattermost” un problema di sistema già presente.

1. Aggiorna l’indice pacchetti e verifica spazio e memoria.

sudo apt update
df -h
free -h
hostnamectl

Il risultato atteso è semplice: filesystem con spazio residuo sufficiente, RAM non saturata e hostname coerente con il FQDN che userai. Se il disco è già al limite, fermati e libera spazio prima di aggiungere un servizio persistente.

2. Verifica che le porte necessarie non siano già occupate.

sudo ss -lntp | egrep ':(80|443|8065)\s'

Di default Mattermost usa la porta 8065 dietro il suo reverse proxy interno o direttamente sul servizio, a seconda della configurazione. Se 80 o 443 sono già occupate da Apache, Nginx o altro proxy, devi decidere chi termina TLS e chi ascolta in locale.

Installazione del pacchetto Mattermost Omnibus

Il modo corretto di procedere è aggiungere il repository ufficiale e installare il pacchetto corrispondente alla release scelta. Non mischiare sorgenti non allineate senza motivo: in caso di problemi, rendi più difficile capire se il difetto arriva dal pacchetto, dal repository o dalla configurazione locale.

In generale la sequenza è questa: import della chiave, aggiunta del repository, installazione del pacchetto. I dettagli del repository possono cambiare nel tempo, quindi va sempre verificata la documentazione del vendor per la release corrente. Se un passaggio non coincide con la tua versione, il gap non è un errore: va chiuso con il repo URL corretto e con il nome esatto del pacchetto disponibile per Ubuntu 20.04.

# Esempio di flusso: adattare URL e nome pacchetto alla release disponibile
curl -fsSL https://deb.packages.mattermost.com/repo-setup.sh | sudo bash
sudo apt update
sudo apt install mattermost

Dopo l’installazione, il controllo minimo è che il servizio esista e sia abilitato. Non assumere che l’installazione abbia avviato tutto correttamente: prima verifica lo stato, poi la configurazione.

systemctl status mattermost --no-pager
systemctl is-enabled mattermost

Se lo stato è active (running), bene; se è failed, il problema va letto nei log prima di toccare altro.

Configurazione minima: database, URL pubblico e storage

La configurazione vive tipicamente nel file di servizio o in un file YAML dedicato, a seconda della versione Omnibus. Il principio non cambia: imposti URL pubblica, backend dati e parametri di sicurezza. Prima di modificare, fai sempre una copia del file o, meglio, lavora con uno snippet versionato. Se il pacchetto rigenera i file, annota dove mettere le override persistenti.

Un errore classico è lasciare l’URL esterna incoerente con il certificato o con il proxy. In quel caso gli utenti vedono redirect loop, cookie non persistenti o errori di autenticazione. L’URL pubblica deve combaciare con il dominio realmente usato dal browser.

Se usi PostgreSQL esterno, prepara un database dedicato e un utente con privilegi minimi. Evita di usare account amministrativi del DB per l’applicazione. La regola è vecchia ma resta valida: un’applicazione non deve avere più permessi del necessario.

# Esempio PostgreSQL esterno: crea database e utente dedicati
sudo -u postgres psql
CREATE DATABASE mattermost;
CREATE USER mmuser WITH PASSWORD 'sostituisci_con_password_forte';
GRANT ALL PRIVILEGES ON DATABASE mattermost TO mmuser;
\q

Qui c’è un punto importante: la password non va lasciata in chiaro in documenti operativi condivisi. Se devi passare credenziali nella configurazione, usa un file con permessi stretti o un secret manager. Se hai già scritto un valore in chiaro, ruotalo subito dopo il deploy e redigi il materiale condiviso.

Per lo storage, verifica dove finiscono file allegati, log e dati applicativi. Se il volume è separato, meglio: riduce il rischio che il sistema si blocchi per saturazione del filesystem di root. In caso contrario, monitora con attenzione df -h e la crescita dei log.

TLS e reverse proxy: scegliere chi termina HTTPS

La scelta architetturale è questa: o lasci a Omnibus la terminazione HTTPS, oppure metti davanti un reverse proxy come Nginx o Apache. Evita il doppio TLS senza motivo. Se hai già un’infrastruttura con proxy centralizzato, di solito conviene usare quello e lasciare l’app in locale, con un upstream chiaro e semplice.

Se il certificato è gestito localmente, assicurati che il CN/SAN includa il dominio pubblico e che il rinnovo automatico sia in piedi. Se invece il TLS è fuori da Omnibus, controlla che il proxy inoltri correttamente header come X-Forwarded-Proto e X-Forwarded-For. Senza questi dettagli, Mattermost può generare URL sbagliati o comportamenti incoerenti su login e webhook.

# Verifica rapida del certificato dal client
openssl s_client -connect chat.example.it:443 -servername chat.example.it 

L’output atteso è un certificato valido e la catena corretta. Se il certificato non corrisponde al dominio, il problema non è “Mattermost lento”: è un problema di pubblicazione TLS o di DNS.

Avvio del servizio e lettura dei log

Dopo la configurazione, riavvia il servizio in modo controllato e leggi i log subito. Non aspettare che siano gli utenti a segnalare il primo errore. L’obiettivo è vedere il servizio salire, inizializzare il database e pubblicarsi sulla porta prevista.

sudo systemctl restart mattermost
sudo journalctl -u mattermost -n 100 --no-pager

Se il servizio non parte, cerca tre classi di errore: connessione al database, file di configurazione non valido, permessi su directory o file. In molti casi il log indica già il punto esatto. Non fare tentativi casuali: prendi la prima riga di errore utile e risali da lì.

Un controllo semplice ma spesso trascurato è la porta in ascolto.

sudo ss -lntp | grep 8065
curl -I http://127.0.0.1:8065

Se la porta risponde in locale ma il dominio pubblico no, il problema si sposta quasi sempre su firewall, security group, proxy o DNS. Se non risponde nemmeno in locale, il guasto è dentro il servizio o nelle sue dipendenze.

Primo accesso e controlli applicativi

Al primo accesso verifica che la login page sia raggiungibile, che l’URL sia quello atteso e che le sessioni persistano dopo refresh. Se il browser mostra errori di mixed content o redirect continui, di solito il problema è nell’allineamento tra URL pubblica e terminazione TLS.

Controlla anche la creazione di un utente amministratore, i permessi dei canali e l’invio delle email. Mattermost senza mail funzionante è “quasi completo”, ma in pratica ti complica reset password, inviti e notifiche. Se il server SMTP non è pronto, segnalo il gap e chiudilo prima di andare in produzione: host, porta, autenticazione, mittente valido e test di consegna reale.

# Verifica HTTP dal client e dal server
curl -I https://chat.example.it
curl -I http://127.0.0.1:8065

Il comportamento atteso è coerente: dal client vedi 200 o 3xx verso HTTPS, dal server locale vedi il servizio vivo. Se il client riceve 502 o 503, il problema è spesso il proxy. Se riceve timeout, guarda prima firewall e routing.

Backup e ripristino: la parte che non va improvvisata

Una installazione seria non è completa finché non hai un backup ripristinabile. Per Mattermost devi considerare almeno database, file allegati e configurazione. Se il database è PostgreSQL, il dump va schedulato e testato. Se gli allegati stanno su filesystem, il backup deve essere coerente con il dump o coordinato con una finestra di quiete applicativa.

La verifica minima non è “il backup è partito”, ma “il backup si ripristina in un ambiente di test”. Anche un restore parziale ti dice subito se mancano path, permessi o dipendenze.

# Esempio di dump PostgreSQL
pg_dump -U mmuser -h 127.0.0.1 mattermost | gzip > mattermost-$(date +%F).sql.gz

Se devi automatizzare, usa un account con privilegi minimi e conserva i dump cifrati a riposo. Non lasciare credenziali in chiaro nello script: usa file root-only, variabili d’ambiente gestite bene o un secret store. Se una credenziale è già finita in un file distribuito, la misura corretta è la rotazione, non la speranza.

Hardening minimo che vale davvero

Per un servizio esposto su Internet, il minimo sindacale è ridurre la superficie d’attacco. Tieni aggiornato Ubuntu 20.04 con patch di sicurezza, limita l’accesso SSH con chiavi, chiudi porte non necessarie e controlla che il servizio ascolti solo dove serve. Se Mattermost è dietro reverse proxy, il backend non deve essere esposto pubblicamente senza motivo.

Controlla i permessi delle directory dati e dei file di configurazione. Un servizio applicativo deve leggere ciò che serve, non scrivere ovunque. Un audit veloce con ls -l e find sulle directory del pacchetto spesso evita errori banali ma costosi.

sudo ufw status verbose
sudo find /opt -maxdepth 2 -type d -iname '*mattermost*' -ls

Se usi UFW, permetti solo le porte necessarie. Tipicamente: 22 per SSH, 80/443 per il proxy pubblico, e niente accesso diretto alla porta applicativa dall’esterno se non è un requisito esplicito.

Quando qualcosa va storto: segnali rapidi da leggere

Se vedi pagina bianca, 502, 503 o timeout, non partire dal browser: identifica il layer. DNS, edge, proxy, origin, app, database e storage hanno sintomi diversi. Un curl -I dal server e uno dal client esterno danno subito il primo taglio diagnostico. Se il servizio locale risponde ma il dominio pubblico no, il problema non è l’applicazione in sé.

Se il log mostra errori di connessione al database, verifica prima reachability e credenziali, poi il pool e infine la compatibilità della versione. Se il disco è pieno, il servizio può apparire avviato ma fallire su scrittura log o upload. Se la RAM è al limite, puoi vedere restart o degradazione pesante senza un crash netto.

La regola utile è questa: prima osserva, poi tocca. Ogni modifica senza evidenza ti fa perdere tempo e rende più difficile il rollback.

Chiusura operativa: cosa considerare installato davvero

Puoi considerare completata l’installazione solo quando hai quattro riscontri: servizio attivo, URL pubblica corretta, login funzionante e backup pianificato. Se uno di questi manca, hai un sistema avviato ma non ancora affidabile.

In pratica, Mattermost Omnibus su Ubuntu 20.04 LTS funziona bene quando lo tratti come servizio di produzione e non come esperimento monolitico. La semplicità dell’Omnibus è utile proprio se la accompagni con verifiche elementari ma costanti: stato servizio, log, porta in ascolto, TLS, database, storage e restore testato. Il resto è rumore.