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” :\

Qualche giorno fa ho terminato Rage, già proprio lui, QUEL Rage, quello dello zio John Carmack e di mamma Id.
Non posso dire che mi abbia pienamente soddisfatto, sono oggettivamente deluso ma non lo considero la merda con cui tanti l’hanno etichettato.

Rage è l’ennesima dimostrazione del fatto che Id è un’eccellenza dal punto di vista tecnico, ma a livello di gameplay e design è oggettivamente carente, per lo meno lo è da quando non c’è più John Romero.
Tecnicamente si tratta di un gran gioco ancora oggi, a distanza di quasi un anno e mezzo dall’uscita, anzi possiamo dire che lo è soprattutto oggi visti i grossissimi problemi di cui ha sofferto al momento della pubblicazione.
L’engine è particolare, coraggioso per l’approccio tecnico, e imho riesce ad esprimere una bellezza grafica disarmante negli scenari aperti e ampi, d’altro canto risulta carente nella definizione delle texture a corto e cortissimo raggio.

Il design “grafico” dei livelli è veramente spettacolare, ci sono scene da rimanere a bocca aperta, in termini invece di design vero e proprio purtroppo tutti i livelli sono composti dal classico tunnel obbligatorio senza alcuna libertà di movimento o azione.
Per certi versi questo aspetto non è nemmeno così deprecabile, dato che permette di creare alcune situazione di gioco estremamente frenetiche (classici rush in cui i mostri “spuntano dalle fottute pareti” – cit.) oppure con
miniboss ben strutturati che riescono a sorprendere e a mettere sotto grande stress il giocatore.

Anche le armi sono carine, non sono tante ma sono tutte abbastanza utili, spingono il giocatore a cambiare combinazioni e stile di gioco di continuo.
Il problema sono le possibili varianti nell’approccio agli avversari, poche e decisamente banali, es:

1. mob impazzito che schiva colpi e attacca melee
2. mob con arma a distanza che si nasconde e cerca copertura (lasciando sempre scoperta l’invitante testolina pronta ad essere headshottata all’istante)
3. mob super-resistente dotato di arma automatica devastante che però si muove con lentezza elefantiaca

Anche nelle sequenze di guida il gioco è godibile, ho passato serate giocando solo in quella modalità, altre solo in modalità fps, e tutto sommato Rage è divertente e godibile sia in un caso che nell’altro.

Il vero difetto che ahimè ha spinto tanti utenti a criticare questo gioco è il fatto che si tratta di un titolo estremamente ripetitivo :\
Di fatto Rage è composto da uno schema che viene ripetuto di continuo ogni volta che si passa da una zona all’altra, ognuna ha una base, con gli stessi tipi di png, con la solita sequenza di quest primarie e secondarie, insomma lo stesso schema di gioco ripetuto dall’inizio alla fine…
Tanto per fare un esempio: per ogni locazione di gioco fps sono previste due missioni, prima una principale più lunga e complessa e poi una secondaria più veloce e generalmente più semplice; tutto questo si ripete dalla prima all’ultima locazione, con l’unica eccezione del finale, e credetemi c’è da rimanere a bocca aperta nell’osservare con quanta fredda precisione questo schema viene rispettato…

Insomma passi da una zona alla successiva e sai già quello che ti aspetta, sai già che ci sarà la sequenza di missioni principali, sai già che a un certo punto ti chiederanno di cambiare mezzo, sai già che farai la tua sfilza di gare in pista (per guadagnare punti da spendere per i potenziamenti dei mezzi), sai già che dovrai fare il pieno di munizioni e sai già che dopo aver affrontato una missione in una zona dovrai tornare nello stesso posto per una missione secondaria… insomma sai già tutto :\

E’ un peccato, perchè l’ambientazione è davvero carina e tecnicamente (dopo patch e patch) il gioco è davvero appagante per la vista e gira benissimo su qualsiasi configurazione da gaming.
Da 1 a 10 io non mi sento di dargli la sufficienza, toh un 5, ma solo perchè dietro c’è il grande lavoro di r&d di Engine John.

Vorrei approfittare di questo spazio per ricordare i membri dell’equipaggio di un’altra tragica spedizione dello Space Shuttle, 10 anni fa il Columbia si disintegrò al rientro dalla Stazione Spaziale Internazionale.

Nonostante si sia trattato dell’ultima grande tragedia spaziale, quello del Columbia mi è sempre parso un avvenimento passato quasi sotto silenzio, un po’ come la prima tragedia della storia dell’esplorazione spaziale, di quell’Apollo 1 che ahimè non vide mai il cielo.

Eppure la tragedia del Columbia ha qualcosa di più triste e grave, il succedersi degli eventi che portò alla morte dell’equipaggio, la loro origine, la deliberata decisione di ignorare la rottura dello scudo termico, e poi quel silenzio assordante delle immagini che mostrano i detriti precipitare.
Quella dell’Apollo 1 è stata una tragedia dovuta all’ignoranza, quella del Challenger una vera fatalità, ma quella del Columbia è stata il frutto di noncuranza, la stessa che ha fatto si che raramente nei media tradizionali e nell’opinione pubblica si ricordi di questi altri 7 eroi:

• Rick Husband – comandante
• William McCool – pilota
• Michael Anderson – comandante di carico
• Ilan Ramon – specialista di carico
• Kalpana Chawla – specialista di missione
• David Brown – specialista di missione
• Laurel Clark – specialista di missione

Sono passati 27 anni dal quel tragico 28 gennaio 1986 in cui si è verificato il disastro dello Space Shuttle Challenger.

Sebbene all’epoca avessi soltanto 7 anni ricordo distintamente quel giorno.
Ricordo particolarmente la sera, le immagini dell’esplosione al telegiornale, quel velo di tristezza tipico delle tragedie che superano i confini di una comunità, di una nazione, di quelle sciagure che toccano davvero tutti gli esseri umani che popolano questo pianeta.

Vorrei ricordare i membri dell’equipaggio con le splendide parole del presidente Ronald Reagan, uno dei messaggi più emozionanti e belli che siano mai stati pronunciati.

• Francis R. Scobee – comandante
• Michael J. Smith – pilota
• Gregory B. Jarvis – specialista di carico 1
• Christa McAuliffe – specialista di carico 2
• Judith A. Resnik – specialista di missione 1
• Ellison S. Onizuka – specialista di missione 2
• Ronald E. McNair – specialista di missione 3

Non vi dimenticheremo.

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 ;)