Come installare Rocket.Chat Server e client su Ubuntu 19.04

Perché Rocket.Chat su Ubuntu 19.04 richiede una base pulita

Rocket.Chat è un’applicazione web che mette insieme backend Node.js, database MongoDB e un front-end accessibile via browser. Su Ubuntu 19.04 la differenza la fa la preparazione: se il sistema è sporco, con repository misti o pacchetti non allineati, l’installazione diventa fragile già prima di avviare il servizio. Conviene quindi partire da una macchina aggiornata, con rete funzionante, nome host coerente e spazio disco sufficiente per database, log e allegati.

In questa guida il termine “client” va inteso nel senso pratico: l’accesso utente a Rocket.Chat avviene via browser, oppure tramite app desktop/mobile collegata allo stesso server. Lato amministrazione, quello che conta è installare correttamente il server, esporlo dietro HTTPS e verificare che il database risponda in modo stabile. Se salti questi passaggi, il problema non è l’interfaccia: è quasi sempre il layer applicativo o MongoDB.

Prerequisiti reali: non solo pacchetti, ma compatibilità

Ubuntu 19.04 è una release non LTS e, proprio per questo, è sensibile alla disponibilità dei repository nel tempo. Prima di iniziare verifica che la macchina sia raggiungibile e che i repository siano ancora validi nel tuo ambiente. Se stai lavorando su un sistema storico, la prima anomalia possibile non è Rocket.Chat ma APT che non riesce a risolvere i mirror.

Ti servono almeno questi componenti: un utente con privilegi sudo, accesso a Internet o a un mirror interno, un nome DNS già puntato verso il server e una porta HTTPS disponibile davanti al servizio. Se hai già un reverse proxy come Nginx o Apache, meglio usarlo subito. Esporre Rocket.Chat direttamente sulla porta pubblica non è la scelta più pulita per un’installazione che deve restare manutenibile.

Controllo minimo iniziale:

lsb_release -a
uname -r
hostname -f
ss -ltnp | grep -E ':(80|443|3000)\b'

Se `hostname -f` non restituisce un FQDN sensato, sistemalo prima: Rocket.Chat e il proxy reverse tendono a riflettere il nome host in redirect, link assoluti e configurazioni TLS. È un dettaglio che sembra secondario finché non ti ritrovi con URL incoerenti dopo il login.

Installazione di MongoDB: scegli una versione compatibile

Rocket.Chat dipende da MongoDB e la compatibilità tra versione applicativa e versione database va presa sul serio. Non improvvisare con il pacchetto disponibile “di default” se non hai verificato la matrice di supporto della release che vuoi installare. L’obiettivo qui è avere un database stabile, con replica set anche in singola istanza se richiesto dalla versione dell’applicazione.

Una procedura tipica prevede l’installazione del repository MongoDB ufficiale e l’avvio del demone. Esempio generico:

sudo apt update
sudo apt install -y gnupg curl
curl -fsSL https://pgp.mongodb.com/server-4.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-4.0.gpg --dearmor
echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-4.0.gpg ] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.0.list
sudo apt update
sudo apt install -y mongodb-org
sudo systemctl enable --now mongod

La riga del repository è un esempio da adattare alla versione effettivamente compatibile con il tuo Rocket.Chat. Se la tua release richiede una versione diversa di MongoDB, fermati e allinea prima quel punto. La falsificazione rapida è semplice: `mongod --version` e i log di avvio in `journalctl -u mongod -n 50 --no-pager` devono mostrare una versione avviata correttamente, senza errori di storage engine o incompatibilità di configurazione.

Se l’app richiede replica set anche in singolo nodo, abilitalo nel file di configurazione di MongoDB, poi riavvia il servizio. In molti casi basta un nome replica set minimale, ma va fatto prima del bootstrap dell’applicazione:

sudo nano /etc/mongod.conf

Aggiungi o verifica una sezione simile:

replication:
  replSetName: rs0

Poi riavvia e inizializza il set, se necessario:

sudo systemctl restart mongod
mongo --eval 'rs.initiate()'

Verifica con `rs.status()` che lo stato sia coerente. Se il comando fallisce, non andare avanti: Rocket.Chat può partire ma poi bloccarsi su operazioni di startup, migrazioni o indicizzazione. Qui il costo dell’errore è basso e il rollback è semplice: commenti la replica set, riavvii MongoDB e torni allo stato precedente.

Creazione dell’utente e del database per Rocket.Chat

Non usare l’account amministrativo di MongoDB per l’applicazione. Crea un database dedicato e un utente con privilegi limitati al solo database di Rocket.Chat. È una misura banale, ma riduce la superficie di danno se un giorno la credenziale finisce in un log, in una variabile d’ambiente esposta o in un backup non protetto.

mongo
use rocketchat
db.createUser({
  user: "rocketchat",
  pwd: "SOSTITUISCI_CON_PASSWORD_FORTE",
  roles: [ { role: "readWrite", db: "rocketchat" }, { role: "dbAdmin", db: "rocketchat" } ]
})

La password va trattata come segreto, non come esempio didattico da lasciare in chiaro. Se stai documentando un ambiente reale, redigila o usa un placeholder e conserva il valore nel tuo vault. Dopo la creazione dell’utente, testa l’accesso con autenticazione esplicita. Se il login fallisce, il problema è quasi sempre una combinazione di database sbagliato, credenziali errate o replica set non pronto.

mongo -u rocketchat -p --authenticationDatabase rocketchat

Installazione del server Rocket.Chat

Per installare il server conviene usare il pacchetto ufficiale o il metodo previsto dalla release che hai scelto, evitando repository casuali. L’obiettivo è ottenere un binario coerente con la versione di MongoDB e con la versione di Node inclusa o gestita dal pacchetto. Su distribuzioni non LTS, il rischio principale è la dipendenza che cambia sotto i piedi: oggi installa, domani il repo non c’è più o il pacchetto si trascina dietro una libreria incompatibile.

Una volta ottenuto il pacchetto, l’installazione tipica segue questo schema:

sudo apt install -y ./rocketchat-server_*.deb

Se il pacchetto non è locale ma arriva da repository, sostituisci il comando con quello previsto dal vendor. Dopo l’installazione, controlla che il servizio esista e sia abilitabile:

systemctl status rocketchat
sudo systemctl enable rocketchat

Se il servizio non compare, il problema non è ancora Rocket.Chat ma il packaging. In quel caso conviene leggere il log del gestore pacchetti e verificare se mancano dipendenze o se il sistema non soddisfa i prerequisiti della release. Il controllo rapido è `journalctl -xe` per gli errori di installazione e `dpkg -l | grep -i rocket` per capire cosa è stato realmente installato.

Configurazione del servizio e variabili d’ambiente

La configurazione pulita di Rocket.Chat passa da un file di ambiente o da un’unità systemd ben definita. L’idea è semplice: connessione al database, URL pubblico e porta locale devono essere determinati in modo esplicito. Se lasci tutto implicito, il servizio può partire ma generare URL sbagliati, problemi di callback OAuth o redirect verso localhost.

Un esempio di unità systemd o override potrebbe includere variabili come queste:

sudo systemctl edit rocketchat

Contenuto indicativo:

[Service]
Environment="ROOT_URL=https://chat.example.com"
Environment="MONGO_URL=mongodb://rocketchat:SOSTITUISCI_CON_PASSWORD_FORTE@127.0.0.1:27017/rocketchat?authSource=rocketchat"
Environment="PORT=3000"

Dopo il salvataggio, ricarica systemd e riavvia il servizio:

sudo systemctl daemon-reload
sudo systemctl restart rocketchat
sudo systemctl status rocketchat --no-pager

Il controllo da fare subito dopo non è il browser, ma il log del servizio. Cerca errori di connessione al database, variabili non lette o porte occupate. Con `journalctl -u rocketchat -n 100 --no-pager` devi vedere il bootstrap dell’app e, se tutto è corretto, il passaggio allo stato di ascolto sulla porta configurata.

Reverse proxy con Nginx: TLS, header e websocket

Rocket.Chat funziona bene dietro un reverse proxy, ed è la scelta consigliata anche per gestire certificati, compressione, HTTP/2 e sicurezza di base. Nginx è una soluzione lineare: termina TLS, inoltra il traffico verso il backend locale e mantiene pulito il servizio applicativo. Il punto delicato è il supporto ai websocket, indispensabili per notifiche, chat realtime e sessioni persistenti.

Configurazione di partenza, da adattare al tuo dominio e al certificato effettivo:

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;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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 https;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Se il proxy non inoltra `Upgrade` e `Connection`, l’interfaccia può caricarsi ma le funzionalità realtime diventano instabili o si interrompono dopo pochi secondi. La falsificazione è rapida: apri la console del browser, verifica gli errori websocket e confrontali con i log di Nginx in `/var/log/nginx/error.log`. Se vedi handshake falliti, il problema è quasi sempre lì.

Dopo aver scritto la configurazione, valida e ricarica:

sudo nginx -t
sudo systemctl reload nginx

Installazione del client: browser e app desktop

Il client di Rocket.Chat non richiede installazione sul server: gli utenti accedono via browser, mentre chi preferisce un’app dedicata può usare il client desktop. L’errore comune è trattare il client come un componente separato dell’infrastruttura. In realtà il punto di verità resta il server: se il backend non è corretto, il client mostra soltanto il sintomo.

Dal lato operativo, la verifica più utile è aprire `https://chat.example.com` e controllare tre cose: login, caricamento della lista canali, invio di un messaggio di test. Se una di queste tre azioni fallisce, hai già una traccia per restringere il problema a proxy, autenticazione o applicazione. Per il client desktop, scarica il pacchetto ufficiale per il sistema operativo dell’utente e configura il server URL iniziale con lo stesso dominio pubblico usato nel browser.

Se vuoi distribuire il client desktop in ambiente aziendale, prepara un test su una postazione pulita. Le variabili che fanno saltare l’esperienza sono spesso banali: proxy aziendale, certificati intermedi mancanti, filtro TLS, blocco dei websocket o policy di Content Security che impediscono il caricamento di risorse esterne. In questi casi il server è sano, ma il client non riesce a stabilire una sessione completa.

Primo avvio: cosa deve comparire nei log

Il primo avvio è il momento in cui si separano le installazioni sane da quelle “apparente successo”. Cerca nei log del servizio segnali chiari: connessione a MongoDB riuscita, migrazioni completate, porta in ascolto, URL pubblico riconosciuto. Se il servizio resta in crash loop, non insistere con restart ripetuti: prima identifica il messaggio di errore dominante.

journalctl -u rocketchat -f
ss -ltnp | grep 3000
curl -I http://127.0.0.1:3000

Il comando `curl -I` deve restituire una risposta HTTP coerente, tipicamente `200`, `302` o `301` a seconda della configurazione iniziale. Se ottieni `connection refused`, il processo non è in ascolto. Se ottieni `502` dal proxy, il backend non risponde. Se la pagina resta bianca ma lo status è `200`, allora è più probabile un problema di asset, websocket o incompatibilità del browser con il certificato/proxy.

Hardening minimo: sicurezza senza complicare l’avvio

Una volta che Rocket.Chat funziona, applica un hardening minimo ma concreto. Mantieni MongoDB in ascolto solo su localhost se il database non deve essere raggiungibile da altri host. Limita l’accesso alla porta 3000 al solo reverse proxy o alla rete di management. Usa un certificato valido, possibilmente rinnovato in automatico con un timer o con il meccanismo che già usi per gli altri virtual host.

Controlla anche permessi e proprietà dei file di configurazione: l’unità systemd deve leggere solo ciò che le serve, mentre le credenziali devono stare fuori da documenti condivisi o script dimenticati in `/tmp`. Se devi fare auditing, parti da questi punti: `systemctl cat rocketchat`, `ss -ltnp`, `sudo ufw status verbose` se usi UFW, e `grep -R "MONGO_URL\|ROOT_URL"` solo sui file di configurazione controllati.

Manutenzione: aggiornamenti, backup e ripristino

Rocket.Chat non va trattato come un’app statica. Va aggiornato con attenzione, perché il binomio applicazione-database può introdurre migrazioni. Prima di aggiornare, fai un backup del database e conserva la configurazione del servizio. Se qualcosa va storto, il rollback deve essere semplice: ripristino del database, reinstallazione del pacchetto precedente e riavvio del servizio con la stessa configurazione.

Per il backup di MongoDB, una procedura standard è questa:

mongodump --uri="mongodb://rocketchat:SOSTITUISCI_CON_PASSWORD_FORTE@127.0.0.1:27017/rocketchat?authSource=rocketchat" --out /backup/rocketchat-$(date +%F)

Se il dump fallisce, controlla spazio su disco, permessi e autenticazione. Un backup che non si completa non è un backup. Dopo l’aggiornamento, verifica il numero di versioni dell’app, i log di startup e la capacità di login di un utente normale. È il controllo più semplice e spesso il più rivelatore.

Problemi tipici e lettura rapida dei sintomi

Se il sito non risponde, la prima domanda è sempre la stessa: il problema è DNS, proxy, applicazione o database? `curl -I https://chat.example.com` ti dice subito se il layer HTTP è vivo. Se la risposta arriva ma è un `502`, il backend non è raggiungibile. Se il backend è su ma l’interfaccia non si carica, guarda websocket, certificato e console del browser. Se il login si blocca, verifica MongoDB e i log dell’applicazione.

Una buona abitudine è tenere tre riferimenti pronti: il log di Rocket.Chat, il log del proxy e lo stato di MongoDB. In pratica: `journalctl -u rocketchat`, `journalctl -u mongod` e il file di errore di Nginx. Con questi tre punti spesso chiudi il 90% dei casi senza toccare nulla. Il resto sono dettagli di compatibilità o configurazioni ereditate da ambienti precedenti.

Verifica finale dell’installazione

Un’installazione corretta si considera tale solo quando il servizio è raggiungibile via HTTPS, il login funziona, i messaggi si inviano e i log non mostrano errori ripetuti. La sequenza minima di controllo è semplice e va eseguita sempre nello stesso ordine: stato del servizio, risposta HTTP locale, risposta dal dominio pubblico, test browser, test websocket, verifica log.

systemctl is-active rocketchat
curl -I http://127.0.0.1:3000
curl -I https://chat.example.com
journalctl -u rocketchat -n 50 --no-pager

Se tutti i controlli sono positivi, hai un’installazione pronta per l’uso quotidiano. Se uno dei passaggi fallisce, correggi il layer corrispondente e ripeti la verifica senza cambiare altro. È il modo più veloce per evitare correzioni casuali che spostano il problema da un punto all’altro senza risolverlo.

Assunzione operativa: i comandi e gli esempi qui riportati vanno adattati alla versione effettiva di Rocket.Chat e alla politica di sicurezza del tuo ambiente, con particolare attenzione alla compatibilità tra release dell’applicazione e MongoDB.