Per varie ragioni (che non includono solamente il masochismo) voglio portare una procedurina di monitoraggio che ho scritto in Perl sotto Linux in ambiente Windows.

Volendo usare un linguaggio script nativo in ambiente Windows per evitare di installare programmi di qualsiasi tipo sulla macchina da monitorare, decido di usare la PowerShell.

Prima sorpresa: Microsoft distribuisce un (a suo dire) potente interprete di comandi e di script in cui l’esecuzione degli script è bloccata per default. Vabbè, la cosa si risolve creando (o modificando) la chiave di registro HKEY_Local_Machine\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.Powershell\ExecutionPolicy con valore Unrestricted. Benedetta Microsoft!

Ok, gli script ora sono eseguibili.

Veniamo allo scopo del test: creare uno script che prende una variabile data e la invia ad un server tramite HTTP POST (ovvero simulando la compilazione di un form) e recuperare la risposta del server.

Svolgimento in PERL:
$ua = LWP::UserAgent->new;
$req = (POST "http://pippo", ["campo1" => "valore1", "campo2" => "valore2"]);
$risposta = $ua->request($req);

Svolgimento in PowerShell:
[Reflection.Assembly]::LoadFile(’C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Web.dll’) | out-null
$postData = ‘campo1=valore1&campo2=valore2′
$buffer = [text.encoding]::ascii.getbytes($postData)
[net.httpWebRequest] $req = [net.webRequest]::create(’http://pippo’)
$req.method = “POST”
$req.ContentType = “application/x-www-form-urlencoded”
$req.ContentLength = $buffer.length
$req.TimeOut = 5000
$reqst = $req.getRequestStream()
$reqst.write($buffer, 0, $buffer.length)
$reqst.flush()
$reqst.close()
[net.httpWebResponse] $res = $req.getResponse()
$resst = $res.getResponseStream()
$sr = new-object IO.StreamReader($resst)
$risposta = $sr.ReadToEnd()

E per fortuna che è una shell power!!!

Questa mattina nella lettura delle varie mailing list che seguo ho trovato una piacevole sorpresa.

Michael Abbott di Apple ha postato un messaggio nella mailing list di Dovecot in cui annunciava la disponibilità di Apple a contribuire al progetto con alcune patch sviluppate al suo interno e già verificate.

Negli ultimi tempi Apple non è stata un esempio di apertura come tecnologie e piattaforme, ma mi sembra corretto segnalare un comportamento meritevole quando questo si verifica. Troppo spesso le ditte approfittano del software Open Source per ridurre tempi e costi di sviluppo senza, però, attenersi alle regole di questo tipo di distribuzione, ovvero senza contribuire a loro volta ai progetti che sfruttano. L’ultimo esempio di questo comportamento poco corretto sarebbe rappresentato da CISCO (la giustizia americana deciderà), contro cui la FSF ha intentato una causa.

Tornando ad un esempio di comportamento meritevole, Apple ha offerto di contribuire al progetto Dovecot con varie migliorie, quali:

• permettere ai processi IMAP e POP di gestire client multipli;
• code di ascolto più lunghe;
• modifiche per permettere la compilazione su varie piattaforme;
• sistemi per aggirare bachi noti di OSX;
• varie correzioni a bachi del software;
• integrazione con Apple Open Directory;
• implementazione di un sistema che blocca i client dopo vari ripetuti tentativi di accesso falliti;
• gestione dei cambiamenti dinamici degli hostname.

Timo Sirainen, l’autore di Dovecot, hamostrato molto interesse per l’offerta di Apple. Con ogni probabilità, le correzioni dei bachi verranno implementate nella versione corrente, 1.1, mentre le nuove caratteristiche verranno aggiunte alla nuova versione 1.2 in fase di sviluppo.

Collaborazioni di questo tipo tra aziende e progetti Open Source ce ne sono molte e sono l’esempio che un modello di sviluppo del software di questo tipo, quando le circostanze lo permettono, non solo è possibile, ma è anche vantaggioso per tutti.

FreeNAS è un software gratuito per creare un NAS utilizzando del normale hardware PC e, ovviamente, dei dischi.

Ci sono molti NAS pronti all’uso con vari prezzi e varie caratteristiche e moltissimi utilizzano un Linux personalizzato come software di gestione. I Buffalo sono NAS molto buoni, ma non esattamente a buon mercato; di contro i Linksys mi hanno deluso per le loro basse performance, specialmente in caso di ricostruzione del RAID dopo uno spegnimento accidentale.

Può capitare di dover dismettere un server o un PC con un case ben carrozzato ancora in perfetto funzionamento. In questo caso, si possono aggiungere altri dischi o si possono sostituire quelli presenti e si può installare FreeNAS. Come si vede in questa scheda, i requisiti minimi per far funzionare FreeNAS sono davvero minimi ed è, quindi, possibile riciclare senza problemi un PC o un server in dismissione.

Il software si installa in pochissimo tempo; la configurazione del NAS può essere salvata su un floppy, su una chiavetta USB o su un disco, FreeNAS lascia ampio spazio di scelta. Una volta configurata l’interfaccia di rete, l’interazione con FreeNAS avviene tramite il browser e si può staccare la tastiera dal PC, posto di aver configurato il BIOS per non bloccarsi in caso di assenza della tastiera.

Nell’interfaccia web si aggiungono i dischi alla gestione del NAS, li si organizza nel RAID desiderato e li si pubblica in rete. La parte di pubblicazione è quella che mi colpisce favorevolmente, in quanto sono disponibili moltissimi protocolli di condivisione dati.

La qualità del software è decisamente elevata e non ha nulla da invidiare ai software dei NAS commerciali; non ho ancora visto un NAS commerciale che disponga di tutti i protocolli di FreeNAS. Con i costi attuali degli hard disk in costante calo è facile approntre un NAS spendendo veramente poco; la versatilità di FreeBSD permette, inoltre, di utilizzare un’ampia varietà di hardware senza problemi.

Vale la pena investire qualche ora per fare delle prove e per prendere confidenza con quiesto prezioso software.

Scrivo software da… uhm… tanti anni e ho visto nascere, crescere e morire molti linguaggi del futuro.

Nei primi anni di MS-DOS e anche nei primi anni di Windows (diciamo dal 3.0 in avanti) queste erano piattaforme entusiasmanti su cui scrivere. C’erano dei bachi sia nel sistema operativo sia nei tool di sviluppo, ma erano ben noti e quasi sempre facilmente aggirabili. C’erano molte librerie di terze parti (anche senza Internet le informazioni circolavano benissimo tra i programmatori) che sopperivano alle carenze delle librerie standard dei linguaggi e alle necessità dei programmatori. C’era chi pubblicava compilatori, chi pubblicava librerie e chi comprava i due per creare programmi.

Poi è successo qualcosa, credo attorno al 1995/1996. Windows si è trasformato in una piattaforma di utilizzo in cui i tool di sviluppo c’erano, ma gestiti quasi esclusivamente dal produttore del sistema operativo. Sono usciti prodotti interessanti, ma la potenza di fuoco di Micorosft è sempre stata soverchiante: quante volte hanno cambiato il modello di accesso ai database in Access e/o in Visual Basic con la motivazione (sempre uguale) che il nuovo modello è migliore di quello vecchio, ogni occorrenza del quale nel vostro codice deve essere isolata e distrutta come un campione di malattia infettiva? La prima volta ci siamo stati dietro, la seconda abbiamo storto il naso, la terza è partita una raffica di moccoli verso Redmond ed il codice è rimasto invariato.

È inutile che Ballmer, sudato come un cammello, si metta ad urlare «Developers! Developers! Developers!» sul palco delle presentazioni di Microsoft se poi loro stessi fanno scappare gli sviluppatori innovando i loro linguaggi ogni 18 mesi. Ma credono davvero che le aziende che sviluppano (per non parlare del software sviluppato in house) abbiano soldi da buttare per stare dietro ai loro capricci?! Anche ars tecnica recentemente ha trattato il problema dello sviluppo sotto Microsoft.

E allora cosa rimane a noi sviluppatori? Una buona alternativa potrebbe essere l’utilizzo dell’interfaccia HTML generata da un linguaggio server side che si appoggia su un motore SQL. La piattaforma del web browser è oramai ben consolidata presso l’utente finale, che ha una discreta familiarità con essa e ne accetta le limitazioni. Su questo fronte ci sono vari linguaggi, molti dei quali gratuiti, integrabili tra loro e con un’ampia base di installato e di librerie pronte per vari scopi. L’innegabile vantaggio di queste soluzioni è la portabilità tra gli ambienti e la facilità con cui interagiscono con altre piattaforme attraverso protocolli aperti.

Vista la natura di questi linguaggi e di queste tecnologie, è anche più facile trovare sviluppatori, anche giovani, entusiasti di poter mettere a frutto le loro esperienze e vogliosi di crescere.

Quando Ballmer se ne accorgerà sarà sempre comunque troppo tardi.