Meridian ARC ITSM: il Service Desk completo e cosa aggiunge la Enterprise Edition

Quando si parla di software ITSM (IT Service Management) la domanda ricorrente è sempre la stessa: cosa mi danno davvero gratis, e per cosa devo pagare?. Con la maggior parte dei prodotti la risposta è frustrante — la versione gratuita è una demo mutilata, pensata per farti sentire stretto entro la prima settimana.

Meridian ARC ribalta questo schema. La sua Community Edition è un Service Desk ITIL completo e pronto alla produzione: la Enterprise non sblocca le funzioni base aggiunge le funzioni che servono a chi del servizio IT fa il proprio business. In questo articolo vediamo tutte le funzionalità del modulo ITSM (il Desk) e, soprattutto, dove finisce la Community e dove inizia la Enterprise — con un occhio a come funziona concretamente la licenza EE.

Questo articolo è dedicato al solo modulo ITSM / Service Desk. Le aree Orbit (governance e contratti) e CRM interno hanno un articolo a parte.

Dashboard del Service Desk di Meridian ARC: ticket aperti, SLA, KPI in tempo reale, asset CMDB e ultimi incident

La base: un ciclo ITIL completo, già nella Community

Partiamo da un punto fermo, perché è il vero elemento differenziante. La Community Edition di Meridian ARC non è una versione di prova: copre l’intero ciclo di vita di un ticket secondo le pratiche ITIL, ed è pensata per girare in produzione, on-premise o in cloud privato, sui tuoi server.

Ecco cosa include — tutto gratuito e self-hosted.

Gestione ticket end-to-end

Il cuore del sistema. Cinque tipi di ticket nativi, ciascuno con il proprio flusso:

• Incident — gestione interruzioni e malfunzionamenti
• Problem — analisi delle cause (RCA con metodi *5 Whys* e *Ishikawa*), workaround, registrazione del *known error* e post-review.
• Change Request — con tipi (standard, normale, emergency, pre-autorizzato), finestra di deployment, test plan, piano di rollback e **workflow di approvazione** (interno, cliente o entrambi, anche tramite link pubblico per il cliente).
• Service Request — richieste di servizio.
• Security Incident — tipologia dedicata agli incidenti di sicurezza.

Gli stati del ticket sono strutturati (nuovo → preso in carico → in lavorazione → risolto → chiuso, più stati di attesa) e alcuni di essi sospendono automaticamente il contatore SLA.

Dettaglio di un ticket Incident con stato, priorità, badge SLA e cronologia

Change Management: stato di approvazione, finestra di deployment e calendario dei change

Code, priorità e categorie

• Code di supporto con SPOC (single point of contact), coda di default ed email di gruppo.
• Livelli di priorità personalizzabili per cliente (nome, colore, ordine).
• Categorie per tipo di ticket, con regole di approvazione configurabili.
• Orari di lavoro (business hours) per coda, con fuso orario — base di calcolo per gli SLA.

SLA inclusi

Configurazione delle metriche di servizio — *prima risposta*, *presa in carico*, *risoluzione* — per priorità, coda e tipo di ticket. Gli stati di attesa mettono in pausa il conteggio, così non vieni penalizzato per tempi che non dipendono da te.

Contratto & SLA del cliente: copertura, RPO/RTO, retention e livelli di priorità

CMDB e gestione asset

Un CMDB vero, non un elenco statico: Configuration Item per cliente, con numero auto-generato, hostname, IP/MAC, seriale, produttore, modello, date di acquisto, scadenza garanzia e fine vita. Le relazioni tra CI permettono di mappare le dipendenze, e l’anagrafica licenze software con alert di scadenza completa il quadro.

CMDB: l’inventario dei Configuration Item del cliente

Service Catalog, Knowledge Base e Task Flows

• Service Catalog con form dinamici: il cliente compila e la richiesta diventa un ticket.
• Knowledge Base con articoli pubblici e interni, versionamento e template; collegando un articolo a un ticket Problem si costruisce il KEDB (Known Error Database).
• Task Flows: una richiesta dal catalogo può generare più task ordinati, ciascuno assegnato a una coda diversa — flussi multi-stage anche paralleli.

Service Catalog: le voci di servizio con form dinamici

Automazioni, email e portale

• Motore di automazione** config-driven: trigger (ticket creato, cambio stato, assegnazione, commento, SLA violato), condizioni e azioni (imposta priorità, assegna, trasferisci coda, aggiungi commento). In Community è incluso con un tetto di **3 regole**.
• Email-to-Ticket (Mailgun/SMTP) con processamento inbound via webhook.
• Portale self-service per il cliente: apertura ticket, commenti, consultazione di KB e catalogo.
• CSAT: survey di soddisfazione dopo la risoluzione.
• RBAC, LDAP/Active Directory e SSO (OAuth 2.0) per autenticazione e controllo accessi.
• Allegati con scansione antivirus (ClamAV) ed email templates personalizzabili.

Knowledge Base: articoli pubblici e interni, pubblicabili nel portale self-service del cliente

Editor di una regola di automazione: trigger, condizioni e azioni

In sintesi: con la Community gestisci clienti reali, SLA, asset e tutto il ciclo operativo. Non è una demo

Cosa aggiunge la Enterprise Edition

La Enterprise entra in gioco quando il servizio diventa il business: gestisci SLA contrattuali con penali, vuoi misurare la marginalità di commessa e devi integrare l’ITSM con il resto dei tuoi sistemi. Ecco cosa si attiva.

Operazioni sotto pressione

• Major Incident con War Room — dichiarazione di incidente grave con *incident commander*, *communications officer*, collaborazione in war room e postmortem strutturato. Quando un disservizio diventa una crisi, hai un protocollo, non l’improvvisazione.
• OLA e gestione avanzata degli SLA — Operational Level Agreement con tracciamento degli handoff inter-team e target in minuti lavorativi; pause SLA legate ai contratti.
• Skill routing & supervisor — assegnazione basata sulle competenze degli agenti (con livello 1–5) e vista supervisore con la disponibilità del team.

Dashboard KPI & Performance: il polso operativo del servizio in tempo reale

Supervisor view: carico di lavoro in tempo reale e routing per competenze del team

Margine e controllo

• Costing & marginalità — figure professionali con costo giornaliero/orario; il tempo registrato sui ticket si trasforma in **costo e margine per cliente, in tempo reale**. Non a fine anno.
• Reporting esteso (tier Professional) — filtri salvati per entità, export massivo e *time tracking*.
• Forecasting — analisi di trend.

Marginalità di commessa: valore venduto, costo consuntivo e margine per cliente

Integrazioni e automazione (add-on *Integrations & API*)

• REST API versionata con Personal Access Token (abilities selettive: lettura/scrittura ticket, lettura CMDB e BI), rate limit per tier.
• Webhook in/out firmati HMAC-SHA256.
• Notifiche Slack/Teams, import asset massivo da CSV/JSON.
• Automazione avanzata (regole illimitate e logiche più ricche rispetto alle 3 della Community).

BI & Analytics (add-on)

Feed BI read-only per Power BI/Tableau, export avanzato (PDF/Excel formattati) e dashboard estese.

Omnichannel (add-on)

Chatbot sul portale per ricerca in KB e apertura ticket.

Workforce & Signature (add-on) + Firma massiva

• Firma digitale (FEA) con OTP, conservazione a 10 anni e crypto-shredding (cancellazione della chiave su richiesta GDPR).
• Magazzino cespiti — beni serializzati e consumabili, movimenti append-only.
• Assegnazione materiale al dipendente con ricevuta firmabile.
• Firma documenti massiva — lo stesso documento a più firmatari, con tracking dello stato (questa funzione è di tier Enterprise).

Nota: firma digitale, magazzino e assegnazioni sono disponibili dal tier Professional (con l’add-on Workforce & Signature); Major Incident, costing, skill routing, OLA e firma massiva sono Enterprise. Lo strumento di firma vive principalmente nella console interna, di cui parlo nell’articolo dedicato a Orbit + CRM.

Firma documenti massiva: campagne di firma dello stesso documento a più destinatari, con tracking dello stato

Community vs Enterprise: il confronto

| Funzionalità | Community | Enterprise |
|—|:—:|:—:|
| Incident / Problem / Change (con approvazione) | | |
| Service Request / Security Incident | | |
| Code, SPOC, priorità, categorie | | |
| SLA base + pause | | |
| CMDB + relazioni CI + licenze software | | |
| Service Catalog + form dinamici | | |
| Knowledge Base + KEDB | | |
| Task Flows | | |
| Automazioni | (max 3 regole) | (illimitate + avanzate) |
| Email-to-Ticket, Portale, CSAT, RBAC, LDAP/SSO | | |
| Major Incident / War Room | — | |
| OLA e SLA avanzati | — | |
| Skill routing & supervisor | — | |
| Costing & marginalità di commessa | — | |
| Reporting esteso + time tracking | — | (da Professional) |
| Forecasting | — | |
| REST API + token, webhook in/out | — | (add-on) |
| Slack/Teams, feed BI, import asset, chatbot | — | (add-on) |
| Firma digitale (FEA), magazzino, assegnazioni | — | (da Professional, add-on) |
| Firma documenti massiva | — | |

Limiti operativi per edizione

| Limite | Community | Professional | Enterprise |
|—|:—:|:—:|:—:|
| Agenti (seat) | 20 | illimitato | illimitato |
| Clienti gestiti | 3 | illimitato | illimitato |
| Regole di automazione | 3 | illimitato | illimitato |
| Retention audit | 90 giorni | 365 giorni | 36 mesi |
| Storage allegati | 5 GB | 10 GB/agente | 25 GB/agente |
| Rate limit API | nessuna API | 120 req/min | 600 req/min |

Come funziona la licenza Enterprise

Questa è la parte che rende Meridian ARC diverso da un classico SaaS — e che lo rende adatto ad ambienti regolati (bancario, sanitario, PA).

1. È lo stesso codice, ma immagini diverse.
Community ed Enterprise condividono lo stesso prodotto, ma la Community **non contiene affatto** il codice delle funzioni Enterprise: non è una versione depotenziata via flag, è proprio un’immagine Docker diversa. Le variabili d’ambiente, da sole, non bastano a sbloccare nulla.

2. La licenza è una chiave firmata, verificata offline.
L’attivazione avviene con una chiave **Ed25519** validata localmente: l’istanza **non deve “chiamare casa”**. Funziona in ambienti air-gapped, senza dipendere da un server di attivazione. Nessun lock-in.

3. Professional ed Enterprise sono due tier dello stesso impianto.
La *license key* determina quali feature e add-on sono attivi. La Professional copre il passo intermedio; l’Enterprise sblocca tutto. Non c’è un prodotto nuovo da imparare.

4. L’upgrade non richiede reinstallazione.
Si parte dalla Community, poi si punta alle immagini Enterprise e si applica la licenza da **Admin → Licenza & Edizione**. OAuth, configurazione .env e dati restano identici: nessuna migrazione, nessun fermo del servizio.

Attivazione in 3 passi

1. Parliamone — esigenze, clienti gestiti, volumi e integrazioni. Si valuta insieme il tier giusto.
2. Accesso e licenza — un token di sola lettura al registry privato delle immagini + il file azienda.license.key firmato.
3. Attivazione — un docker login al registry, si puntano le immagini Enterprise nello stesso stack e si applica la licenza dal pannello Admin.

Admin → Licenza & Edizione: stato della licenza e feature attive

In conclusione

La forza del modello di Meridian ARC sta in una promessa rispettata: la Community è davvero completa. Puoi gestire un help desk ITIL serio, con clienti, SLA, CMDB e automazioni, senza spendere un euro e senza che i tuoi dati lascino i tuoi server.

La Enterprise non ti vende ciò che dovrebbe essere gratis: ti vende ciò che serve quando il servizio cresce — gestione delle crisi, marginalità misurabile, integrazioni e firma digitale. E lo fa con un modello di licenza pulito, offline, senza lock-in.

Se gestisci servizi IT per più clienti e ti riconosci in almeno uno di questi tre segnali — eroghi SLA contrattuali con penali, vuoi conoscere il margine di commessa, devi integrare l’ITSM con altri sistemi — è il momento di guardare alla Enterprise.

Trovi tutti i dettagli, la guida di installazione della Community e le condizioni Enterprise su meridian-arc.io

Odoo è una delle piattaforme ERP open source più complete e diffuse al mondo.

Grazie alla sua architettura modulare permette di gestire in un’unica soluzione processi aziendali come vendite, acquisti, magazzino, contabilità, CRM, risorse umane e molto altro adattandosi sia a piccole realtà che a strutture più complesse.

In questa guida vedremo come installare e configurare Odoo 18 Community Edition su Ubuntu Server 26.04 LTS “Resolute Raccoon”, la distribuzione più recente di Canonical con supporto a lungo termine.

Si tratta di una combinazione particolarmente interessante per chi vuole costruire un ambiente di produzione stabile e aggiornato sfruttando Python 3.14 e PostgreSQL 18 già inclusi nel sistema operativo.

Seguiremo un approccio from source clonando il codice direttamente dal repository ufficiale GitHub di Odoo e installando le dipendenze Python all’interno di un ambiente virtuale isolato.

Questo metodo offre il massimo controllo sulla versione installata semplifica gli aggiornamenti futuri e consente di aggiungere moduli personalizzati senza interferire con il sistema operativo sottostante.

Al termine della guida avrai un’istanza di Odoo funzionante gestita come servizio systemd pronta per essere raggiunta dal browser e configurata secondo le esigenze del tuo progetto.

PREREQUISITI

Ubuntu Server 26.04 con almeno 2 GB di RAM
Accesso SSH con utente dotato di privilegi sudo

AGGIORNAMENTO DEL SISTEMA

Connettiti al server via SSH e verifica la versione e aggiorna i pacchetti:

lsb_release -a

Dovremmo visualizzare il seguente output:

Distributor ID: Ubuntu
Description: Ubuntu 26.04 LTS
Release: 26.04
Codename: resolute

Aggiornare i pacchetti con il comando:

sudo apt update && sudo apt upgrade -y

CREAZIONE DELL’UTENTE DI SISTEMA

Non eseguire mai Odoo come root. Creare un utente di sistema dedicato con il comando:

sudo /usr/sbin/adduser \
--system \
--shell /bin/bash \
--gecos 'Odoo user' \
--group \
--home /opt/odoo18 \
odoo18

INSTALLAZIONE DELLE DIPENDENZE

Ubuntu 26.04 include Python 3.13 di default compatibile con Odoo 18 che richiede almeno Python 3.10.

Installare tutte le librerie necessarie con il comando:

sudo apt install -y build-essential wget git \
python3-pip python3-dev python3-venv python3-wheel \
libfreetype6-dev libxml2-dev libzip-dev libsasl2-dev \
python3-setuptools libjpeg-dev zlib1g-dev libpq-dev \
libxslt1-dev libldap2-dev libtiff5-dev libopenjp2-7-dev \
nodejs npm

INSTALLAZIONE DI POSTGRESQL

PostgreSQL è il solo database engine supportato da Odoo per la gestione dei dati.

Odoo 18 richiede almeno PostgreSQL 12 e Ubuntu 26.04 include PostgreSQL 18 nei suoi repository.

Eseguire i comandi elencati di seguito:

sudo apt install -y postgresql

Verificare che il servizio sia attivo con il comando:

sudo systemctl status postgresql

Dovremmo visualizzare il seguente output:

postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; prese>
Active: active (exited) since Fri 2026-05-15 18:59:24 UTC; 7s ago
Invocation: 514460320a2e43829b3f254d590ed50d
Main PID: 10157 (code=exited, status=0/SUCCESS)
Mem peak: 2M
CPU: 4ms

Quindi abilitare il servizio con il comando:

sudo systemctl enable postgresql

Creare l’utente PostgreSQL per Odoo con il comando:

sudo su - postgres -c "createuser -s odoo18"

INSTALLAZIONE DI WKHTMLTOPDF

Odoo utilizza wkhtmltopdf per generare report in PDF. È necessaria la versione con patched Qt.

Posizionarsi nella cartella tmp con il comando:

cd /tmp

Quindi scaricare wkhtmltopdf con il comando:

wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-2/wkhtmltox_0.12.6.1-2.jammy_amd64.deb

Installare wkhtmltopdf con il comando:

sudo apt install -y ./wkhtmltox_0.12.6.1-2.jammy_amd64.deb

Verificare l’installazione con il comando:

wkhtmltopdf --version

Dovremmo visualizzare il seguente output:

wkhtmltopdf 0.12.6.1 (with patched qt)

DOWNLOAD E INSTALLAZIONE DI ODOO

Passare all’utente odoo18 e clonare il sorgente da GitHub con i seguenti comandi:

sudo su - odoo18

git clone https://www.github.com/odoo/odoo --depth 1 --branch 18.0 odoo18

Creare e attivare un ambiente virtuale Python con i seguenti comandi:

python3 -m venv --system-site-packages odoo18-venv

source odoo18-venv/bin/activate

Installare le dipendenze Python di Odoo con i comandi:

pip3 install wheel

pip3 install -r odoo18/requirements.txt

Verificare che lxml sia disponibile (l’errore di build è ignorabile)

python3 -c "import lxml; print(lxml.__version__)"

Dovremmo visualizzare il seguente output:

6.0.2

CHECK E FIX LXML

Se il pip si interrompe quando lxml fallisce non installa i pacchetti successivi.

La soluzione è installare tutto escludendo lxml dal requirements.txt

Creare un requirements filtrato senza lxml con il comando:

grep -v "^lxml" odoo18/requirements.txt > /tmp/requirements_no_lxml.txt

Installare tutto tranne lxml con il comando:

pip3 install -r /tmp/requirements_no_lxml.txt

Installare il pacchetto lxml_html_clean con il comando:

pip3 install lxml-html-clean

Verificare che sia tutto OK con il comando:

python3 -c "import pytz, werkzeug, psycopg2, PIL; print('OK')"

Disattivare l’ambiente virtuale e creare la cartella per i moduli custom con i comandi:

deactivate

mkdir /opt/odoo18/odoo18/custom-addons

exit

FILE DI CONFIGURAZIONE

Creare il file di configurazione principale con il comando:

sudo nano /etc/odoo18.conf

Incollare il seguente contenuto (sostituisci la master password!):

[options]
admin_passwd = CambiaMiConPasswordSicura!
db_host = False
db_port = False
db_user = odoo18
db_password = False
addons_path = /opt/odoo18/odoo18/addons,/opt/odoo18/odoo18/custom-addons
logfile = /var/log/odoo18/odoo18.log
http_port = 8069

Creare la cartella per i log e impostare i permessi con i seguenti comandi:

sudo mkdir /var/log/odoo18

sudo chown odoo18:odoo18 /var/log/odoo18

sudo chmod 640 /etc/odoo18.conf

sudo chown odoo18:root /etc/odoo18.conf

Salvare e chiudere il file di configurazione.

CREAZIONE DEL SYSTEMD

Creare l’unit file per gestire Odoo come servizio con il comando:

sudo nano /etc/systemd/system/odoo18.service

Incollare il seguente output:

[Unit]
Description=Odoo 18 Community Edition
Requires=postgresql.service
After=network.target postgresql.service

[Service]
Type=simple
SyslogIdentifier=odoo18
PermissionsStartOnly=true
User=odoo18
Group=odoo18
ExecStart=/opt/odoo18/odoo18-venv/bin/python3 /opt/odoo18/odoo18/odoo-bin -c /etc/odoo18.conf
StandardOutput=journal+console

[Install]
WantedBy=multi-user.target

Salvare chiudere il file di configurazione.

Abilitare e avviare il servizio con i seguenti comandi:

sudo systemctl daemon-reload

sudo systemctl enable --now odoo18

sudo systemctl status odoo18

Se è tutto OK dovremmo visualizzare il seguente output:

● odoo18.service
Loaded: loaded (/etc/systemd/system/odoo18.service; enabled; preset: enabl>
Active: active (running) since Fri 2026-05-15 19:30:41 UTC; 19ms ago
Invocation: 89df5e70c325462586d852df85cfbed0
Main PID: 22114 (python3)
Tasks: 1 (limit: 6210)
Memory: 3.3M (peak: 3.3M)
CPU: 15ms
CGroup: /system.slice/odoo18.service
└─22114 /opt/odoo18/odoo18-venv/bin/python3 /opt/odoo18/odoo18/odo>

May 15 19:30:41 vm-srv-test systemd[1]: Started odoo18.service.

CONFIGURAZIONE DEL FIREWALL

Se usi UFW aprire la porta 8069 con il comando:

sudo ufw allow 8069/tcp

sudo ufw reload

ACCESSO DA WEBGUI

Accedi a Odoo dal browser richiamando il link:

http://IP_DEL_SERVER:8069

Al primo accesso ti verrà mostrata la pagina di creazione database.

Inserisci la master password definita nel file di configurazione.

Scegliere un nome per il database e creare il tuo primo admin.

Cliccare su Create Database

Accedere con le credenziali create nel passaggio precedente

Se abbiamo fatto tutto correttente dovremmo accedere al backend di Odoo

CONFIGURAZIONE DEL REVERSE PROXY CON NGINX

Per un ambiente di produzione è consigliato mettere Nginx davanti a Odoo con SSL:

sudo apt install -y nginx

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

Quindi incollare il seguente output:

nginxupstream odoo {
server 127.0.0.1:8069;
}

server {
listen 80;
server_name tuodominio.it;

access_log /var/log/nginx/odoo18.access.log;
error_log /var/log/nginx/odoo18.error.log;

proxy_read_timeout 720s;
proxy_connect_timeout 720s;
proxy_send_timeout 720s;

location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_redirect off;
proxy_pass http://odoo;
}

location ~* /web/static/ {
proxy_cache_valid 200 90m;
proxy_buffering on;
expires 864000;
proxy_pass http://odoo;
}
}

Salvare e chiudere il file di configurazione.

Attivare il sito e ricaricare Nginx con il comando:

sudo ln -s /etc/nginx/sites-available/odoo18 /etc/nginx/sites-enabled/

sudo nginx -t

sudo systemctl reload nginx

Aggiungi poi proxy_mode = True al file /etc/odoo18.conf e riavviare il servizio.

COMANDI UTILI

Comandi utili per la gestione quotidiana:

sudo systemctl restart odoo18 # riavvio

sudo systemctl stop odoo18 # stop

journalctl -u odoo18 -f # log in tempo reale

tail -f /var/log/odoo18/odoo18.log # log applicativo

COMMUNITY VS ENTERPRISE: COSA CAMBIA?

Odoo è disponibile in due versioni:

Community: completamente gratuita e open source rilasciata sotto licenza LGPL-3

Enterprise: a pagamento con licenza proprietaria.

La versione Community include tutti i moduli fondamentali per la gestione aziendale: vendite, acquisti, magazzino, fatturazione base, CRM, progetto, inventario e molto altro ed è più che sufficiente per la maggior parte delle piccole e medie imprese.

Il codice sorgente è pubblico e liberamente modificabile e distribuibile.

La versione Enterprise aggiunge funzionalità avanzate su tre fronti principali:

Moduli esclusivi: tra cui la contabilità completa con riconciliazione bancaria automatica, il modulo per la firma elettronica dei documenti, VoIP integrato, eLearning, marketing automation avanzato e la gestione della qualità e manutenzione in ambito manifatturiero.

Interfaccia e usabilità: Enterprise include una UI più rifinita, l’app mobile nativa per iOS e Android (la Community è accessibile solo via browser), e una dashboard di reportistica più avanzata con Spreadsheet integrato.

Supporto e aggiornamenti: con la licenza Enterprise si ha accesso al supporto ufficiale Odoo, agli aggiornamenti automatici gestiti tramite Odoo.sh (la piattaforma cloud proprietaria) e alla migrazione assistita tra versioni maggiori.

Il costo della licenza Enterprise si basa sul numero di utenti e parte da circa €24,90 per utente al mese (prezzo indicativo 2025, può variare per area geografica e partner).

Vale la pena sottolineare che le due versioni condividono lo stesso core infatti un’installazione Community può essere migrata a Enterprise semplicemente aggiungendo la licenza e i moduli aggiuntivi, senza dover reinstallare nulla.

QUANDO SCEGLIERE LA VERSIONE COMMUNITY E QUANDO LA VERSIONE ENTERPRISE?

La scelta tra le due edizioni dipende principalmente dalle dimensioni dell’azienda, dai processi da gestire e dal budget disponibile.

Scegli Community se:

• sei una piccola o media impresa con processi aziendali standard e non troppo complessi
• hai a disposizione un tecnico interno o un partner in grado di installare, configurare e manutenere il sistema autonomamente
• vuoi valutare Odoo prima di impegnarti economicamente, magari con l’intenzione di migrare a Enterprise in futuro
• la contabilità avanzata non è un requisito prioritario e puoi gestire le fatture con moduli di terze parti o integrazioni esterne
• hai bisogno di personalizzazioni profonde sul codice sorgente, possibili senza restrizioni solo nella versione open source

Scegli Enterprise se:

• hai un reparto contabile strutturato che necessita di riconciliazione bancaria automatica, localizzazione fiscale certificata e report avanzati
• i tuoi utenti lavorano spesso da dispositivi mobili e hanno bisogno dell’app nativa iOS/Android
• vuoi affidarti al supporto ufficiale Odoo per la risoluzione dei problemi e gli aggiornamenti di versione
• stai valutando un deployment su Odoo.sh, la piattaforma cloud gestita direttamente da Odoo S.A.
• operi in settori specifici come la produzione, dove i moduli di qualità, manutenzione e PLM di Enterprise fanno la differenza

Una via di mezzo praticabile è partire con la Community per i primi mesi e verificare quali funzionalità mancano nel flusso di lavoro reale, e poi valutare il passaggio a Enterprise solo se strettamente necessario.

Trattandosi della stessa base di codice, la migrazione è sempre possibile senza perdita di dati.

Nel panorama della sicurezza informatica moderna, il modello tradizionale basato sul perimetro di rete quello del “dentro si fida, fuori non si fida” ha mostrato tutti i suoi limiti.

Ambienti ibridi lavoro remoto microservizi distribuiti su cloud multipli: il perimetro, semplicemente, non esiste più.

È in questo contesto che nasce il paradigma Zero Trust il cui principio fondamentale è tanto semplice quanto radicale: non fidarsi mai di nessuno per default, verificare sempre tutto.

OpenZiti è una piattaforma open source che porta questo modello dalla teoria alla pratica.

Ogni connessione viene autenticata con un’identità crittografica, ogni accesso è autorizzato da policy esplicite, il traffico è cifrato end-to-end e i servizi restano completamente invisibili a chiunque non sia autorizzato nessuna porta aperta, nessuna superficie di attacco esposta.

Il tutto senza richiedere modifiche al codice delle applicazioni esistenti.

In questa guida vedremo come installare e configurare OpenZiti su Ubuntu Server 26.04 costruendo da zero un overlay network zero trust con Controller, Edge Router e console di amministrazione web.

Che tu voglia proteggere un homelab, esporre servizi interni senza aprire porte sul firewall o semplicemente capire come funziona una rete zero trust nella pratica, questa è la guida da cui partire.

Di seguito uno schema che spiega il funzionamento di OpenZiti

PREREQUISITI

Ubuntu 26.04 LTS (fresh install)
Utente con privilegi sudo
FQDN servertest.lab.prv risolvibile via DNS o /etc/hosts su tutti i client
Porte aperte sul firewall (vedi sezione dedicata)

Controller — il cervello della rete: gestisce identità, policy e certificati
Edge Router — il piano dati che instrada il traffico cifrato
ZAC (Ziti Admin Console) — interfaccia web di amministrazione

Porte richieste:

FASE 1 – PREPARAZIONE DEL SISTEMA

Aggiornare il sistema con il comando:

sudo apt update && sudo apt upgrade -y

Installare le dipendenze di base con il comando:

sudo apt install -y curl wget gnupg2 apt-transport-https ca-certificates

Verifica che l’FQDN sia corretto con il comando:

hostname -f

Dovremmo visualizzare il seguente output:

servertest.lab.prv

Se necessario impostare l’FQDN con il comando:

sudo hostnamectl set-hostname servertest.lab.prv

Assicurarsi che /etc/hosts contenga la riga corretta:

sudo nano /etc/hosts

Aggiungere (sostituire con l’IP reale del server):

192.168.X.X servertest.lab.prv servertest

FASE 2 – AGGIUNTA DEL REPOSITORY OPENZITI

Questi comandi configurano il repository APT ufficiale di OpenZiti.

Scaricare e installare la chiave GPG del repository con il comando:

curl -sSLf https://get.openziti.io/tun/package-repos.gpg \
| sudo gpg --dearmor --output /usr/share/keyrings/openziti.gpg

Rendere la chiave leggibile da tutti gli utenti con il comando:

sudo chmod a+r /usr/share/keyrings/openziti.gpg

Creare il file di repository APT con il comando:

sudo tee /etc/apt/sources.list.d/openziti-release.list >/dev/null <<EOF
deb [signed-by=/usr/share/keyrings/openziti.gpg] https://packages.openziti.org/zitipax-openziti-deb-stable debian main
EOF

Aggiornare la lista dei pacchetti con il comando:

sudo apt update

NOTA BENE: OpenZiti usa debian come label del repository anche per Ubuntu — è corretto così.

FASE 3 – INSTALLAZIONE E CONFIGURAZIONE DEL CONTROLLER

3.1 INSTALLAZIONE DEL PACCHETTO

Eseguire il comando:

sudo apt install -y openziti-controller

Il pacchetto installa anche la CLI ziti come dipendenza.

3.2 AVVIARE IL BOOTSTRAP DEL CONTROLLER

Il bootstrap crea automaticamente: PKI, certificati, config file e database.

sudo /opt/openziti/etc/controller/bootstrap.bash

Lo script pone alcune domande interattive. Rispondere come indicato nella tabella sottostante:

Al termine dell’installazione dovremmo vedere il seguente output:

bootstrap completed successfully and will not run again. Adjust /var/lib/private/ziti-controller/config.yml to suit.

Al termine abilitare il controller con il comando:

sudo systemctl enable --now ziti-controller

IMPORTANTE: Salvare la password admin mostrata a fine bootstrap, ti servirà per accedere!

3.3 VERIFICARE LO STATO DEL CONTROLLER

Controllare che il servizio sia attivo con il comando:

sudo systemctl status ziti-controller

Se è tutto OK dovremmo visualizzare il seguente output:

● ziti-controller.service - OpenZiti Controller
Loaded: loaded (/usr/lib/systemd/system/ziti-controller.service; enabled; >
Drop-In: /etc/systemd/system/ziti-controller.service.d
└─override.conf
Active: active (running) since Sat 2026-05-16 18:59:45 UTC; 30s ago
Invocation: d39fb50a519e44ef9f761f6d5db446e1
Process: 3028 ExecStartPre=/opt/openziti/etc/controller/entrypoint.bash che>
Main PID: 3054 (ziti)
Tasks: 7 (limit: 6210)
Memory: 64.6M (peak: 64.7M)
CPU: 922ms
CGroup: /system.slice/ziti-controller.service
└─3054 /opt/openziti/bin/ziti controller run config.yml --

May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/zit>
May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/zit>
May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/zit>
May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/zit>
May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/zit>
May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/zit>
May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/cha>
May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/zit>
May 16 18:59:46 servertest.lab.prv ziti[3054]: {"file":"github.com/openziti/xwe>
lines 1-23

Verificare i log con il comando:

sudo journalctl -u ziti-controller -f

FASE 4 – INSTALLAZIONE E CONFIGURAZIONE DELL’EDGE ROUTER

4.1 INSTALLAZIONE DEL PACCHETTO

Eseguire il comando:

sudo apt install -y openziti-router

4.2 CREARE IL ROUTER NEL CONTROLLER TRAMITE CLI

Prima fai login con la CLI ziti:

Login al controller (usa la password salvata nel passo 3.2)

ziti edge login servertest.lab.prv:1280 \
--username admin \
--password PASSWORD \
--yes

Dovremmo visualizzare il seguente output:

Untrusted certificate authority retrieved from server
Verified that server supplied certificates are trusted by server
Server supplied 2 certificates
Server certificate chain written to /home/rchiatto/.config/ziti/certs/servertest.lab.prv
Token: af50d889-9308-49fb-a1e3-6c16d388f7a5
Saving identity 'default' to /home/rchiatto/.config/ziti/ziti-cli.json

ATTENZIONE: copiare il TOKEN perchè ci verrà chiesto più avanti

Ora creare il router (ottieni il token JWT di enrollment):

Creare l’edge router

ziti edge create edge-router "servertest-router" \
--role-attributes public \
--tunneler-enabled \
--jwt-output-file /tmp/router.jwt

Dovremmo visualizzare il seguente output:

New edge router servertest-router created with id: mKAQ7adB2Q
Enrollment expires at 2026-05-16T22:03:55.226Z

Verificare che il file JWT sia stato creato con il comando:

cat /tmp/router.jwt

Dovremmo visualizzare un output simile al seguente:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjBlZWJhMmU4MzMiLCJ0eXAiOiJKV1QifQ.eyJpc3MLnBydjoxMjgwIiwic3ViIjoibUtBUTdhZEIyUSIsImF1ZCI6WyIiXSwiZXhwIjoxNzc4OTY5MDM1LCJqdGkiOiI0YzlmZmRlYS1iZWViLTQ3Y2UtYjY0NS0yMjQyYTc4MTlhMDYiLCJlbSI6ImVyb3R0IiwiY3RybHMiOlsidGxzOnNlcnZlcnRlc3QubGFiLnBydjoxMjgwIl19.Bh7bd_oYjC0Y-YtxkmLQZsJ5J-CHi4enI5A-rbQ7c7N6n44EAC2hfFy1f-ve6vVoJA-7bko7A5Yw57llCUy55yiwSMeuh5XTjiy2bdpL3v3A6MqbVA7mCSE5WYHIOcCGuo-fLdy_iZ-r0ZZNjHiI_9_PWJ2_SLUcx45OsNA6gBHtMwEN4yZKPxGYoSesBnAJ__cdqKXx9S_IG8U-wLQQE0eDK8Je21wavj4kZuCm297UUjocg7xk0qkiPQ3TkyJZDWYOM0YjJmKWBexDWzJF-ANG3Zz8A38kiRIAEHYFBM1KTgS8RbjJ6ruK8vwaHtAtnxp-neHNtrP64Xb0D5VDem4k1NV_Lc_X53u004E3jHWYwb1n8IJ72liF4sTtczQllsHmgTj756l07j6r4P8Jlv1uPkL3cMSiOj6ZiUdYROZj76befSgZQ95C2vj5Zj3-0KvQnUcnqCcWO0aMtJYXSPEsOjesukqZkIuY7Ce_796VQbBgSre4bBydpJu4o4-ktz_XmNtP-dvScHNr-32qUpvxanWlG7RfSwM7u1qfzL1vxfbGWwB8xvrt516fYricip7pGcHadxJZfZvc2gYm55lZB8TBLfAX5qAYX1EpS2CfZr_k_av7Z51EiwqDEYr-9ogc4RouaoVTe4PB8f4Xhx5C-Yy6J4e-m9ZHTRnx7Nsrchiatto@vm-srv-test:~$

4.3 AVVIARE IL BOOSTRAP DEL ROUTER

Eseguire il comando:

sudo /opt/openziti/etc/router/bootstrap.bash

Rispondere alle domande come di seguito:

Al termine abilitare il router con il comando:

sudo systemctl enable --now ziti-router

Quindi eseguire l’enrollment con il JWT con il comando:

sudo ziti router enroll \
/var/lib/private/ziti-router/config.yml \
--jwt /tmp/router.jwt

Cambiare il proprietario dei file root:root a nobody:nogroup con il comando:

sudo chown nobody:nogroup \
/var/lib/private/ziti-router/router.key \
/var/lib/private/ziti-router/router.cas \
/var/lib/private/ziti-router/router.server.chain.cert \
/var/lib/private/ziti-router/endpoints.yml

Verificare le ACL con il comando:

sudo ls -la /var/lib/private/ziti-router/

Dovremmo visualizzare il seguente output:

drwxr-xr-x 2 nobody nogroup 4096 May 16 19:11 .
drwx------ 4 root root 4096 May 16 19:05 ..
-rw-r--r-- 1 nobody nogroup 1560 May 16 19:07 config.yml
-rw------- 1 nobody nogroup 41 May 16 19:11 endpoints.yml
-rw------- 1 nobody nogroup 4250 May 16 19:11 router.cas
-rw------- 1 nobody nogroup 3243 May 16 19:11 router.key
-rw------- 1 nobody nogroup 4252 May 16 19:11 router.server.chain.cert

4.4 VERIFICARE LO STATO DEL ROUTER

Controllare che il servizio sia attivo con il comando:

sudo systemctl status ziti-router

Dovremmo visualizzare il seguente output:

● ziti-router.service - OpenZiti Router
Loaded: loaded (/usr/lib/systemd/system/ziti-router.service; enabled; pres>
Drop-In: /etc/systemd/system/ziti-router.service.d
└─override.conf
Active: active (running) since Sat 2026-05-16 19:17:07 UTC; 19ms ago
Invocation: ae59ec8bd0e64710b62adac8855aeb8a
Process: 6671 ExecStartPre=/opt/openziti/etc/router/entrypoint.bash check c>
Main PID: 6680 (ziti)
Tasks: 5 (limit: 6210)
Memory: 3.2M (peak: 3.2M)
CPU: 36ms
CGroup: /system.slice/ziti-router.service
└─6680 /opt/openziti/bin/ziti router run config.yml --extend

May 16 19:17:07 servertest.lab.prv systemd[1]: Starting ziti-router.service - O>
May 16 19:17:07 servertest.lab.prv entrypoint.bash[6671]: WARN: set VERBOSE=1 o>
May 16 19:17:07 servertest.lab.prv entrypoint.bash[6671]: WARN: see output in '>
May 16 19:17:07 servertest.lab.prv systemd[1]: Started ziti-router.service - Op>

Verificare i log con il comando:

sudo journalctl -u ziti-router -f

FASE 5 — CONFIGURAZIONE POLICY DI DEFAULT

Dopo l’installazione creare le policy per permettere a identità e servizi di usare il router.

Assicurati di essere loggato

ziti edge login servertest.lab.prv:1280 -u admin -p PASSWORD --yes

Creare una Edge Router Policy (tutti i client possono usare router con attributo #public)

ziti edge create edge-router-policy "all-endpoints-all-routers" \
--edge-router-roles '#public' \
--identity-roles '#all'

Creare una Service Edge Router Policy (tutti i servizi possono usare router #public)

ziti edge create service-edge-router-policy "all-services-all-routers" \
--edge-router-roles '#public' \
--service-roles '#all'

FASE 6 – INSTALLAZIONE DELLA CONSOLE WEB (ZAC)

Installare il pacchetto della console con il comando:

sudo apt install -y openziti-console

Poi bisogna abilitarla nel config del controller quindi aprire il config del controller con il comando:

sudo nano /var/lib/private/ziti-controller/config.yml

Cercare la sezione web e aggiungere il binding zac.

Dovrebbe già esserci una sezione simile nel caso va aggiunto zac agli apis:

yaml apis:
- binding: edge-management
- binding: edge-client
- binding: fabric
- binding: zac

Salvare e poi riavviare il controller con il comando:

sudo systemctl restart ziti-controller

FASE 7 — ACCESSO ALLA CONSOLE WEB (ZAC)

Aprire il browser e richiamare il seguente link:

https://servertest.lab.prv:1280/zac

Se abbiamo fatto tutto correttamente dovremmo visualizzare una schermata come quella mostrata nell’immagine sovrastante

Inserire le credenziali di accesso

Username: admin
Password: quella impostata/generata al passo 3.2

Cliccare Login

ATTENZIONE: Il certificato è self-signed: accetta l’eccezione nel browser (è normale in ambiente lab).

Dovremmo visualizzare la Ziti Admin Console

Gestire più server, tenere sotto controllo i container Docker, automatizzare i deployment e monitorare le risorse di sistema da un’unica interfaccia: è esattamente quello che promette Komodo, un progetto open-source che negli ultimi mesi sta guadagnando sempre più attenzione nella community homelab e non solo.

Se hai già utilizzato Portainer, l’idea di base ti sarà familiare ma Komodo spinge il concetto un passo più avanti.

Oltre alla gestione dei container, integra un sistema di build, procedure automatizzate, alerting e un agente leggero chiamato Periphery che permette di collegare e supervisionare server remoti senza la complessità di soluzioni enterprise.

Il tutto completamente gratuito e con il codice sorgente disponibile su GitHub.

In questa guida vedremo come installare e configurare Komodo su Ubuntu Server 26.04, utilizzando Docker Compose e MongoDB come backend.

Seguiremo ogni passaggio dalla preparazione dell’ambiente fino al primo accesso all’interfaccia web, con qualche consiglio utile per adattare la configurazione al proprio setup.

Che tu stia cercando un pannello di controllo per il tuo homelab o uno strumento più strutturato per gestire ambienti multi-server, Komodo potrebbe essere esattamente quello che fa per te.

PREREQUISITI

• Ubuntu Server 26.04 aggiornato
• Accesso root o utente con sudo
• Docker Engine installato (vedi sotto)
• Porte 9120 disponibile nel firewall

INSTALLAZIONE DI DOCKER ENGINE

Aggiornare i pacchetti con il comando:

sudo apt update && sudo apt upgrade -y

Installare le dipendenze con il comando:

sudo apt install -y ca-certificates curl gnupg

Aggiungere la chiave GPG ufficiale di Docker con il comando:

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

Aggiungere il repository Docker con il comando:

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

Installare Docker con il comando:

sudo apt update

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

Verificare che Docker funzioni con il comando:

sudo docker run --rm hello-world

Se è tutto ok dovremmo visualizzare il seguente output:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
4f55086f7dd0: Pull complete
d5e71e642bf5: Download complete
Digest: sha256:f9078146db2e05e794366b1bfe584a14ea6317f44027d10ef7dad65279026885
Status: Downloaded newer image for hello-world:latest

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/

Aggiungere il proprio utente al gruppo docker per evitare di usare sudo ogni volta con il comando:

sudo usermod -aG docker $USER && newgrp docker

CREAZIONE DELLA STRUTTURA DI CARTELLE

mkdir -p ~/komodo

cd ~/komodo

DOWNLOAD DEL FILE DI CONFIGURAZIONE

Komodo fornisce un file compose.yaml e un file di variabili d’ambiente pronti all’uso. Scaricarli nella cartella appena creata:

File Docker Compose (con MongoDB — opzione consigliata):

wget -O mongo.compose.yaml \
https://raw.githubusercontent.com/moghtech/komodo/main/compose/mongo.compose.yaml

File delle variabili d’ambiente:

wget -O compose.env \
https://raw.githubusercontent.com/moghtech/komodo/main/compose/compose.env

ATTENZIONE: Se il tuo server ha hardware datato o un kernel vecchio che non supporta MongoDB recente, usa invece ferretdb.compose.yaml:

wget -O ferretdb.compose.yaml \
https://raw.githubusercontent.com/moghtech/komodo/main/compose/ferretdb.compose.yaml

CONFIGURAZIONE DELLE VARIABILI DI AMBIENTE

Aprire compose.env con un editor:

nano compose.env

Le variabili essenziali da modificare sono:

Tag versione immagine (2 = ultima major release)

COMPOSE_KOMODO_IMAGE_TAG="2"

Percorso backup del database

COMPOSE_KOMODO_BACKUPS_PATH=/etc/komodo/backups

Credenziali MongoDB — Modificarle!!!

KOMODO_DATABASE_USERNAME=admin
KOMODO_DATABASE_PASSWORD=una_password_sicura

Fuso orario

TZ=Europe/Rome

URL pubblico di Komodo (usare IP o dominio reale)

KOMODO_HOST=http://192.168.1.100:9120

Titolo visualizzato nel browser

KOMODO_TITLE=Komodo

Credenziali admin iniziale — Modificarle!!!

KOMODO_INIT_ADMIN_USERNAME=admin
KOMODO_INIT_ADMIN_PASSWORD=una_password_sicura

Segreti JWT e webhook — Modificarli con stringhe casuali!!!

KOMODO_WEBHOOK_SECRET=segreto_webhook_casuale (fsj09fuy039rjiodcj0923urhjdi)
KOMODO_JWT_SECRET=segreto_jwt_casuale (08dsfjksaOi32ein23o9ruu23)

Nome del primo server (di solito l’hostname va bene)

KOMODO_FIRST_SERVER_NAME=server-locale

Salvare e chiudere il file di configurazione

CREAZIONE DELLA CARTELLA DI BACKUP

Creare la cartella con il comando:

sudo mkdir -p /etc/komodo/backups

AVVIO DI KOMODO CON DOCKER COMPOSE

docker compose -p komodo \
-f ~/komodo/mongo.compose.yaml \
--env-file ~/komodo/compose.env \
up -d

Verificare che tutti e tre i container siano in esecuzione:

docker compose -p komodo ps

L’output atteso mostra mongo, core e periphery tutti in stato running come mostrato sotto:

NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
komodo-core-1 ghcr.io/moghtech/komodo-core:2 "entrypoint.sh core" core 13 seconds ago Up 12 seconds 0.0.0.0:9120->9120/tcp, [::]:9120->9120/tcp
komodo-mongo-1 mongo "docker-entrypoint.s…" mongo 19 seconds ago Up 12 seconds 27017/tcp
komodo-periphery-1 ghcr.io/moghtech/komodo-periphery:2 "entrypoint.sh perip…" periphery 13 seconds ago Up 12 seconds 8120/tcp

APERTURE FIREWALL

Di seguito i comandi:

sudo ufw allow 9120/tcp

sudo ufw reload

PRIMO ACCESSO DALL’INTERFACCIA WEB

Aprire il browser e navigare su:

http://<IP-del-server>:9120

IMPORTANTE: al primo avvio fare clic su Sign Up, non su Log In.
Inserire le credenziali impostate in compose.env (KOMODO_INIT_ADMIN_USERNAME / KOMODO_INIT_ADMIN_PASSWORD). Questo crea l’account amministratore iniziale.

Se è andato tutto a buon fine dovremmo accedere alla Dashboard di Komodo

VERIFICA DEL SERVER LOCALE

Dopo il login andare su Servers nel menu di sinistra. Il server locale (chiamato come impostato in KOMODO_FIRST_SERVER_NAME) dovrebbe già risultare connesso tramite il container Periphery avviato in automatico.

COMANDI UTILI

Vedere i log in tempo reale con il comando:

docker compose -p komodo -f ~/komodo/mongo.compose.yaml logs -f

Fermare Komodo con il comando:

docker compose -p komodo -f ~/komodo/mongo.compose.yaml down

Aggiornare Komodo all’ultima versione con i seguenti comandi:

docker compose -p komodo -f ~/komodo/mongo.compose.yaml pull

docker compose -p komodo -f ~/komodo/mongo.compose.yaml up -d

Per gestire server aggiuntivi con Komodo, bisogna installare il Periphery agent su ciascuno di essi. La guida ufficiale è disponibile su Connect More Servers | Komodo

PRO E CONTRO

PRO

Open source e gratuito: nessun piano a pagamento per le funzionalità core, a differenza di Portainer che nasconde molte feature dietro licenza Business.

Multi-server nativo: l’agente Periphery permette di collegare e monitorare server remoti in modo semplice, senza configurazioni complesse.

Tutto in uno: gestione container, build di immagini, deployment automatizzati, procedure schedulate e alerting sono integrati nella stessa piattaforma.

Interfaccia moderna e reattiva: la UI è pulita, veloce e decisamente più curata rispetto ad alcune alternative.

Integrazione Git: supporto nativo per repository Git, utile per workflow GitOps e sincronizzazione di stack Docker Compose.

Webhook e automazione: supporta trigger via webhook per pipeline CI/CD leggere senza dipendere da strumenti esterni.

Comunità attiva: sviluppo frequente, issue tracker reattivo e buona documentazione ufficiale.

CONTRO

Nessun supporto Kubernetes: è pensato esclusivamente per ambienti Docker; chi gestisce cluster K8s deve guardare altrove (Rancher, ArgoCD, ecc.).

Richiede MongoDB o FerretDB: aggiunge un componente in più da mantenere rispetto a soluzioni che usano SQLite o un semplice file.

Curva di apprendimento iniziale: il modello Core + Periphery può disorientare chi si aspetta uno strumento plug-and-play come Portainer.

Ecosistema ancora giovane: rispetto a soluzioni più mature mancano alcune integrazioni e plugin di terze parti.

Nessuna gestione IAM avanzata: il controllo degli accessi è presente ma basilare; non è adatto ad ambienti enterprise con esigenze complesse di ruoli e permessi.

Terminali remoti dipendenti dalla rete: la funzionalità di shell remota via browser può essere instabile su connessioni lente o con latenza elevata.

In sintesi Komodo è una scelta eccellente per homelab e piccoli ambienti multi-server basati su Docker, ma non è ancora pronto per sostituire strumenti enterprise o per chi lavora con Kubernetes

Nel panorama della sicurezza informatica moderna, proteggere la propria infrastruttura non è più un’opzione riservata alle grandi aziende: è una necessità concreta anche per chi gestisce ambienti homelab, piccole reti aziendali o server esposti su Internet.

Le minacce evolvono rapidamente, i log si moltiplicano su decine di sistemi diversi, e tenere tutto sotto controllo manualmente diventa presto impossibile.

È qui che entra in gioco UTMStack, una piattaforma open source di tipo SIEM (Security Information and Event Management) e XDR (Extended Detection and Response) che centralizza la raccolta, l’analisi e la correlazione degli eventi di sicurezza provenienti da tutta la tua infrastruttura.

In un’unica interfaccia web puoi monitorare log di sistema, traffico di rete, attività sospette, alert in tempo reale e molto altro, il tutto supportato da regole di correlazione scritte in YAML e da feed di threat intelligence integrati.

In questa guida vedremo come installare e configurare UTMStack su Ubuntu Server 26.04 LTS (Resolute Raccoon), l’ultima release LTS di Canonical.

Il percorso non è privo di insidie: essendo una distribuzione molto recente, ci troveremo ad affrontare qualche conflitto di pacchetti legato alla coesistenza tra i repository ufficiali di Docker e quelli di Ubuntu.

Niente che non si possa risolvere con i giusti comandi, ma vale la pena documentarlo passo per passo per evitare di perdere tempo davanti a errori criptici.

Alla fine della guida avrai un’istanza UTMStack perfettamente funzionante, raggiungibile via HTTPS, pronta ad accogliere le prime sorgenti di log e a fare il suo lavoro: tenerti un passo avanti rispetto a chi cerca di entrare dove non dovrebbe.

PREREQUISITI

Requisiti minimi assoluti (verificati dall’installer stesso):

2 CPU core
16 GB di RAM
30 GB di spazio libero su disco
Connessione Internet per il download dei componenti
Accesso root

Sulla base di quanto trovato nella documentazione ufficiale i requisiti variano in base al numero di sorgenti di log che vuoi monitorare e alla retention desiderata (assumendo ~100 GB/mese per 60 dispositivi):

RIMUOVERE DOCKER.IO E RESIDUI

Eseguire i comandi:

apt remove -y docker.io docker-compose docker-compose-v2 docker-doc containerd runc 2>/dev/null || true

apt autoremove -y

INSTALLAZIONE DI DOCKER CE UFFICIALE PER UBUNTU 26.04

Docker 29 include il supporto nativo per Ubuntu 26.04 (resolute) nei repository ufficiali senza bisogno di workaround sul repo noble.

Eseguire il comando:

apt install -y ca-certificates curl

Aggiungere la GPG key di Docker con i comandi:

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

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

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

Aggiungere il repository Docker (resolute) con il comando:

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" | \
tee /etc/apt/sources.list.d/docker.list > /dev/null

Aggiornare e installare Docker CE con i comandi:

apt update

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

Verificare che Docker funzioni con il comando:

systemctl enable --now docker

docker run hello-world

Se è tutto OK dovremmo visualizzare Hello from Docker!

Forzare l’installazione di docker compose sovrascrivendo il file in conflitto con il comando:

apt install -y -o Dpkg::Options::="--force-overwrite" docker-compose-v2

Questo dice a dpkg di sovrascrivere /usr/libexec/docker/cli-plugins/docker-compose senza protestare.

Il file finale sarà quello di docker-compose-v2 ma entrambi i pacchetti risulteranno installati e dpkg sarà soddisfatto.

PREPARAZIONE DEL SISTEMA

Aggiornare i pacchetti e installare le dipendenze di base:

sudo apt update && sudo apt upgrade -y

sudo apt install -y wget curl

Assicurarsi di operare come root per tutta l’installazione:

sudo -i

DOWNLOAD DELL’INSTALLER

Scaricare l’ultima versione dell’installer direttamente da GitHub:

wget https://github.com/utmstack/UTMStack/releases/latest/download/installer

Rendere il file eseguibile con il comando:

chmod +x installer

ESECUZIONE DELL’INSTALLER

Eseguire l’installer come root con il comando:

./installer

L’installer esegue automaticamente una serie di operazioni in sequenza: verifica i requisiti di sistema (almeno 2 CPU core e 30 GB di spazio libero), prepara il sistema, installa i componenti necessari, configura lo stack e inizializza i database.

L’installazione richiede alcuni minuti. Al termine viene generata una password casuale per l’utente admin.

Al termine dovemmo visualizzare il seguente output:

### Installing UTMStack ###
Generating Stack configuration...
Balancing memory...
Memory distribution successful. Total Assigned: 13476MB (Available: 13476MB)
Configuring Docker [OK]
Initializing Swarm [OK]
Downloading images:
Downloading ghcr.io/utmstack/utmstack/eventprocessor:v11.2.6... [OK]
Downloading ghcr.io/utmstack/utmstack/eventprocessor:v11.2.6... [OK]
Downloading ghcr.io/utmstack/utmstack/web-pdf:v11.2.6... [OK]
Downloading ghcr.io/utmstack/utmstack/agent-manager:v11.2.6... [OK]
Downloading ghcr.io/utmstack/utmstack/postgres:latest... [OK]
Downloading ghcr.io/utmstack/utmstack/frontend:v11.2.6... [OK]
Downloading ghcr.io/utmstack/utmstack/backend:v11.2.6... [OK]
Downloading ghcr.io/utmstack/utmstack/opensearch:latest... [OK]
Downloading ghcr.io/utmstack/utmstack/user-auditor:v11.2.6... [OK]
Installing reverse proxy. This may take a while. [OK]
Installing Administration Tools [OK]
Initializing UTMStack and AgentManager databases [OK]
Initializing User Auditor database [OK]
Initializing OpenSearch. This may take a while. [OK]
Waiting for Backend to be ready. This may take a while. [OK]
Generating Connection Key [OK]
Generating Base URL [OK]
Installing Updater Service [OK]
Running post installation scripts. This may take a while.
Securing ports 9200, 5432 and 10000 [OK]
Restarting Stack [OK]
Cleaning up Docker system [OK]
Installation fisnished successfully. We have generated a configuration file for you, please do not modify or remove it. You can find it at /root/utmstack.yml.
You can also use it to re-install your stack in case of a disaster or changes in your hardware. Just run the installer again.
You can access to your Web-GUI at https://<your-server-ip> using admin as your username
Web-GUI default password for admin: 26tS2jvcZgViuGyM
You can also access to your Web-based Administration Interface at https://<your-server-ip>:9090 using your Linux system credentials.
Detailed installation logs can be found at /var/log/utmstack-installer.log
### Thanks for using UTMStack ###

RECUPERO DELLE CREDENZIALI (OPZIONALE)

Al termine dell’installazione la password generata e le configurazioni si trovano in:

cat /root/utmstack.yml

Annotare la password perchè servirà per il primo accesso.

ACCESSO ALL’INTERFACCIA WEB

Aprire il browser e richiamare l’indirizzo del server usando HTTPS. L’utente predefinito è admin e la password è quella generata durante l’installazione:

https://<IP_DEL_SERVER>

Dovremmo visualizzare una schermata come quella sovrastante

ATTENZIONE: Usare sempre https://, non http://.

Inserire le credenziali di accesso quidi cliccare Sign In

Cliccare su Authenticator App per configurare l’autenticazione a due fattori

Inserire il codice a 6 cifre

Cliccare Complete

Selezionare se procedere con il Quick Setup oppure con l’installazione Expert Mode

In questo tutorial procederò con il Quick Setup

Inserire l’indirizzo email, la password corrente quindi creare una nuova password. Cliccare Set up

Cliccare Continue

Compilare tutti i campi relativi al mail server e alle notifiche quindi cliccare Save Changes

CONFIGURAZIONE INIZIALE

Dopo il login:

Andare alla sezione Integrations per installare gli agenti sui dispositivi da monitorare.

Configurare le sorgenti di log (firewall, server, endpoint, SaaS).

Rivedere le Correlation Rules per personalizzare gli alert.

PORTE DA APRIRE SUL FIREWALL

Configurare UFW per consentire le porte necessarie:

SSH (limita all’IP di admin)

ufw allow from <IP_ADMIN> to any port 22

Web UI (HTTPS redirect)

ufw allow 80/tcp
ufw allow 443/tcp

Syslog

ufw allow 514/tcp
ufw allow 514/udp

Agent communication

ufw allow 9000/tcp

ufw enable

NOTA SU UBUNTU 26.04: Ubuntu 26.04 LTS è appena uscita (aprile 2026) e UTMStack non ha ancora rilasciato supporto ufficiale.

Mantenere i propri server aggiornati è una delle pratiche fondamentali per garantire sicurezza e stabilità in qualsiasi infrastruttura, che si tratti di un homelab casalingo o di un ambiente di produzione.

Sapere in tempo reale quali pacchetti necessitano di aggiornamento, quali patch di sicurezza sono disponibili e avere una visione centralizzata dello stato dei propri sistemi Linux è qualcosa che, fino a poco tempo fa, richiedeva script personalizzati o soluzioni enterprise costose.

PatchMon v2 si propone come una soluzione open source elegante e leggera per il monitoraggio degli aggiornamenti su sistemi Debian/Ubuntu, offrendo una dashboard web intuitiva, notifiche configurabili e un’API REST che si integra facilmente con i principali strumenti di automazione e orchestrazione.

In questa guida vedremo come installare e configurare PatchMon v2 da zero su Ubuntu Server 26.04 LTS, la nuova release a supporto prolungato che introduce diverse ottimizzazioni lato sicurezza e gestione dei pacchetti. Partiremo dai prerequisiti di sistema, passeremo attraverso l’installazione del servizio e la sua configurazione base, fino ad avere un’istanza perfettamente funzionante e pronta all’uso.

Che tu stia gestendo un singolo server o una piccola flotta di macchine, al termine di questa guida avrai un sistema di monitoraggio delle patch affidabile, sempre sotto controllo.

PREREQUISITI

Ubuntu Server 26.04 LTS (Resolute Raccoon)

Architettura amd64/arm64

Utente con privilegi sudo o root

AGGIORNAMENTO DEL SISTEMA

Aggiornare il sistema con il comando:

sudo apt update && sudo apt upgrade -y

RIMOZIONE DEI PACCHETTI DOCKER CONFLITTUALI

Prima di installare Docker Engine, devi rimuovere eventuali pacchetti non ufficiali che potrebbero creare conflitti: Docker

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc -y

Non preoccuparti se alcuni pacchetti non risultano installati è normale.

INSTALLAZIONE DOCKER CE DAL REPOSITORY UFFICIALE

Per avere sempre le ultime patch di sicurezza, aggiungi il repository ufficiale Docker alle sorgenti APT: iRexta

Installare i prerequisiti con il comando:

sudo apt install ca-certificates curl -y

Aggiungere la GPG key ufficiale di Docker con i comandi:

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

Aggiungere il repository (usa automaticamente il codename “resolute”) con il comando:

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

Aggiornare l’indice e installare Docker con i comandi:

sudo apt update

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

VERIFICARE DOCKER E ABILITARE L’AVVIO AUTOMATICO

Verificare e abilitare Docker con i seguenti comandi:

sudo systemctl enable --now docker

sudo systemctl status docker

Dovremmo vedere Active: active (running).

AGGIUNGERE IL TUO UTENTE AL GRUPPO DOCKER (OPZIONALE MA CONSIGLIATO)

Per eseguire i comandi Docker senza sudo aggiungere il tuo utente al gruppo docker con i seguenti comandi:

sudo usermod -aG docker $USER

newgrp docker

ATTENZIONE: questo equivale a privilegi root sull’host. Fallo solo con utenti fidati.

VERIFICA DEL DOCKER

Per verificare che Docker funzioni esseguire il comando:

docker run hello-world

Dovremmo visualizzare il seguente output:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
4f55086f7dd0: Pull complete
d5e71e642bf5: Download complete
Digest: sha256:f9078146db2e05e794366b1bfe584a14ea6317f44027d10ef7dad65279026885
Status: Downloaded newer image for hello-world:latest

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/

Quindi verificare la versione di Docker Compose installata con il comando:

docker compose version

Dovremmo visualizzare il seguente output:

Docker Compose version v5.1.3

INSTALLAZIONE DI PATCHMON V2

Eseguire lo script di setup da una directory vuota.

Scaricherà automaticamente docker-compose.yml e env.example, genererà tutti i secret necessari e ti guiderà nella configurazione dell’URL e del fuso orario in modo interattivo.

Eseguire i comandi:

mkdir ~/patchmon && cd ~/patchmon

bash -c "$(curl -fsSL https://raw.githubusercontent.com/PatchMon/PatchMon/refs/heads/main/docker/setup-env.sh)"

Lo script chiederà le seguenti cose:

Will you be accessing PatchMon via a reverse proxy (nginx, Caddy, etc.)? (y/n) [n]: n

Do you want to change the timezone from UTC? (y/n) [n]: y

PatchMon runs on port 3000 by default. Include the port in your URL unless you are
terminating it at a reverse proxy on a standard port (e.g. https://patchmon.example.com).
Examples: http://192.168.1.10:3000 https://patchmon.local:3000 https://patchmon.example.com

What URL will you use to access PatchMon? [http://localhost:3000]: http://miodominio.lab:3000

Add (a), Remove (r), or Done (d) [d]: d

AVVIARE IL CONTAINER

Eseguire il comandi:

docker compose up -d

Verificare che tutti i servizi siano Up:

[+] up 48/48
 Image postgres:17-alpine Pulled 10.6s
 Image redis:7-alpine Pulled 4.3s
 Image guacamole/guacd:latest Pulled 10.3s
 Image ghcr.io/patchmon/patchmon-server:latest Pulled 22.2s
 Network patchmon_patchmon-internal Created 0.0s
 Volume patchmon_postgres_data Created 0.0s
 Volume patchmon_redis_data Created 0.0s
 Container patchmon-database-1 Healthy 9.6s
 Container patchmon-redis-1 Healthy 10.1s
 Container patchmon-guacd-1 Healthy 11.6s
 Container patchmon-server-1 Started 5.5s

Eseguire il comando:

docker compose ps

Dovremmo vedere 4 container attivi: server, database (PostgreSQL), redis e guacd.

NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
patchmon-database-1 postgres:17-alpine "docker-entrypoint.s…" database 38 seconds ago Up 31 seconds (healthy) 5432/tcp
patchmon-guacd-1 guacamole/guacd:latest "/opt/guacamole/entr…" guacd 38 seconds ago Up 31 seconds (healthy) 4822/tcp
patchmon-redis-1 redis:7-alpine "docker-entrypoint.s…" redis 38 seconds ago Up 31 seconds (healthy) 6379/tcp
patchmon-server-1 ghcr.io/patchmon/patchmon-server:latest "./entrypoint.sh" server 32 seconds ago Up 25 seconds (healthy) 0.0.0.0:3000->3000/tcp, [::]:3000->3000/tcp

WIZARD DI PRIMO ACCESSO TRAMITE WEBGUI

Aprire il browser e richiamare l’URL che abbiamo configurato (es. http://miodominio.lab:3000).

Inserire tutte le info richieste quindi cliccare Next

Scegliere ser attivare l’MFA subito oppure se farlo dopo quindi cliccare Next

Confermare l’URL del Server e valutare se abilitare il Certificato Self Signed. Cliccare Next

Cliccare Next

Cliccare su Access Dashboard

Se è tutto OK dovremmo visualizzare la Dashboard di Patchmon come mostrato nell’immagine sovrastante

AGGIUNTA DI UN SERVER WINDOWS A PATCHMON

Dalla Dashboard

Cliccare su Host dal menu laterale quindi Add Host

Selezionare Windows come tipolgia di server quindi cliccare Next

Inserire il nome quindi cliccare Next

Copiare il comando da eseguire sul server da monitorare

Sul server da monitorare aprire un Powershell con diritti amministrativi quindi incollare il comando

Sulla Console PatchMon dovremmo vedere Waiting for Connection

Sul Server da monitorare se è andato tutto a buon fine dovremmo visualizzare il seguente output del Powershell:

Encoding UTF8; & "$env:TEMP\patchmon-install.ps1"
Fetching credentials from PatchMon server...
Credentials received successfully.
PatchMon Agent Installation for Windows
=======================================
Downloading agent from PatchMon server: http://192.168.80.34:3000/api/v1/hosts/agent/download?arch=amd64&os=windows
Architecture: amd64
Install Path: C:\Program Files\PatchMon
Config Path: C:\ProgramData\PatchMon

Creating installation directory...
Creating configuration directory...
Downloading PatchMon agent...
Download completed.
Installing agent to C:\Program Files\PatchMon\patchmon-agent.exe...
Creating default configuration file...
Adding PatchMon to system PATH...
Configuring API credentials...
Credentials configured successfully.

Testing installation...
 API credentials are valid
 Connectivity test successful
Installation test successful!

Setting up Windows Service...
Creating Windows Service...
Service created successfully.
Starting service...
Service started successfully!

PatchMon Agent installation completed successfully!

Installation Summary:
⢠Configuration directory: C:\ProgramData\PatchMon
⢠Agent binary installed: C:\Program Files\PatchMon\patchmon-agent.exe
⢠Architecture: amd64
⢠Windows Service: configured and running
⢠API credentials configured and tested
⢠Logs: C:\ProgramData\PatchMon\patchmon-agent.log

Management Commands:
⢠Test connection: patchmon-agent ping
⢠Manual report: patchmon-agent report
⢠Check status: patchmon-agent diagnostics
⢠Service status: Get-Service -Name PatchMonAgent
⢠Service logs: Get-Content "C:\ProgramData\PatchMon\patchmon-agent.log" -Tail 50 -Wait
⢠Restart service: Restart-Service -Name PatchMonAgent

Your system is now being monitored by PatchMon!

Sulla Console PatchMon dovremmo visualizzare il server appena aggiunto

AGGIUNTA DI UN SERVER LINUX A PATCHMON

Dalla Dashboard

Cliccare su Host dal menu laterale quindi Add Host

Selezionare Linux come tipologia di server quindi cliccare Next

Inserire il nome quindi cliccare Next

Copiare il comando da eseguire sul server Linux da monitorare

Dopo aver eseguito il comando sul server da monitorare se è tutto OK dovremmo visualizzare il seguente output:

INFO: Installing curl...
SUCCESS: All required packages are already installed

SUCCESS: Dependencies installation completed

INFO: Setting up configuration directory...
INFO: Creating new configuration directory...
INFO: Checking if agent is already configured...
SUCCESS: Agent not yet configured - proceeding with installation

INFO: Creating configuration files...
INFO: Downloading PatchMon agent binary...
INFO: Agent version: Unknown
INFO: Setting up log directory...
INFO: Testing API credentials and connectivity...
 API credentials are valid
 Connectivity test successful
SUCCESS: TEST: API credentials are valid and server is reachable
INFO: Setting up systemd service...
Created symlink /etc/systemd/system/multi-user.target.wants/patchmon-agent.service → /etc/systemd/system/patchmon-agent.service.
SUCCESS: PatchMon Agent service started successfully
INFO: WebSocket connection established
SUCCESS: PatchMon Agent installation completed successfully!

Installation Summary:
• Configuration directory: /etc/patchmon
• Agent binary installed: /usr/local/bin/patchmon-agent
• Architecture: amd64
• Dependencies installed: curl
• Systemd service configured and running
• API credentials configured and tested
• WebSocket connection established
• Logs directory: /etc/patchmon/logs

Management Commands:
• Test connection: /usr/local/bin/patchmon-agent ping
• Manual report: /usr/local/bin/patchmon-agent report
• Check status: /usr/local/bin/patchmon-agent diagnostics
• Service status: systemctl status patchmon-agent
• Service logs: journalctl -u patchmon-agent -f
• Restart service: systemctl restart patchmon-agent

SUCCESS: Your system is now being monitored by PatchMon!

Se è andato tutto a buon fine sulla console di PatchMon dovremmo visualizzare il server aggiunto

DISINSTALLAZIONE DELL’AGENT PATCHMON DA UN HOST WINDOWS

Su un server Windows eseguire con una console Powershell con diritti amministrativi eseguire i comandi:

# 1. Ferma il servizio
Stop-Service -Name "patchmon-agent" -Force -ErrorAction SilentlyContinue

# 2. Rimuovi il servizio Windows
sc.exe delete "patchmon-agent"

# 3. Rimuovi il binario e i file dell'agente
Remove-Item -Path "C:\Program Files\patchmon-agent\*" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item -Path "C:\Program Files\patchmon-agent" -Recurse -Force -ErrorAction SilentlyContinue

# 4. Rimuovi la configurazione e le credenziali
Remove-Item -Path "C:\ProgramData\patchmon\*" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item -Path "C:\ProgramData\patchmon" -Recurse -Force -ErrorAction SilentlyContinue

# 5. Verifica che il servizio sia stato rimosso
Get-Service -Name "patchmon-agent" -ErrorAction SilentlyContinue

NOTA BENE: rimuovere l’agente dall’host non lo elimina automaticamente dalla dashboard di PatchMon. Ricordati di cancellare l’host anche dalla UI per tenerla pulita

DISINSTALLAZIONE DELL’AGENT PATCHMON DA UN HOST LINUX

Su un server Linux eseguire l’agente include un comando di disinstallazione integrato:

# Rimozione base (binario + crontab)
sudo patchmon-agent uninstall

# Rimozione completa (binario + config + log)
sudo patchmon-agent uninstall --remove-all

# Rimozione silenziosa senza conferma
sudo patchmon-agent uninstall -af

Se il server non è raggiungibile, puoi rimuovere l’agente manualmente:

# 1. Ferma e disabilita il servizio (systemd)

sudo systemctl stop patchmon-agent
sudo systemctl disable patchmon-agent
sudo rm -f /etc/systemd/system/patchmon-agent.service
sudo systemctl daemon-reload

# 2. Termina eventuali processi residui

sudo pkill -f patchmon-agent

# 3. Rimuovi il binario

sudo rm -f /usr/local/bin/patchmon-agent
sudo rm -f /usr/local/bin/patchmon-agent.backup.*

# 4. Rimuovi configurazione e log

sudo rm -rf /etc/patchmon/

# 5. Rimuovi eventuali entry crontab

crontab -l 2>/dev/null | grep -v "patchmon-agent" | crontab -

# 6. Verifica la rimozione completa

which patchmon-agent # deve restituire vuoto
ls /etc/patchmon/ 2>/dev/null # deve dire "No such file or directory"
systemctl status patchmon-agent 2>&1 | head -1 # deve dire "not found"
Per Alpine Linux (OpenRC) al posto dei comandi systemd usa:
bashsudo rc-service patchmon-agent stop
sudo rc-update del patchmon-agent default
sudo rm -f /etc/init.d/patchmon-agent

NOTA BENE: rimuovere l’agente dall’host non lo elimina automaticamente dalla dashboard di PatchMon. Ricordati di cancellare l’host anche dalla UI per tenerla pulita

AGGIORNAMENTO DI PATCHMON

Per aggiornare PatchMon eseguire i comandi elencati di seguito:

cd ~/patchmon

docker compose pull

docker compose up -d

CONFIGURAZIONE DI PATCHMON DIETRO REVERSE PROXY

La configurazione si articola in due parti: il file .env di PatchMon e il Proxy Host in NPM.

Parte 1 — Modificare il file .env di PatchMon

Questo è il passaggio più importante. Apri il file .env nella directory di PatchMon:

nano ~/patchmon/.env

Individuare e modificare le seguenti variabili:

env# URL pubblico del tuo server PatchMon
SERVER_PROTOCOL=https
SERVER_HOST=patchmon.tuodominio.it
SERVER_PORT=443
CORS_ORIGIN=https://patchmon.tuodominio.it

# OBBLIGATORIO con NPM o qualsiasi reverse proxy
TRUST_PROXY=true

# Abilita HSTS in produzione con HTTPS
ENABLE_HSTS=true

TRUST_PROXY ora è true per default in v2. La maggior parte degli utenti usa PatchMon dietro un reverse proxy (Traefik, Caddy, Nginx, NPM); il precedente default false causava problemi di login OIDC e perdita degli IP reali dei client. Se esponi PatchMon direttamente su IP pubblico senza proxy, imposta esplicitamente TRUST_PROXY=false.

Dopo aver salvato, riavvia i container con i comandi:

cd ~/patchmon
docker compose down && docker compose up -d

Parte 2 — Configurare il Proxy Host in NPM

Accedere alla dashboard di NPM (http://IP-NPM:81)
Andare su Proxy Hosts → Add Proxy Host
Compila la scheda Details così:

Domain Names: patchmon.tuodominio.it

Scheme: http

Forward Hostname / IP: IP del server PatchMon (es. 192.168.1.100)

Forward Port: 3000

Cache Assets Off

Block Common Exploits On

Websockets Support On ← fondamentale

Nella scheda SSL:

• Selezionare o richiedere un certificato Let’s Encrypt
• Abilitare Force SSL
• Abilitare HTTP/2 Support

Nella scheda Advanced, incollare queste direttive custom per garantire il corretto passaggio degli header ai WebSocket:

nginxproxy_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 $scheme;

# WebSocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;

Cliccare Save

Perché i WebSocket sono critici

TLS in produzione: usa sempre HTTPS e WSS. L’agente assume WSS quando l’URL del server inizia con https://. Quando sei dietro Nginx (o simili), assicurati che l’header X-Forwarded-Proto: https venga inviato correttamente al backend, in modo che rilevi la connessione sicura.

Gli agenti usano HTTPS per i report e la configurazione, e WSS (WebSocket over TLS) per eventi in tempo reale come lo streaming live delle patch e lo stato Docker. Assicurati che i WebSocket siano supportati dal proxy quando inoltri il traffico al container PatchMon sulla porta 3000.

Verifica finale

Dopo aver salvato tutto, controlla che la connessione sia corretta accedendo a https://patchmon.tuodominio.it.

Nella dashboard, gli agenti connessi dovrebbero mostrare lo stato WSS (verde) e non WS (non sicuro).

Se un agente già installato usa il vecchio URL HTTP, aggiorna la sua configurazione

NOTE IMPORTANTI

UFW e Docker: Ubuntu 26.04 usa UFW come firewall, ma Docker manipola iptables direttamente, bypassando UFW. Se esponi una porta tramite Docker, questa rimane aperta al pubblico anche se bloccata in UFW. Per mitigare, fai bind solo su localhost e usa un reverse proxy (Nginx, Caddy, NPM) per l’accesso esterno.

Reverse proxy e WebSocket: assicurati che il tuo proxy supporti i WebSocket, poiché gli agenti li usano per eventi in tempo reale (WSS su porta 443).