I certificati SSL sono un elemento fondamentale per garantire la sicurezza dei siti web e la fiducia degli utenti. Una loro scadenza non monitorata può causare interruzioni di servizio, avvisi di sicurezza nei browser e potenziali problemi di reputazione. Per questo motivo è importante adottare strumenti che permettano di controllare in modo proattivo lo stato dei certificati e ricevere avvisi prima che si verifichino criticità.

In questo articolo vedremo come utilizzare LibreNMS per monitorare la scadenza dei certificati SSL dei siti web così da avere sotto controllo le date di rinnovo e intervenire tempestivamente.

Analizzeremo i passaggi necessari per configurare il monitoraggio e impostare notifiche efficaci in modo semplice e centralizzato.

ABILITAZIONE DELLA FUNZIONE SSL

Collegarsi in console sul server LibreNMS quindi eseguire i comandi:

cd /opt/librenms
sudo -u librenms php artisan config:set ssl_certificates.auto_discover true

Oppure utilizzare con il comando lnms:

sudo -u librenms lnms config:set ssl_certificates.auto_discover true

L’opzione ssl_certificates.auto_discover abilita il job schedulato che prova a connettersi ai device attivi sulla porta 443 e memorizza il certificato presentato.

VERIFICA DEI JOB SCHEDULATI

LibreNMS usa due task distinti:

• lnms maintenance:discover-ssl-certificates per la discovery
• lnms maintenance:refresh-ssl-certificates per il refresh periodico dei certificati già noti

Se il tuo scheduler LibreNMS è configurato correttamente, questi task vengono eseguiti automaticamente.

Per provarli subito a mano eseguire i comandi:

sudo -u librenms php artisan maintenance:discover-ssl-certificates

sudo -u librenms php artisan maintenance:refresh-ssl-certificates

VERIFICA DEI CERTIFICATI SCOPERTI

Collegarsi alla Web UI di LibreNMS

Quindi cliccare su Overview → Tools → SSL Certificates

Dovremmo visualizzare una schermata con tutti i certificati discoverati.

Da questa pagina è possibile:

• vedere i certificati scoperti
• aggiungere voci manualmente come host + porta
• mettere in pausa o riattivare il monitoraggio
• rimuovere una voce

AGGIUNTA MANUALE DEI SITI WEB DA MONITORARE

Questo è il passaggio più utile se vuoi controllare siti web pubblici o nomi DNS specifici.

Nella schermata SSL Certificates aggiungere manualmente:

Host: ad esempio www.tuodominio.it
Port: normalmente 443

Cliccare su Add Certificate

Per host HTTPS standard è sufficiente così. LibreNMS supporta proprio l’aggiunta manuale di host e porta da UI.

ESCLUDERE HOST CHE NON SI VUOL MONITORARE

Se si vuole evitare check automatici su certi host impostare ssl_certificates.skip_hosts con lista di hostname o IP.

L’esclusione vale sia per discovery sia per refresh.

Esempio di comando per esclusione:

sudo -u librenms lnms config:set ssl_certificates.skip_hosts '["lb01.example.local","10.10.10.5"]'

ATTIVAZIONE DELL’ALERT

LibreNMS indica che esiste una regola di alert già disponibile chiamata Expiring SSL Certificates che avvisa quando il certificato scadrà entro 14 giorni.

Aprire la Web UI quindi Alerts → Alert Rules

Verificare che la regola Expiring SSL Certificates sia presente e abilitata.

Nel caso la regola non fosse presente aggiungerla cliccando su Create rule from collection

Nel campo cerca scrivere SSL in modo che compaia la regola Expiring SSL Certificates quindi cliccare Select

Impostare l’alert come da immagine sovrastante impostando il numero di giorni a proprio piacimento.

Cliccare su Save Rule

Associare quindi il transport che usi già come per esempio:

Email
Telegram
Teams
Slack
webhook

CONSIDERAZIONI FINALI

Questo metodo è perfetto quando si usa la funzione nativa se si vuole:

• monitorare la scadenza del certificato
• vedere un elenco centralizzato dei certificati
• ricevere alert “sta per scadere”
• aggiungere manualmente host web esterni o interni su host/porta
• Limite importante da sapere

La funzione nativa fa bene il monitoraggio della scadenza del certificato presentato dal server, ma se vuoi controlli più “applicativi” del tipo:

• HTTP 200/301 atteso
• contenuto pagina
• timeout applicativo
• warning/critical personalizzati, ad esempio 30/14 giorni
• casi particolari con reverse proxy e virtual host

allora conviene usare anche i Services con plugin Nagios.

LibreNMS supporta i Service Checks tramite Nagios plugins e i servizi devono sempre essere associati a un device.

Quando si gestiscono più sottodomini avere un certificato SSL wildcard è una delle soluzioni più comode per semplificare la configurazione e mantenere tutto protetto con un solo certificato.

In questo scenario l’accoppiata tra Nginx Proxy Manager, Let’s Encrypt e Cloudflare rappresenta una soluzione pratica, moderna ed efficace, soprattutto se si vuole automatizzare il rilascio e il rinnovo dei certificati senza impazzire con configurazioni manuali.

In questo articolo vedremo come configurare un certificato wildcard Let’s Encrypt in Nginx Proxy Manager utilizzando Cloudflare tramite DNS Challenge, una procedura particolarmente utile quando i servizi non sono esposti direttamente in pubblico oppure quando si desidera una gestione più pulita e flessibile dei sottodomini.

Ti guiderò passo dopo passo nella configurazione spiegando non solo cosa fare, ma anche perché farlo, così da ottenere un setup affidabile, sicuro e facilmente replicabile.

PREREQUISITI

• Dominio gestito su Cloudflare
• Nginx Proxy Manager funzionante
• Accesso admin a Cloudflare
• Possibilità di creare un API Token Cloudflare con permessi DNS minimi

Per i token Cloudflare, la combinazione raccomandata è:

Zone – DNS – Edit

Zone – Zone – Read

Cloudflare documenta la creazione dei token, e questa coppia di permessi è anche quella normalmente richiesta dai client ACME che usano Cloudflare.

CONFIGURARE IL DOMINIO SU CLOUDFLARE

Accedere a Cloudlfare

Cliccare su Add quindi selezionare Connect a Domain

Inserire il nome del dominio quindi selezionare l’opzione Import DNS records automatically. We will scan for common DNS records and import them for you.

Quindi cliccare Continue

Selezionare il piano. Nel mio caso selezionerò quello Free

In questa fase verificare che siano stai creati tutti i record DNS presenti sul provider di origine.

Quindi cliccare Continue to Activation al fondo della pagina

A questo punto sostituire sul provider i Nameservers inserendo quelli di Cloudflare e quindi:

annabel.ns.cloudflare.com

nash.ns.cloudflare.com

Trovare e disattivare l’impostazione di sicurezza DNS (DNSSEC), se è attiva. Potremo riattivarla in seguito tramite Cloudflare.

Consentire al tuo server di origine solo gli indirizzi IP di Cloudflare

Quindi cliccare I updated my nameservers

In questa schermata siamo in attesa che il registrar propaghi i nuovi nameserver

E’ in corso la verifica che il tuo dominio punti a Cloudflare.

In genere sono necessarie 1-2 ore, ma potrebbero volerci fino a 24 ore, a seconda del tuo registrar. Lo stato viene controllato periodicamente.

Cliccare check nameservers now per verificare lo stato

Al termine della propagazione dovremmo visualizzare una schermata come quella sovrastante che ci dice che il dominio ora è protetto da Cloudflare.

A questo punto sarà possibile gestire i record DNS da Cloudflare

CREAZIONE DEL TOKEN API SU CLOUDLFLARE

Dalla Dashboard di Cloudlfare

Cliccare su My Profile → API Tokens → Create Token

Utilizzare il template tipo Edit zone DNS e poi restringilo al tuo dominio.

Cliccare Use Template

Sopra un immagine che mostra le impostazioni consigliate da impostare sul template

Impostazioni consigliate del token:

Permissions

Zone / DNS / Edit

Zone / Zone / Read

Zone Resources

Include / Specific zone / tuodominio.it

Quindi cliccare su Continue to Summary

ATTENZIONE: Questo è meglio della vecchia Global API Key che Cloudflare sconsiglia in favore degli API token.

Cliccare su Create Token

Quando Cloudflare ti mostra il token copiarlo subito, conservalo in modo sicuro e non condividerlo con nessuno

CONFIGURAZIONE DI NGINX PROXY MANAGER

Aprire Nginx Proxy Manager

Cliccare su Certificates nel menù in alto quindi Add Certificate e selezionare Let’s Encrypt via DNS

A questo punto inserire i nomi di dominio corretti.

Nel campo domini inserire: *.tuodominio e tuodominio.it

In questo modo il certificato:

*.tuodominio.it copre app.tuodominio.it, home.tuodominio.it, vpn.tuodominio.it

tuodominio.it copre il dominio principale

ATTENZIONE: Ricorda che *.tuodominio.it non copre tuodominio.it

Questa è una caratteristica normale dei wildcard certificate. Il DNS-01 serve proprio a validare questo tipo di richiesta.

Impostare come Key Type: RSA 2048

Come DNS Provider impostare: Clouflare

Nella sezione Credential File Content: dns_cloudflare_api_token=IL_TUO_TOKEN

Nella sezione Propagation Seconds: impostare i secondi da attendere per la propagazione. Lasciarlo vuoto per usare la propagazione di default.

Cliccare Save

Se è andato tutto a buon fine dovremmo visualizzare una schermata come quella sovrastante con il provider di emissione del certificato e la data di scadenza.

A questo punto NPM prova a:

• chiedere il certificato a Let’s Encrypt
• creare via API su Cloudflare il record TXT _acme-challenge
• attendere la propagazione DNS
• completare la validazione DNS-01
• salvare il certificato e configurarne il rinnovo automatico

NOTA BENE: Let’s Encrypt conferma che il DNS-01 funziona creando TXT record di validazione e che è il metodo richiesto per i wildcard.

ATTENZIONE: Per capire se il record viene creato davvero:

da fuori: controlla _acme-challenge con Resolve-DnsName o nslookup
da dentro: controlla i log del container NPM
non fidarti solo della UI di Cloudflare, perché il TXT può essere temporaneo e sparire subito

ASSEGNAZIONE DEL CERTIFICATO AI PROXY HOST

Quando il certificato compare in SSL Certificates andare sul Proxy Host e:

• aprire il proxy host
• posizionarsi nella scheda SSL
• seleziona il certificato wildcard appena creato
• abilitare Force SSL, HTTP/2 Support e HSTS Enabled solo se sai di volerlo davvero

Salvare la configurazione.

Da quel momento i sottodomini coperti dal certificato useranno quel wildcard.

Se è tutto OK dovremmo visualizzare una schermata come quella sovrastante.

CONTROLLO DEL FUNZIONAMENTO DEL CERTIFICATO

Di seguito una serie di controlli rapidi per verificare che tutto funzioni.

In NPM → SSL Certificates il certificato deve risultare valido

Aprendo https://app.tuodominio.it il browser deve mostrare certificato valido

Nel certificato devono comparire i SAN:

*.tuodominio.it e tuodominio.it

ERRORI PIU’ COMUNI E COME RISOLVERLI

1) Permessi token insufficienti

Sintomo:

• errore tipo 403
• impossibilità di leggere la zone o creare il TXT

Controllare il token Cloudflare:

• Zone:DNS:Edit
• Zone:Zone:Read
• limitato alla zone corretta

2) Hai impostato solo *.tuodominio.it

Risultato:

• i sottodomini funzionano
• https://tuodominio.it non funziona

Per coprire anche il dominio base devi aggiungere anche tuodominio.it. Il wildcard da solo non basta.

3) Il dominio non usa davvero Cloudflare DNS

Sintomo:

• Cloudflare accetta il token
• ma il challenge non si completa

Se i nameserver del dominio non puntano davvero a Cloudflare, NPM può non riuscire a pubblicare il TXT dove Let’s Encrypt lo cerca.

4) Propagazione DNS o pre-check fallito

Sintomo:

• errori su TXT non trovato

Il DNS-01 dipende dalla visibilità pubblica del record TXT. Let’s Encrypt verifica via DNS pubblico, non tramite richieste HTTP al server.

Spesso basta:

• rifare la richiesta
• attendere un po’
• controllare che non ci siano problemi di permessi/token

5) Hai usato la Global API Key invece del Token

Può funzionare in alcuni flussi legacy ma Cloudflare raccomanda gli API token al posto della Global API Key.

Buone pratiche:

• usare un token limitato a una sola zone
• non usare la Global API Key
• includere sia *.tuodominio.it sia tuodominio.it
• non cancellare il certificato dopo averlo associato ai proxy host
• controllare ogni tanto che il rinnovo automatico continui a funzionare

C’è anche un aspetto di sicurezza: Let’s Encrypt segnala che nel DNS-01 le credenziali API restano sul server quindi vanno trattate con attenzione.

UniFi OS Server rappresenta una soluzione sempre più interessante per chi desidera centralizzare la gestione della propria infrastruttura di rete in modo semplice, moderno e scalabile.

Installarlo su Ubuntu 24.04 permette di sfruttare una piattaforma stabile, aggiornata e adatta sia ad ambienti domestici evoluti sia a contesti professionali di piccole e medie dimensioni.

In questo articolo vedremo come eseguire l’installazione e la configurazione base di UniFi OS Server su Ubuntu 24.04, partendo dai prerequisiti fino ai primi passaggi fondamentali per rendere il sistema operativo e pronto alla gestione dei dispositivi UniFi.

L’obiettivo è fornire una guida pratica e lineare, utile per chi vuole avvicinarsi a questa piattaforma senza perdersi in configurazioni complesse fin dall’inizio.

Al termine della procedura avrai un’istanza funzionante di UniFi OS Server, configurata correttamente e pronta per essere personalizzata in base alle esigenze della tua rete.

ATTENZIONE: oggi UniFi OS Server è il metodo nuovo e consigliato da Ubiquiti per il self-hosting, e sostituisce il vecchio UniFi Network Server. Su Linux, Ubiquiti richiede Ubuntu 23.04+ e usa Podman + slirp4netns per l’installazione. L’ultima release che risulta disponibile è UniFi OS Server 5.0.6 for Linux (x64).

PREREQUISITI

Ubiquiti indica la seguente configurazione per Linux:

• Ubuntu 23.04 o superiore
• CPU x86-64
• almeno 2 GB RAM
• almeno 10 GB liberi
• podman 4.3.1+ e slirp4netns 1.2+

AGGIORNAMENTO DEL SISTEMA

sudo apt update
sudo apt full-upgrade -y
sudo reboot

Dopo il riavvio rientrare via terminale/SSH.

INSTALLAZIONE DI PODMAN E SLIRP4NETNS

Questo è il passaggio ufficiale richiesto da Ubiquiti per Linux.

sudo apt-get update
sudo apt-get install -y podman slirp4netns

Controllare le versioni installate con i seguenti comandi:

podman --version

Dovremmo visualizzare un output simile al seguente:

podman version 4.9.3

Quindi eseguire il comando:

slirp4netns --version

Dovremmo visualizzare un output simile al seguente:

slirp4netns version 1.2.1
commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.5

DOWNLOAD DELL’INSTALLAER DI UNIFI OS SERVER

Ubiquiti indica di prendere il link diretto del file Linux x64 dalla pagina download o dalle release, poi scaricarlo con curl o wget, renderlo eseguibile ed eseguirlo.

Apri la pagina download di UniFi OS Server e copia il link dell’ultima release Linux (x64) disponbile.

https://ui.com/download/software/unifi-os-server

NOTA BENE: al momento della stesura del seguente articolo l’ultima versione disponibile è la UniFi OS Server 5.0.6 for Linux (x64)

Sul server Ubuntu eseguire i comandi di seguito risporati sostituendo l’URL con quello copiato:

cd /tmp
wget "https://fw-download.ubnt.com/data/unifi-os-server/1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64"

Controllare il nome del file scaricato con il comando:

ls -lh

Dovremmo trovare il seguente file:

1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64

RENDERE IL FILE ESEGUIBILE E AVVIARE L’INSTALLAZIONE

Eseguire il comando:

chmod +x 1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64

Quindi avviare l’installazione con il comando:

sudo ./1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64

Alla domanda:

You are about to install UOS Server version 5.0.6. Proceed? (y/N):

Premere Y

Se è andato tutto a buon fine dovremmo visualizzare il seguente output:

INFO Installing UOS Server 5.0.6...
INFO Checking compatible podman runtime available...
INFO Checking disk space for required directories...
INFO - /home/: Requires 15.00 GB, available 28.17 GB
INFO - /var/lib/uosserver/: Requires 1.00 GB, available 28.17 GB
INFO - /usr/local/bin/: Requires 0.12 GB, available 28.17 GB
INFO - /tmp/: Requires 2.00 GB, available 28.17 GB
INFO - /var/tmp/: Requires 2.00 GB, available 28.17 GB
INFO All disk space requirements met.
INFO Checking ports...
INFO Adding uosserver user and group...
INFO Adding user 'root' to 'uosserver' group...
INFO Creating /var/lib/uosserver dir...
INFO Creating /var/lib/uosserver/logs dir...
INFO Creating /var/lib/uosserver/bin dir...
INFO Creating /home/uosserver/tmp dir...
INFO Setting up /usr/local/bin/uosserver binary...
INFO Setting up /usr/local/bin/uosserver-purge binary...
INFO Setting up /var/lib/uosserver/bin/discovery binary...
INFO Setting up /var/lib/uosserver/bin/pasta binary...
INFO Setting up /var/lib/uosserver/bin/uosserver-service service binary...
INFO Setting up /var/lib/uosserver/bin/updater-service binary...
INFO Initializing podman conf...
INFO Allowing raw socket execution...
INFO Creating file /var/lib/uosserver/server.conf...
INFO Config set UOS_UUID=8ad0470d-bf8d-595f-85a4-6adaac647f51
INFO Config set CONTAINER_VERSION=0.0.54
INFO Config set UOS_SERVER_VERSION=5.0.6
INFO Config set NETWORK_MODE=pasta
INFO Creating systemd services...
INFO Loading container image...
INFO [podman] Getting image source signatures
INFO [podman] Copying blob sha256:b7fe3d1983242adf9765bc16155a1dc9d621b7e54d32060f806fc121a65fd637
INFO [podman] Copying blob sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1
INFO [podman] Copying blob sha256:632a1a8daa7590599cc733470c6fa2cf39735430febf72016f33ed37a943e237
INFO [podman] Copying blob sha256:cf4be161aa1de3cf14fa15d9611898552c9cc01c18563acb37324d19077afbd6
INFO [podman] Copying blob sha256:9dedd62b9228b7f8a7c95677425772d778033ce15f979d2b08ec9e95d71eac10
INFO [podman] Copying blob sha256:0fb3170f3e0f99ca912f8d5768fedfac1b8ce6c99ce530eb38885cf3dd36961e
INFO [podman] Copying blob sha256:f7604bf526f0462afa853691be9d2e087358a1331bfa1a8e7f442c9350ac1fb9
INFO [podman] Copying blob sha256:41c4718d584d57ba2f4060f80b2afc40ddd79869da751ca66435acbf2fd32035
INFO [podman] Copying config sha256:0faf0b7f0e4ebcbbae964ab0876fab00e47c166d67e649daa4143f7c53e62977
INFO [podman] Writing manifest to image destination
INFO [podman] Loaded image: docker.io/library/uosserver:0.0.54
INFO Config set CONTAINER_IMAGE_NAME=docker.io/library/uosserver:0.0.54
INFO Starting container...
INFO 6972ac2043407a0ab6d699d312ad3a4f219e4f0078fa4610d7e866b39f72ab74
INFO run --detach --pids-limit 65536 --systemd=always --cap-add=NET_RAW --cap-add=NET_ADMIN --name uosserver --restart unless-stopped --health-cmd curl --fail http://127.0.0.1/api/ping || exit 1 --health-interval 60s --health-timeout 5s --health-retries 3 --network pasta:--ns-ifname,eth0,--map-host-loopback,203.0.113.113,--dns-forward,203.0.113.113 --add-host host.docker.internal:203.0.113.113 --add-host host.containers.internal:203.0.113.113 --dns 203.0.113.113 -e UOS_UUID=8ad0470d-bf8d-595f-85a4-6adaac647f51 -e UOS_SERVER_VERSION=5.0.6 -e FIRMWARE_PLATFORM=linux-x64 -v uosserver_persistent:/persistent -v uosserver_var_log:/var/log -v uosserver_data:/data -v uosserver_srv:/srv -v uosserver_var_lib_unifi:/var/lib/unifi -v uosserver_var_lib_mongodb:/var/lib/mongodb -v uosserver_etc_rabbitmq_ssl:/etc/rabbitmq/ssl -p 11443:443 -p 5005:5005 -p 9543:9543 -p 6789:6789 -p 8080:8080 -p 8443:8443 -p 8444:8444 -p 3478:3478/udp -p 5514:5514/udp -p 10003:10003/udp -p 11084:11084 -p 5671:5671 -p 8880:8880 -p 8881:8881 -p 8882:8882 docker.io/library/uosserver:0.0.54
INFO Config set CONTAINER_ARG_HASH=6972ac2043407a0ab6d699d312ad3a4f219e4f0078fa4610d7e866b39f72ab747689b15fbc14594ed82584a1393c33c78b2ab638c1cf7c0648f8cfb901c18913
INFO Waiting for container 'uosserver' to start (timeout: 60s)
INFO Container 'uosserver' is running. (elapsed: 0.0s)
INFO Waiting for systemd to be ready (timeout: 60s)
INFO Systemd is ready. (elapsed: 7.8s)
INFO Starting uosserver systemd service...
INFO Waiting for UOS Server to start...
WARN Timeout: Unifi-core did not start within 60 seconds.
WARN
!!! INSTALLATION COMPLETE !!!
To grant permission for a user to run 'uosserver' commands:
-> Add the user to the 'uosserver' group:
usermod -aG uosserver <username>
-> Then log out and log back in for the changes to take effect.
To get started with available commands, run:
uosserver help

WARNING: UOS Server startup timed out after 60 seconds. On low-powered devices, the web interface can take a few minutes to be accessible. Try opening it at: 192.168.1.120:11443

CONTROLLARE CHE IL SERVIZIO SIA ATTIVO

Ubiquiti indica che il servizio systemd si chiama uosserver.

Verificare lo stato con il comando:

systemctl status uosserver --no-pager

Se è tutto OK dovremmo un output simile al seguente:

● uosserver.service - Unifi OS Service
Loaded: loaded (/etc/systemd/system/uosserver.service; enabled; preset: enabled)
Active: active (running) since Sun 2026-03-22 13:23:30 UTC; 2min 39s ago
Main PID: 3096 (uosserver-servi)
Tasks: 8 (limit: 2262)
Memory: 8.0M (peak: 19.7M swap: 3.2M swap peak: 3.2M)
CPU: 3.866s
CGroup: /system.slice/uosserver.service
├─3096 /var/lib/uosserver/bin/uosserver-service
└─3111 /var/lib/uosserver/bin/discovery

Per abilitarlo all’avvio eseguire il comando:

sudo systemctl enable uosserver

Per riavviare il servizio eseguire il comando:

sudo systemctl restart uosserver

Per fermarlo/avviarlo manualmente eseguire i comandi:

sudo systemctl stop uosserver
sudo systemctl start uosserver

ACCESSO DA INTERFACCIA WEB

Per il login locale ai self-hosted Network Server, Ubiquiti indica la porta 11443.

Apri da un qualsiasi browser il seguente link:

https://IP_DEL_SERVER:11443

Accettare l’eventuale avviso del certificato e completare il wizard.

RIMOZIONE DI UNIFI OS SERVER

Di seguito una sequenza completa per rimuovere i residui di UniFi OS Server, compresi servizio, processi, container, binari, utente e gruppo uosserver.

Eseguire tutti i comandi come root oppure con sudo.

sudo systemctl stop uosserver 2>/dev/null || true
sudo systemctl disable uosserver 2>/dev/null || true
sudo pkill -f uosserver || true
sudo pkill -u uosserver 2>/dev/null || true

podman rm -f $(podman ps -aq) 2>/dev/null || true
podman image prune -a -f 2>/dev/null || true

sudo rm -f /usr/local/bin/uosserver
sudo rm -f /etc/systemd/system/uosserver.service
sudo systemctl daemon-reload

sudo rm -rf /var/log/uosserver
sudo rm -rf /var/lib/uosserver
sudo rm -rf /opt/uosserver
sudo rm -rf /usr/local/share/uosserver
sudo rm -rf /home/uosserver

sudo userdel -r uosserver 2>/dev/null || sudo userdel uosserver 2>/dev/null || true
sudo groupdel uosserver 2>/dev/null || true

sudo cp /etc/passwd /etc/passwd.bak
sudo cp /etc/shadow /etc/shadow.bak
sudo cp /etc/group /etc/group.bak
sudo cp /etc/gshadow /etc/gshadow.bak

sudo sed -i '/^uosserver:/d' /etc/passwd
sudo sed -i '/^uosserver:/d' /etc/shadow
sudo sed -i '/^uosserver:/d' /etc/group
sudo sed -i '/^uosserver:/d' /etc/gshadow

getent passwd uosserver
getent group uosserver
id uosserver
grep '^uosserver:' /etc/passwd /etc/shadow /etc/group /etc/gshadow

Al termine dell’esecuzione dei comandi se è andato tutto a buon fine dovremmo visualizzare il seguente output:

nessun output per getent

Negli ultimi anni l’automazione dell’infrastruttura è diventata un elemento fondamentale per semplificare la gestione degli ambienti IT, migliorare la coerenza delle configurazioni e ridurre i tempi operativi.

In questo contesto AWX la versione open source di Ansible Tower rappresenta una soluzione particolarmente interessante per centralizzare playbook, job template, credenziali e workflow di automazione attraverso un’interfaccia web intuitiva.

Allo stesso tempo l’adozione di distribuzioni Kubernetes leggere come K3S ha reso possibile eseguire workload containerizzati anche in ambienti più snelli, di laboratorio o edge, senza rinunciare ai vantaggi dell’orchestrazione.

Se a questo aggiungiamo Rancher, otteniamo un livello ulteriore di semplificazione nella gestione del cluster grazie a una console centralizzata e a strumenti pratici per il deployment e il monitoraggio delle applicazioni.

In questo articolo vedremo come eseguire l’installazione di AWX su K3S utilizzando Rancher analizzando i prerequisiti, i componenti necessari e i passaggi principali per arrivare a una piattaforma di automazione funzionante, moderna e facilmente amministrabile.

L’obiettivo è costruire un ambiente solido e replicabile utile sia per test che per scenari più strutturati.

PREREQUISITI

Un server Ubuntu 24.04 con queste caratterstiche:

• almeno 4 vCPU / 8 GB RAM come minimo pratico;
• meglio 8 vCPU / 16 GB RAM se vuoi usare Rancher + AWX senza sofferenze

un FQDN

porte aperte: 22, 80, 443

un utente con privilegi di sudo

Per Rancher su K3s conviene scegliere una versione Kubernetes supportata.

La matrice Rancher corrente indica supporto per K3s da v1.32 a v1.34, quindi in questa guida fisserò una release K3s v1.32.x per stare in zona sicura.

AGGIORNAMENTO DI UBUNTU E INSTALLAZIONE DEGLI STRUMENTI BASE

Aggiornare Ubuntu con i seguenti comandi:

sudo apt update && sudo apt -y upgrade
sudo apt -y install curl wget git vim jq apt-transport-https ca-certificates gnupg lsb-release

Controllare l’IP del server con il comando:

hostname -I

Supponiamo che l’IP sia 192.168.1.50.

Per il laboratorio puoi usare questi hostnames:

rancher.test.lab – 192.168.1.50

awx.test.lab – 192.168.1.50

INSTALLAZIONE DI K3S

Rancher documenta l’installazione di K3s con cluster-init anche su singolo nodo, così mantieni una via semplice verso una futura migrazione HA.

K3s installa anche i link a kubectl di default se non già presenti nel PATH.

Installare K3s fissando una release supportata con il comando:

curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="v1.32.6+k3s1" sh -s - server --cluster-init

Verificare che tutto sia ok con i seguenti comandi:

sudo systemctl status k3s --no-pager
sudo kubectl get nodes -o wide
sudo kubectl get pods -A

Configurare il kubeconfig per il tuo utente con i seguenti comandi:

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
export KUBECONFIG=~/.kube/config
echo 'export KUBECONFIG=~/.kube/config' >> ~/.bashrc

Verificare i nodi con il comando:

kubectl get nodes

Dovremmo visualizzare un output simile al seguente:

NAME STATUS ROLES AGE VERSION
vm-srv-ubu-awx Ready control-plane,etcd,master 76s v1.32.6+k3s1

CONTROLLO DI TRAEFIK E DELLO STORAGE CLASS

K3s include di default l’ingress controller. Per Rancher non serve installarne uno extra su K3s.

Verificare che Traefik sia presente con i comandi:

kubectl get pods -n kube-system | grep traefik
kubectl get svc -n kube-system

Verificare lo storage class di default con il comando:

kubectl get storageclass

Su K3s normalmente trovi local-path come default sufficiente per una AWX con database interno in ambiente lab.

INSTALLAZIONE DI HELM

Rancher richiede Helm 3.

Eseguire i comandi per installare Helm:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod +x get_helm.sh
sudo ./get_helm.sh
helm version

Dovremmo visualizzare il seguente output:

version.BuildInfo{Version:"v3.20.0", GitCommit:"b2e4314fa0f229a1de7b4c981273f61d69ee5a59", GitTreeState:"clean", GoVersion:"go1.25.6"}

INSTALLAZIONE DI CERT-MANAGER

La documentazione cert-manager raccomanda l’installazione via chart Helm/OCI e con crds.enabled=true.

La release indicata nella documentazione corrente è v1.19.4.

Eseguire i comandi:

helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \
--version v1.19.4 \
--namespace cert-manager \
--create-namespace \
--set crds.enabled=true

Aspettare che sia pronto quindi eseguire i comandi:

kubectl rollout status deployment -n cert-manager cert-manager
kubectl rollout status deployment -n cert-manager cert-manager-webhook
kubectl rollout status deployment -n cert-manager cert-manager-cainjector
kubectl get pods -n cert-manager

INSTALLAZIONE DI RANCHER

Rancher si installa via Helm nel namespace cattle-system esposto tramite Ingress HTTPS.

Il chart supporta opzioni come bootstrapPassword, hostname e ingress.tls.source.

Aggiungere il repository e creare il namespace con i seguenti comandi:

helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
helm repo update
kubectl create namespace cattle-system

Opzione più semplice per lab: certificato generato da Rancher

Usa ingress.tls.source=rancher che è il default del chart Rancher. Il chart supporta anche bootstrapPassword.

Eseguire i comandi:

helm upgrade --install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=rancher.192.168.1.50.sslip.io \
--set bootstrapPassword='AdminTemp!2026' \
--set replicas=1

Dovremmo visualizzare il seguente output:

Rancher Server has been installed. Rancher may take several minutes to fully initialize.

Please standby while Certificates are being issued, Containers are started and the Ingress rule comes up.

Check out our docs at https://rancher.com/docs/

## First Time Login

If you provided your own bootstrap password during installation, browse to https://rancher.mypsx.net to get started.
If this is the first time you installed Rancher, get started by running this command and clicking the URL it generates:

```
echo https://rancher.mypsx.net/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}')
```

To get just the bootstrap password on its own, run:

```
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}{{ "\n" }}'
```

Happy Containering!

A questo punto eseguire il rollout con i seguenti comandi:

kubectl rollout status deployment -n cattle-system rancher
kubectl get pods -n cattle-system
kubectl get ingress -n cattle-system

Controllare l’URL di bootstrap con il comando:

echo "https://rancher.192.168.1.50.test.lab/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}')"

Aprire l’URL nel browser. Al primo accesso accettare il certificato self-signed quindi inserire la password

Cliccare su Login with Local User

Inserire l’URL del server corretto

Rancher richiede HTTPS e la sua documentazione mostra hostname come parametro fondamentale del chart.

Cliccare Continue

Se tutto è andato bene dovremmo visualizzare la Dashboard del Rancher

Quando si accede in Rancher la prima cosa che si vede è il cluster locale.

Questo cluster può ospitare anche AWX.

Per un lab va bene usare il local cluster.

In produzione di solito si separa il cluster di management da quello dei workload.

INSTALLAZIONE DI AWX OPERATOR

L’AWX Operator si installa nel cluster e gestisce il ciclo di vita di AWX nello stesso namespace.

L’installazione ufficiale base usa Kustomize con una kustomization.yaml che punta al tag dell’operator.

Creare il namespace con il comando:

kubectl create namespace awx

Creare una cartella di lavoro con il comando:

mkdir -p ~/awx-operator-install
cd ~/awx-operator-install

Creare kustomization.yaml con il comando:

NOTA BENE: Consiglio di usare un tag esplicito invece del branch devel. La doc ufficiale mostra proprio questo schema con github.com/ansible/awx-operator/config/default?ref=<tag>.

cat > kustomization.yaml <<'EOF'
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- github.com/ansible/awx-operator/config/default?ref=2.7.2

images:
- name: quay.io/ansible/awx-operator
newTag: 2.7.2

namespace: awx
EOF

Applicare con il comando:

kubectl apply -k .

Verificare con i seguenti comandi:

kubectl get pods -n awx
kubectl get deployments -n awx
kubectl get crd | grep awx

Dovremmo vedere il seguente output:

kubectl get pods -n awx
kubectl get deployments -n awx
kubectl get crd | grep awx
NAME READY STATUS RESTARTS AGE
awx-operator-controller-manager-59669d4d4-6wcck 0/2 ErrImagePull 0 20s
NAME READY UP-TO-DATE AVAILABLE AGE
awx-operator-controller-manager 0/1 1 0 20s
awxbackups.awx.ansible.com 2026-03-08T16:54:22Z
awxrestores.awx.ansible.com 2026-03-08T16:54:22Z
awxs.awx.ansible.com 2026-03-08T16:54:22Z
root@vm-srv-ubu-awx:~/awx-operator-install# kubectl get pods -n awx
NAME READY STATUS RESTARTS AGE
awx-operator-controller-manager-59669d4d4-6wcck 1/2 ImagePullBackOff 0 36s
root@vm-srv-ubu-awx:~/awx-operator-install# kubectl get deployments -n awx
NAME READY UP-TO-DATE AVAILABLE AGE
awx-operator-controller-manager 0/1 1 0 44s
root@vm-srv-ubu-awx:~/awx-operator-install# kubectl get crd | grep awx
awxbackups.awx.ansible.com 2026-03-08T16:54:22Z
awxrestores.awx.ansible.com 2026-03-08T16:54:22Z
awxs.awx.ansible.com 2026-03-08T16:54:22Z

CREAZIONE DI AWX

L’operator supporta servizi ClusterIP, LoadBalancer e NodePort; per ingress di default non crea nulla finché non imposti ingress_type.

Supporta ingress_type: ingress e campi come ingress_class_name, ingress_hosts, ingress_annotations.

Di seguito riporto una configurazione pulita con:

• service interno ClusterIP
• Ingress gestito da Traefik
• hostname dedicato
• storage class local-path
• admin password predefinita in Secret
• Crea la password admin

La documentazione AWX chiarisce che admin_password_secret deve essere un Secret Kubernetes; se non lo si passa, l’operator genera <resourcename>-admin-password.

Eseguire il comando:

cat > awx-admin-secret.yaml <<'EOF'
apiVersion: v1
kind: Secret
metadata:
name: awx-admin-password
namespace: awx
stringData:
password: "AwxAdmin!2026"
EOF

Applicare con il comando:

kubectl apply -f awx-admin-secret.yaml

Creare il manifest di AWX con il comando:

cat > awx.yaml <<'EOF'
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
name: awx
namespace: awx
spec:
admin_user: admin
admin_email: admin@example.local
admin_password_secret: awx-admin-password

service_type: ClusterIP

ingress_type: ingress
ingress_class_name: traefik
ingress_annotations: |
kubernetes.io/ingress.class: traefik
ingress_hosts:
- hostname: awx.mypsx.net

projects_persistence: true
projects_storage_class: local-path
projects_storage_size: 5Gi

postgres_storage_class: local-path
postgres_storage_requirements:
requests:
storage: 8Gi

web_resource_requirements:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1
memory: 2Gi

task_resource_requirements:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1
memory: 2Gi
EOF

Applicare con il comando:

kubectl apply -f awx.yaml

Controllare l’avanzamento con il comando:

kubectl get pods -n awx -w

Quando i pod sono pronti eseguire i comandi:

kubectl get awx -n awx
kubectl get svc -n awx
kubectl get ingress -n awx
kubectl get pvc -n awx

RECUPERARE LA PASSWORD DI AWX

Se hai usato il Secret che ti ho fatto creare in precedenza la password è già quella impostata.

In ogni caso la doc ufficiale AWX indica che la password è leggibile dal secret <resourcename>-admin-password.

Nel nostro caso eseguire il comando:

kubectl get secret awx-admin-password -n awx -o jsonpath="{.data.password}" | base64 --decode ; echo

Aprire quindi il seguente link da qun qualsiasi browser:

http://awx.mypsx.net

oppure se il tuo ingress forza HTTPS in base alla configurazione del controller/certificato aprire il seguente link:

https://awx.mypsx.net

Se è tutto corretto dovremmo visualizzare la pagina di accesso di AWX

AWX NON RISPONDE SUBITO: COSA FARE?

Controlli rapidi da eseguire:

kubectl describe awx awx -n awx
kubectl logs -n awx deployment/awx-operator-controller-manager
kubectl get events -n awx --sort-by=.metadata.creationTimestamp
kubectl describe ingress -n awx
kubectl describe pvc -n awx

I problemi più comuni sono questi:

hostname non risolto: verifica ping awx.test.lab

pod postgres in errore: quasi sempre storage/PVC

Ingress creato ma la pagina non si apre: verificare che Traefik sia attivo in kube-system

AWX ancora Progressing: aspettare qualche minuto, il primo deploy scarica molte immagini e ci va tempo

AGGIORNAMENTI FUTURI

K3s: usa una versione supportata dalla matrice Rancher prima di aggiornare Rancher o Kubernetes.

cert-manager: aggiornalo con Helm, mantenendo una release supportata.

AWX Operator: usa tag espliciti e non devel in produzione/lab stabile. La doc base dell’operator è proprio costruita attorno al concetto di tag/versione.

In questa guida vedremo come installare e configurare un Server AI completo e replicabile basato su Ubuntu 24.04 LTS e hardware Intel N100, ottimizzato per ambienti domestici o piccoli laboratori IT.

ARCHITETTURA E PREREQUISITI

L’infrastruttura prevede:

Ollama per l’esecuzione dei modelli LLM locali
Open-WebUI come interfaccia web moderna stile ChatGPT
Agent AI (RAG Server) per estendere le funzionalità con documenti, embedding e automazioni
Nginx con HTTPS per un accesso sicuro
Ottimizzazioni CPU, RAM (zram), LVM e hardening di base
La guida è completamente replicabile, strutturata passo-passo e pensata per ottenere un sistema:
Performante anche su hardware a basso consumo e Sicuro (zero porte AI esposte)

Pronto per utilizzo personale o laboratorio professionale

Al termine avrai un’infrastruttura AI locale stabile, organizzata e pronta per essere integrata nella tua rete (anche su VLAN dedicata).

Base: Ubuntu 24.04 LTS minimal
Hardware: Intel N100 – 16/32GB RAM – NVMe

INSTALLAZIONE DEL SISTEMA BASE

Aggiornamento sistema

sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y

OTTIMIZZAZIONE N100

Governor performance

sudo apt install cpufrequtils -y
echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils
sudo systemctl restart cpufrequtils

ZRAM

sudo apt install zram-tools -y
sudo nano /etc/default/zramswap

Impostare la percentuale della memoria adeguata (es 50%)

sudo systemctl restart zramswap

INSTALLAZIONE DOCKER

sudo apt install docker.io -y
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker $USER
newgrp docker

INSTALLAZIONE OLLAMA

curl -fsSL https://ollama.com/install.sh | sh

Procedere con l’Hardening Ollama:

sudo systemctl edit ollama

Inserire il seguente output:

ini
[Service]
Environment="OLLAMA_NO_CLOUD=true"
Environment="OLLAMA_HOST=127.0.0.1"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_QUEUE=8"
Environment="OLLAMA_KEEP_ALIVE=5m"

Poi:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Scaricare i modelli consigliati

ollama pull phi3
ollama pull mistral
ollama pull deepseek-coder:6.7b-instruct-q4_K_M
ollama pull nomic-embed-text

INSTALLAZIONE OPEN-WEBUI

Creare una cartella persistente con i seguenti comandi:

sudo mkdir -p /data-ai/openwebui
sudo chown -R $USER:$USER /data-ai

Avviare il container sicuro con il comando:

docker run -d --name open-webui -p 127.0.0.1:3000:8080 -e OLLAMA_BASE_URL=http://127.0.0.1:11434 -e CORS_ALLOW_ORIGIN=https://ai.local -v /data-ai/openwebui:/app/backend/data --restart always ghcr.io/open-webui/open-webui:main

INSTALLAZIONE DI NGINX PER HTTPS

sudo apt install nginx -y
sudo mkdir -p /etc/nginx/ssl

Generare un certificato self-signed con i seguenti comandi:

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:4096 \
-keyout /etc/nginx/ssl/ai.key \
-out /etc/nginx/ssl/ai.crt

Procedere con la configurazione del vhost:

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

Contenuto completo da copiare all’interno del file di configurazione:

nginx
server {
listen 80;
server_name ai.local;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl;
server_name ai.local;

ssl_certificate /etc/nginx/ssl/ai.crt;
ssl_certificate_key /etc/nginx/ssl/ai.key;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header X-XSS-Protection "1; mode=block";
server_tokens off;

location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

Attivare il sito con i comandi:

sudo ln -s /etc/nginx/sites-available/ai /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

FIREWALL BASE

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 443/tcp
sudo ufw allow from 192.168.3.0/24 to any port 22
sudo ufw enable

VERIFICA FINALE

ss -tulnp

Deve risultare:

0.0.0.0:443
0.0.0.0:80
0.0.0.0:22
127.0.0.1:3000
127.0.0.1:11434

BACKUP CONFIGURAZIONE

sudo mkdir -p /data-ai/backups

sudo tar -czf /data-ai/backups/ai_stack_backup_$(date +%F).tar.gz /etc/nginx /etc/systemd/system/ollama.service.d /data-ai /home/$USER/.ollama

Negli ultimi anni l’infrastruttura iperconvergente (HCI) è diventata uno standard di riferimento per chi desidera ambienti IT più semplici, scalabili e performanti.

Tra le soluzioni più interessanti in questo ambito troviamo Nutanix Community Edition (CE) 2.1, la versione gratuita pensata per laboratori, test e ambienti di apprendimento.

Installare Nutanix CE su VMware ESXi 8 rappresenta un’ottima opportunità per sperimentare concretamente le funzionalità della piattaforma Nutanix senza dover disporre di hardware dedicato.

Grazie alla virtualizzazione nested, è possibile creare un laboratorio completo direttamente sopra ESXi, ideale per amministratori di sistema, consulenti IT e appassionati che vogliono approfondire il funzionamento di AOS, Prism e dei principali componenti dell’ecosistema Nutanix.

In questo articolo vedremo passo dopo passo come installare e configurare correttamente Nutanix Community Edition 2.1 su VMware ESXi 8, partendo dai prerequisiti fino alla prima configurazione base del cluster, con suggerimenti pratici per evitare gli errori più comuni e ottenere un ambiente stabile e funzionante sin dal primo avvio.

PREREQUISITI

I requisiti per Nutanix CE sono:

Minimo 32GB di memoria
Minimo 4 core CPU
Minimo 64GB di Boot Disk
Minimo 200GB di disco Hot Tier
Minimo 500GB di disco cold Tier

Download della ISO Nutanix Community Edition al seguente link:

Download Nutanix Community Edition

ATTENZIONE: per scaricare la ISO è necessaria la registrazione con una mail aziendale

CREAZIONE E CONFIGURAZIONE DELLA VM SU VSPHERE

Accedere al vCenter o all’host ESXi singolo quindi selezionare New Virtual Machine

Selezionare l’opzione Create a new virtual machine quindi cliccare Next

Inserire il nome della VM, scegliere la location quindi cliccare Next

Selezionare l’Host quindi cliccare Next

Selezionare il Datastore quindi cliccare Next

Selezionare la compatibilità quindi cliccare Next

Configurare i seguenti parametri come di seguito:

Guest OS Family: Linux

Guest OS Version: CentOS 7 (64-bit)

Cliccare Next

Impostare l’Hardware della VM come da Prerequisiti quindi agganciare la ISO di Nutanix CE. Cliccare Next

ATTENZIONE: dato che è un installazione Nested è indispensabile attivare l’opzione relativa alla CPU Expose hardware assisted virtualization to the guest OS

Selezionare l’opzione CPU Expose hardware assisted virtualization to the guest OS quindi cliccare OK

Leggere il riepilogo quindi cliccare Finish per terminare la creazione della VM

Selezionare l’Host dove abbiamo creato la Vm quindi vSwitch → Security → Edit

Sul Virtual Switch dove è collegata la VM è necessario abilitare:

Promiscuous Mode → Accept

MAC Address Changes → Accept

Forged Transmits → Accept

Al termine avviare la VM

INSTALLAZIONE DI NUTANIX

Dopo aver avviato la VM attendere la schermata di configurazione

In questa fase è indispensabile definire:

• Disk Selection: il disco dove andremo ad installare Nutanix
• Host IP Address: AHV (Acropolis Hypervisor) è l’hypervisor di Nutanix. Lo si utilizza per l’Accesso SSH all’host, per la Gestione di basso livello e per il Troubleshooting tecnico
• CVM IP Address: CVM (Controller Virtual Machine) è una VM speciale che gira sopra AHV. Il CVM si occupa di:

Storage distribuito (Nutanix Distributed Storage Fabric)

• Replica dati
• Compressione e deduplicazione
• Gestione del cluster
• Servizi di storage per tutte le VM

Quindi cliccare Next Page per proseguire

Accettare l’EULA quindi cliccare Start

ATTENZIONE: scrollare fino in fondo il testo della licenza altrimenti l’installazione andrà in errore

Attendere qualche minuto fino al termine dell’installazione

Rimuovere la ISO dalla VM quindi premre Y per riavviare il server

Poiché non abbiamo specificato i server DNS durante la creazione del cluster, Community Edition configurerà due server DNS di Google.

CONFIGURAZIONE DEL CLUSTER

Accedere in SSH al Controller Virtual Machine (CVM)

Le credenziali di accesso sono:

USER: nutanix

PASSWORD: nutanix/4u

Verificare lo stato del cluster con il comando:

cluster status

Dovremmo visualizzare il seguente output:

863Z CRITICAL MainThread cluster:3241 Cluster is currently unconfigured. Please create the cluster.

Questo messaggio vuol dire che Nutanix CE è installato ma il cluster non è stato ancora creato.

Per creare il cluster eseguire il comando:

cluster -s IP_CVM create

NOTA BENE: al posto di IP_CVM inserire l’IP

A questo punto attendere dai 5 ai 10 minuti fin quando non visualizziamo il seguente output:

The state of the cluster: start
Lockdown mode: Disabled

CVM: 192.168.80.30 Up, ZeusLeader
Xmount UP [67112, 67311, 67312, 67364]
IkatProxy UP [66890, 67063, 67064, 67065]
Zeus UP [62547, 62606, 62607, 62608, 62617, 62635]
Scavenger UP [67121, 67358, 67359, 67360]
SysStatCollector UP [72320, 72450, 72451, 72452]
IkatControlPlane UP [72497, 72632, 72633, 72634]
SSLTerminator UP [72543, 72918, 72919]
SecureFileSync UP [73035, 73425, 73426, 73427]
Medusa UP [76451, 76594, 76595, 76608, 76940]
DynamicRingChanger UP [81714, 81831, 81832, 81878]
Pithos UP [81767, 81980, 81981, 81995]
InsightsDB UP [81861, 82101, 82102, 82117]
Athena UP [82039, 82283, 82284, 82285]
Mercury UP [82109, 82410, 82411, 82427]
Mantle UP [82436, 83305, 83306, 83342]
VipMonitor UP [84502, 84503, 84504, 84505, 84512]
Stargate UP [84708, 84993, 84994, 85053, 85054]
InsightsDataTransfer UP [85983, 86901, 86902, 86924, 86925, 86926, 86927, 86928, 86929]
GoErgon UP [86486, 87087, 87088, 87102]
Cerebro UP [86946, 87182, 87183, 87327]
Chronos UP [87097, 87266, 87267, 87320]
Curator UP [87488, 89412, 89413, 89871]
Prism UP [89195, 90404, 90405, 90544, 91212, 91335]
Hera UP [90080, 91028, 91029, 91030]
AlertManager UP [90500, 91141, 91142, 91261]
Arithmos UP [91407, 91715, 91716, 91752]
Catalog UP [91631, 91862, 91863, 91864, 91880]
Acropolis UP [92300, 93155, 93156, 96895]
Castor UP [93282, 94130, 94131, 94170, 94390]
Uhura UP [93378, 94355, 94356, 95233]
NutanixGuestTools UP [94347, 95269, 95270, 95317, 95468]
MinervaCVM UP [102317, 103168, 103169, 103171]
ClusterConfig UP [102778, 103459, 103460, 103461, 103480]
APLOSEngine UP [103370, 103972, 103973, 103975]
APLOS UP [107523, 108515, 108516, 108517]
PlacementSolver UP [108130, 108742, 108743, 108744, 108761]
Lazan UP [108424, 109136, 109137, 109138]
Polaris UP [109259, 110216, 110217, 110416]
Delphi UP [109699, 110725, 110726, 110727, 110748]
Security UP [110843, 111542, 111543, 111545]
Flow UP [111445, 112690, 112691, 112692, 112708]
Anduril UP [112736, 113445, 113446, 113447, 113481]
Narsil UP [113309, 114179, 114180, 114181]
XTrim UP [113492, 114735, 114736, 114738]
ClusterHealth UP [114066, 115634, 116420, 116423, 116431, 116446, 116603, 116604, 116613, 116619, 116620, 116735, 116736, 116743, 116753, 116754, 116755, 116756, 116757, 116766, 116955, 116956, 117043, 117044, 117133, 117134, 117148, 117149]
2026-02-22 11:31:09,341Z INFO MainThread cluster:1745 Running CE cluster post-create script
2026-02-22 11:31:27,377Z INFO MainThread cluster:3465 Success!

ACCESSO ALLA GUI WEB DI NUTANIX

Il cluster è accessibile da un qualsiasi browser tramite https://<cvm_ip>:9440.

Accedere con le seguente credenziali:

USER: admin

PASSWORD: nutanix/4u

Procedere con il cambio password

Accedere con la nuova password

Inserire le credenziali creare in fase di registrazione al portale Nutanix

Se abbiamo fatto correttamante dovremmo visualizzare la Dashboard di Nutanix come mostrato nell’immagine sovrastante

CONCLUSIONI

L’installazione e la configurazione base di Nutanix Community Edition (CE) 2.1 su VMware ESXi 8 rappresentano un’ottima opportunità per approfondire in modo pratico il funzionamento dell’ecosistema Nutanix senza la necessità di disporre di hardware dedicato.

Attraverso pochi passaggi mirati è possibile creare un ambiente di laboratorio funzionale ideale per test, formazione e sperimentazione.

Abbiamo visto come preparare correttamente la macchina virtuale su ESXi configurare le risorse in modo adeguato e completare la fase di bootstrap del cluster.

Una corretta pianificazione iniziale soprattutto in termini di CPU, RAM e storage è fondamentale per garantire stabilità e performance accettabili, anche in un contesto nested.

Nutanix CE 2.1 consente di esplorare funzionalità chiave come AHV, Prism e la gestione dello storage distribuito, offrendo un’esperienza molto vicina a quella di un ambiente enterprise.

Sebbene non sia pensata per ambienti di produzione rimane uno strumento estremamente potente per chi desidera acquisire competenze concrete sull’infrastruttura iperconvergente.

Il passo successivo? Approfondire funzionalità avanzate come la creazione di macchine virtuali su AHV, la gestione delle reti virtuali, snapshot, replica e integrare il laboratorio con altre tecnologie per simulare scenari reali.