Driver repository (per Windows ovviamente)

Poiché molto spesso oramai mi trovo a formattare e reinstallare workstation, mi sono fatto una serie di script in grado di automatizzare un po' di cose (prima di tutto ho integrato il SP3 nel cd di install, poi ho fatto in modo di poter lanciare l'installazione via rete, ecc.) in modo da non dover stare lì 3 ore per una cosa "banale" come "reinstallare il pc".

Certo il massimo sarebbe (essendo problemi che sorgono spesso in ambito lavorativo) avere un immagine del disco con utility tipo "partimage" o "ghost" in modo che un ripristino duri 5 minuti, ma spesso non si hanno terabytes di spazio per memorizzare n^m immagini di workstation (soprattutto poi se le suddette sono state acquistate da fornitori diversi e sono modelli completamente differenti, quindi niente immagine unica da mettere su più pc).

Quasi tutto è automatizzato, quello che ancora mi occupa però tanto tempo è il trovare i drivers. Come dite? I dischi del produttore? Magari!

Indipercuilaquale mi ritrovo a dover pescare dalla lista dei dispositivi una serie di ID (i famosi vendor & device ID) per cercare driver compatibili. Ora, per quanto possa essere "rapida" la ricerca avendo già VEN_ID e DEV_ID, spesso ci si impiega più del 50% del tempo impiegato per rimettere in sesto la workstation.

Ho deciso quindi di realizzare un software che è in grado di interrogare la lista degli ID di cui sopra e cercare la corrispondenza dentro il database di PCI-IDs (lo stesso usato dagli strumenti come lspci di GNU) e, successivamente (ovvero, ora) sto cercando di realizzare un database contenente i driver, in modo che il programma fatto da me non deve far altro che scaricare dal DB il file compresso contenente i device drivers ed installarli. Questo sveltirebbe di molto le operazioni di installazione/manutenzione, visto che molti driver (soprattutto SiS e ASUS che abbiamo a quantità industriali) sono gli stessi per molti devices. Questo presuppone ovviamente uno script che apre e analizza i file .inf per capire il driver a quale dispositivo può essere associato.

Tutto questo in pratica mi renderebbe in grado di lanciare il mio programma sotto Windows (magari insieme agli altri scripts) e fornire al sistema operativo, in modo automatico o semi-automatico, i driver per i dispositivi che ha.

Avevo anche una mezza intenzione di rendere la cosa pubblica su internet, ma poiché già esistono siti del genere, e soprattutto perché non so se i produttori dei suddetti software siano d accordo (vedi licenze), eviterei di farlo.

Per ora, quello che mi manca è solo completare il software che sotto Windows scarica i file compressi dal database. Dopodiché pubblicherò i sorgenti ;-)

Stay tuned ;-)

Enrico

Accidenti quanto tempo...

...che non scrivo!

In effetti, un po' per mancanza di spunti interessanti da scrivere nel blog in questo periodo, sia per un periodo più di vacanza (che per me, guarda caso, si traduce sempre in $lavoretti che mi occupano un sacco di tempo - in effetti mi riposo di più l'inverno) è da tempo che non mi metto a scrivere.

Che dire, ho aggiornato qualche pagina sul sito, e sto per finire una serie di classi (che oserei chiamare "framework") per la creazione di form in HTML: in pratica, essendomi stancato di scrivere sempre le stesse cose, gli stessi controlli con JS, ecc, ho deciso di creare una struttura di classi-oggetti che mi permetta di semplificare il lavoro di scrittura dei form (un po' come fa Xoops), soprattutto per quanto riguarda alcuni componenti non esistenti o di perdita di tempo (come i check lato client - utili per gli utenti "distratti" certo, non per la sicurezza - oppure come un select box che può contenere HTML, come erano una volta quelli di Google).

Il primo progetto nel quale userò questa classe sarà un gestionale web. In futuro potrò approfondire, magari anche con qualche link e/o sorgente ;-)

Per il resto, stay tuned, il periodo di "ripresa della normale routine" è in arrivo ;-)

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

QEMU Live va avanti

Il progetto QEMU Live sta andando avanti: ho inserito il famoso logging, sto testando l'autokill e sto sviluppando un mini-applicativo d'appoggio per il firewall. Ho anche una bozza di modifica al client VNC per fare in modo di sincronizzare il puntatore del client e della macchina virtuale, solo che devo trovare il tempo di applicarla al suddetto webclient in java.

Se qualcuno ha intenzione di collaborare, mi contatti ;-)

Enrico

Progetto QEMU Live

In un tempo molto lontano, Fabrice Bellard disse "qemu", e qemu fu. Poi disse "kqemu", e kqemu fu. Poi la gente si incacchiò nera perché kqemu non era open, e fu open. E poi venne l'Idea.

L'Idea, di Renzo Davoli, era quella di creare uno zoo di sistemi operativi. Difatti il progetto si chiama "Free Os Zoo", ed è un wiki dove è possibile scaricare immagini già installate di diversi sistemi operativi (ovviamente dove la licenza lo permette). Una "sezione" speciale si chiama "Live Os Zoo", che permette di prendere qualcuna di queste immagini e farle partire da remoto: una applet java (client vnc) ci farà vedere qemu da remoto.

Ora, nonostante il progetto non sembri morto, è un sacco di tempo che il server di Live Os Zoo non torna su, e che il loro blog non si aggiorna. Ergo, preso da una mania di scripting, mi sono messo a ricreare il sistema come me lo ricordavo, e come mi piacerebbe, e l'ho chiamato fantasticamente (e temporaneamente) "QEMU Live".

E' ancora in sviluppo, anche se per ora funziona (l'immagine si lancia, posso utilizzarla, la posso "uccidere"), ma ci sono numerosi bugs:

• Tutti possono vedere la macchina lanciata da tutti (nessuna regola sul firewall e nessun filtro). E' nella lista delle cose da fare :-D
  
• Il traffico VNC è inviato non criptato su internet, quindi qualcuno potrebbe intercettare i dati.
• Tutte le modifiche che si fanno nel sistema operativo andranno perdute quando si spegne (e forse rimane così).
  
• La rete nei sistemi virtualizzati NON funziona. This is in ToDo list ;-)
• I puntatori dei mouse del guest e dell'host non sono sincronizzati. Anche questo è nella lista delle cose da fare (diciamo che il programma c'è, devo solo capire come integrarlo nella java applet).
  

E queste invece sono le cose che vorrei fare (la ToDo List):

• IP Logging (eh si, ancora non c'è)
  
• Auto-kill dopo X ore (per tuti) oppure X minuti per quelle istanze di qemu senza connessione associata (qualcosa c'è)
  
• Solo l'IP che ha lanciato l'immagine la può "uccidere"
• Filtri sul firewall per l'accesso VNC
• Crittazione sessione VNC
• Sincronizzazione puntatori VNC (guest e host). (qualcosa c'è, ma è da adattare, vedi su)
  
• Remote networking (VPN or VDE)
• Implementare più opzioni da passare a qemu nel file di config del sistema operativo.
• Image-to-image networking
• Pagine di amministrazione
• Source code and scripts release (ovvero, download e reinstall)
  

Quando sarà a buon punto creerò una pagina web e darò la possibilità a tutti di scaricare i sorgenti degli script. Per ora, è sul mio server casalingo, e inaccessibile da fuori (per ovvi motivi, no security) ma se qualcuno volesse collaborare e/o volesse qualche informazione a riguardo, mi può contattare ;-)

Enrico

Effetto Brunetta

Tempo fa, il Ministro della Pubblica Amministrazione e dell'Innovazione Brunetta ha lanciato quello che si più definire del "terrorismo" contro "i fannulloni", minacciando questi di tante brutte cose (come il licenziamento) se vengono pescati. Nulla di negativo, chi non produce dovrebbe andare a casa.

Qualche giorno fa mi trovavo a vagare un po' con la mente su come poter far funzionare quel codice per generare le statistiche grafiche (per esempio nei sondaggi) utilizzando un "modulo" (chiamata in gergo informatico "Libreria") che avrei potuto riutilizzare quando mi fosse servita. Mi sarei semplificato il lavoro di riscriverlo ogni volta, o di cercare e di adattare le tante librerie che già ci sono. E poi non sarebbe stata la "mia libreria" :-P

Mi serviva quindi un mucchio di dati da poter analizzare, possibilmente che avesse senso e che mi avrebbe consentito di divertirmi con grafici e statistiche. Preso una sera da una forma di "Brunettite acuta", ho recuperato tutte le delibere comunali del Comune di Latina (il mio comune) dall'ultima elezione ad oggi, quelle presenti sul sito internet, e ho provveduto ad analizzarle.

Molte di esse sono state analizzate con successo dal mio "programma", alcune sono state aggiunte manualmente, e quindi non escludo che da qualche parte ci possa essere qualche errore.

I dati in questione si riferiscono alle presenze (e conseguentemente alle assenze) nel primo appello nelle votazioni delle delibere del Consiglio Comunale e NON in tutta la "discussione" che precede la votazione poiché purtroppo sul sito non sono presenti altri tipi di informazioni (verbali completi del Consiglio, oppure verbali di Giunta, ecc.).

Altra nota: i dati utilizzati sono di dominio pubblico, recuperabili dal sito del Comune (a questo indirizzo). Li ho semplicemente presi e messi in un grafico per far evidenziare la situazione.





Maggiori informazioni qui: http://enrico204.dyndns.org/comune/