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

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

OpenWRT: non solo un firmware

Recentemente ho avuto la possibilità di provare OpenWRT su un access point, e devo dire che sono rimasto impressionato dalle possibilità del suddetto sistema operativo. Ma prima spieghiamo qualche secondo cosa è e cosa dovrebbe fare un firmware, giusto per fare un confronto tra OpenWRT e un firmware.

Un firmware è un software generalmente all-in-one o quasi, in grado di gestire solo e soltanto il dispositivo nel quale è stato inserito e per il quale è stato programmato. E' un microprogramma, giusto le istruzioni da dare al microprocessore del dispositivo per fare quello che deve fare (nell'esempio dell'access point, il firmware è stato sviluppato per fare solo da access point wifi).

Tuttavia molte volte gli apparati vengono progettati per fare molte cose e vengono limitati via software (costa di meno). Chiamatelo "override" delle "limitazioni", ma avere la possibilità di riscrivere quel software per sfruttare quei dispositivi al massimo delle loro potenzialità è sempre meta ambita per smanettoni, poiché ti basta un po' di lavoro per rendere il tuo semplice access point anche firewall, limitatore di banda, router tra varie subnet, e addirittura centralino per le reti VoIP.

OpenWRT è un sistema operativo progettato per non essere un firmware, ma un vero e proprio sistema composto da kernel + utility, e spinto molto sulla pacchettizzazione degli applicativi. Anche se molti firmware (soprattutto di router e access point) sono basati su OpenWRT o simili, questo rimane comunque molto configurabile. Inoltre sfizio di molti smanettoni e sistemisti, la possibilità di avere un accesso tramite SSH è il massimo.

Maggiori informazioni: http://openwrt.org/

Enrico