1 21/05/2026 10 min

RabbitMQ su Ubuntu 20.04: scegliere il pacchetto giusto prima di installare

Su Ubuntu 20.04 LTS RabbitMQ si installa senza particolari complicazioni, ma il punto critico non è il comando di installazione: è evitare di partire con una combinazione di versioni fragile o con un servizio che “sembra su” ma non è pronto a ricevere connessioni. In pratica conviene usare il repository ufficiale del vendor, verificare la versione di Erlang supportata e controllare subito lo stato del nodo, invece di affidarsi al solo fatto che il pacchetto sia stato installato correttamente.

La regola utile è semplice: prima si prepara il sistema, poi si installano le dipendenze, infine si valida che RabbitMQ ascolti davvero sulla porta giusta e che l’interfaccia di management, se abilitata, risponda. Questo approccio riduce i casi in cui il servizio parte ma resta inutilizzabile per mismatch di Erlang, firewall locale, hostname non risolvibile o permessi del plugin management.

Prerequisiti pratici e controlli iniziali

Prima di installare, conviene verificare tre cose: aggiornamento del sistema, risoluzione del nome host e spazio disco disponibile. RabbitMQ usa file e code persistenti; se il filesystem è stretto o già saturo, l’installazione può andare a buon fine ma il broker diventare instabile poco dopo.

Esegui questi controlli di base:

sudo apt update
hostnamectl
ip a
free -h
df -h

Se il server è accessibile solo via IP e non hai un nome host coerente, non è un blocco assoluto, ma vale la pena sistemarlo subito. RabbitMQ si appoggia al nodo Erlang e un hostname incoerente può trasformarsi in problemi di avvio, clustering o identità del nodo. Per un host singolo è sufficiente che il nome sia stabile e risolvibile localmente.

Repository ufficiale: perché preferirlo al pacchetto base di Ubuntu

Ubuntu 20.04 include pacchetti nei repository standard, ma per RabbitMQ la scelta più lineare è il repository ufficiale. Il motivo non è solo avere una versione più recente: è allineare RabbitMQ ed Erlang in una coppia supportata. Molti problemi “strani” nascono proprio da una versione di Erlang troppo vecchia o troppo nuova rispetto al broker.

Il flusso corretto è: importare la chiave del repository, aggiungere la sorgente APT, aggiornare l’indice dei pacchetti e installare RabbitMQ insieme a Erlang compatibile. I nomi esatti dei pacchetti possono cambiare nel tempo, quindi se un pacchetto non esiste conviene verificare il catalogo prima di forzare una versione a caso.

sudo apt install -y curl gnupg apt-transport-https
curl -fsSL https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/rabbitmq.gpg
printf 'deb [signed-by=/usr/share/keyrings/rabbitmq.gpg] https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/deb/ubuntu focal main\n' | sudo tee /etc/apt/sources.list.d/rabbitmq.list
sudo apt update

Se il download della chiave o l’update falliscono, il primo sospetto non è RabbitMQ ma la connettività in uscita, la policy proxy o il TLS inspection della rete. In quel caso verifica l’errore preciso di APT prima di proseguire.

Installazione del broker e del runtime Erlang

Con il repository pronto, installa il broker. In molte situazioni il metapacchetto si porta dietro il runtime necessario, ma è buona pratica controllare che la versione di Erlang sia coerente con la documentazione del rilascio RabbitMQ che stai usando.

sudo apt install -y rabbitmq-server

Subito dopo l’installazione, verifica che il servizio sia attivo e abilitato all’avvio automatico. Qui non basta il semplice “install ok”: serve vedere il processo in stato running, con zero restart anomali.

systemctl status rabbitmq-server --no-pager
systemctl is-enabled rabbitmq-server

Il risultato atteso è un servizio attivo e abilitato. Se invece vedi failed, il comando successivo è leggere il journal e non tentare subito reinstallazioni casuali.

journalctl -u rabbitmq-server -b --no-pager

Un errore tipico è l’incompatibilità tra versioni o un problema di hostname. Un altro caso frequente è il nodo che non riesce a scrivere nella directory dati. In entrambi i casi il journal dice quasi sempre più della guida generica.

Abilitare l’interfaccia web di management senza esporla inutilmente

Per amministrare RabbitMQ in modo comodo, il plugin rabbitmq_management è quasi sempre la scelta giusta. Però va trattato come una superficie d’attacco in più, non come una semplice comodità. Su un server esposto a Internet non ha senso lasciare la console aperta su tutte le interfacce se non serve davvero.

sudo rabbitmq-plugins enable rabbitmq_management
sudo systemctl restart rabbitmq-server

Dopo il restart, la console web dovrebbe rispondere sulla porta 15672. Verifica localmente prima di aprire firewall o security group.

curl -I http://127.0.0.1:15672/

Se la risposta è un HTTP/1.1 200 o un redirect coerente, il plugin è attivo. Se ricevi connection refused, il problema è il servizio o il bind. Se ricevi timeout, controlla se un firewall locale sta filtrando la porta o se il demone non ha completato l’avvio.

Per ridurre il rischio, il primo accesso va fatto in locale o tramite tunnel SSH. Solo dopo una verifica minima ha senso esporre la porta verso reti amministrative ben definite.

ssh -L 15672:127.0.0.1:15672 user@server

Creare un utente amministrativo e togliere il default

La fase che molti saltano è anche quella che crea più problemi di sicurezza: lasciare il nodo con credenziali di default o con utenti troppo permissivi. Il pacchetto spesso crea un utente iniziale legato all’uso locale, ma per un’installazione reale conviene definire un utente esplicito, assegnargli i permessi corretti e poi eliminare l’uso del default quando non serve più.

Usa un nome account descrittivo, non riutilizzare password già in circolazione e non metterle in chiaro in file condivisi. Se devi automatizzare, passa da variabili d’ambiente protette o da un secret manager. Qui il punto non è essere paranoici: è evitare che un broker di messaggistica diventi un punto di ingresso banale.

sudo rabbitmqctl add_user admin 'PASSWORD_FORTE'
sudo rabbitmqctl set_user_tags admin administrator
sudo rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"

Dopo aver creato l’utente, accedi alla console e verifica che compaiano vhost, code e statistiche. Se il login fallisce, il primo controllo è la sintassi della password e poi i tag utente. Se l’utente entra ma non vede nulla, il problema è spesso nei permessi sul vhost.

Verifica del listener AMQP e della porta di management

A installazione completata, il controllo più utile non è “il pacchetto c’è”, ma “il broker ascolta davvero”. RabbitMQ normalmente espone AMQP su 5672 e la console web su 15672 se il plugin è attivo. Una verifica rapida evita di scoprire il problema solo quando un’applicazione non riesce a connettersi.

sudo ss -lntp | grep -E '(:5672|:15672)' sudo rabbitmqctl status

Nel comando rabbitmqctl status cerca il nome del nodo, la versione del broker, i listener e lo stato del plugin. Se il nodo è attivo ma la porta manca, il problema può essere di configurazione del listener, non del servizio in sé.

Un buon test di base consiste anche nel verificare l’accesso remoto da un host autorizzato, senza toccare ancora l’applicazione finale. Se la porta 5672 non risponde, controlla firewall locale, security group e bind address.

Hardening minimo che vale la pena fare subito

RabbitMQ non va lasciato “aperto” per abitudine. Anche su un server interno conviene applicare un hardening minimo: limitare l’esposizione, definire permessi per vhost, usare TLS se il traffico attraversa reti non fidate e controllare gli utenti presenti sul broker. Non serve trasformare la guida in un trattato di sicurezza, ma ignorare questi punti è un errore costoso.

Se il broker deve parlare con applicazioni distribuite su più host, valuta TLS sulla porta AMQP. La configurazione precisa dipende dalla versione e dal layout dei certificati, ma il principio operativo è sempre lo stesso: certificati leggibili solo dal servizio, chain valida e test del client prima del cutover. Se i certificati non sono pronti, meglio rimandare l’esposizione esterna piuttosto che improvvisare una configurazione fragile.

Un controllo utile è elencare gli utenti e i vhost presenti, così da capire subito se l’installazione è ancora in stato laboratorio o già pronta per ambienti condivisi.

sudo rabbitmqctl list_users
sudo rabbitmqctl list_vhosts
sudo rabbitmqctl list_permissions -p /

Se trovi utenti sconosciuti o permessi troppo larghi, correggi subito. In un broker il problema non è solo il furto di messaggi: è anche la possibilità di creare code, saturare risorse o intercettare flussi applicativi.

Configurazione base del file rabbitmq.conf

Quando l’installazione è stabile, il passo successivo è spostare le impostazioni dal comportamento predefinito alla configurazione esplicita. Su Ubuntu il file principale è in genere /etc/rabbitmq/rabbitmq.conf. Tenerlo pulito aiuta sia la manutenzione sia il troubleshooting. Evita file pieni di opzioni sparse senza commenti: dopo qualche mese nessuno ricorda più perché una certa coda era stata limitata in quel modo.

Un esempio minimale e ragionevole può essere questo, da adattare al tuo scenario:

listeners.tcp.default = 5672
management.tcp.port = 15672
loopback_users.guest = true
vm_memory_high_watermark.relative = 0.6
disk_free_limit.relative = 1.0

Le ultime due impostazioni servono a proteggere il nodo da pressioni eccessive di memoria e disco. I valori esatti vanno tarati sul server reale, ma il principio è quello: il broker deve fermarsi o rallentare in modo controllato prima di portare giù il sistema operativo o riempire il filesystem.

Dopo ogni modifica al file di configurazione, fai sempre un backup o conserva il diff. Se qualcosa va storto, il rollback deve essere immediato e verificabile.

sudo cp /etc/rabbitmq/rabbitmq.conf /etc/rabbitmq/rabbitmq.conf.bak.$(date +%F-%H%M)

Diagnosi rapida quando il servizio non parte

Se dopo l’installazione RabbitMQ non sale, il problema quasi mai si risolve con un riavvio ripetuto. Serve invece isolare il layer: systemd, runtime Erlang, hostname, permessi o storage. La diagnostica più utile è leggere il journal e controllare i file di log del broker, poi verificare la presenza di errori di boot o di crash loop.

journalctl -u rabbitmq-server -xe --no-pager
sudo tail -n 100 /var/log/rabbitmq/rabbit@$(hostname -s).log

Se vedi errori di permission denied, controlla ownership e permessi della directory dati. Se il nodo non trova il nome host, verifica /etc/hosts e la risoluzione locale. Se il log indica memoria o disco insufficienti, il problema non è RabbitMQ ma la capacità del server.

Un controllo utile sul filesystem è questo:

sudo du -sh /var/lib/rabbitmq
sudo ls -ld /var/lib/rabbitmq /var/log/rabbitmq

Se la directory dati è già piena o con permessi incoerenti, correggi la causa prima di riprovare l’avvio. Altrimenti il servizio tornerà a fallire nello stesso punto.

Verifica finale dell’installazione con un test realistico

Una volta che il servizio è attivo, non fermarti alla schermata verde. Il test finale deve coprire almeno tre aspetti: servizio in esecuzione, porta aperta e console accessibile. Se puoi, aggiungi anche un test client da un host applicativo, così controlli che la catena di rete sia veramente pronta per l’uso.

systemctl is-active rabbitmq-server
sudo ss -lntp | grep 5672
curl -I http://127.0.0.1:15672/

Se tutti e tre i controlli sono coerenti, l’installazione è solida. A quel punto puoi passare alla definizione di vhost, code, binding e integrazione con le applicazioni. Se invece uno dei tre fallisce, non andare oltre: la parte “applicativa” su un broker instabile ti complica solo il debug.

Per un ambiente di produzione, il passo successivo consigliato è documentare: versione RabbitMQ, versione Erlang, utenti creati, vhost, porte esposte e percorsi di log. Questa informazione, se raccolta subito, vale più di molte ore di ricostruzione a posteriori.

Assunzione operativa: la procedura sopra parte da un host Ubuntu 20.04 LTS aggiornato, con accesso sudo e senza vincoli particolari di proxy o repository aziendali; se esistono, vanno verificati prima del repository ufficiale.