Mi capita abbastanza frequentemente di discutere di software open source e uno dei dubbi che spesso sorgono è come contribuire ad un progetto.

Il modello di sviluppo open è una realtà che oggettivamente ha cambiato l’information technology, questo è un dato di fatto incontrovertibile, ed è un fenomeno sorprendente sia dal punto di vista tecnico che sociale.
Basta provare a lavorare in gruppo per un qualche ora per rendersi conto di quanto sia difficile coordinarsi e fare davvero “team”, già perchè è facile scrivere sul CV cazzate false tipo “ottima predisposizione al lavoro di gruppo”, un altro paio di maniche è metterlo in pratica, figuriamoci quando il gruppo è distribuito su un intero pianeta e composto dal più ampio e variegato campionario umano.

La domanda che però molti si pongono è come contribuire concretamente ad un progetto che ci sta particolarmente a cuore, oppure che semplicemente ci è risultato utile.
Dal punto di vista tecnico lo sviluppo di un progetto è una attività complessa che richiede competenze specifiche che solo una percentuale ridottissima degli utenti possiede; poi ci sono altri compiti altrettanto utili e meno impegnativi dal punto di vista tecnico (test, traduzione di documentazione, moderazione di forum e mailing list, creazione di how-to e guide di vario tipo) ma anche questi non sempre sono alla portata di tutti, quantomeno non della maggior parte degli utenti.

Ci sono però due altre cose che un progetto open-source necessità e su cui tutti possono impegnarsi:

1. pubblicità
2. risorse (banda e storage)

Riguardo alla prima c’è poco da dire, non perchè sia poco importante (anzi!) ma perchè è abbastanza autoesplicativa, riguardo al punto due invece qualche considerazione possiamo farla.

Anni fa i progetti open source venivano distribuiti mediante mirror, ovvero server che venivano aggiornati con i rilasci del progetto e che mettevano a disposizione spazio e connettività per permettere alla comunità di scaricare i file e poter beneficiare dei software.
Chiaramente nell’era delle connessioni analogiche (ricordate il vecchio modem 56k?) tutto questo era ad esclusivo appannaggio di pochi, principalmente aziende che in cambio di queste risorse venivano citate tra i “contributors” del progetto.

Se ci pensiamo al giorno d’oggi praticamente tutti (digital divide permettendo) godono di una connessione adsl flat con tagli di banda generosi, connessioni che generalmente sono inutilizzate per la stragrande maggioranza del tempo.
Come se non bastasse oggi esistono sistemi (il celebre Raspberry PI ne è un esempio) dal costo ridicolo (a partire da poche decine di euro) e dall’assorbimento ridottissimo (2-3W per il già citato Raspberry PI, meno di una TV in standby) che sono perfette per questo scopo, a questo aggiungiamo che gran parte dei progetti utilizza come sistema di distribuzione sistemi di file sharing come bittorrent.

Quindi quale miglior modo per contribuire ad un progetto open source offrendo un po’ di banda della propria connessione domestica, magari organizzandosi con dei semplici script per attivare il client bittorrent nelle ore in cui non utilizziamo la linea, siamo fuori casa, al lavoro, oppure semplicemente stiamo dormendo.

Ad esempio con una qualsiasi distribuzione linux e l’ottimo client bittorrent Transmission basta mettere in download una qualsiasi versione di un progetto e lasciare il tutto in seed una volta terminato il download, inserendo dei banalissimi cronjob per arrestare il servizio (schedulato ad esempio quando pensate di tornare a casa dopo una giornata di lavoro, nell’esempio alle ore 19):

00 19 * * * /etc/init.d/transmission-daemon stop > /dev/null 2>&1

e per farlo ripartire (quando generalmente ve ne andate a letto la notte, nell’esempio alle 2):

00 02 * * * /etc/init.d/transmission-daemon start > /dev/null 2>&1

Si tratta di una cosa semplice, alla portata di tutti, che ha un impatto economico ridicolo, ma di grande utilità, pensateci

SSL è sicuramente un ottimo strumento, un po’ meno l’implementazione di keyring proprietari da parte dei vari produttori di software.

Mentre i servizi sviluppati da persone sane di mente utilizzano normalissimi certificati in formato ASCII encodati base 64 e salvati su filesystem, i big usano tutti oggetti astrusi e inutilmente complicati (che quindi aggiungono ulteriori gradi complessità ad un processo tecnicamente complesso) per fare una cosa relativamente semplice, ovvero fornire una coppia di chiavi (pubblica e privata) ad un servizio, che può essere un webserver, un application server, un server di posta o altro..
Così mentre Oracle si incapponisce sul suo orribile Wallet Manager, IBM insiste sul suo (meno orribile ma comunque inutilmente complesso) iKeyman, utilizzandolo per un po’ tutti i prodotti, da WebSphere a Tivoli Access Manager.

Recentemente mi è capitato di dover importare un certificato wildcard (*.dominio.tld) in un keyring di iKeyman proprio su una istanza di TAM.
Il certificato è stato acquistato da Digicert, il quale ha fornito un comodo “zippone” con incluso chiave privata, certificato e certificati delle authorities di root e intermedie, il che non è male considerando che alcune CA nostrane non si preoccupano nemmeno di segnalare dove poter scaricare i certificati della CA stessa.

Ora viene il bello, iKeyman infatti permette di importare certificati in formato ASCI base64, ma solo per i cosidetti “Signer Certificates” ovvero i certificati delle CA; si clicca sull’apposito pulsante “Add…” si indica il percorso del file di testo contenente il certificato e il gioco è fatto.

Il problema sorge con le chiavi di un nuovo certificato, o “Personal Certificate” per usare la nomenclatura di iKeyman.
Per fare tutto questo è necessario convertire, o meglio inglobare, chiave privata e certificato in un unico archivio in formato PKCS12 (un abominio ereditato da Microsoft).

Secondo voi IBM fornisce qualche tool per poter effettuare questa operazione? Naturalmente no…
Eccovi quindi a ricorrere al solito, indispensabile, provvidenziale OpenSSL. Pigliate una qualsiasi macchina con installato openssl (una linux box a caso ad esempio) e utilizzate questa sintassi:

openssl pkcs12 -export -name "<LABEL A PIACERE>" -inkey <CHIAVE PRIVATA> -in <CERTIFICATO> -out <ARCHIVIO>.p12 -keypbe PBE-SHA1-RC2-40

A questo punto non vi resta che tornare a iKeyman, passare alla sezione “Personal Certificates” e utilizzare la funzione di import per integrare nel keyring il vostro certificato con tanto di chiave privata.

Ecco fatto, ennesimo caso della serie “ufficio complicazioni cose semplici” :\

Monitorare i log è un’attività spesso tediosa ma fondamentale per essere certi del corretto funzionamento di un servizio, un modo per rendere tutto più semplice e automatico è sfruttare il buon vecchio Nagios in combutta con l’ottimo plugin check_logfiles.

Il vantaggio di questo plugin rispetto a soluzioni più “caserecce” (es script bash che ‘greppa’ il file di log e genera un output differente in base alla presenza o meno del pattern ricercato) consiste prima di tutto nel fatto di concentrare in un unico service il monitoraggio di differenti log, in secondo luogo check_logfiles non riprocessa i pattern già rilevati e segnalati, evitando quindi di ricevere molteplici segnalazioni relative allo stesso problema.

L’installazione e configurazione è a dir poco banale:

• scaricate l’archivio tar.gz dal sito ufficiale, decomprimetelo (nell’esempio in /usr/src) ed entrate nella directory creata
  
• lanciate il consueto ./configure, i parametri di default andranno più che bene per la maggior parte dei casi, nel caso doveste personalizzarli lanciate il comando seguito da –help per visualizzare tutti i possibili parametri.
  
• compilate i sorgenti lanciando il comando make
  
• installate i file lanciando il comando make install
  
• al termine dell’installazione il binario del plugin sarà disponibile in /usr/local/nagios/libexec/check_logfiles (ovviamente a patto di non aver modificato il parametro –previx, in caso contrario verificate nel percorso che avete definito come valore di quel parametro).
  

A questo punto l’installazione del plugin è completata, non resta che configurare il service direttamente su nagios.
Una soluzione più razionale e comoda può essere quella di definire un solo service e utilizzare nrpe per effettuare la verifica remota, definendo lo stesso comando su tutti i server da monitorare e limitare la personalizzazione al solo file di configurazione di check_logfiles.

Create il file di configurazione di check_logfiles (es /usr/local/nagios/libexec/logfiles.cfg) con un qualsiasi editor di testo e inserite la sintassi necessaria a verificare il vostro file di log, i parametri da modificare sono:

• ‘tag’ (inserite una descrizione del log che state controllando)
• ‘logfile’ (devo spiegare?)
• ‘warningpattern’ (elenco di pattern da cercare nel log che scatena un alert warning in Nagios)
• ‘criticalpattern’ (elenco di pattern da cercare nel log che scatena un alert critical in Nagios)

Quello che segue è un esempio di file di configurazione per monitorare il file catalina.out di una istanza Tomcat posta in /opt/jakarta-tomcat-5.0.28, ciascun avvio di Tomcat (org.apache.catalina.startup.Catalina start) scatena un alert warning, mentre episodi di Out of memory ed esaurimento del pool di connessione ai datasource scatenano un alert di tipo critico.

@searches = (
  {
    tag => 'tomcat_catalina.out',
    logfile => '/opt/jakarta-tomcat-5.0.28/logs/catalina.out',
    warningpatterns => [
        'org.apache.catalina.startup.Catalina start',
    ],
    criticalpatterns => [
        'OutOfMemoryError',
        'pool exhausted',
    ],
  });

Una volta configurato il file logfiles.cfg non resta che editare il file di configurazione di nrpe (/etc/nagios/nrpe.conf o equivalente) aggiungendo la riga che segue (verificate sempre il path in base alle vostre esigenze):

command[check_logfiles]=/usr/local/nagios/libexec/check_logfiles --config /usr/local/nagios/libexec/logfiles.cfg

Riavviate il servizio per rendere effettivo il nuovo command check_logfiles (/etc/init.d/nrpe stop && /etc/init.d/nrpe start).

A questo punto la configurazione del plugin e di nrpe è terminata, non vi resta che aggiungere il service sul server Nagios e associarlo al server che volete monitorare, a titolo di esempio il servizio potrebbe essere definito come segue:

define service{
        use                             generic-service
        host_name                       hostdamonitorare.domain.tld
        service_description             Controllo logs
        check_command                   check_nrpe!check_logfiles
        max_check_attempts              1
        }

Naturalmente la configurazione del service e degli host a cui applicare questo controllo varia a seconda della vostra configurazione di Nagios e della modalità con cui preferite associare services a hosts, l’unico parametro differente rispetto alla configurazione standard dei services è il numero di verifiche necessarie per far scattare l’evento warning o critico che deve essere impostato a 1 (max_check_attempts).

Dato che ogni controllo di check_logfiles verifica soltanto i record del file di log modificati dall’ultimo controllo è essenziale che i warning (e relative notifiche email o sms) partano alla prima rilevazione dei pattern definiti nel file di configurazione.
Per questo motivo è essenziale che questo service non utilizzi il consueto meccanismo di alert softt e hard di Nagios con la sequenza standard di 4 rilevazioni per scatenare la notifica.

Ecco fatto, ora non avete più scuse per ignorare un OutOfMemory ;)

Il wake on lan è fondamentale, lo vado ripetendo da anni ma ahimè troppa gente sottovaluta questo strumento tanto semplice da usare quanto utile per la manutenzione dei sistemi, sia in ambito lavorativo che domestico.

E’ fondamentale per i backup, è fondamentale per i defrag, è fondamentale per le scansioni antivirus, è sostanzialmente fondamentale per tutte quelle operazioni lunghe, “pesanti” e ahimè necessarie, che proprio per questo vengono spesso viste come un male necessario ma rimandabile a tempo indeterminato… almeno finchè qualcosa non si rompe, e allora saranno “pianto e stridore di denti” :\
Avere la possibilità di schedulare queste operazioni di notte, senza interferire con il proprio lavoro e in totale sicurezza è impagabile, wake on lan permette di fare tutto questo senza dover lasciare il proprio pc acceso in eterno, e quindi senza incidere in modo sensibile sulla bolletta elettrica.

Purtroppo una delle prime problematiche che ho riscontrato migrando a Windows 8 Professional è l’impossibilità di utilizzare Wake on Lan, o meglio non poterlo usare dopo aver effettuato un normale shutdown del sistema.
Pare infatti che quello che Windows 8 spaccia per shutdown in realtà non sia altro che uno stato  intermedio tra lo spegnimento puro e l’hybernate del sistema operativo, in sostanza Windows 8 salva i dati di sessione del kernel e i drivers caricati in memoria nel file di hybernate permettendo un più veloce ripristino del sistema all’avvio successivo.

Questa caratteristica (chiamata fast startup) è di fatto incompatibile con wake on lan (che invece funziona ponendo il sistema in stato sleep).

Per poter tornare ad utilizzare normalmente wake on lan occorre disabilitare fast startup mediante una piccola modifica al registro di sistema:

• aprire regedit (WIN+R, digitare regedit e dare invio)
• spostarsi alla chiave di registro HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Power
• modificare il valore della chiave HiberbootEnabled da 1 a 0 (zero)
• riavviare

Dopo il riavvio del sistema wake on lan tornerà a funzionare a dovere anche con Windows 8, un grande vantaggio al costo di un leggero aumento delle tempistiche di boot, che risultano comunque drasticamente più basse di tanti altri sistemi operativi concorrenti (MacOS X su tutti che effettua il boot con tempistiche geologiche).

Ho approfittato dell’offerta Microsoft per effettuare l’upgrade del mio sistema operativo di casa da Windows 7 a Windows 8 Professional.

A prescindere dai pareri positivi o negativi su questa nuova incarnazione di Windows devo ammettere di essere rimasto fortemente sorpreso dalla politica dei prezzi attuata da Microsoft, anche in considerazione delle blande restrizioni presenti in questo “upgrade”, anzi chiamiamolo col suo vero nome, ovvero “condono” informatico, visto che permette di ottenere una istanza regolare anche a chi non è in possesso di una copia genuina di una delle precedenti versioni di Windows.

Sicuramente ci sarà chi si è imbufalito per questo, francamente da possessore di licenza di Windows 7 la cosa non mi fa ne caldo ne freddo, anzi trovo che sia una cosa positiva che abbia finalmente spinto a fare il “grande salto” verso la legalità (anche se borderline) a molte persone che fino a poco tempo fa non avrebbero mai sganciato una lira per una licenza di Windows.

Si tratta dell’ennesima dimostrazione del fatto che per vincere la pirateria non servono protezioni più efficaci (sebbene quelle di Win8 fin’ora si siano dimostrate rocciose sappiamo tutti che è solo questione di tempo prima che esca una “cura” efficace a tempo indeterminato o quasi) ma serve semplicemente una politica di prezzi che renda il prodotto licenziato e regolare più conveniente della controparte pirata.