Pyinfra, LDAP e Proxmox: web UI operativa su bot.gazzi.net

Su bot.gazzi.net e’ stata realizzata una piccola piattaforma operativa per creare macchine virtuali Proxmox via browser, usando pyinfra come runner e una web UI protetta da autenticazione LDAP. L’obiettivo non era aggiungere un altro pannello generico, ma costruire un punto di ingresso pratico e controllato per lanciare provisioning mirati con parametri espliciti.

Il risultato finale e’ una UI raggiungibile su /pyinfra/, pubblicata dietro Nginx, autenticata contro ldap.gazzi.local e collegata al nodo Proxmox per lanciare job reali di creazione VM. Il flusso e’ stato progettato per essere operativo, leggibile e abbastanza sicuro da non lasciare in giro credenziali nel repository Git o nella UI.

Cosa e’ stato costruito

Il progetto e’ composto da tre elementi principali.

• una web UI interna pubblicata su bot.gazzi.net/pyinfra/
• un runner pyinfra che esegue localmente il job su bot.gazzi.local
• una logica di provisioning verso Proxmox via SSH con comandi qm

La UI non si limita a inviare un form. Raccoglie i parametri della VM, li valida, interroga Proxmox per suggerire dati utili e tiene lo storico dei job recenti con log ed esito.

Autenticazione e pubblicazione

L’accesso alla UI e’ protetto da autenticazione LDAP. Il login avviene contro ldap.gazzi.local, con sessione applicativa gestita lato Flask e pubblicazione del servizio tramite reverse proxy su proxy01. In pratica, l’utente entra da Web, si autentica e puo’ lanciare i job senza esporre direttamente l’accesso amministrativo al nodo Proxmox.

La pubblicazione e’ stata integrata anche nella landing di bot.gazzi.net, dove ora compare un link esplicito alla sezione Pyinfra accanto a Checkmk.

Parametri espliciti del provisioning

Una parte importante del lavoro e’ stata evitare campi impliciti o reti hardcoded. La form ora espone in modo chiaro i parametri principali della VM.

• VMID
• nome macchina
• utente e password della VM
• CPU, RAM e disco
• rete in modalita DHCP oppure IP statico
• bridge Proxmox
• VLAN Proxmox
• gateway
• CIDR esplicito per l’indirizzo statico

Questa scelta evita ambiguita operative. Se si usa DHCP, i campi statici vengono disabilitati. Se si usa IP statico, indirizzo, gateway e CIDR diventano obbligatori.

Discovery e validazioni preventive

Per ridurre errori banali, la UI interroga direttamente Proxmox prima del submit.

• puo’ cercare il primo VMID libero a partire da 100
• puo’ mostrare i bridge disponibili rilevati sul nodo
• puo’ mostrare le VLAN disponibili sul bridge scelto
• valida preventivamente la combinazione bridge + vlan prima di avviare il job

In questo modo la UI non lavora alla cieca: aiuta l’operatore a scegliere valori coerenti con lo stato attuale dell’host Proxmox.

Creazione dell’utente sudo nella VM

Il provisioning non si limita a creare la VM e avviare il cloud image. Durante il job viene generato uno snippet cloud-init dedicato per quella VM, che crea l’utente richiesto e lo abilita in sudoers. Questo permette di avere subito una macchina pronta per accesso operativo senza dipendere solo dagli utenti di default del template cloud.

Il comportamento e’ stato pensato per essere pratico ma anche consapevole sul lato sicurezza: la password non viene salvata nel repository Git e non compare nella lista job dell’interfaccia.

Gestione del rischio password

Un punto delicato era capire dove rimane la password della VM. La risposta, inizialmente, era: nello snippet cloud-init generato sul nodo Proxmox. Per evitare che quel file restasse in modo permanente, e’ stato aggiunto un cleanup automatico.

Quando la VM viene avviata subito, il job fa questo:

1. attende il QEMU Guest Agent
2. attende il completamento di cloud-init status --wait dentro il guest
3. rimuove il riferimento cicustom dalla VM
4. cancella lo snippet cloud-init dal nodo Proxmox

Quindi la password resta su Proxmox solo per il tempo strettamente necessario al primo boot. Se invece la VM non viene avviata subito, il cleanup non puo’ partire automaticamente e lo snippet rimane fino al primo avvio effettivo.

Perche usare pyinfra in questo scenario

pyinfra qui non e’ stato usato come framework teorico, ma come runner pratico e ripetibile. La UI raccoglie input e autorizzazione dell’utente, mentre pyinfra fornisce il contesto di esecuzione ordinato del job. Questo separa abbastanza bene il frontend operativo dalla logica di provisioning.

Il vantaggio e’ semplice: si ottiene un workflow web leggibile, ma con logica tecnica sotto controllo e versionabile in Git.

Documentazione ampliata su wiki

La documentazione non e’ rimasta ferma a una nota sintetica. Su wiki.gazzi.net la sezione Pyinfra e’ stata ampliata in modo leggibile per umani, partendo dalle basi fino ad arrivare alla spiegazione tecnica dell’implementazione del deploy automatico di VM.

In particolare ora la wiki copre anche una domanda operativa molto concreta: se devi controllare 10 server, cosa deve essere installato sul manager e cosa deve esserci sui target. La risposta e’ resa con esempi progressivi, inventory, test di reachability e deploy reali.

• Pyinfra: pagina principale e mappa di lettura
• Esempi Pyinfra: esempi base, scenario manager/10 server target, inventory e deploy progressivi
• Pyinfra/Deploy automatico VM Proxmox: runbook operativo della web UI
• Pyinfra/Implementazione deploy VM linea per linea: spiegazione dettagliata del codice reale

Questa parte e importante perche’ la UI web risolve il caso d’uso pratico della creazione VM, ma la wiki ora spiega anche il modello mentale generale di pyinfra: il manager contiene il runner e la logica, mentre i server target vengono raggiunti via SSH senza installare un agente pyinfra dedicato.

Tracciamento in Git

Tutto il lavoro applicativo e documentale e’ stato portato nel repository dedicato degli script e delle automazioni. Questo include:

• README del modulo
• web UI
• runner pyinfra
• documentazione operativa
• snippet di reverse proxy
• landing aggiornata di bot.gazzi.net

L’approccio e’ coerente con una regola operativa importante: il wiki puo’ restare utile per documentazione ad alto livello, ma la logica riusabile e il materiale tecnico devono stare in repository Git, dove possono essere letti, aggiornati e revisionati meglio.

Conclusione

Questa implementazione trasforma bot.gazzi.net in un piccolo punto di automazione reale: autenticazione LDAP, UI web, validazioni preventive, provisioning Proxmox, utente sudo nel guest e cleanup del materiale sensibile dopo il primo boot. Non e’ una piattaforma enorme, ma e’ gia’ abbastanza strutturata da essere utile sul serio.

Il valore principale non sta solo nel fatto che “si puo’ creare una VM dal browser”, ma nel modo in cui e’ stato fatto: con logging, Git, controlli di rete, pubblicazione chiara e attenzione a non lasciare segreti permanenti dove non servono.