Piccoli aggiornamenti

Piano piano il programma per l'inventario sta funzionando, anche se devo ancora implementare molte cose, e spero con la fine della scuola di avere più tempo e finirlo entro "tempo utile".

I vari "QEMU Live" sono in attesa di tempo dal precedente. Inoltre ho in mente di sviluppare un "lspci" per Windows un po' più sofisticato di quello in uso spesso su GNU/Linux (giusto perché sotto Win i driver è un terno al lotto, mentre Linux li ha pressoché tutti direttamente nella sorgente del kernel oppure pacchettizzati nelle varie distribuzioni, quindi difficilmente si necessiterà di un programma simile sotto tale piattaforma).

Enrico

Voglio un programma per gestire l'inventario!!!

Dunque, nella mania di ogni sistemista di automatizzare e semplificare le cose (senza perdere "il controllo" delle stesse), mi trovo a voler/dover semplificare la gestione del parco macchine. Il problema è che non volevo sviluppare un programma per l'inventario solo per quel tipo particolare di problematica, ma qualcosa che sia "adattabile" e non troppo rigido. Ho deciso quindi di ritagliare un po' di tempo che uso per QEMU Live 2 e usarlo per questo, che è meno complesso e più utile al momento.

Presupponendo che non posso mettermi a variare la struttura del database da codice, ho pensato di usare dei file XML per gestire la struttura delle varie tipologie di componenti, e poi in modo generico associarli come "padre-figlio" con un banale campo intero nel DB. Ogni oggetto ha un riferimento al suo "modello XML" che viene usato per generare l'XML dei dati.

Inoltre, vorrei aggiungere subito un'estensione (un "plugin") per memorizzare i driver delle periferiche mediante i codici VendorID e DeviceID (nel caso di periferiche PCI, oppure i corrispondenti nel caso di altri), magari con un sistema di analisi e catalogazione automatica del driver per ogni periferica.

Per ora, il codice che è presente e funzionante è quello per i modelli XML. Nei prossimi giorni lavorerò sull'insert dei dati e la generazione del form partendo dal modello XML.

Enrico

QEMU Live 2, la vendetta

Dunque, dopo aver sviluppato QEMU Live un bel po', sono giunto a conclusione che dare la possibilità a PHP di lanciare alcuni script (con tutte le limitazioni del caso) e comunque di gestire tutto, non era il caso (anche se era il sistema più semplice), anche perché andiamo a minare la scalabilità di tale sistema (in un ipotetico sistema con un load balancing, sarà un reverse proxy o un DNS a dover bilanciare il carico, cosa che invece vorrei evitare - non tutti hanno voglia/tempo/denaro per qualcosa del genere). Ho deciso dunque di ridisegnare "QEMU Live" da zero.

La nuova "appliance" sarà formata da due componenti principali: il "controller" e l'esecutore (un po' come la tecnica Model-View-Controller, anche se non è che mi vada molto a genio...): ci sarà una applicazione "server" che gestirà firewall e macchine virtuali, e ci sarà una web application che farà da front-end per gli utenti. Le due "applicazioni" comunicheranno attraverso socket (di rete, altrimenti se avessi usato socket UNIX avrei perso la portabilità sotto Windows, anche se non escludo di metterlo nel file di configurazione insieme ai path dei vari programmi).

In questo modo, stabilendo un "protocollo" di comunicazione, sia il front-end sia il back-end possono essere scritti in linguaggi diversi, possono essere su diverse piattaforme. Inoltre il front-end può integrare del codice per il load balancing.

Per ora sto sviluppando il "demone" di back-end. Appena avrò finito di capire come fare la maggior parte delle cose, scriverò quattro righe su questo "protocollo" e poi comincierò ad implementarlo nel server. Successivamente farò lo stesso nel client. Il demone lo sto scrivendo in Java (vorrei farlo portabile) mentre l'interfaccia web la vorrei sviluppare in PHP. Ma nulla vieta di cambiare e/o di fare diverse versioni delle suddette in futuro (dotNet .aspx per IIS, JSP, ecc.)

Inoltre con la fine della scuola spero di avere più tempo anche per scrivere sul Blog ;-)

Enrico