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

Aaron H. Swartz (November 8, 1986 – January 11, 2013)

 Requiescat in pace

Una feature di Windows che qualunque amministratore di rete utilizza pesantemente sono le condivisioni amministrative.
Sono utili per un sacco di motivi, permettono di eseguire software in remoto, permetto di accedere ai dettagli di un sistema da remoto, permettono di accedere ai volumi di un sistema da remoto (i celebri \\server\C$, D$ etc etc).
So già che qualcuno storcerà il naso per quanto sto per dire, però queste condivisioni di rete sono estremamente comode anche per fare dei backup (e non a caso io le uso per i miei backup domestici, mount in sola lettura ovviamente…).

Ahimè Windows 8 non va molto d’accordo con le admin shares, pertanto per usarle occorre essere un tantino… insistenti ;)

Per prima cosa occorre abilitare le share di rete, per farlo basta aprire il pannello di controllo e selezionare il link “Rete e Internet”

Poi cliccare su “Centro di connessioni di rete e condivisione”

E infine su “Modifica impostazioni di condivisione avanzate”

Arrivati a questo punto abilitate le condivisioni di rete per i profili di rete che vi interessano.

Una volta fatto aprite l’editor di registro (WIN+R, digitate “regedit” e date invio) e spostatevi alla chiave:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System

Create quindi un nuovo valore di tipo DWORD, chiamatelo LocalAccountTokenFilterPolicy e assegnategli valore 1.

Cliccando su OK il risultato dovrebbe essere il seguente

Riavviate e magicamente le condivisioni amministrative saranno attive a accessibili agli utenti del gruppo Administrators.