Postal è una piattaforma open source per l’invio e la ricezione di email, pensata per siti web, applicazioni e servizi che devono spedire grandi quantità di messaggi in modo affidabile.

Si può considerare un’alternativa self-hosted a servizi commerciali come SendGrid, Mailgun o Amazon SES: offre le stesse funzionalità principali, ma lascia il pieno controllo dell’infrastruttura, dei dati e dei costi.

Sviluppato dal provider britannico Krystal e distribuito con licenza MIT, Postal mette a disposizione un’interfaccia web completa per gestire organizzazioni, server di posta e domini.

Gli invii avvengono via SMTP o tramite API HTTP, con firma DKIM automatica dei messaggi. Postal offre anche il tracciamento di aperture e clic, i webhook per notificare alle applicazioni consegne e rimbalzi, la gestione dei pool di IP e un sistema di instradamento per la posta in arrivo.

Un punto va chiarito subito: Postal non è un server di caselle di posta.

Non offre IMAP o POP3 e non sostituisce soluzioni come Dovecot, Exchange o Microsoft 365.

È un Mail Transfer Agent orientato all’invio transazionale e massivo: email di registrazione, reset password, notifiche, newsletter e comunicazioni generate da applicazioni.

Dalla versione 3 l’architettura si è semplificata: Postal gira interamente in container Docker e non richiede più RabbitMQ, ma solo un database MariaDB.

Un server dedicato basta quindi per avere in poco tempo una piattaforma di invio professionale.

In questa guida vedremo passo dopo passo come installare e configurare Postal su Ubuntu Server 26.04 LTS con Docker Engine.

Partiremo dalla configurazione dei record DNS e arriveremo al primo accesso all’interfaccia web, con HTTPS gestito automaticamente da Caddy.

PREREQUISITI

Un server Ubuntu Server 26.04 LTS con un utente sudo e accesso SSH, dedicato (Postal non convive bene con altri servizi che occupano le stesse porte o risorse).

RAM: almeno 4 GB. CPU: almeno 2 core. Disco: almeno 25 GB (di più se prevedi volumi alti di invio, per via dei log dei messaggi).

Un dominio dedicato all’infrastruttura di invio (es. postal.tuodominio.it), con accesso al pannello DNS.

La porta 25 in uscita non bloccata dal provider: è la condizione più comune di fallimento — verificala prima di iniziare.

NOTA BENE: Postal gira interamente in container Docker: qualunque sistema operativo compatibile con Docker va bene, questa guida usa Ubuntu 26.04 come richiesto.

CONFIGURAZIONE DEL DNS

Configura nel pannello DNS del dominio scelto per Postal:

Record A (e AAAA se hai IPv6):

postal.tuodominio.it. IN A a.b.c.d
postal.tuodominio.it. IN AAAA ipv6::address

Record MX:

postal.tuodominio.it. IN MX 10 postal.tuodominio.it.

PTR (reverse DNS) richiesto lato provider, l’IP deve risolvere all’indietro nell’hostname:

nslookup a.b.c.d → deve restituire postal.tuodominio.it

I record SPF, return-path e DKIM li completerai allo step 11, dopo aver avviato Postal e creato il dominio dalla dashboard.

PREPARAZIONE DEL SISTEMA

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y ca-certificates curl gnupg git jq ufw

NOTA BENE: se l’aggiornamento include un nuovo kernel, riavvia con sudo reboot prima di proseguire.

INSTALLAZIONE DI DOCKER ENGINE

Aggiungi la chiave GPG e il repository Docker:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Quindi aggiornare con il comando:

sudo apt update

Installa Docker Engine e il plugin Compose:

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verifica e abilita l’utente corrente:

sudo docker run hello-world
sudo usermod -aG docker $USER
newgrp docker

ATTENZIONE: se poco dopo il rilascio di Ubuntu 26.04 il repository Docker non ha ancora una build per il suo codename, sostituisci $(. /etc/os-release && echo “$VERSION_CODENAME”) con il codename della LTS precedente supportata (es. noble) nel comando sopra.

AVVIARE MARIADB E RABBITMQ

Postal richiede MariaDB (10.6+) per i dati e RabbitMQ come coda dei messaggi. Genera prima due password robuste:

openssl rand -hex 16 # usala come password di MariaDB

openssl rand -hex 16 # usala come password di RabbitMQ

Avvia i due container (sostituisci PASSWORD_MARIADB e PASSWORD_RABBITMQ con i valori generati):

sudo docker run -d --name postal-mariadb \
-p 127.0.0.1:3306:3306 \
--restart always \
-e MARIADB_DATABASE=postal \
-e MARIADB_ROOT_PASSWORD=PASSWORD_MARIADB \
mariadb

sudo docker run -d --name postal-rabbitmq \
-p 127.0.0.1:5672:5672 \
--restart always \
-e RABBITMQ_DEFAULT_USER=postal \
-e RABBITMQ_DEFAULT_PASS=PASSWORD_RABBITMQ \
-e RABBITMQ_DEFAULT_VHOST=postal \
rabbitmq:3.8

Entrambi pubblicano la porta solo su 127.0.0.1, quindi restano raggiungibili esclusivamente dal server stesso.

NOTA BENE: per volumi di invio elevati o messaggi molto grandi, la documentazione ufficiale consiglia di alzare innodb_log_file_size di MariaDB ad almeno 10 volte la dimensione massima prevista dei messaggi.

INSTALLAZIONE DELLA CLI DI POSTAL

sudo git clone https://github.com/postalserver/install /opt/postal/install
sudo ln -s /opt/postal/install/bin/postal /usr/bin/postal

Verifica che il comando sia disponibile:

postal --help

Se è tutto corretto dovremmo visualizzare il seguente output:

Usage: postal [command]

Running postal:

* start - start Postal
* stop - stop Postal
* restart - restart Postal
* status - view current process status
* logs [service] - view logs from services

Setup/upgrade tools:

* initialize - create and load the DB schema
* upgrade - upgrade the DB schema

Other tools:

* version - show the current Postal version
* make-user - create a new global admin user
* default-dkim-record - display the default DKIM record
* console - open an interactive console
* test-app-smtp - send a test message through Postal
* bootstrap hostname [path] - create a new set of config
* bash [service] - access a bash console for a running process

BOOTSTRAP DELLA CONFIGURAZIONE

sudo postal bootstrap postal.tuodominio.it

Sostituisci postal.tuodominio.it con l’hostname configurato al passo CONFIGURAZIONE DEL DNS.

Il comando crea in /opt/postal/config:

Latest version is: 3.3.7
=> Creating /opt/postal/config/postal.yml
=> Creating /opt/postal/config/Caddyfile
=> Creating signing private key

postal.yml — file di configurazione principale
signing.key — chiave privata per la firma dei messaggi
Caddyfile — configurazione del proxy web/TLS

CONFIGURAZIONE DI POSTAL.YML

Apri il file postal.yml con il comando:

sudo nano /opt/postal/config/postal.yml

Quindi inserire all’interno del file il seguente output:

main_db:
host: 127.0.0.1
username: root
password: LA_PASSWORD_MARIADB generata allo step AVVIARE MARIADB E RABBITMQ
database: postal

message_db:
host: 127.0.0.1
username: root
password: LA_PASSWORD_MARIADB generata allo step AVVIARE MARIADB E RABBITMQ
prefix: postal

rabbitmq:
host: 127.0.0.1
username: postal
password: LA_PASSWORD_RABBITMQ generata allo step AVVIARE MARIADB E RABBITMQ
vhost: postal

dns:
mx_records:
- postal.tuodominio.it
smtp_server_hostname: postal.tuodominio.it
spf_include: spf.postal.tuodominio.it
return_path: rp.postal.tuodominio.it
route_domain: routes.postal.tuodominio.it
track_domain: postal.tuodominio.it

Sezione DNS (sostituisci tuodominio.it con il tuo dominio)

INIZIALIZZARE IL DATABASE E CREARE L’AMMINISTRATORE

sudo postal initialize
sudo postal make-user

Il secondo comando chiede email, nome, cognome e password del primo utente amministratore: rispondi ai prompt interattivi.

Se è andato tutto a buon fine dovremmo visualizzare un output simile al seguente:

Postal User Creator
Enter the information required to create a new Postal user.
This tool is usually only used to create your initial admin user.

E-Mail Address : admin@lab.prv
First Name : admin
Last Name : admin
Initial Password : ***********

User has been created with e-mail address admin@lab.prv

AVVIO DI POSTAL E DEL PROXY CADDY

sudo postal start
sudo postal status

Tutti i servizi devono risultare Up. Avvia poi Caddy per la gestione automatica di TLS/HTTPS:

sudo docker run -d --name postal-caddy \
--restart always \
--network host \
-v /opt/postal/config/Caddyfile:/etc/caddy/Caddyfile \
-v /opt/postal/caddy-data:/data \
caddy

Verifica che tutti i container siano attivi:

sudo docker ps

ACCESSO A POSTAL DA WEB GUI

Visita https://postal.tuodominio.it e accedi con l’utente creato allo step INIZIALIZZARE IL DATABASE E CREARE L’AMMINISTRATORE

Inserire le credenziali e cliccare Login

Dovremmo visualizzare la schermata di benvenuto di Postal

COMPLETARE I RECORD DNS (SPF, RETURN-PATH, DKIM)

Dalla dashboard: crea un’organizzazione, poi un mail server al suo interno, quindi aggiungi il dominio da cui invierai la posta.

Postal genera automaticamente la chiave DKIM specifica per quel dominio, mostrata nella pagina di verifica.

Cliccare su Create the first Organization

Inserire i dati e cliccare Create Organization

Cliccare Build your first mail server

Inserire le info richieste quindi cliccare Build Server

A questo punto dovremmo visualizzare la Dashboard di Postal

AGGIUNTE NEL DNS

Aggiungi nel DNS i seguenti record:

SPF sul sottodominio dedicato (TXT su spf.postal.tuodominio.it):

v=spf1 ip4:a.b.c.d ip6:ipv6::address ~all

SPF sull’hostname principale (TXT su postal.tuodominio.it):

v=spf1 a mx include:spf.postal.tuodominio.it ~all

Return-path (A/AAAA su rp.postal.tuodominio.it verso l’IP del server, più un CNAME psrp.postal.tuodominio.it → rp.postal.tuodominio.it) e lo stesso TXT SPF di cui sopra sul record rp.

DKIM copia esattamente il record TXT mostrato dalla dashboard, nel formato postal-[CHIAVE]._domainkey.postal.tuodominio.it.

Usa il pulsante “verifica DNS” nella dashboard per confermare che tutti i record siano stati recepiti prima di iniziare a inviare.

CONFIGURAZIONE DEL FIREWALL

Aprire le porte con i seguenti comandi:

sudo ufw allow OpenSSH
sudo ufw allow 25/tcp # SMTP (ricezione e invio)
sudo ufw allow 587/tcp # Submission, se usato dalle tue app
sudo ufw allow 80/tcp # HTTP (validazione TLS)
sudo ufw allow 443/tcp # HTTPS (dashboard)
sudo ufw enable
sudo ufw status

MANUTENZIONE E COMANDI UTILI

Stato dei servizi: sudo postal status

Log di Postal: sudo postal logs -f

Riavviare Postal: sudo postal restart

Fermare/avviare Postal: sudo postal stop / sudo postal start

Aggiornare Postal: sudo postal upgrade

Console Rails (debug avanzato): sudo postal console

Backup: i dati critici sono nel database MariaDB (container postal-mariadb) e nella cartella /opt/postal/config (in particolare signing.key, da conservare con cura: è la chiave usata per firmare i messaggi). Un mysqldump periodico più una copia di /opt/postal/config coprono un ripristino completo.

Risoluzione problemi: se l’invio non parte, verifica di nuovo la porta 25 in uscita (causa più comune) e che i record SPF/DKIM/return-path risultino “verificati” nella dashboard prima di dichiarare il dominio pronto all’invio.

CONCLUSIONI

In questa guida abbiamo visto come installare e configurare Postal su Ubuntu Server 26.04 LTS con Docker Engine.

Siamo partiti dalla preparazione dei record DNS e siamo arrivati al primo accesso all’interfaccia web in HTTPS, passando per l’installazione di Docker, l’avvio di MariaDB, la generazione della configurazione e la creazione dell’utente amministratore.

Prima di decidere se adottare Postal in produzione, conviene valutarne con attenzione punti di forza e limiti.

PRO

• Open source e gratuito: distribuito con licenza MIT, senza costi di licenza né tariffe per singolo messaggio inviato, a differenza dei servizi commerciali.
• Pieno controllo dei dati: messaggi, log e statistiche restano sui propri server, un aspetto rilevante per privacy, GDPR e requisiti di compliance.
• Interfaccia web completa: gestione centralizzata di organizzazioni, server, domini, credenziali e log dei messaggi, senza dover lavorare solo da riga di comando.
• Multi-tenant: permette di separare clienti, progetti o applicazioni in organizzazioni e server distinti, ideale per MSP e agenzie.
• SMTP e API HTTP: si integra facilmente con qualsiasi applicazione, CMS o gestionale.
• Funzionalità avanzate: firma DKIM automatica, tracciamento di aperture e clic, webhook per consegne e rimbalzi, pool di IP e route per la posta in arrivo.
• Installazione semplificata: dalla versione 3 gira interamente in Docker e richiede solo MariaDB, senza RabbitMQ.

CONTRO

• La consegnabilità è tutta a carico vostro: reputazione dell’IP, warm-up, monitoraggio delle blacklist e configurazione corretta di SPF, DKIM, DMARC e PTR sono responsabilità dell’amministratore. Con un IP nuovo o “sporco”, i messaggi finiscono facilmente in spam.
• Porta 25 spesso bloccata: molti provider cloud (AWS, Azure, Google Cloud e diversi VPS) bloccano il traffico SMTP in uscita, e a volte è difficile ottenerne lo sblocco.
• Non è un server di caselle di posta: niente IMAP o POP3. Per la posta degli utenti servono altre soluzioni.
• Niente gestione delle campagne: mancano liste di contatti, editor di template e gestione delle disiscrizioni. Per le newsletter serve un software dedicato, come Listmonk o Mautic, che usi Postal come motore di invio.
• Server dedicato e risorse non trascurabili: almeno 4 GB di RAM e un host riservato, perché Postal non convive bene con altri servizi sulle stesse porte.
• Manutenzione e sicurezza a carico vostro: aggiornamenti, backup, monitoraggio e protezione del server non sono inclusi come in un servizio gestito, e non c’è un supporto ufficiale con SLA.
• Community e documentazione più limitate rispetto alle alternative commerciali: per i problemi meno comuni spesso bisogna cercare tra le issue su GitHub.

In sintesi, Postal è un’ottima scelta per chi ha competenze sistemistiche, vuole mantenere il controllo dell’infrastruttura di invio e gestisce volumi tali da rendere costosi i servizi a consumo.

Chi invece preferisce non occuparsi di reputazione degli IP, blacklist e manutenzione troverà più comodo un servizio gestito, accettandone costi e dipendenza da terzi.

Chi gestisce un sito web prima o poi deve chiedersi quanti utenti lo visitano, da dove arrivano e quali contenuti funzionano meglio.

Per anni la risposta quasi automatica è stata Google Analytics. Oggi però la scelta non è più così scontata, tra l’attenzione crescente alla privacy, il GDPR, i banner dei cookie sempre più invasivi e il desiderio di tenere i propri dati sotto controllo.

Umami è una piattaforma di web analytics open source, leggera e pensata per rispettare la privacy dei visitatori.

Non usa cookie, non raccoglie dati personali e non traccia gli utenti tra siti diversi.

Offre comunque tutte le metriche che servono davvero: visualizzazioni di pagina, visitatori unici, sorgenti di traffico, dispositivi, browser, paesi di provenienza ed eventi personalizzati.

Il tutto in una dashboard pulita e immediata, lontana dalla complessità di strumenti più blasonati.

Il punto di forza principale è che Umami si può installare in self-hosting sulla propria infrastruttura.

Così i dati delle statistiche restano sul nostro server e non passano da servizi di terze parti.

In questa guida vedremo passo passo come installare e configurare Umami su Ubuntu Server 26.04 usando Docker Compose.

Con questo approccio il deploy è rapido, gli aggiornamenti sono semplici e l’ambiente resta ordinato e portabile. Partiremo dalla preparazione del server e arriveremo al primo accesso alla dashboard. Lungo la strada configureremo il database PostgreSQL e collegheremo il primo sito da monitorare.

PREREQUISITI

Un server con Ubuntu Server 26.04 LTS già installato, con accesso SSH e un utente con permessi sudo.

Risorse minime: Umami è leggero 1 vCPU e 1 GB di RAM sono sufficienti per un sito con traffico moderato; per più siti o volumi alti, meglio 2 GB+.

L’indirizzo IP del server, che userai per raggiungere Umami dal browser (es. 192.0.2.10).

Connessione internet in uscita sul server, per scaricare pacchetti e immagini Docker.

PREPARAZIONE DEL SERVER

Collegati via SSH e porta il sistema all’ultima versione dei pacchetti.

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg openssl

Verifica che il fuso orario del sistema sia impostato su UTC: Umami e PostgreSQL si comportano meglio così, ed è più semplice confrontare i dati con altri strumenti.

sudo timedatectl set-timezone UTC

timedatectl

Dovremmo visualizzare un output simile al seguente:

Local time: Sat 2026-10-10 19:24:31 UTC
Universal time: Sat 2026-10-10 19:24:31 UTC
RTC time: Sat 2026-10-10 19:24:31
Time zone: UTC (UTC, +0000)
System clock synchronized: no
NTP service: active
RTC in local TZ: no

INSTALLAZIONE DI DOCKER ENGINE

Aggiungi il repository ufficiale Docker e installa Engine, CLI e il plugin compose. Ubuntu 26.04 (“Resolute”) è tra le versioni supportate ufficialmente da Docker.

# Chiave GPG e repository apt di Docker
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Quindi aggiornare con il comando:

sudo apt update

Quindi procedere con l’installazione:

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verifica che l’installazione funzioni con i comandi:

sudo systemctl status docker --no-pager
sudo docker run --rm hello-world
docker compose version

OPZIONALE: usare Docker senza sudo

Per lanciare i comandi Docker senza anteporre sudo, aggiungi il tuo utente al gruppo docker e apri una nuova sessione SSH.

sudo usermod -aG docker $USER
newgrp docker

Dovremmo visualizzare un output simile al seguente:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/get-started/

Docker Compose version v5.6.0

CREAZIONE DELLA CARTELLA DI PROGETTO

Tieni Umami in una cartella dedicata: rende più semplici backup e aggiornamenti.

sudo mkdir -p /opt/umami
sudo chown $USER:$USER /opt/umami
cd /opt/umami

Genera due segreti che useremo nel prossimo passaggio: la password del database e la chiave APP_SECRET di Umami (usata per firmare le sessioni — deve restare privata).

openssl rand -hex 24 # → usa il risultato come password del DB
openssl rand -hex 32 # → usa il risultato come APP_SECRET

Crea un file .env con i valori generati (sostituisci i segnaposto):

sudo nano .env

Inserire all’interno del file il seguente output:

POSTGRES_DB=umami
POSTGRES_USER=umami
POSTGRES_PASSWORD=sostituisci-con-il-primo-valore-generato
APP_SECRET=sostituisci-con-il-secondo-valore-generato

ATTENZIONE: Non usare le password d’esempio delle guide online (umami/umami): sono note pubblicamente e il servizio finirebbe esposto sull’IP del server.

SCRIVERE IL DOCKER-COMPOSE.YML

Nella stessa cartella, crea docker-compose.yml con i due servizi: il database PostgreSQL e l’applicazione Umami, entrambi con healthcheck così Umami parte solo quando il database è davvero pronto.

sudo nano docker-compose.yml

Inserire all’interno del file YML il seguente output:

services:
umami:
image: docker.umami.is/umami-software/umami:postgresql-latest
container_name: umami
ports:
- "3000:3000"
environment:
DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
DATABASE_TYPE: postgresql
APP_SECRET: ${APP_SECRET}
depends_on:
db:
condition: service_healthy
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "curl -fSs http://localhost:3000/api/heartbeat || exit 1"]
interval: 10s
timeout: 5s
retries: 5

db:
image: postgres:15-alpine
container_name: umami-db
environment:
POSTGRES_DB: ${POSTGRES_DB}
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- umami-db-data:/var/lib/postgresql/data
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
interval: 5s
timeout: 5s
retries: 5

volumes:
umami-db-data:

NOTA BENE: Docker Compose legge automaticamente il file .env nella stessa cartella e sostituisce le variabili ${…}: non serve altro collegamento tra i due file.

VARIABILI UTILIZZATE

Di seguito l’utilizzo delle variabili:

POSTGRES_DB/USER/PASSWORD – .env – Credenziali del database, condivise tra i due servizi

DATABASE_URL – compose – Stringa di connessione che Umami usa verso il container db

APP_SECRET – .env – Chiave usata da Umami per firmare le sessioni utente

AVVIO DI UMAMI

Dalla cartella /opt/umami, scarica le immagini e avvia i container in background.

docker compose up -d

Dovremmo visualizzare il seguente output:

[+] up 40/40
 Image postgres:15-alpine Pulled 9.5s
 Image docker.umami.is/umami-software/umami:postgresql-latest Pulled 23.8s
 Network umami_default Created 0.1s
 Volume umami_umami-db-data Created 0.0s
 Container umami-db Healthy 12.4s
 Container umami Started

Al primo avvio Umami esegue automaticamente le migrazioni del database: può richiedere qualche istante. Controlla lo stato e i log:

docker compose ps

docker compose logs -f umami # Ctrl+C per uscire dai log

Quando entrambi i servizi mostrano stato healthy, Umami è pronto sulla porta 3000 del server.

APERTURA DELLE PORTE NEL FIREWALL

Se ufw non è ancora attivo, configuralo lasciando sempre passare SSH prima di abilitarlo, per non restare tagliati fuori dal server.

sudo ufw allow OpenSSH
sudo ufw allow 3000/tcp
sudo ufw enable
sudo ufw status

Senza un reverse proxy, il traffico verso la porta 3000 non è cifrato (HTTP semplice) e la porta è raggiungibile da chiunque conosca l’IP. Se il server ha un IP fisso e conosci in anticipo da dove ti collegherai, restringi l’accesso con sudo ufw allow from <TUO-IP> to any port 3000 al posto della regola generica.

ACCESSO TRAMITE WEB GUI

Apri nel browser http://<IP-DEL-SERVER>:3000 e accedi con le credenziali predefinite

Inserire le seguenti credenziali:

utente: admin
password: umami

ATTENZIONE: Cambia la password subito dopo il primo accesso, da Impostazioni → Profilo. Le credenziali predefinite sono pubbliche e note a chiunque abbia letto la documentazione di Umami.

Se è andato tutto a buon fine dovremmo visualizzare la Dashboard di Umami

CONFIGURAZIONE DI BASE

Aggiungere il primo sito

Vai su Impostazioni → Websites → Add website

Inserire la descrizione del sito e il dominio quindi cliccare Save

Dovremmo visualizzare il sito come mostrato nell’immagine sobvrastante

Umami genera uno snippet <script> univoco per quel sito.

Incolla lo snippet prima della chiusura del tag </head> di ogni pagina del sito da monitorare.

Regolare fuso orario e formato dati

In Impostazioni → Profilo puoi impostare il tuo fuso orario di visualizzazione (il database resta in UTC) e la lingua dell’interfaccia.

Dalla Dashboard di Umami sarà possibile visualizzare tutte le info relative al sito

CREAZIONE DI UTENTI AGGIUNTIVI

Se altre persone del team devono consultare le statistiche, creale da Impostazioni → Utenti invece di condividere l’account admin.

MANUTENZIONE

Aggiornare Umami con i seguenti comandi:

cd /opt/umami
docker compose pull
docker compose up -d

Backup del database con i seguenti comandi:

docker exec umami-db pg_dump -U umami umami > backup-umami-$(date +%F).sql

Comandi utili

docker compose stop # ferma i container, mantiene i dati

docker compose start # riavvia dopo uno stop

docker compose down # rimuove i container, il volume dati resta

docker compose logs -f # segue i log di entrambi i servizi

CONSIDERAZIONI FINALI

Con pochi comandi e un file docker-compose.yml abbiamo messo in piedi una piattaforma di web analytics completa e indipendente, che gira interamente sulla nostra infrastruttura. È proprio questo il valore principale di Umami: raccoglie le statistiche che contano senza sacrificare la privacy dei visitatori e senza consegnare i dati a servizi esterni.

Dopo averlo provato sul campo, ecco i punti di forza che mi hanno convinto:

Privacy by design: niente cookie e niente dati personali. Nella maggior parte dei casi questo semplifica parecchio la conformità al GDPR e può evitare il classico banner dei cookie per le sole statistiche.

Leggerezza: lo script di tracking pesa pochi kilobyte e non rallenta il sito, un dettaglio da non sottovalutare anche in ottica SEO e Core Web Vitals.

Semplicità: la dashboard è chiara e immediata e le informazioni utili si trovano in pochi secondi, senza perdersi tra menu e report.

Multi-sito e multi-utente: da un’unica istanza si possono monitorare più siti e dare accesso a colleghi o clienti, anche con dashboard condivise in sola lettura.

Open source e self-hosted: il controllo completo resta nostro, senza costi di licenza né vincoli con un fornitore.

Ci sono però anche alcuni limiti da tenere a mente:

Chi arriva da Google Analytics non troverà funzionalità avanzate come funnel complessi, attribuzione multicanale o integrazione nativa con le piattaforme pubblicitarie.

Il self-hosting richiede un minimo di manutenzione: aggiornamenti dei container, backup del database PostgreSQL e monitoraggio del server sono a nostro carico.

Come tutti gli strumenti di analytics, Umami può essere bloccato dagli ad-blocker più aggressivi. Si può attenuare il problema rinominando lo script di tracking o servendolo tramite reverse proxy sul proprio dominio.

In conclusione, Umami è un’ottima scelta per blog, siti aziendali, portali di documentazione e progetti personali.

È adatta a chiunque voglia statistiche affidabili e rispettose della privacy senza la complessità di Google Analytics.

Per chi già gestisce un’infrastruttura Docker, il costo di adozione è praticamente nullo e i vantaggi si vedono da subito.

Quante volte vi è capitato di dover stampare un documento dall’iPhone o dall’iPad e di scoprire che la stampante di casa o dell’ufficio non viene nemmeno rilevata?

Il motivo è semplice: i dispositivi Apple stampano in modalità wireless tramite AirPrint, un protocollo supportato solo dalle stampanti più recenti.

Molte stampanti ancora funzionanti restano quindi escluse, in particolare i modelli USB, le laser di qualche anno fa e le multifunzione da ufficio.

Per fortuna non serve cambiare stampante. Con un Raspberry Pi, CUPS (il sistema di stampa open source usato su Linux e macOS) e Avahi (per l’annuncio dei servizi in rete tramite Bonjour) potete creare un piccolo print server AirPrint.

In questo modo qualsiasi stampante, collegata via USB o già presente in rete, diventa visibile e utilizzabile da iPhone, iPad e Mac senza installare driver o app aggiuntive.

In questa guida vedremo passo dopo passo come:

• preparare il Raspberry Pi e installare i pacchetti necessari
• configurare CUPS e aggiungere la stampante
• abilitare la condivisione e la pubblicazione AirPrint tramite Avahi
• verificare il funzionamento da iOS e macOS

Il risultato è una soluzione economica e silenziosa, che consuma pochissimo e può restare accesa 24 ore su 24.

È adatta sia alla rete di casa sia a un piccolo ufficio dove convivono dispositivi Apple, Windows e Linux.

PREMESSA

Questa guida descrive come configurare un server di stampa AirPrint con Raspberry Pi OS.
CUPS gestisce le code di stampa e Avahi annuncia la stampante sulla rete locale rendendola individuabile dai dispositivi compatibili.

I comandi e i nomi riportati sono esempi: sostituiscili con quelli del tuo sistema e della tua stampante.
Il Raspberry Pi deve essere acceso e collegato alla rete quando vuoi stampare.
La procedura riguarda la stampa e non configura la funzione scanner di eventuali dispositivi multifunzione.

PREREQUISITI

• Raspberry Pi con Raspberry Pi OS. Per esempio: Raspberry Pi 4B con Raspberry Pi OS basato su Debian 13 (Trixie).
• Stampante USB. Per esempio: Brother MFC-1810, laser monocromatica.
• Dispositivo Apple collegato alla stessa rete locale.
• Accesso SSH al Raspberry Pi.

AGGIORNARE IL SISTEMA E INSTALLARE I SERVIZI

Aggiorna l’elenco dei pacchetti e installa gli aggiornamenti disponibili:

sudo apt update
sudo apt full-upgrade -y

Installa CUPS, Avahi e gli strumenti per rilevare i servizi in rete:

sudo apt install -y cups avahi-daemon avahi-utils

Abilita e avvia i servizi:

sudo systemctl enable --now cups
sudo systemctl enable --now avahi-daemon

Aggiungi il tuo utente al gruppo degli amministratori CUPS.

Riconnettiti via SSH perché la modifica abbia effetto:

sudo usermod -aG lpadmin "$USER"

APRIRE IL PANNELLO CUPS TRAMITE SSH

Sul Raspberry Pi, il pannello CUPS è disponibile all’indirizzo http://localhost:631.
Per amministrarlo da un altro computer senza rendere accessibile la porta a tutta la rete, crea un tunnel SSH sostituendo utente e indirizzo con i tuoi:

ssh -L 8631:localhost:631 <utente>@<indirizzo-pi>

Lascia aperta la sessione SSH e apri http://localhost:8631 nel browser del computer. Accedi con l’utente del Raspberry Pi aggiunto al gruppo lpadmin.

COLLEGARE E RILEVARE LA STAMPANTE

Collega la stampante al Raspberry Pi tramite USB e accendila.

Verifica che il sistema la rilevi:

sudo lpinfo -v

Nell’elenco dovrebbe apparire una riga simile a questa:

usb://Brother/MFC-1810%20series?serial=...

La Brother MFC-1810 è una stampante “host-based” e richiede un driver dedicato. Installa il driver open source brlaser:

sudo apt install -y printer-driver-brlaser

Cerca il modello disponibile:

sudo lpinfo -m | grep -i MFC-1810

L’output dovrebbe contenere una voce simile a:

drv:///brlaser.drv/br1810.ppd Brother MFC-1810 series ...

CREARE E CONDIVIDERE LA CODA DI STAMPA

Abilita la condivisione delle stampanti:

sudo cupsctl --share-printers

Crea la coda usando il modello e l’indirizzo USB rilevati.

I valori seguenti sono un esempio basato su una Brother MFC-1810: sostituisci nome coda, indirizzo USB, seriale, modello, driver e posizione con quelli della tua stampante:

sudo lpadmin -p NOME_CODA \
-v 'usb://Brother/MFC-1810%20series?serial=SERIALE_USB' \
-m 'drv:///brlaser.drv/br1810.ppd' \
-D 'Brother MFC-1810' \
-L 'POSIZIONE' \
-o printer-is-shared=true \
-E

Imposta la coda come predefinita, abilitala e consenti l’invio dei lavori:

sudo lpadmin -d NOME_CODA
sudo cupsaccept NOME_CODA
sudo cupsenable NOME_CODA

Controlla lo stato:

lpstat -t

STAMPARE UNA PAGINA DI PROVA

Invia una pagina di prova e controlla la coda:

lp -d NOME_CODA /usr/share/cups/data/testprint
lpstat -o

Prima di proseguire, verifica che la pagina venga stampata correttamente.

ANNUNCIARE LA STAMPANTE IN RETE (AIRPRINT)

Verifica che CUPS e Avahi siano attivi:

systemctl is-active cups avahi-daemon

Controlla l’annuncio DNS-SD della stampante:

avahi-browse -at --resolve | grep -i -E 'IPP|NOME_CODA'

Nel record TXT verifica la presenza di informazioni come:

URF=V1.4,...
pdl=...image/urf,application/pdf

La voce URF identifica il supporto al formato AirPrint. Su iPhone o iPad, apri un documento o una foto, tocca **Condividi**, poi **Stampa** e seleziona la Brother MFC-1810.

SICUREZZA

Limita le porte 631 (CUPS) e 22 (SSH) alla rete locale fidata.

Non inoltrarle dal router verso Internet.

Il tunnel SSH descritto nel capitolo 2 consente di raggiungere il pannello di amministrazione senza esporlo a tutta la rete.

RISOLUZIONE DEI PROBLEMI

LA STAMPANTE NON COMPARE IN CUPS

Controlla il cavo USB, l’alimentazione e l’output di sudo lpinfo -v. Alcune multifunzione espongono più interfacce USB.

CUPS STAMPA, MA IPHONE O IPAD NON TROVA LA STAMPANTE

Verifica che la condivisione sia attiva (cupsctl --share-printers), che entrambi i dispositivi siano sulla stessa rete e che Avahi sia attivo.

Controlla anche che il Wi-Fi non abbia l’isolamento dei client abilitato e che il multicast DNS (UDP 5353) non sia bloccato tra rete Wi-Fi e rete cablata.

LA CODA COMPARE, MA I LAVORI FALLISCONO O LA STAMPA È ERRATA

Controlla la sezione **Jobs** del pannello CUPS e i messaggi di errore nei log di CUPS.

Verifica inoltre di aver selezionato il modello e il driver corretti.

Chiunque gestisca un’infrastruttura aziendale sa quanto la posta elettronica sia, ancora oggi, uno dei servizi più critici da tenere in piedi.

Notifiche di backup, alert di monitoraggio, invii applicativi, comunicazioni interne: se lo smarthost SMTP che inoltra questo traffico va giù, il problema spesso non si nota subito, ma quando emerge è già tardi — un job di backup fallito senza preavviso, un allarme di sicurezza mai recapitato.

Postfix è da anni la scelta di riferimento per costruire un relay SMTP affidabile, leggero e facilmente configurabile, ma da solo resta comunque un singolo punto di guasto: se il server che lo ospita si ferma, tutta la posta in transito rimane bloccata finché non si interviene manualmente.

La soluzione più naturale, e anche una delle più economiche in termini di risorse, è affiancare a Postfix un meccanismo di failover automatico che sposti l’IP virtuale del servizio su un nodo di backup senza intervento umano.

In questa guida vedremo come installare e configurare due nodi Postfix identici in ruolo di smarthost, e come metterli in alta affidabilità usando KeepAlived e il protocollo VRRP per gestire l’IP virtuale condiviso.

Al termine avrai un’infrastruttura di relay SMTP che sopravvive al riavvio o al guasto di uno dei due nodi, senza che le applicazioni a monte debbano nemmeno accorgersene.

ARCHITETTURA

Come si ottiene il failover senza toccare i client

Sì, si può fare, ed è uno scenario molto comune. La chiave è che i client non parlano mai direttamente a postfix1 o postfix2: parlano sempre a un unico nome DNS (smtp-relay.azienda.local) che risolve verso un indirizzo IP virtuale (VIP).

Quell’indirizzo, in ogni istante, è ospitato fisicamente da uno solo dei due nodi.

keepalived, tramite il protocollo VRRP, sposta la VIP da un nodo all’altro in caso di guasto, in genere in 1-3 secondi, senza che nulla vada riconfigurato lato client o lato DNS.

Perché funzioni tra due reti fisicamente diverse serve un accorgimento: i due nodi devono condividere un segmento di livello 2 (la stessa VLAN/subnet) su cui far vivere la VIP e scambiarsi l'”heartbeat” VRRP.

Il client si affida sempre allo stesso nome DNS e allo stesso IP virtuale. È keepalived, tramite VRRP sul segmento L2 dedicato che collega le due reti, a spostare la VIP dal nodo attivo a quello di standby in caso di guasto senza che DNS o client vengano toccati.

PREREQUISITI

Prima di iniziare servono:

• Due host (fisici o VM), uno per rete/sede, con una distribuzione Ubuntu Server 26.04
• Un segmento L2 dedicato esteso tra le due reti (VLAN stretch, trunk dedicato o overlay tipo VXLAN gestito dal team di rete), anche una subnet piccola basta (negli esempi 10.10.10.0/29).
• Un nome DNS interno per lo smarthost, es. smtp-relay.azienda.local, che punterà alla VIP.
• Accesso root su entrambi i nodi.
• Le subnet delle reti client che dovranno essere autorizzate a inoltrare posta (per mynetworks).
• Se lo smarthost deve a sua volta inoltrare la posta verso un relay esterno (provider anti-spam, Microsoft 365, SES, ecc.), le relative credenziali/host in questa guida: una casella email esistente (indirizzo completo e password) da usare solo per l’autenticazione SMTP in uscita.

RIFERIMENTO

Schema IP usato in questo tutorial

ATTENZIONE: Sostituire questi valori con i tuoi.

I due nodi mantengono anche il proprio indirizzo “normale” sulla rete A/B per la gestione ordinaria (SSH, monitoring): l’interfaccia sul segmento 10.10.10.0/29 è dedicata esclusivamente al cluster.

PREPARAZIONE DELLA RETE

Prima di toccare i server, va predisposto il segmento su cui vivrà la VIP.

Chiedi al team di rete di estendere una VLAN dedicata (o un overlay L2) tra le due sedi/reti, riservata al cluster, non serve che sia grande, basta un /29 o /28.

Verifica se il link tra le due sedi inoltra correttamente il traffico multicast: su collegamenti WAN-like tra sedi spesso no.

In questa guida configuriamo comunque VRRP in modalità unicast, che non dipende dal multicast ed è la scelta più robusta per questo scenario.

Aprire sui firewall intermedi il protocollo VRRP (IP protocol 112) tra i due indirizzi cluster (10.10.10.1 10.10.10.2).

Verificare che la latenza tra le due sedi sul link cluster sia bassa e stabile: latenze alte o instabili causano falsi failover.

Creare il record DNS smtp-relay.azienda.local → 10.10.10.10.

INSTALLAZIONE DI POSTIFIX SU UBUNTU 26.04

Ripetere questi passaggi su entrambi i nodi.

Impostare prima l’hostname corretto: Postfix lo legge in fase di installazione per proporre il “system mail name”, e usarlo da subito evita di doverlo correggere dopo.

Sul server Postfix 1 eseguire il comando:

hostnamectl set-hostname postfix1.azienda.local

Sul server Postfix 2 eseguire il comando:

hostnamectl set-hostname postfix2.azienda.local

Verificare che /etc/hosts risolva l’hostname localmente (Ubuntu lo fa già in automatico con la riga 127.0.1.1), poi aggiorna il sistema e preconfigura le risposte debconf di Postfix per un’installazione non interattiva e ripetibile in modo identico sui due nodi.

Sul Server Postfix 1 e Postfix 2 eseguire i comandi:

apt update && apt upgrade -y

echo "postfix postfix/main_mailer_type select Internet Site" | debconf-set-selections

echo "postfix postfix/mailname string smtp-relay.azienda.local" | debconf-set-selections

DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules keepalived

libsasl2-modules non è strettamente necessario per il ruolo di smarthost verso i client interni, ma serve al passo 4 per autenticarsi in uscita verso il Mail Server Esterno con i meccanismi PLAIN/LOGIN. Al termine dell’installazione Postfix è già attivo con una configurazione minima: il passo successivo la sostituisce.

CONFIGURAZIONE BASE DI POSTFIX

Questa configurazione deve essere identica su entrambi i nodi (a parte l’hostname, se vuoi differenziarlo).

Il punto chiave è inet_interfaces = all: Postfix ascolta su tutte le interfacce del nodo, quindi non serve riavviarlo quando la VIP arriva o se ne va.

Editare sul server Postfix 1 e postfix 2 il file /etc/postfix/main.cf con il comando:

sudo nano /etc/postfix/main.cf

Quindi incollare all’interno il seguente output:

myhostname = smtp-relay.azienda.local
mydomain = azienda.local
myorigin = $mydomain

# ascolta su tutte le interfacce: fisica + VIP, indifferentemente
inet_interfaces = all
inet_protocols = ipv4
mydestination = localhost

# reti autorizzate a usare questo smarthost per il relay
mynetworks = 127.0.0.0/8, 10.10.10.0/29, <RETE_A>/24, <RETE_B>/24, <ALTRE_RETI_CLIENT>/24

# è un puro relay in uscita: non consegna localmente per altri domini
relay_domains =
smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination

# il relay esterno (relayhost + SASL) è configurato successivamente

smtpd_tls_security_level = may
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/ssl/certs/smtp-relay.pem
smtpd_tls_key_file = /etc/ssl/private/smtp-relay.key

message_size_limit = 26214400

Applicare e ricaricare il server Postfix 1 e postfix 2 con i seguenti comandi:

postfix check

systemctl restart postfix

CONFIGURAZIONE RELAY AUTENTICATO

Invece di consegnare direttamente via MX, in questo tutorial inoltriamo a entrambi i nodi tutta la posta in uscita attraverso il server SMTP Pubblico, autenticandosi con una casella email già esistente (dedicata solo a questo scopo, non usata per leggere posta).

ATTENZIONE: La maggior parte dei gestori di posta applicano limiti al numero di messaggi inviabili per casella/giorno, pensati per un uso da client di posta, non da relay aziendale. Se il volume di posta di tutta la rete interna passa da qui, verifica con il fornitore di posta i limiti del tuo piano prima di andare in produzione: superarli comporta email rifiutate o accodate, non un errore visibile ai client interni.

Modificare il file main.cf, su entrambi i nodi con il comando:

sudo nano /etc/postfix/main.cf

Quindi aggiungere il seguente output:

relayhost = [smtps.aruba.it]:465
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain, login

Creare il file con le credenziali della casella Mail e trasformalo nella mappa che Postfix usa per cercarle (va rifatto ogni volta che il file cambia).

Ovviamante è da fare su entrambe i Server Postfix 1 e Postfix 2

Eseguire il comando:

sudo nano /etc/postfix/sasl_passwd

Quindi incollare il seguente output:

[smtps.test.it]:465 nomecasella@tuodominio.it:PasswordDellaCasella

Salvare e chiudere il file di configurazione

Quindi eseguire i comandi:

postmap /etc/postfix/sasl_passwd

chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

systemctl restart postfix

Verificare che l’autenticazione funzioni inviando un messaggio di prova e controllando il log con i seguenti comandi:

echo "corpo del messaggio" | mail -s "test relay Aruba" destinatario@dominio-esterno.tld

tail -f /var/log/mail.log

Nel log, una consegna riuscita verso il mail server pubblico mostra una riga relay=smtps.test.it[…]:465, … status=sent; un problema di credenziali compare invece come SASL authentication failed.

SINCRONIZZAZIONE DELLA CONFIGURAZIONE TRA I NODI

Il rischio più comune in un cluster attivo/passivo è il drift: i due nodi si scollegano nel tempo perché una modifica viene fatta solo su uno dei due, e il giorno del failover il nodo di riserva si comporta diversamente.

Di seguito alcune opzioni, dalla più semplice alla più solida da implementare:

Repository git + deploy manuale: tieni main.cf/master.cf in un repository, applichi le modifiche su un nodo, apri una PR/commit, poi esegui lo stesso file sull’altro nodo.

rsync a senso unico con verifica: uno script che confronta i due file e segnala differenze prima di ogni modifica pianificata.

Ansible (consigliato se hai già altra infrastruttura gestita così): un playbook con un unico template main.cf.j2 applicato a entrambi i nodi garantisce che siano sempre identici per costruzione.

CONFIGURAZIONE DI KEEPALIVED

Keepalived gira su entrambi i nodi con lo stesso virtual_router_id, ma priorità diverse: il nodo con priorità più alta diventa MASTER e prende la VIP; l’altro resta BACKUP finché non rileva l’assenza degli annunci VRRP del master.

Un dettaglio importante: non basta che il processo keepalived sia vivo, deve esserlo anche postfix.

Per questo aggiungere uno script di controllo (vrrp_script) che verifica che Postfix sia realmente in ascolto sulla porta 25: se fallisce, la priorità del nodo viene abbassata e la VIP migra automaticamente sull’altro nodo anche se il sistema operativo è ancora “vivo”.

Su entrambe i server creare il file check_postfix.sh con il comando:

sudo nano /usr/local/bin/check_postfix.sh

Quindi incollare il seguente output:

#!/bin/bash
# esce con 0 se postfix è sano, 1 altrimenti
if systemctl is-active --quiet postfix && ss -ltn | grep -q ':25 '; then
exit 0
else
exit 1

Salvare e chiudere lo script

Dare i permessi corretti con il comando:

chmod +x /usr/local/bin/check_postfix.sh

Sul Server Postfix 1 creare il file keepalived.conf con il comando:

sudo nano /etc/keepalived/keepalived.conf

Incollare all’interno il seguente output:

postfix1 · priorità 150
vrrp_script chk_postfix {
script "/usr/local/bin/check_postfix.sh"
interval 2
timeout 2
fall 2
rise 2
weight -20
}

vrrp_instance VI_SMTP {
interface eth1.10 # interfaccia sul segmento cluster (VLAN dedicata)
state BACKUP # BACKUP su entrambi i nodi: decide la priorità, non lo stato dichiarato
virtual_router_id 51
priority 150
advert_int 1

unicast_src_ip 10.10.10.1
unicast_peer {
10.10.10.2
}

authentication {
auth_type PASS
auth_pass CambiaQuestaPassword
}

virtual_ipaddress {
10.10.10.10/29
}

track_script {
chk_postfix
}
}

Salvare e chiudere il file di configurazione

Sul Server Postfix 2 creare il file keepalived.conf con il comando:

sudo nano /etc/keepalived/keepalived.conf

Incollare all’interno il seguente output:

postfix2 · priorità 100
vrrp_script chk_postfix {
script "/usr/local/bin/check_postfix.sh"
interval 2
timeout 2
fall 2
rise 2
weight -20
}

vrrp_instance VI_SMTP {
interface eth1.10
state BACKUP
virtual_router_id 51
priority 100
advert_int 1

unicast_src_ip 10.10.10.2
unicast_peer {
10.10.10.1
}

authentication {
auth_type PASS
auth_pass CambiaQuestaPassword
}

virtual_ipaddress {
10.10.10.10/29
}

track_script {
chk_postfix
}
}

Salvare e chiudere il file di configurazione

ATTENZIONE: virtual_router_id deve essere univoco su quel segmento L2 (0-255): se in futuro aggiungi altri cluster VRRP sulla stessa VLAN, usa ID diversi per evitare conflitti. La password di autenticazione VRRPv2 è una protezione minima contro annunci accidentali, non una misura di sicurezza forte su un segmento dedicato e isolato è comunque sufficiente.

AVVIO E VERIFICA

Su entrambe i server Postfix 1 e Postfix 2 eseguire i comandi:

systemctl enable --now postfix

systemctl enable --now keepalived

Quindi verificare che la VIP sia presente solo sul server Postfix 1 (quello con priorità più alta) con i comandi:

ip -4 addr show dev eth1.10 | grep 10.10.10.10

journalctl -u keepalived -n 20

Verificare che lo smarthost risponda sulla VIP da un client sulla rete interna con il comando:

telnet smtp-relay.azienda.local 25

Oppure per un test più completo usare il comando:

swaks --to destinatario@test.tld --from mittente@azienda.local \
--server smtp-relay.azienda.local

TEST DI FAILOVER

Non dare per scontato che funzioni: verificare il failover in tre modi crescenti di severità.

TEST 1 — Fermare solo Postfix (guasto applicativo)

Sul server Postfix 1 (Master) eseguire il comando:

systemctl stop postfix

Lo script di controllo dovrebbe fallire entro pochi secondi, la priorità di postfix1 scende sotto 100 e postfix2 prende la VIP.

Verificare con il comando:

ip -4 addr show dev eth1.10 su postfix2

Quindi ripetere il test SMTP dal client e se è tutto ok non dovremmo accorgerci di nulla.

TEST 2 — Isolare il nodo (guasto di rete/hardware)

Spegnere il nodo master o disabilitare la sua interfaccia cluster.

Il failover in questo caso dipende dal timeout degli annunci VRRP (circa 3 × advert_int, quindi ~3 secondi con i valori di questa guida).

TEST 3 — Failback

Riaccendere/ripristinare postfix1: avendo priorità più alta e preempt attivo (il default), riprenderà automaticamente la VIP.

Se si preferisce evitare che il nodo torni a fare da master automaticamente subito dopo un ripristino (per rivedere prima i log), aggiungere nopreempt nel blocco vrrp_instance di postfix1.

DA SAPERE

Alcuni punti che vale la pena capire prima di considerare l’infrastruttura pronta per la produzione:

Le code non sono condivise. Ogni nodo ha la propria coda di posta locale. Se un nodo accetta un messaggio e va giù prima di consegnarlo, quel messaggio resta nella sua coda finché il nodo non torna operativo. Il VIP non sposta la posta già in coda. Per uno smarthost outbound con codifica breve è normalmente accettabile, ma monitora mailq su entrambi i nodi.

mynetworks deve includere sia Rete A sia Rete B, oltre a qualunque altra subnet client autorizzata al relay altrimenti dopo un failover i client di una delle due reti potrebbero non risultare più fidati per l’altro nodo.

Le regole firewall verso i client non cambiano mai: puntano tutte alla VIP, che è sempre lo stesso indirizzo indipendentemente da quale nodo la ospita.

Monitoraggio consigliato: stato keepalived (master/backup) su entrambi i nodi, servizio postfix attivo, lunghezza della coda (mailq -p), spazio disco, log in /var/log/mail.log.

Non allargare mai mynetworks oltre le subnet realmente fidate: è l’unica barriera che impedisce che lo smarthost diventi un open relay.

smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination rifiuta esplicitamente qualunque mittente non compreso in mynetworks.

Se alcuni client non fanno parte di una rete fidata (es. workload cloud, VPN client), valutare l’aggiunta di autenticazione SASL sulla porta submission (587) invece di allargare mynetworks.

Usare certificati TLS validi (interni o Let’s Encrypt) per cifrare la sessione SMTP tra client e smarthost.

/etc/postfix/sasl_passwd contiene la password della casella di posta in chiaro: i permessi 600 impostati al passo 4 sono il minimo indispensabile. Se lo distribuisci tra i nodi tramite un repository, non versionarlo in chiaro, usare un secret manager o uno strumento tipo Ansible Vault, e valutare la rotazione periodica della password della casella.

Questa architettura richiede che le due reti possano condividere un segmento L2 per la VIP. E’ il caso confermato per il tuo scenario. Se in futuro questo non fosse più possibile (es. le due sedi passano a un collegamento puramente L3, senza alcuna possibilità di stretch), il failover trasparente via VIP condivisa non è più applicabile e le alternative diventano più complesse: DNS con più record A e retry lato client (funziona solo se i client stessi, tipicamente altri MTA, ritentano automaticamente su un secondo indirizzo), oppure anycast via BGP se l’azienda ha il controllo del routing. Entrambe richiedono più lavoro e garanzie più deboli sui tempi di failover rispetto a VRRP: vale la pena riconsiderarle solo se la premessa sulla rete cambia.

Se gestisci un’istanza di LibreNMS su Ubuntu Server 24.04, potresti esserti imbattuto in un avviso che compare all’accesso alla dashboard: “PHP version X is the minimum supported version”.

Questo messaggio segnala che la versione di PHP in uso sul sistema non è più tra quelle supportate dal progetto LibreNMS e se ignorato a lungo comporta la perdita di aggiornamenti e patch di sicurezza.

Il problema nasce dal fatto che Ubuntu 24.04 include di default una versione di PHP che, con il tempo, viene superata dai requisiti minimi di LibreNMS, il quale segue un ciclo di aggiornamenti più rapido rispetto ai repository LTS di Ubuntu.

La soluzione richiede l’installazione di una versione più recente di PHP tramite repository di terze parti, la configurazione di un pool PHP-FPM dedicato e l’aggiornamento della configurazione del web server, passaggi che, se non eseguiti nell’ordine corretto, possono generare conflitti non banali da diagnosticare.

In questa guida vedremo passo per passo come aggiornare PHP su Ubuntu Server 24.04, configurare correttamente PHP-FPM per LibreNMS evitando le insidie più comuni (socket duplicati, pool in conflitto, timezone non allineato), e verificare che tutto funzioni a dovere con lo script di validazione integrato.

WARNING DEL PHP

Di seguito una schermata che mostra il Warning relativo al PHP

PHP Unsupported

Web server PHP version does not meet the minimum requirements. PHP 8.4 is the minimum supported version as of October, 2026.
We recommend you update PHP to a supported version (8.5 suggested) and check your CLI PHP version matches by running ./validate.php on your server.

Questo è l’avviso di LibreNMS: la versione PHP attuale non soddisfa il requisito minimo (PHP 8.4), e consiglia di passare a PHP 8.5.

VERIFICA DELLA VERSIONE ATTUALE DEL PHP

Eseguire il comando:

php -v

Dovremmo visualizzare un output simile al seguente:

PHP 8.3.33 (cli) (built: Jul 30 2026 15:39:15) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.33, Copyright (c) Zend Technologies
with Zend OPcache v8.3.33, Copyright (c), by Zend Technologies

AGGIUNGERE IL REPOSITORY SURY/ONDREJ SU NOBLE 24.04

Aggiungere il repository con i seguenti comandi:

sudo apt install -y ca-certificates apt-transport-https software-properties-common lsb-release
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update

INSTALLAZIONE DEL PHP 8.5 CON LE ESTENSIONI COMUNI PER LIBRENMS

Eseguire il comando:

sudo apt install php8.5 php8.5-cli php8.5-fpm php8.5-mysql php8.5-curl php8.5-xml php8.5-mbstring php8.5-zip php8.5-gd php8.5-snmp php8.5-json -y

NOTA BENE: alcune estensioni tipo opcache non hanno un pacchetto php8.5-opcache separato, sono già incluse nel pacchetto base

IMPOSTARE PHP 8.5 COME VERSIONE ATTIVA PER CLI

Eseguire il comando:

sudo update-alternatives --config php

Dovremmo visualizzare un output simile al seguente:

Sono disponibili 4 scelte per l'alternativa php (che fornisce /usr/bin/php).

Selezione Percorso Priorità Stato
------------------------------------------------------------
0 /usr/bin/php8.5 85 modalità automatica
1 /usr/bin/php7.4 74 modalità manuale
2 /usr/bin/php8.1 81 modalità manuale
* 3 /usr/bin/php8.3 83 modalità manuale
4 /usr/bin/php8.5 85 modalità manuale

Scegliere l’entry /usr/bin/php8.5

CONFIGURAZIONE DEL WEB SERVER PER USARE PHP-FPM 8.5

Se si utilizza Nginx, nel vhost di LibreNMS puntare al nuovo socket editando il file di configurazione con il comando:

sudo nano /etc/nginx/sites-available/librenms

Individuare la riga

fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;

E sostituirla con la seguente:

fastcgi_pass unix:/run/php/php8.5-fpm.sock;

Se si utilizza Apache con PHP-FPM aggiornare il proxy handler in modo analogo; se si utilizza mod_php, disabilitare il vecchio modulo e abilitare quello nuovo con i seguenti comandi:

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo a2enconf php8.5-fpm
sudo systemctl restart apache2

RIAVVIO DEI SERVIZI

Riavviare i servizi con i seguenti comandi:

sudo systemctl restart php8.5-fpm
sudo systemctl restart nginx # o apache2

VERIFICA CON LO SCRIPT DI LIBRENMS

Verificare con lo script di LibreNMS esrguendo i comandi:

cd /opt/librenms
sudo -u librenms ./validate.php

Se è andato tutto a buon fine dovremmo visualizzare in output simile al seguente:

===========================================
Component | Version
--------- | -------
LibreNMS | 26.9.1-dev.4+9212d2599f (2026-08-23T19:01:46+02:00)
DB Schema | 2026_07_30_162514_add_device_refresh_config_permission (397)
PHP | 8.5.4
Python | 3.14.4
Database | MariaDB 11.8.6-MariaDB-5ubuntu0.1 from Ubuntu
RRDTool | 1.9.0
SNMP | 5.9.4.pre2
===========================================

Da interfaccia web cliccando sulla rotellina in alto a destra e quindi About LibreNMS dovremmo vedere una schermata come quella sottostante

Gestire un server di posta elettronica in autonomia è da sempre una delle sfide più ostiche del self-hosting: tra Postfix, Dovecot, filtri antispam, DKIM, SPF, DMARC e certificati TLS da tenere sincronizzati, mettere in piedi un mail server “a mano” può richiedere giorni di lavoro e una manutenzione costante.

Mailu nasce proprio per abbattere questa complessità: è una suite di posta elettronica open source che impacchetta tutti i componenti necessari server SMTP (Postfix), server IMAP/POP3 (Dovecot), filtro antispam e antivirus (Rspamd), webmail (Roundcube o Rainloop) e un pannello di amministrazione via web in un set di container Docker orchestrati con Docker Compose, pronti a essere avviati con poche righe di configurazione.

In questo articolo vedremo come installare e configurare Mailu da zero su un’istanza Ubuntu Server 26.04 pulita, partendo dall’installazione di Docker Engine fino ad arrivare a un server di posta funzionante: creazione del dominio, generazione delle chiavi DKIM, gestione dei certificati TLS (Let’s Encrypt o manuali), esposizione delle porte corrette e creazione del primo utente amministratore.L’obiettivo è arrivare, passo dopo passo, ad avere un ambiente Mailu operativo e sicuro, evitando gli errori di configurazione più comuni dal binding delle porte sbagliato ai problemi di risoluzione DNS che spesso fanno perdere ore a chi affronta questo setup per la prima volta.

Non serve essere sysadmin esperti per seguire questa guida: bastano una VM (o un server fisico) con Ubuntu Server 26.04, accesso root via SSH e un po’ di pazienza con la riga di comando.

PREREQUISITI

• Un server Ubuntu Server 26.04 LTS con un utente sudo e accesso SSH.
• Un IP pubblico dedicato (non condiviso via NAT) con la porta 25 non bloccata dal provider: molti provider cloud/VPS bloccano di default il traffico SMTP in uscita sulla porta 25 — verifica con il tuo hosting o chiedi lo sblocco prima di iniziare, altrimenti la posta in uscita non funzionerà.
• RAM: almeno 1 GB (senza antivirus) o 3 GB se abiliti ClamAV (consigliato), più 1 GB di swap.
• Root partition ext4 o btrfs; opzionale una partizione dedicata montata su /mailu per lo storage della posta.
• Un nome a dominio che gestirai per la posta (es. tuodominio.it) con accesso al pannello DNS del registrar.
• Nessun altro servizio in ascolto sulle porte riservate a Mailu: 25, 80, 110, 143, 443, 465, 587, 993, 995, 4190.

NOTA BENE: Mailu richiede una versione recente di Docker installata dal repository ufficiale (non dai pacchetti Ubuntu), perché usa funzionalità Docker aggiornate.

DNS DI BASE

Prima di avviare Mailu, configura nel pannello DNS del tuo dominio:

Record A: l’hostname del server di posta che punta all’IP pubblico:

mail.tuodominio.it. IN A a.b.c.d

Record MX: indirizza la posta del dominio verso l’hostname:

tuodominio.it. IN MX 10 mail.tuodominio.it.

PTR (reverse DNS): l’IP deve risolvere all’indietro nell’hostname del mail server. Si configura lato provider/hosting, non nel DNS del dominio:

nslookup a.b.c.d → deve restituire mail.tuodominio.it

ATTENZIONE: un reverse DNS non configurato correttamente è una delle cause più comuni per cui la posta in uscita viene classificata come spam o rifiutata. Contatta il tuo provider se non puoi impostarlo da solo.

I record SPF, DKIM e DMARC li aggiungerai allo step successivo, dopo aver avviato Mailu (le chiavi DKIM vengono generate dal pannello di amministrazione).

PREPARAZIONE DEL SISTEMA

sudo apt update && sudo apt full-upgrade -y

sudo apt install -y ca-certificates curl gnupg ufw iptables-persistent

NOTA BENE: se l’aggiornamento include un nuovo kernel, riavvia con sudo reboot prima di proseguire.

INSTALLAZIONE DI DOCKER ENGINE

Aggiungere la chiave GPG e il repository Docker:

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

Installare Docker Engine e il plugin Compose con il comando:

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verificare e abilitare l’utente corrente:

sudo docker run hello-world

sudo usermod -aG docker $USER

newgrp docker

ATTENZIONE: se poco dopo il rilascio di Ubuntu 26.04 il repository Docker non ha ancora una build per il suo codename, sostituire $(. /etc/os-release && echo “$VERSION_CODENAME”) con il codename della LTS precedente supportata (es. noble) nel comando sopra.

GENERARE LA CONFIGURAZIONE CON IL SETUP WIZARD

Mailu fornisce un wizard ufficiale che genera i due file necessari (docker-compose.yml e mailu.env) in base alle tue scelte.

sudo mkdir -p /mailu

cd /mailu

Aprire sul tuo computer https://setup.mailu.io, selezionare la versione (di norma l’ultima release stabile proposta di default) e compilare il wizard indicando almeno:

Hostname del server di posta: mail.tuodominio.it

Dominio principale: tuodominio.it

Postmaster: l’utente che riceverà la posta amministrativa (es. admin)

TLS: Let’s Encrypt (consigliato per il rinnovo automatico dei certificati)

Funzionalità: webmail (Roundcube), antivirus (ClamAV, opzionale ma consigliato), antispam (Rspamd, incluso di default)

Database: SQLite va bene per installazioni piccole/singolo server

Il wizard produce due file da scaricare: docker-compose.yml e mailu.env.

Eseguire i comandi elecanti nella pagina web per scaricarli sul server

REVISIONE DI MAILU.ENV

Apri il file con un editor (nano mailu.env) e controlla in particolare la sezione “Common configuration”: HOSTNAME, DOMAIN, POSTMASTER, TLS_FLAVOR.

Le chiavi segrete (es. SECRET_KEY) vengono generate automaticamente dal wizard: non serve modificarle a mano, ma vanno mantenute private.

Se hai scelto TLS_FLAVOR=cert invece di letsencrypt, crea manualmente una cartella certs con cert.pem e key.pem; con letsencrypt il certificato viene ottenuto e rinnovato automaticamente.

AVVIO DELLO STACK

Avviare lo stack con i seguenti comandi:

cd /mailu

docker compose pull

docker compose up -d

docker compose ps

Al primo avvio Mailu scarica tutte le immagini dei servizi (postfix, dovecot, rspamd, admin, webmail, ecc.) e inizializza i volumi: può richiedere qualche minuto.

[+] pull 73/73
 Image ghcr.io/mailu/webmail:2024.06 Pulled 32.9s
 Image ghcr.io/mailu/postfix:2024.06 Pulled 29.4s
 Image ghcr.io/mailu/unbound:2024.06 Pulled 29.6s
 Image ghcr.io/mailu/dovecot:2024.06 Pulled 31.3s
 Image redis:alpine Pulled 21.7s
 Image ghcr.io/mailu/nginx:2024.06 Pulled 31.3s
 Image ghcr.io/mailu/oletools:2024.06 Pulled 29.1s
 Image ghcr.io/mailu/admin:2024.06 Pulled 30.2s
 Image ghcr.io/mailu/rspamd:2024.06 Pulled

Seguire i log per verificare che tutto parta correttamente:

docker compose logs -f admin

CREAZIONE DEL PRIMO ACCOUNT AMMINISTRATORE

Creare il primo account amministratore con il comando:

docker compose exec admin flask mailu admin me tuodominio.it 'PasswordRobusta123!'

Questo comando crea l’utente me@tuodominio.it con privilegi di amministratore.

Accedere poi da un qualsiasi browser al pannello dal link https://mail.tuodominio.it/admin.

Inserire le credenziali create in precedenza quindi cliccare Entra

ATTENZIONE: è fondamentale che esista un utente con lo stesso indirizzo email impostato in POSTMASTER in mailu.env (o un alias con quel nome), altrimenti la posta amministrativa (bounce, abuse, ecc.) non avrà una casella di destinazione.

Se è andato tutto bene dovremmo visualizzare il pannelo Admin di Mailu

AGGIUNGERE I RECORD SPF, DKIM E DMARC

Dal pannello admin andare su https://mail.tuodominio.it/admin/domain/details/tuodominio.it

Cliccare su Generare Chiavi per ottenere i valori DKIM specifici del tuo dominio

Cliccare Conferma

La pagina mostra i record esatti da copiare. In generale avrai bisogno di:

SPF (record TXT sul dominio): autorizza l’IP del server a inviare posta per conto del dominio.

DKIM (record TXT su un sottodominio tipo dkim._domainkey.tuodominio.it): la chiave pubblica generata dal pannello.

DMARC (record TXT su _dmarc.tuodominio.it): policy di gestione della posta che fallisce SPF/DKIM.

Copiare i valori esatti mostrati dal pannello (cambiano da installazione a installazione) nel DNS del dominio.

NOTA BENE: se abiliti SPF/DKIM/DMARC senza aggiungere questi record nel DNS, la tua posta rischia di non essere consegnata: i due passaggi vanno sempre fatti insieme.

CONFIGURAZIONE DEL FIREWALL

Eseguire i comandi:

sudo ufw allow OpenSSH
sudo ufw allow 25/tcp # SMTP
sudo ufw allow 465/tcp # SMTPS
sudo ufw allow 587/tcp # Submission
sudo ufw allow 143/tcp # IMAP
sudo ufw allow 993/tcp # IMAPS
sudo ufw allow 110/tcp # POP3 (se abilitato)
sudo ufw allow 995/tcp # POP3S (se abilitato)
sudo ufw allow 4190/tcp # ManageSieve (se abilitato)
sudo ufw allow 80/tcp # HTTP (validazione Let's Encrypt)
sudo ufw allow 443/tcp # HTTPS (webmail, admin)
sudo ufw enable
sudo ufw status

MANUTENZIONE E COMANDI UTILI

Stato dei container: docker compose ps

Log di un servizio: docker compose logs -f admin (o smtp, imap, rspamd, ecc.)

Riavviare un servizio: docker compose restart admin

Aggiornare Mailu: docker compose pull && docker compose up -d

Fermare lo stack (dati conservati): docker compose down

Creare un altro utente: docker compose exec admin flask mailu user nome dominio.it ‘Password’

Backup: i dati (caselle, chiavi DKIM, configurazione) risiedono nei volumi Docker montati in /mailu; un backup periodico della cartella /mailu (con lo stack fermo, o con uno strumento che gestisca i file aperti) copre database SQLite, posta e certificati.

Risoluzione problemi: se la posta in uscita non parte, il sospetto numero uno è la porta 25 bloccata dal provider (vedi step 1). Se i client di posta non si connettono, verifica che nessun altro servizio (es. un vecchio Postfix locale) occupi le porte richieste da Mailu prima dell’avvio dello stack.

PRO E CONTRO

Ecco un elenco pro/contro di Mailu, pensato per stare bene dentro l’articolo:

Pro

• Stack completo pronto all’uso: Postfix, Dovecot, Rspamd, webmail e pannello admin arrivano già integrati e configurati per parlarsi tra loro, senza dover cablare a mano ogni componente.
• Gestione via Docker Compose: aggiornamenti, backup e rollback dei singoli servizi sono più semplici rispetto a un’installazione tradizionale su pacchetti di sistema.
• Pannello di amministrazione web intuitivo per gestire domini, utenti, alias, DKIM e regole antispam senza toccare file di configurazione per le operazioni quotidiane.
• Supporto nativo a Let’s Encrypt e a scenari con reverse proxy esterno (i vari TLS_FLAVOR), quindi si adatta sia a installazioni esposte direttamente sia dietro un proxy già esistente.
• Multi-dominio e multi-utente di serie, utile per chi gestisce la posta di più organizzazioni o clienti dalla stessa istanza.
• Progetto open source attivo, con documentazione e community su GitHub che rispondono abbastanza rapidamente ai problemi comuni.

Contro

• Overhead di risorse: una decina di container sempre attivi (come hai visto nel tuo docker compose ps) pesano di più, in RAM e gestione, di un classico Postfix+Dovecot installato via apt.
• Configurazione “a doppio binario”: alcune impostazioni vivono nel file .env/mailu.env, altre finiscono scritte direttamente nel docker-compose.yml (come il binding delle porte che abbiamo dovuto correggere) — un po’ di attenzione va messa per non perdere modifiche tra un aggiornamento e l’altro.
• La deliverability della posta in uscita resta comunque un problema “tuo”: IP reputation, PTR record, SPF/DKIM/DMARC e blacklist vanno curati indipendentemente dal software, e i grandi provider (Gmail, Outlook) sono sempre più severi con la posta da IP self-hosted.
• Nessun clustering/alta disponibilità nativo: per scalare o avere ridondanza serve mettere mano tu all’infrastruttura attorno a Mailu.
• Esporre direttamente le porte di posta (25, 587, 465, 993, 995) su internet richiede attenzione a firewall e hardening, specie su una VM di test come quella usata in questa guida.
• Il troubleshooting a basso livello (binding delle porte, permessi dei volumi, variabili d’ambiente) richiede comunque familiarità con Docker: non è un prodotto completamente “point and click” per chi non mastica la riga di comando.