Gestire Mattermost su un server proprio significa occuparsi di messaggi, allegati, autenticazione e chiamate, oltre che degli aggiornamenti. La pagina di login raggiungibile è soltanto la prima verifica: il servizio deve funzionare dalle reti degli utenti e poter essere ripristinato.
Nel setup Romiltec documentato a maggio 2026, Mattermost gira in un container LXC su Proxmox, su un dedicato Hetzner. Il reverse proxy Caddy è separato dall’applicazione e lo storage del nodo usa un mirror ZFS. È un caso utile per distinguere le responsabilità dei componenti, senza trasformare l’intero server nel dimensionamento minimo di una chat.
Separare applicazione e ingresso web
Un proxy separato permette di gestire certificati e instradamento in un punto riconoscibile. Mattermost mantiene una propria configurazione, il database PostgreSQL e i percorsi degli allegati. Nella manutenzione devono essere chiari proprietario e versione di ciascun componente.
La separazione in container non elimina il nodo comune: un guasto dell’host può coinvolgere sia proxy sia chat. Per decidere quanta disponibilità serve, partirei da quanto a lungo il team può lavorare senza il servizio e da quale canale alternativo usare durante l’intervento.
Gli script della comunità possono accelerare l’installazione, ma vanno letti e ricondotti a una procedura mantenibile. Nel runbook devono restare i passaggi per aggiornare, tornare alla versione precedente quando possibile e ricostruire il guest senza dipendere dalla memoria di chi lo ha creato.
Le chiamate hanno un percorso diverso dal sito
La documentazione di Mattermost Calls distingue segnalazione e traffico multimediale. Il fatto che HTTPS funzioni non prova che audio e condivisione schermo raggiungano il servizio RTC.
Verificherei indirizzo annunciato ai client, porte esposte e attraversamento di firewall e NAT. Un server TURN può servire quando la rete impedisce la connessione diretta; non va considerato obbligatorio in ogni installazione né una correzione universale per una configurazione errata.
La prova utile coinvolge almeno due client su reti differenti, inclusa una rete con restrizioni se fa parte del contesto d’uso. Controllerei ingresso, riconnessione e durata della chiamata. Un test tra due dispositivi sulla stessa LAN lascia fuori proprio molti problemi di raggiungibilità.
Cloudflare e CrowdSec: quale indirizzo stai bloccando?
Dietro un proxy CDN, la connessione al server arriva dall’infrastruttura del proxy. Il vero indirizzo del visitatore deve essere ricostruito da header accettati soltanto da proxy fidati. Fidarsi dello stesso header ricevuto da chiunque permette di falsificarlo.
CrowdSec richiede log interpretabili e un componente che applichi le decisioni. Se il traffico passa da Cloudflare, un blocco nel firewall dell’origine sull’IP del visitatore può non intercettarlo. Il componente di remediation per Cloudflare agisce al livello della CDN: è una scelta da valutare rispetto al percorso effettivo delle richieste.
Anche il rinnovo TLS va provato nel percorso reale. Le challenge ACME hanno requisiti diversi; la terminazione TLS sulla CDN non equivale a inoltrare una challenge TLS-ALPN al proxy di origine. Con DNS-01 entrano invece in gioco permessi e disponibilità delle API DNS.
Il mirror mantiene una copia dei blocchi, non la storia del servizio
Il mirror ZFS aiuta a gestire il guasto di un disco. Non conserva automaticamente una versione precedente dopo una cancellazione applicativa, e non offre una copia indipendente dall’host.
Per il recupero di Mattermost servono dati e configurazione coerenti. La procedura ufficiale di backup considera database, configurazione e file e indica l’arresto del servizio per un backup pulito. Se si sceglie una strategia diversa, bisogna dimostrarne la coerenza.
Controllerei separatamente i plugin: un’esportazione pensata per migrare i messaggi non garantisce di includere tutti i loro dati. È un punto emerso anche nei materiali di una migrazione interna tra due installazioni.
La prova che chiude il lavoro
Ripristinerei una copia isolata, con email e integrazioni esterne disabilitate, e proverei accesso, ricerca, allegati e dati dei plugin necessari. Registrerei tempo impiegato e passaggi mancanti: il tempo di recupero si misura con un recupero, non con la durata del backup.
Per approfondire la scelta del contenitore, ho raccolto i criteri su VM, LXC e Docker. Il principio vale anche qui: ogni strato deve avere uno scopo e una procedura di manutenzione comprensibile a chi interverrà dopo di me.