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.

E’ stata rilasciata la Interim Fix 2 per Lotus Notes 8.5.3 FP2 versione standard e basic.

A questa pagina potete trovare l’elenco completo delle fix con relativi Software Problem Reports e i link per scaricare l’aggiornamento.