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…

Fin da quando ho cominciato a giocare con le prime distribuzioni GNU/Linux (si trattava del 1998 con una Redhat 5.0, seguita da una Debian potato un paio d’anni dopo) non ho potuto fare a meno di rimanere affascinato dall’universo IT che si contrapponeva al mondo commerciale, ciò nonostante non ho mai approfondito molto il concetto di free software, la storia della Free Software Foundation e l’opera di Richard Stallman.

In particolare RMS mi è sempre parso un personaggio colorito nei modi ma piuttosto talebano nella sostanza, col passare degli anni, il lavoro e l’esperienza sul campo ho capito che forse le mie impressioni iniziali non erano poi così lontane dalla realtà, quello che è cambiato è il valore che ho imparato a dare a queste impressioni superficiali.
Recentemente mi è capitato di leggere la bellissima biografia ufficiale di RMS “Codice Libero (Free as in Freedom)”, tra un aneddoto curioso e l’altro questo libro non ha fatto che confermare la convinzione che, per quanto intransigente e poco diplomatico, il messaggio e le idee di Stallman fossero imho essenzialmente corrette, e mi ha finalmente chiarito la vera portata globale di questa battaglia.

Una delle cose che mi ha particolarmente colpito in quel libro è notare la quantità INDUSTRIALE di personaggi chiave della storia informatica che hanno ruotato attorno a RMS, alla FSF e alle loro creature (GPL in primis).
E non mi riferisco solo a Linus Torvalds (il creatore del kernel linux, il cui rapporto con Stallman è stato, ed è ancora oggi estremamente complesso), pensate ad uno qualsiasi dei grandi progetti free software o open source che sta alla base delle odierne infrastrutture e servizi informatici (quindi anche dietro i tanto adorati servizi di social networking), non ce n’è uno il cui creatore non abbia venerato la figura di Stallman o non abbia avuto stretti rapporti con lui e la Free Software Foundation.

E’ stupefacente poi notare quanta disinformazione abbia accumulato attorno a se la figura di Stallman, questo suo modo di apparire trasandato e apparentemente hippy (niente di più lontano dalla sua storia e dal suo modo di pensare), piuttosto che le accuse assurde di fomentare una sorta di comunismo informatico (niente di più lontano dalle idee di libertà estrema che ha sempre divulgato e difeso).
Che tecnicamente RMS sia un genio è un dato di fatto (i suoi trascorsi accademici lo dimostrano, così come la sua attività come sviluppatore Lisp e C), ma lo è altrettanto dal punto di vista comunicativo, anzi politico e culturale, quindi ben al di fuori di quei confini IT che lui stesso ha sempre considerato come il suo unico perimetro d’azione.

Confesso che non vedo l’ora di assistere ad una sua conferenza, se c’è un personaggio che riuscirebbe a far muovere il sederone a questo kender campione di pigrizia è proprio RMS, nel frattempo Happy Hacking a tutti!

Dalla mia esperienza professionale ho notato che nella valutazione delle risorse per un server l’aspetto in assoluto più sottovalutato è lo storage.
Molte persone tendono a valutare il carico applicativo solo in termini computazionali e di occupazione ram, lo storage è sempre e solo considerato in termini quantitativi, al massimo vengono valutate misure per garantire continuità di servizio in caso di guasti (es array raid).

Eppure l’esperienza insegna che generalmente le cpu sono sovradimensionate (sono relativamente pochi gli ambiti in cui vengono spremute a dovere), idem per la ram (con la scusa che “costa poco” si tende sempre ad esagerare con questa risorsa), l’unica risorsa che ha mantenuto dei costi piuttosto elevati è lo storage, e guardacaso è proprio la risorsa su cui si tende a risparmiare.

C’è da dire che alla base di questa tendenza c’è anche una buona dose di ignoranza da parte di molti (presunti) specialisti che non sanno rilevare carico di I/O nemmeno quando ce l’hanno davanti al naso, anzi magari lo confondono con carico computazionale consigliando migrazioni a cpu ancora più potenti e quindi “più inutili”.

Rilevare carico di tipo IOWait non è difficile (quantomeno su sistemi operativi unix like), basta il semplice comando “top”…

…oppure i fantastici tool del package sysstat

…oppure software un po’ più complessi come Collectd (insieme al fantastico collectd graph panel).

Quello che risulta un po’ più ostico è risalire ai processi responsabili di questo carico, specialmente su macchine un po’ datate.

Sui server con sistemi operativi recenti (ad esempio da Rhel/CentOS 5.x in poi) questo compito è spaventosamente semplificato da uno dei tool che non deve mancare su nessun server, IOtop.

Su macchine più datate purtroppo non sempre è possibile utilizzare questi comodi strumenti, oppure a causa di policy di gestione particolarmente rigide non è proprio possibile installare altro software.
In questi casi occorre sfruttare quello che fornisce il buon vecchio kernel, anzitutto abilitando le funzioni di debugging di scrittura blocchi sui dispositivi di IO portando a 1 il parametro block_dump:

echo 1 > /proc/sys/vm/block_dump

Una volta effettuata questa operazione basta interrogare il kernel ed estrarre i dati utili al nostro scopo:

dmesg | egrep "READ|WRITE|dirtied" |  awk '{print $1}'|  sort | uniq -c | sort -rn | head -n 20

Il risultato è piuttosto chiaro e riporta i 20 processi (con tanto di pid tra parentesi) che generano il maggior carico di IO sul sistema da quando è stato attivato il debugging del kernel.

Al termine ricordatevi di riportare a zero il valore del parametro modificato precedentemente:

echo 0 > /proc/sys/vm/block_dump

A questo punto è possibile proseguire con l’indagine per scoprire per quale motivo il processo in questione sta impattando sul sottosistema di storage. Magari come me scoprirete qualche furbastro che alle 17:00 di venerdì ha pensato bene di lanciare un job particolarmente gravoso senza avvisare, e pensando che nessuno se ne accorgesse.

Ora vi lascio, devo preparare gli strumenti di tortura per l’interrogator… ehhhmm la verifica con l’utente lunedì prossimo ;)