Proxmox – SDN con zona VLAN

La SDN di Proxmox con zone VLAN ha una limitazione che non è immediatamente visibile e non viene limitata dalla GUI purtroppo.. poi pensandoci è normale che non si possa fare, pero’ se la GUI te lo dicesse sarebbe meglio.

Dentro a SDN->Zone puoi fare parecchi tipi di zona, fra questa la comodissima ‘ZONA VLAN’ che in sostanza sarebbe (passami il termine) la stessa feature degli switch distribuiti di Vmware. In sostanza invece di andare a definire i bridge nodo per nodo con la solita nomenclatura “vmbr0.vlanID” qui puoi farti una specie di alias che quando attacchi la VM su ‘carsano’ sta a significare che in SDN hai fatto un ‘carsano che equivale a vmbr0.123 – Fin qua tutto ok.. Se non fosse che mentre lo definisci ti scappo l’occhio un un flag con scritto SNAT e un tab con scritto ‘DHCP RANGE’.. quindi ti viene in mente che siccome stai configurando SDN puoi fare anche la ‘moltiplicazione dei pani e dei pesci’.. e li ti ci pianti.. semplicemente perche’ non si puo’ avere un DHCP distribuito sui server e un default gateway per far navigare la VM da dentro verso fuori. Purtroppo questa non-feature non viene fuori da nessuna parte escludendo i forum pieni di sistemisti con la testa rotta a furia di dare capocciate nei rack proxmox.. Sarebbe state semplice tirare fuori un messaggio che dice ‘per i miracoli ci stiamo ancora lavorando’. Quindi la SDN con zona VLAN funziona regolarmente ma non puoi avere un DHCP e un DGW per far uscire le tue VM.. Bastava saperlo mi sarei andato a prendere un gelato oggi pomeriggio.. invece mi sono ammazzato per cercare di trovare dove sbagliavo..

PS: Secondo me, il fatto che una zona VLAN non si veda (xke non si vede te lo garantisco) sui nodi dove è implementata ma si veda solo nella parte SDN, IMHO è una bella minchiata.

Saluti.

Wazuh – A cosa serve

La piattaforma Wazuh offre funzionalità XDR e SIEM per proteggere i carichi di lavoro cloud, container e server. Queste includono l’analisi dei dati di log, il rilevamento di intrusioni e malware, il monitoraggio dell’integrità dei file, la valutazione della configurazione, il rilevamento delle vulnerabilità e il supporto per la conformità normativa.

La soluzione Wazuh si basa sull’agente Wazuh, che viene distribuito sugli endpoint monitorati, e su tre componenti centrali: il server Wazuh, l’indicizzatore Wazuh e la dashboard Wazuh.

  • L’ indicizzatore di Wazuh è un motore di ricerca e analisi full-text altamente scalabile. Questo componente centrale indicizza e memorizza gli avvisi generati dal server Wazuh.
  • Il server Wazuh analizza i dati ricevuti dagli agenti. Li elabora tramite decodificatori e regole, utilizzando l’intelligence sulle minacce per individuare i noti indicatori di compromissione (IOC). Un singolo server può analizzare i dati provenienti da centinaia o migliaia di agenti e scalare orizzontalmente se configurato in cluster. Questo componente centrale viene utilizzato anche per gestire gli agenti, configurandoli e aggiornandoli da remoto quando necessario.
  • La dashboard di Wazuh è l’interfaccia utente web per la visualizzazione e l’analisi dei dati. Include dashboard predefinite per la ricerca di minacce, la conformità normativa (ad esempio, PCI DSS, GDPR, CIS, HIPAA, NIST 800-53), le applicazioni vulnerabili rilevate, i dati di monitoraggio dell’integrità dei file, i risultati della valutazione della configurazione, gli eventi di monitoraggio dell’infrastruttura cloud e altro ancora. Viene inoltre utilizzata per gestire la configurazione di Wazuh e per monitorarne lo stato.
  • Gli agenti Wazuh vengono installati su endpoint quali laptop, computer desktop, server, istanze cloud o macchine virtuali. Forniscono funzionalità di prevenzione, rilevamento e risposta alle minacce. Sono compatibili con sistemi operativi come Linux, Windows, macOS, Solaris, AIX e HP-UX.

Oltre alle funzionalità di monitoraggio basate su agenti, la piattaforma Wazuh è in grado di monitorare dispositivi senza agenti come firewall, switch, router o IDS di rete, tra gli altri. Ad esempio, i dati di log di un sistema possono essere raccolti tramite Syslog e la sua configurazione può essere monitorata tramite interrogazioni periodiche dei dati, via SSH o tramite API.

Zabbix Proxy su container con Sqlite

  1. Su Ubuntu 24.04 installa docker
  2. Lavora in “sudo -s” nella /root
  3. Fai una directory zabbix-proxy
  4. Crea una directory data con dentro sqlite e logs
  5. Dai permessi chmod -R 777 ./data/
  6. Crea un docker compose come quello che vedi qui sotto
  7. Fallo partire: docker “compose up -d”
  8. Controlla che stia su “docker ps” e anche “docker stats zabbix-proxy-sqlite”
  9. Quando si modifica il docker-compose bisogna fare “docker compose down’ e poi ‘docker compose up -d’

docker-compose.yml



services:
  zabbix-proxy-sqlite:
    image: zabbix/zabbix-proxy-sqlite3:7.0-ubuntu-latest
    container_name: zabbix-proxy-sqlite
    restart: unless-stopped

    # Limiti di risorse: proteggiamo la VM da 8GB
    deploy:
      resources:
        limits:
          memory: 1G    # Il container non supererà mai 1GB (ne usa circa 160MB ora)
        reservations:
          memory: 256M  # RAM garantita al boot

    ports:
      - "10051:10051"

    environment:
      # --- Connessione ---
      - ZBX_HOSTNAME=zp01
      - ZBX_SERVER_HOST=10.12.14.56
      - TZ=Europe/Rome

      # --- Database SQLite ---
      - ZBX_DBNAME=zabbixproxy01.sqlite

      # --- Ottimizzazione Performance (per 100 host) ---
      - ZBX_CONFIGCACHESIZE=32M      # Cache per la configurazione degli host
      - ZBX_HISTORYCACHESIZE=16M     # Buffer per i dati prima della scrittura su disco
      - ZBX_HISTORYINDEXCACHESIZE=4M # Velocizza l'indicizzazione dei dati

      # --- Tuning Processi ---
      - ZBX_STARTPOLLERS=10          # Numero di processi per interrogare gli host
      - ZBX_STARTPOLLERSUNREACHABLE=5 # Processi dedicati agli host offline
      - ZBX_STARTTRAPPERS=5          # Per dati inviati attivamente dagli agenti

    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./data/sqlite:/var/lib/zabbix/db_data
      - ./data/logs:/var/lib/zabbix/logs
    logging:
      driver: "json-file"
      options:
        max-size: "10m" # Ogni file di log massimo 10 Mega
        max-file: "3"   # Tiene solo gli ultimi 3 file


Update zabbix proxy containerized

Procedura definitiva per aggiornare un proxy Zabbix containerizzato (SQLite) — versione 7.0.x → 7.0.x

Questa procedura è valida per:

  • proxy Zabbix 7.0.x containerizzati
  • database SQLite interno
  • nessun dato da preservare (proxy online)
  • configurazione gestita via variabili ZBX_*
  • nessun bind‑mount del file di configurazione

È esattamente il modello che ora funziona.

1️⃣ Preparazione

1.1. Verifica versione attuale del proxy

bash

docker exec -it zabbix-proxy-sqlite zabbix_proxy -V

1.2. Verifica che il proxy sia online sul server

(UI → Administration → Proxies)

2️⃣ Scarica l’immagine aggiornata

bash

docker pull zabbix/zabbix-proxy-sqlite3:7.0-ubuntu-latest

Questo garantisce che il nuovo container userà l’ultima build della 7.0 LTS.

3️⃣ Spegni e parcheggia il vecchio container

bash

docker stop zabbix-proxy-sqlite
docker rename zabbix-proxy-sqlite zabbix-proxy-sqlite-old

Questo ti permette un rollback immediato.

4️⃣ Crea il nuovo container (modello corretto)

⚠️ Niente bind‑mount del file di configurazione. ⚠️ Nessun volume per il DB SQLite.

Il comando standard è:

bash

docker run -d \
  --name zabbix-proxy-sqlite \
  --restart unless-stopped \
  -p 10051:10051 \
  -e ZBX_SERVER_HOST="10.12.14.56" \
  -e ZBX_HOSTNAME="NOME_DEL_PROXY" \
  zabbix/zabbix-proxy-sqlite3:7.0-ubuntu-latest

Per gli altri proxy, cambia solo:

  • --name
  • ZBX_HOSTNAME

Esempio:

Codice

zabbixproxy02
zabbixproxy03

5️⃣ Verifica immediata

5.1. Container running

bash

docker ps | grep zabbix-proxy-sqlite

5.2. Log del proxy

bash

docker logs -f zabbix-proxy-sqlite

Devi vedere:

  • “Starting Zabbix Proxy…”
  • “received configuration data from server”
  • nessun errore sed
  • nessun errore sul log file
  • creazione del DB SQLite senza errori

5.3. Versione

bash

docker exec -it zabbix-proxy-sqlite zabbix_proxy -V

6️⃣ Verifica dal server Zabbix

UI → Administration → Proxies → proxy‑name

Controlla:

  • Last seen aggiornato
  • Stato Online
  • Nessun errore

7️⃣ Rollback (se necessario)

bash

docker stop zabbix-proxy-sqlite
docker rm zabbix-proxy-sqlite
docker rename zabbix-proxy-sqlite-old zabbix-proxy-sqlite
docker start zabbix-proxy-sqlite

Rollback istantaneo.

Copia di due directory

Se vuoi fare una copia di due directory su due NAS il comando migliore che tu possa utilizzare è RSYNC:

/bin/rsync -rtlhv –no-p –no-g –no-o –ignore-existing /volume1/a500-Musica/Music/ /volume1/music/

/bin/rsync -rtlhv –no-p –no-g –no-o –ignore-existing /volume1/a500-Photo/Photo/ /volume1/photo/

Sostituzione Sonicwall Alta Affidabilità con due nuove unità

Questa procedura serve a guidare la sostituzione di due firewall Sonicwall in alta affidabilità resi obsoleti dal passare del tempo, con una coppia di firewall in alta affidabilità.

Si assume la nuova coppia sia gia’ stata registrata, provata e configurata con la configurazione della vecchia coppia di firewall.

Si assume che il cluster HA sia funzionante e a regime (Primario Attivo e Secondario Stand by)

Occorre avere a disposizione un pc portatile con interfaccia ethernet configurata su un ip compatibile con l’interfaccia di management del firewall (se di fascia NSa) il quale è di default configurato con l’ip 192.168.1.254/24

  1. Etichettare tutti i cavi
  2. Spegnere il vecchio secondario, che deve essere in STAND-BY ovviamente.
  3. Smontare il vecchio secondario
  4. Montare il nuovo primario al posto del vecchio secondario
  5. Collegare i cavi al nuovo primario ma senza inserire sino a fondo le ethernet in modo che non siano collegate elettricamente ma pronte ad esserlo con una piccola pressione per minimizzare i tempi. L’interfaccia per l’alta disponibilità non deve essere collegata.
  6. Accendere il nuovo primario che (ripeto) non dovra’ avere i cavi elettricamente connessi.
  7. Attendere sino a che il nuovo primario sia pronto all’operativita’ (spie con la chiave inglese spente)
  8. Spegnere il vecchio primario
  9. Spingere le connessioni ethernet del nuovo primario in modo che siano elettricamente connesse.
  10. Effettuare i primi test per verificare che tutto sia perfettamente funzionante.
  11. Nota che l’interfaccia di alta disponibilità non è collegata.

NOTA BENE : In caso di problemi è sufficiente spegnere il nuovo primario ed accendere il vecchio primario per essere nella vecchia situazione sicuramente funzionante.

Se possibile lasciare questa configurazione per qualche giorno, in modo da essere perfettamente certi che il nuovo primario sia operativo esattamente come ci si aspetta.

Inserimento nuova unità secondaria

Per l’inserimento del nuovo secondario è sufficiente smontare il vecchio primario e al suo posto installare il nuovo secondario rispettando l’ordine delle interfacce ethernet. Ora è possibile collegare l’interfaccia di alta disponibilità. Accendere il nuovo secondario e aspettare. Il nuovo primario prenderà in carico il nuovo secondario, gli invierà la configurazione e lo farà ripartire.. dopo circa 10 minuti la pagina della gestione HA dovrebbe mostrare il primario attivo e il secondario in stand-by.

Proxmox aggiornamento da 8.4.16 a 9.1

Oggi 7 gennaio 2026 ho iniziato l’aggiornamento del nostro Proxmox 8.4.16 all’ultima versione. Elenco i passi necessari che ho fatto per questo aggiornamento.

A macro step questi sono i passi:

  • Allineamento di tutti i nodi all’ultima versione di PVE nel mio caso 8.4.16
  • Aggiornamento di CEPH da versione Reef (V.18) a Squid (V.19) su tutti i nodi
  • Aggiornamento di tutti i nodi alla V9.1 di PVE

Aggiornamento di CEPH da Reef a Squid

Questo si fa abbastanza velocemente: è sufficiente modificare le sorgenti ceph con
sed -i ‘s/reef/squid/’ /etc/apt/sources.list.d/ceph.list
e impostare il flag noout:
ceph osd set noout
Seguito da:
apt update
apt full-upgrade

Ovviamente su tutti i nodi.
Il flag di noout deve restare cosi’ sino alla fine dell’aggiornamento.

Aggiornamento da PVE V.8.4.16 a V9.1

Successivamente quando tutti i nodi sono su CEPH Squid si modificano le sorgenti APT in che da bookworm si modifica in trixie con un comando sed:

sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list
sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list.d/pve-no-subscription.list
sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list.d/pve-enterprise.list
sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list.d/pve-enterprise.list
sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list.d/ceph.list

Per verifica poi fa un:
grep -R “trixie” /etc/apt/sources.list /etc/apt/sources.list.d
dovresti vedere un bel po’ di file che matchano e poi un
grep -R “book” /etc/apt/sources.list /etc/apt/sources.list.d
e non dovrebbe darti nessun risultato
Ora puoi procedere con:
apt update
Seguito da:
apt dist-upgrade
e poi un ‘reboot’
Ovviamente su tutti i nodi.
Quando hai finito dovresti avere solo da togliere il flag noout, basta che lo fai su un nodo
ceph osd unset noout

Il tuo cluster ora è V9.1

Fonti:
https://pve.proxmox.com/wiki/Upgrade_from_8_to_9?utm_source=copilot.com#In-place_upgrade
https://pve.proxmox.com/wiki/Ceph_Reef_to_Squid

Disabilitare Hyper-V per abilitare la “nested virtualization” in Vmware Workstation

Fai girare questo script se continui a ricevere l’errore da Vmware Workstation che non puo’ abilitare la “Intel VT-x”

@echo off
echo Disattivazione di Hyper-V e funzionalità correlate…

:: Disattiva Hyper-V e componenti legati
dism /Online /Disable-Feature:Microsoft-Hyper-V-All /NoRestart
dism /Online /Disable-Feature:VirtualMachinePlatform /NoRestart
dism /Online /Disable-Feature:HypervisorPlatform /NoRestart
dism /Online /Disable-Feature:Microsoft-Windows-Subsystem-Linux /NoRestart
dism /Online /Disable-Feature:Containers /NoRestart
dism /Online /Disable-Feature:Windows-Defender-ApplicationGuard /NoRestart

:: Disattiva il caricamento dell’hypervisor all’avvio
bcdedit /set hypervisorlaunchtype off

:: Disabilita la sicurezza basata sulla virtualizzazione (VBS)
reg add “HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard” /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\Lsa” /v LsaCfgFlags /t REG_DWORD /d 0 /f

:: Disabilita Credential Guard (se attivo)
reg delete “HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard” /f

echo.
echo Riavviare il computer per applicare le modifiche.
pause

Ubuntu 24.04 – Estendere hard disk su VM

Segui questi passi:

Aumenta di quanto server il disco su Vmware

Fai ripartire la VM

Usa “cfdisk” via terminale sulla vm per effettuare il resize della partizione

Usa resize sulla partizione da allargare.

Successivamente vai su write

Ultimo step da shell usa il comando ” sudo resize2fs /dev/sda2″

Controlla con ‘df’ la nuova dimnsione della partizione.

fonte: https://www.youtube.com/watch?v=brR0G7Fg3i0

Qnap – Permessi particolari sulle cartelle nidificate.

Questo si applica quando abbiamo un utente, anche AD, che deve accedere in full control ad una cartella che è posizionata dentro ad una cartella in read-only per lui.

Occorre abilitare le “autorizzazione avanzate” come in figura

Poi nella GUI di Qnap nelle cartelle condivise dare accesso all’utente, come in figura togliendo “Applica le modifiche ai file e alle cartelle secondarie” per ovvi motivi.

successivamente via windows dare i permessi come segue per le cartelle ‘read only’:

Dare ‘Full Control’ alle cartelle che Mario Rossi deve avere il pieno accesso.