Archivi tag: logrotate

Creazione di una logging facility mediante logrotate ed expect

Scenario

Diversi siti Web (Apache) con N virtual host, ciascuno dei quali utilizza 2 file di log dedicati (access ed error), per il salvataggio degli accessi (nel primo caso) e degli errori generati (nel secondo caso).

Problema

Data l’enorme mole di utenza, è necessario comprimere e salvare i suddetti file di log con cadenza settimanale, spostando l’archivio appena ottenuto su di una logging facility (nella fattispecie una linux box), utilizzando il protocollo SFTP.

Soluzione

Integrare lo scrip di logrotate con alcuni scrip expect fatti in casa.

logging-facility

Logrotate

Lo scrip logrotate che si occuperà della vera e propria rotazione dei file di log (con cadenza settimanale) è il seguente:

/var/log/httpd/*log {
    rotate 1
    missingok
    notifempty
    sharedscrips
    dateext
    compress
    copytruncate
    weekly
    postrotate
        /sbin/service httpd restart > /dev/null 2>/dev/null || true
    endscrip
    lastaction
        /root/logrotation/autoputlog/apache > /var/log/autoputlog/apache.log
    endscrip
}

/var/log/httpd/virtual/*/*log {
    rotate 1
    missingok
    notifempty
    sharedscrips
    dateext
    compress
    copytruncate
    weekly
    postrotate
        /sbin/service httpd restart > /dev/null 2>/dev/null || true
    endscrip
    lastaction
         /root/logrotation/autoputlog/apachecustom > /var/log/autoputlog/apachecustom.log
    endscrip
}

Nella fattispecie, la prima parte si occupa della rotazione dei file di log relativi alla root directory canonica di Apache, ovvero /var/www/html, mentre la seconda parte si occupa dei virtual host veri e propri.

I suddetti scrip ci permettono di integrare logrotate con expect grazie alla direttiva lastaction. In particolare, essa farà in modo che, una volta completata la rotazione (con la creazione di una tarball opportuna), venga eseguito lo scrip expect apache (nel primo caso) ed apachecustom (nel secondo caso), presenti nella directory /root/logrotation/autoputlog.

L’output realtivo al processo di esecuzione degli scrip in questione verrà salvato rispettivamente all’interno del file apache.log ed apachecustom.log, presenti in /var/log/autoputlog. Inoltre, sarà necessario creare i file in questione prima che la rotazione venga testata, utilizzando i comandi :

[root@frontend ~]# mkdir -p /var/log/autoputlog

e

[root@frontend ~]# touch apache.log apachecustom.log

Infine, di seguito riporto il contenuto dello scrip expect apache:

#!/usr/bin/expect
set timeout 60
set password "vostrapassword"
spawn sftp admin@iplogfacility:array1/logs/frontend1/httpd
expect "*?assword:*"
send "$password\r"
expect "sftp"
send "put /var/log/httpd/*.gz\r"
expect "sftp"
send "exit\r"
expect eof

ed apachecustom:

#!/usr/bin/expect
set timeout -1
set password "vostrapassword"
spawn sftp admin@iplogfacility:array1/logs/frontend1/httpd
expect "*?assword:*"
send "$password\r"
expect "sftp"
send "cd vhost1\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost1/*.gz\r"
expect "sftp"
send "cd ../vhost2\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost2/*.gz\r"
expect "sftp"
send "cd ../vhost3\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost3/*.gz\r"
expect "sftp"
send "exit\r"
expect eof

Non ci rimane che lanciare forzatamente logrotate per testarne il funzionamento, utilizzando il comando:

[root@frontend ~]# logrotate -f /etc/logrotate.d/httpd

ed abbiamo finito.

A presto.

Centos 6 e snmptrapd: ricevere le trap SNMP sulla nostra linux box

Il protocollo SNMP, nativamente, ci mette a disposizione 2 modalità di funzionamento: quella classica, basata sul semplice polling, che utilizza la porta UDP 161, e quella “asincrona”, le cosiddette trap, che utilizzano la porta UDP 162.

Va da se che la seconda modalità è migliore rispetto alla prima, in quanto ci consente di ricevere un allarme quasi in tempo reale, dato che è proprio il dispositivo monitorato a generare l’evento (trap) ed a inoltrarcelo.

snmptrap

Ma vediamo ora come configurare la nostra linux box in modo da farle accettare (e loggare) le suddette trap.

Iptables

La prima cosa da fare consiste nel consentire il traffico UDP in ingresso, sulla porta 162:

iptables -I INPUT -p udp --dport 162 -j ACCEPT

Ovviamente tale regola iptables può essere ulteriormente affinata, specificando, ad esempio, l’interfaccia in ingresso (-i), l’IP sorgente (-s) e l’IP di destinazione (-d).

Configurazione di snmptrapd

Adesso occorre configurare il demone che si occupa della ricezione delle trap, ovvero snmptrapd.

Il suo file di configurazione è /etc/snmp/snmptrapd.conf, il cui contenuto dovrà essere simile al seguente:

authCommunity log,execute,net keypublic
format1 %l-%m-%y %h:%j:%k from %A: %b %P %N %W %v\n
format2 %l-%m-%y %h:%j:%k from %A: %b %P %N %W %v\n

La prima entry specifica la community string (keypublic) e le azioni che snmptrapd può effettuare alla ricezione delle trap, ovvero loggarle (log), eseguire un evento specifico tramite handler (execute) oppure inoltrarle ad un altro dispositivo connesso in rete (net).

Mediante le direttive format1 e format2 (utilizzare, rispettivamente, nell’ambito del protocollo SNMPv1 e v2c), specifichiamo il formato del file di log in cui verranno salvate le trap ricevute. In particolare, con:

%l-%m-%y %h:%j:%k

indichiamo il timestamp nel formato giorno-mese-anno ora:minuto:secondo.

Utilizzando invece:

from %A

siamo in grado di loggare il nome del dispositivo che ci ha inviato la trap, mentre con:

%b

ricaviamo l’indirizzo IP del suddetto dispositivo.

Infine, con:

 %P, %N, %W

abbiamo rispettivamente la community string utilizzata dalla trap, la stringa enterprise (che identifica univocamente il produttore del dispositivo) e la descrizione della trap. Ecco un esempio del contenuto del file di log popolato da snmptrapd:

23-7-2015 10:9:0 from 10.12.12.3: UDP: [10.12.12.3]:62741->[10.12.12.2] TRAP, SNMP v1, community keypublic VMWARE-CIMOM-MIB::vmwCimOm Enterprise Specific VMWARE-ENV-MIB::vmwEnvIndicationTime.0 = STRING: 2015-7-23,8:8:59.0

Occorre notare che le trap non vengono ricevute (e loggate) in formato numerico, in quanto sulla linux box sono presenti le MIB (scritte attraverso il linguaggio SMI) specifiche per i dispisitivi monitorati (in questo caso degli host VMWare). Solo a titolo informativo, le suddette MIB vanno salvate all’interno della directory /usr/share/snmp/mibs/.

 Opzioni di avvio

Una volta configurato, snmptrapd deve essere avviato utilizzando determinate opzioni, affinchè il processo di logging venga effettuato secondo le nostre necessità. Il file in cui specificare tali opzioni è /etc/sysconfig/snmptrapd, il cui contenutò dovrà essere simile al seguente:

OPTIONS="-A -m ALL -M /usr/share/snmp/mibs -Lf /var/log/snmptrapd.log -p /var/run/snmptrapd.pid"

dove l’opzione -A indica la modalità di scrittura del file di log (append); -m ALL indica la necessità di utilizzare tutte le MIB presenti sul sistema; -M serve a specificare il pathname delle MIB; -Lf indica il file di log ed infine -p punta al pathname del file *.pid (process ID) associato al demone in questione.

Rotazione del file di log

Naturalmente un file di log troppo grande risulta molto più difficile da consultare, ergo occorre definire delle regole di rotazione utilizzando lo strumento messo a disposizione dalla nostra linux box, ovvero logrotate. In particolare, il contenuto del file snmptrapd presente nella directory /etc/logrotate.d dovrà essere il seguente:

/var/log/snmptrapd.log {
    rotate 10
    missingok
    notifempty
    sharedscripts
    delaycompress
    copytruncate
    weekly
    postrotate
        /sbin/service snmtrapd restart > /dev/null 2>/dev/null || true
    endscript
}

Tra le suddette opzioni, quella più importante è certamente copytruncate, senza la quale, dopo ogni rotazione, il file di log non sarebbe in grado di registrare nuovi eventi.

Ora che è tutto configurato possiamo avviare il demone:

[root@linuxbox ~]# service snmptrapd start

e fare in modo che venga eseguito automaticamente dopo ogni boot:

[root@linuxbox ~]# chkconfig snmptrapd on

Invio tramite email delle trap di allarme

L’ultimo step consiste nel fare in modo che tutte le trap di allarme vengano inviate sulla nostra mailbox. Per fare ciò si può utilizzare swatch, il cui file di configurazione (/etc/swatch_snmp.conf) dovrà essere simile a questo:

#SNMP TRAP ALERT
watchfor  /Alert|alert/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH LINUX-BOX: SNMP TRAP ALERT

Editiamo il file /etc/rc.local in modo da avviare automaticamente swatch ad ogni boot della macchina:

swatch -c /etc/swatch_snmp.conf -t /var/log/snmptrapd.log &

Lanciamo il comando:

[root@linuxbox ~]# swatch -c /etc/swatch_snmp.conf -t /var/log/snmptrapd.log &

ed abbiamo finito.

Alla prossima.

SOHO 77 e logging su una linux box

In questo post abbiamo visto come salvare i log di un Cisco PIX 501 su di un apposito server linux. Oggi invece descriverò la procedura per impostare correttamente il logging su di un router Cisco SOHO 77, affinchè le informazioni da esso generate vengano inviate ad una linux box che funge da logserver.

soho77.jpg


SOHO 77

Per prima cosa entriamo in modalità enable e lanciamo un conf t:

soho77# conf t

soho77(config)#

Adesso digitiamo i seguenti comandi:

soho77(config)# logging <indirizzo IP del logserver>

soho77(config)# log facility local2

Nel caso in cui si voglia impostare un certo livello di severity (ad esempio warning), deve essere usato il comando:

soho77(config)# logging trap 4

Infine, lanciamo un copy run start per rendere effettive le modifiche apportate alla configurazione del nostro router:

soho77(config)# copy run start

Linux box

Sulla nostra linux box (ovvero il logserver) occorre fare in modo che il demone rsyslogd intercetti a dovere gli eventi inviati dal router.

Per prima cosa apriamo in scrittura il file 50-default.conf presente nella directory /etc/rsyslog.d ed inseriamo la seguente stringa subito dopo user.* :

local2.4                        /var/log/soho77.log

Creiamo il file che dovrà contenere i log del SOHO77:

nightfly@nightbox:/etc/rsyslog.d$ sudo touch soho77.log

Riavviamo quindi il demone rsyslogd:

nightfly@nightbox:/etc/rsyslog.d$ sudo service rsyslog restart

A questo punto non ci resta che definire appositamente la logrotation, in modo da tenere traccia dei log inviati dal router per un giusto lasso di tempo, magari sottoforma di tarball.

Per fare ciò posizioniamoci nella directory /etc/logrotate.d/ e creiamo il file soho77, il cui contenuto dovrà essere:

/var/log/soho77.log {

rotate 7

weekly

compress

missingok

notifempty

}

In particolare, il numero massimo di log che verranno conservati (comprese le tarball) è pari a 7 (rotate 7), ciascun log verrà compresso (compress) ed archiviato settimanalmente (weekly). Inoltre, nel caso in cui il file di log sia mancante non verrà generato alcun messaggio di errore (missingok) e la rotation non verrà attuata quando il file di log risulta vuoto (notifempty).

Fine del post, alla prossima.