Da qualche giorno si sta consumando uno scontro piuttosto acceso tra gli (ormai ex) sviluppatori e manutentori dei nagios-plugins e Nagios Enterprises, che detiene i diritti per il marchio oltre a sviluppare e distribuire la soluzione commerciale e Nagios Core.

Da quanto è emerso pare che Nagios Enterprises abbia letteralmente defenestrato il gruppo di sviluppatori e li abbia estromessi dalla gestione del sito e del progetto dopo che questi hanno cominciato a citare anche altre soluzioni alternative al loro Core (Icinga, Naemon, Shinken etc etc..), sostituendoli con altre persone non meglio definite e che non hanno alcuna esperienza su quei progetti, mettendo a capo del tutto colui che ha mantenuto i nagios-plugins inizialmente (ma che da molti anni non contribuisce).
Il gruppo di sviluppatori storici dei nagios-plugins ha creato un fork e sta sottoponendo i propri package ai manutentori dei principali repository, trovate tutte le info al sito https://www.monitoring-plugins.org.

Per quanto può valere esprimo la mia più totale solidarietà ai ragazzi di monitoring-plugins.org che hanno subito un torto mostruoso, aggravato da futili motivazioni e da una arroganza spaventosa da parte del team ufficiale di Nagios, questi ragazzi hanno svolto un lavoro FANTASTICO e sono certo faranno altrettanto con il nuovo progetto, auguro a loro ogni fortuna.
Non so voi ma oggi ho un motivo in più per valutare seriamente un fork alternativo a Nagios Core…

Potete trovare riassunta un po’ tutta la diatriba alla url https://bugzilla.redhat.com/show_bug.cgi?id=1054340

Proprio durante queste feste mi sono ritrovato a fronteggiare un problema abbastanza rognoso su un cluster WebSphere Portal 6.0, come da tradizione i problemi più bloccanti sono quasi sempre originati da cause che più banali non si può…

Lo scenario in cui si è presentato il problema è il seguente:

• cluster WPS 6.0 composto da 4 nodi distribuiti su due server fisici, uno dei quali ospitante deployment manager
• OS RedHat Enterprise Linux ES 4 x86
• shutdown dell’intero cluster per attività di manutenzione sul dbms Oracle 10g utilizzato dal cluster
• al riavvio del cluster solo uno dei 4 nodi WPS non effettua lo startup bloccandosi immediatamente dopo il comando di avvio (sia tramite interfaccia dmgr che tramite script startServer.sh)

E’ parso chiaro fin da subito che la causa non potesse essere legata al dbms o altri servizi di supporto (es ldap) in quanto gli altri nodi che utilizzano le medesime risorse risultavano funzionare perfettamente, a prescindere da ciò il problema si presentava molto prima che il servizio potesse anche solo inizializzare le connessioni a ldap o database; escluse queste componenti non è restato da fare altro che concentrarsi su JVM e sistema operativo.

Analizzando la directory che contiene i log del nodo ho notato che:

1. la gran parte dei log presentava timestamp allineato e corrispondente allo shutdown del nodo (effettuato tramite deployment manager, nessun SIGKILL di processo o altre porcate del genere).
2. L’unico log modificato al momento dello startup è risultato essere lo startServer.log, aprendo il quale non risultano esserci indicazioni particolarmente utili.
   
3. Nei log di stdout (SystemOut.log) e stderr (SystemErr.log) della JVM non risultano record significativi tranne poche eccezioni relative a transazioni non completate verso i datasource JDBC (risolvibili mediante avvio in modalità recover, oppure eliminazione dei trasactlog e partnerlog WPS).
   Sniffando il traffico tra nodo WPS e listener Oracle durante l’avvio del nodo problemativo non risultano alcuna comunicazione, pertanto si escludono problemi legati ai datasource o alle transazioni con il repository dbms.
4. Non sussistono problemi legati ai permessi di lettura/scrittura sui filesystem dove risiedono i file del servizio, il file di pid non è presente e non ci sono processi in ascolto su porte utilizzate dal nodo WPS.

A questo punto stavo cominciato a brancolare nel buio, verificando nella directory WAS_HOME ho rilevato un file javacore.txt con timestamp corrispondente allo shutdown del nodo, spulciando tra le prime righe di questo file di trace ho notato una indicazione chiave.

Da Wikipedia: “The SIGXFSZ signal is sent to a process when it grows a file larger than the maximum allowed size”

A questo punto mi sono messo alla ricerca di file di dimensioni considerevoli nelle principali directory dove il servizio (o i processi del servizio) vanno a scrivere, principalmente logs.
Proprio nella directory dei log del nodo era presente il log di errore del Garbage Collector JVM (native_stderr.log) di dimensione “abbastanza” sospetta: 2GB precisi precisi.
Aprendonolo risulta che l’ultimo record in coda risulta stranamente troncato.

Dopo aver svuotato il log il nodo è magicamente partito e non ha mostrato alcun segno di anomalia!
VITTORIA! :)

Uno degli strumenti che utilizzo frequentemente in ambito lavorativo e che personalmente apprezzo tantissimo è Bugzilla.

So bene che questo strumento è nato come tool di bug tracking, e per quanto abbia una struttura dichiaratamente general purpose non sarebbe l’ideale per la gestione di progetti o comunque come tool di trouble ticketing.

Dalla mia esperienza però purtroppo le aziende italiane sono scarsamente abituate ad una gestione strutturata dei problemi e tendono a inondare il povero consulente (o tecnico in generale) con una valanga di email, generando entropia “a gerle”; in scenari di questo tipo anche una semplice istanza Bugzilla può letteralmente cambiare la vita (in positivo), poi diciamocelo, come non amare un software con un logo così carino?

Come tutte le cose però anche Bugzilla non è esente da difetti, in particolare le vecchie versioni hanno un motore di ricerca imho molto macchinoso, e al crescere dei bug le performance risultano tutt’altro che brillanti.
Guarda caso mi sono trovato proprio in questa situazione da un cliente, Bugzilla versione 2.22 su una altrettanto arcaica Debian Etch installata su un pc recuperato da uno sgabuzzino e oltre 8000 bug alle spalle, come potete immaginare fare query estese su questa istanza non è certo una passeggiata.

Preso dallo sconforto un giorno mi sono riservato un’oretta di tempo per buttar giù una semplice pagina php che andasse ad interrogare direttamente il database di Bugzilla per generare una tabella riassuntiva dei bug successivi ad una certa data, formattando i record con colori differenti in base allo stato del bug e che permettesse di aprire il dettaglio di ciascuno con un semplice link.

Il risultato è il seguente, ci tengo a precisare che:

• le mie skill di sviluppo php sono prossime allo zero assoluto
• la pagina viene utilizzata unicamente da rete trustata e il codice presente nella pagina è stato sviluppato in modo becero e in spregio a qualsiasi best practice
• la pagina effettua soltanto query di select, pertanto non è distruttiva, a prescindere da questo declino ogni responsabilità per qualsiasi utilizzo scorretto della stessa
• la pagina è stata sviluppata per interrogare il database MySQL di Bugzilla v. 2.22

Download: quick_bugzilla (2 KB)
MD5sum: a42afdbec6ea4cee123d04cb15fe6014

Se c’è una cosa che ho sempre odiato dal profondo del cuore è lo schedulatore di Oracle, al punto da arrivare a schedulare jobs (query, esecuzione di package, qualsiasi cosa) tramite bash script in cron mediante sqlplus.

Sicuramente qualche dba Oracle starà rabbrividendo, altri grideranno allo scandalo… non prendetela sul personale però imho, modestamente, personalmente, lo schedulatore di Oracle FA LETTERALMENTE CAGARE!

Terminato lo sfogo veniamo a noi, una cosa che capita spesso è schedulare un job per girare giornalmente ad una data ora, una cosa semplice, pulita che con crontab risulta essere di una banalità disarmante, vediamo come farlo con i job di Oracle.
Partiamo da presupposto per modificare un job di Oracle richiede una connessione al db con lo schema adatto e l’esecuzione del package DBMS_JOB.CHANGE.

La sintassi è apparentemente semplice:

exec DBMS_JOB.CHANGE( job, what, next_date, interval);

Il campo job indica l’id del job (lo trovate lanciando una select sulle viste dba_jobs o user_jobs) , il campo what indica cosa deve fare il job in questione, il campo next_date indica la prossima data di esecuzione, il bello viene con l’intervallo.

Oracle utilizza un perverso sistema di calcolo degli intervalli temporali, partiamo dall’istruzione SYSDATE che riporta data e ora corrente.

WTF!?!?! Dove diavolo è l’ora?
Pensavate forse di trovarvi ad usare un database amichevole e con una interfaccia ragionevole? Oh ragazzi state lavorando su Oracle! La complicazione è una feature…
Utilizzate l’istruzione to_char per renderizzare data e ora in un formato umano.

Ma se voglio visualizzare la data di domani? Utilizzate l’istruzione SYSDATE+1 che somma 24 ore alla data e ora correnti

Ora il volo pindarico: per identificare le ore 5:00 del giorno successivo dovete partire dalle 00:00 di SYSDATE+1 (mediante istruzione TRUNC) e aggiungere 5/24.

Prestate molta attenzione alle parentesi, specialmente se usate l’istruzione TRUNC, ad esempio tra “TRUNC(SYSDATE+1)+5/24” e “TRUNC((SYSDATE+1)+5/24)” c’è una enorme differenza.

Non disperate, questo è solo un piccolo assaggio dell’assurda e ingiustificata complessità e inusabilità di Oracle.

Recentemente IBM ha diramato un security bulletin in cui dichiara deprecato l’utilizzo del fantastico client di amministrazione web bases di IBM Lotus Domino (webadmin.nsf) a causa di alcune vulnerabilità di tipo cross-site scripting e una vulnerabilità di tipo cross-site request forgery.

Giusto una manciata di riflessioni in merito:

1. a fronte di un bug, una vulnerabilità, un problema di sicurezza, una azienda seria (e sottolineo SERIA) dovrebbe FIXARE il problema e non nascondere la testa sotto la sabbia dicendo “Beh sai che c’è? Non devi più usarlo…”
2. proporre come unica soluzione l’utilizzo del client di amministrazione IBM Domino Administrator è (scusate il francesismo) UNA CAZZATA COLOSSALE in quanto il client di amministrazione è disponibile SOLO per Windows, gli amministratori Domino che utilizzano GNU/Linux o MacOS X “si attaccano al tram e urlano in curva” (e questo nonostante i proclami planetari che IBM ha propinato per un decennio a favore dell’adozione di GNU/Linux)
3. IBM non si è limitata a ignorare i problemi di webdadmin, l’ha proprio ignorato in toto da sempre (ovvero dall’acquisizione di Lotus) tant’è che questo potentissimo e utilissimo tool è rimasto identico a com’è nelle release Domino di 10 anni fa, una accozzaglia di applet java che fa molto “nineties”
4. In riferimento al punto 3, visto che IBM non riesce a convincere mezzo cliente a migrare il suo parco applicativo nfs alle nuove e potenti tecnologie introdotte con la release 8 di Notes/Domino (Xpages tanto per dirne una), quale miglior case del rifacimento di un pezzo fondamentale dello stesso prodotto per mostrare le potenzialità di queste tecnologie?
5. Dove diavolo è finito il motto “MobileFirst” razza di ipocriti?

Shame on you Big Blue…