giovedì 27 novembre 2014

cron > /dev/spam

Penso sia capitato piu' o meno a tutti i sysadmin di qualunque razza, età e professionalità di crearsi uno o piu' programmi o script per il monitoring di una qualche risorsa specifica. Non importa quale sistema di monitoring si usi, prima o poi occorre qualche riga di codice Perl o Shell per tenere sotto controllo una risorsa, il classico quick and dirty.
E siccome i sysadmin sono anche pigri, meglio dotare il proprio script di un alert via e-mail quando qualcosa va male.
E per essere proprio sicuri che il disastro non passi inosservato si manderà tale alert a piu' persone, in modo che anche in caso di assenza qualcuno possa dominare la situazione.

Fin qui tutto regolare, nulla di sconvolgente.
Se non fosse che ci sono sysadmin che semplicemente ignorano gli alert inviati da cron (e per esperienza sono gli stessi che fanno un update senza leggere le release notes!). Diversi anni fa ne ho conosciuta una tipologia che non solo ignorava gli alert, ma li classificava anche come spam!

Come ci si accorge di un simile atteggiamento? Ebbene io diversi anni me ne accorsi perché, durante una giornata di ferie, ricevetti una telefonata che mi informava che il servizio di posta si rifiutava di inviare nuove e-mail. Apparentemente un problema al demone stesso, o questo è quello che si pensa subito, fino a quando non ci si collega e si trova nella propria inbox qualche pagina come segue:



In breve il server di posta aveva, in un certo senso, fatto il suo dovere collassando sotto l'enorme mole di e-mail inviate da uno script che ogni minuto controllava una risorsa non disponibile inviando poi una mail di lamentela.
E ovviamente, nessuno prima si era accorto del fattaccio perché le e-mail veniva scartate a priori....

Quindi meglio essere sicuri che le e-mail siano trattate per quello che sono: delle risorse che vanno anch'esse controllato (manualmente). E meglio anche evitare che ogni minuto uno script fatto a mano si incazzi!

Nessun commento: