Cerchiamo innanzitutto di capire cos’è il Syslog.
Iniziamo da un esempio pratico, loggatevi sulla macchina come root e esplorate la directory /var/log. Troverete un certo numero di file di testo che contengono il log, ossia la traccia di ciò che è accaduto, relativamente a vari eventi o programmi del sistema.
Ad esempio in /var/log/maillog troverete gli eventi che riguardano l’email, in /var/log/cron il log dei comandi che sono stati impartiti attraverso il cron, infine in /var/log/messages troverete tutti i messaggi che hanno una certa rilevanza per il sistema.
Facciamo un esperimento, digitate:# logger Messaggio di prova
Se visualizzate il file /var/log/messages troverete, proprio in fondo, una riga tipo la seguente:Jun 7 12:40:12 gollum maurizio: Messaggio di prova
La riga in questione riporta, in ordine, la data e ora dell’evento registrato, il nome della macchina su cui si è verificato l’evento (nel mio caso gollum), il nome dell’utente che ha generato l’evento (maurizio) e infine una stringa di testo descrittiva.
Abbiamo quindi scoperto che è possibile aggiungere, da un qualsiasi script, usando il comando logger, una riga al registro dei messaggi del sistema.
Cerchiamo però di capire meglio come funziona il syslog.
In primo luogo notiamo che Syslog è un sistema client/server. C’è un software server, syslogd, che gira stando in ascolto e occupandosi di accodare, secondo una serie di regole, i messaggi che gli arrivano ai vari file di log.
I messaggi possono giungere al syslogd sia in locale (come con l’utility logger nell’esempio di prima), sia dalla rete attraverso un protocollo di comunicazione estreamamente semplificato basato su datagrammi UDP.
Le regole seguite dal syslogd per archiviare i messaggi ricevuti sono contenute nel file /etc/syslog.conf, e sono basate sui concetti di facility e di level.
La facility è una sorta di categoria a cui appartiene il messaggio. Le categorie definite sono le seguenti:
auth: messaggi relativi al sistema di autorizzazione (es. login, su, getty, ecc.)
authpriv: come auth
console: messaggi visualizzati sulla console attraverso il device /dev/console
cron: messaggi provenienti da servizi di schedulazione come cron o at
daemon: messaggi provenienti da altri servizi
ftp: messaggi relativi al sistema di ftp server (es. ftpd, tftpd)
kern: messaggi relativi al kernel
lpr: messaggi generati dal sistema di stampa (es. lpr, lpc, lpd)
mail: messaggi relativi al sistema di posta email
mark: riservato per uso interno al syslog
news: messaggi relativi al sistema news
ntp: messaggi relativi al network time protocol
security: messaggi relativi al sistema di sicurezza (es. ipfw)
syslog: messaggi generati internamente al syslog
user: messaggi generici di livello utente (questa è la facility di default se non ne viene specificata una)
uucp: messaggi relativi al sistema uucp
local0, local1,….local7: per utilizzi definiti dall’utente
Ogni messaggio, oltre ad appartenere ad una facility, è poi caratterizzato da un livello. I livelli definiti hanno un ordine di “gravità” e sono i seguenti:
debug: 7 - messaggi di debug
info: 6 - messaggi informativi
notice: 5 - messaggi di notifica
warning: 4 - messaggi di attenzione
err: 3 - messaggi di errore
crit: 2- messaggi di errore critico
alert: 1- messaggi di allerta
emerg: 0 - messaggi di emergenza
Il file di configurazione /etc/syslog.conf ha una sintassi estreamamente semplice: in pratica ogni riga che non sia un commento (preceduta da #) è divisa in due colonne. Nella colonna di sinistra sono indicate le facility e le priority da loggare e in quella di destra il nome del file in cui immagazzinare i messaggi. Le due colonne sono, storicamente, separate da un carattere di tabulazione, ma FreeBSD accetta anche al separazione fatta con degli spazi.
Ad esempio la seguente riga:mail.alert /var/log/mailalert
imporrebbe al syslogd di accodare al file /var/log/mailalert tutti i messaggi della facility mail con livello uguale o superiore a alert.
Nella colonna di sinistra è possibile specificare una lista di facility/priority separandole con un punto e virgola, ad esempio la riga:mail.alert;kern.alert /var/log/alerts
impone al syslog di archiviare tutti i messaggi di livello alert o superiori provenienti dalla facility mail e dalla facilty kernel.
Sono anche disponibili alcuni marcatori speciali, utili per semplificare la compilazione della configurazione; ad esempio il carattere * può essere utilizzato per specificare tutte le facility o tutti i livelli. Ad esempio:*.crit;kern.*;cron.* /var/log/miolog
archivierà tutti i messaggi di livello crit o superiore, da qualsiasi facility essi provengano, e tutti i messaggi delle facility kern e cron.
Inoltre, grazie alla keyword none specificata al posto del livello, è possibile escludere i messaggi di una certa facility, ad esempio:*.err;kern.none /var/log/errors
archivierà tutti i messaggi di qualsivoglia facility, di livello err o superiori, esclusa la facility kern, in /var/log/errors.
Attraverso la keyword = è inoltre possibile archiviare i messaggi di uno specifico livello, ad esempio:kern.=debug /var/log/kerneldebug
archivierà tutti e soli i messaggi di debug del kernel in /var/log/kerneldebug.
I più curiosi tra voi, che sono andati ad aprire il file /etc/syslog.conf presente sulla loro macchina, si saranno già accorti che si possono specificare più righe e definire più file di log. Ad esempio le prime tre righe (tolti i commenti) del file standard su FreeBSD (rel. 5.3) sono le seguenti:
*.notice;authpriv.none;kern.debug;
lpr.info;mail.crit;news.err /var/log/messages
security.* /var/log/security
auth.info;authpriv.info /var/log/auth.log
e di fatto impongo al syslog di archiviare in /var/log/messages tutti i messaggi dal livello notice per tutte le facility, esclusi tutti i messaggi della facility authpriv, ma includendo tutti i messaggi del kernel, i messaggi di lpr dal livello info, i messaggi di mail dal livello crit, i messaggi di news dal livello err.
La seconda riga impone di accodare a /var/log/security tutti i messaggi della facility security.
La terza riga invece impone di accodare a /var/log/auth.log i messaggi dal livello info in poi di auth e authpriv.
Ma non è finita, infatti è possibile dal lato facility/level, specificare come archiviare i messaggi provenienti da una fonte esterna, attraverso il carattere +, o da un certo programma attraverso il carattere !.
Utilizzare questi operatori consente di aprire dei “blocchi” dentro al file di configurazione. Ad esempio posso impostare una configurazione specifica da applicare a tutti i messaggi che provengono dalla macchina cerbero (ovviamente il nome cerbero deve essere definito nel dns o almeno nel file /etc/hosts), come nel seguente esempio:
+cerbero
*.err;kern.info /var/log/cerbero.log
+*
Nell’esempio abbiamo definito che tutti i messaggi provenienti dalla macchina cerbero vengano processati loggando tutti quelli di livello err o superiore, o quelli del kernel di livello info o superiore, nel file /var/log/cerbero.log.
L’ultima riga dell’esempio è opzionale, ma serve per “chiudere” il blocco di configurazione relativa a cerbero.
Ma se è possibile raccogliere dati syslog di altre macchine, deve essere possibile anche imporre al syslog di spedirli ad altre macchine. Infatti utilizzando il carattere speciale @ seguito dal nome di una macchina è possibile reindirizzare il flusso di log, invece che su un file, su un syslogd remoto. Nel seguente esempio spediamo tutti i messaggi relativi alla posta di livello info o superiore ad una macchina chiamata gollum (anche in questo caso il nome deve essere definito nel dns o in hosts):mail.info @gollum
Il file di configurazione del syslog permette molte altre cose, ma per adesso a noi basta questo e per ulteriori informazioni vi rimando alla lettura della pagina del man: man syslog.conf.
Passiamo ora a vedere come gestire qualche dettaglio della configurazione di base del syslogd per consentirgli di ricevere gli eventi dalla rete.
Dato che il syslogd si è prestato in passato a qualche uso improprio compromettendo la sicurezza di qualche sistema, di default FreeBSD lo avvia specificando lo switch -s che in pratica gli impone di ignorare tutti i messaggi provenienti da indirizzi di rete diversi da localhost.
Per modificare questa configurazione è necessario utilizzare lo switch -a specificando la subnet dalla quale consideriamo sicuro ricevere messaggi di tipo syslog. Normalmente specificheremo la subnet locale. Ad esempio se la subnet locale è 192.168.1.0/24, dovremo aggiungere al file di configurazione /etc/rc.conf la riga:syslogd_flags="-a 192.168.1.0/24:*"
E’ possibile specificare più subnet ripetendo lo switch -a, ad esempio:syslogd_flags="-a 192.168.1.0/24:* -a 192.168.2.0/24:*"
A questo punto per attivare la nuova configurazione basta riavviare il syslogd con il comando# /etc/rc.d/syslogd restart
A questo punto basta configurare i vari device di rete in modo che utilizzino il server syslog predisposto. Qui ovviamente la configurazione cambia da dispositivo a dispositivo, ma in generale vi troverete di fronte a tre possibilità:
1) Il dispositivo non supporta il syslog: qui non c’è niente da fare. Se supporta il protocollo SNMP potete trovare qualche strada alternativa, ma andiamo fuori dal tema di questo post.
2) Il dispositivo permette di configurare un syslog esterno ma non la facility: dovete utilizzare il carattere speciale + e il nome assegnato al device sulla rete per catturare gli eventi in un file specifico.
3) Il dispositivo permette di configurare sia il server syslog esterno sia una facility local da utilizzare: è il caso migliore, basta configurare la facility sul syslog.conf.
Tanto per fissare le idee, supponiamo di avere un dispositivo chiamato accesspoint, che consente di configurare il solo indirizzo del syslog server, ed un altro che invece consente di configurare anche una facility, e supponiamo di aver scelto la facility local1.
A questo punto per tracciare gli eventi di questi device in un file di log bisogna aggiungere a /etc/syslog.conf le seguenti righe:
local1.* /var/log/localnetwork.log
+accesspoint
*.* /var/log/localnetwork.log
+*
Attenzione: per far funzionare il tutto è necessario creare il file di log, impostare i corretti permessi, e riavviare il servizio syslogd:# touch /var/log/localnetwork.log # chown root:wheel /var/log/localnetwork.log # chmode 600 /var/log/localnetwork.log
I file di log hanno però un brutto difetto: tendono a crescere indefinitamente. Per questo FreeBSD ha una utility che consente di eseguire la cosìddetta rotazione dei file di log in automatico.
Per rotazione del file di log si intende l’archiviazione periodica di questi file, attraverso un meccanismo ne che assicura la conservazione per un tempo determinato.
Date, ad esempio, un’occhiata alla directory /var/log. Noterete che oltre al file maillog, dove abbiamo detto vengono archiviati gli eventi relativi alla facility mail, esistono anche mailog.0.bz2, maillog.1.bz2, ….maillog.7.bz2.
Noterete anche che questi file, compressi con bzip2, hanno tutti data di creazione alla mezzanotte ognuno del giorno precedente all’altro in sequenza.
Esempio:
# ll | grep maillog
-rw-r----- 1 root wheel 197803 Jun 7 15:20 maillog
-rw-r----- 1 root wheel 30003 Jun 7 00:00 maillog.0.bz2
-rw-r----- 1 root wheel 23086 Jun 6 00:00 maillog.1.bz2
-rw-r----- 1 root wheel 22552 Jun 5 00:00 maillog.2.bz2
-rw-r----- 1 root wheel 25153 Jun 4 00:00 maillog.3.bz2
-rw-r----- 1 root wheel 31391 Jun 3 00:00 maillog.4.bz2
-rw-r----- 1 root wheel 27132 Jun 2 00:00 maillog.5.bz2
-rw-r----- 1 root wheel 33441 Jun 1 00:00 maillog.6.bz2
-rw-r----- 1 root wheel 27581 May 31 00:00 maillog.7.bz2
In pratica a mezzanotte di ogni giorno viene eseguito un programma che cancella il log più vecchio (maillog.7.bz2), rinomina a scalare ogni log, ossia il 6 diventa il 7, il 5 diventa il 6 e così via, e infine crea maillog.0.bz2 comprimendo maillog e crea un nuovo maillog vuoto. E’ ovvio capire il perché questa operazione è detta rotazione!
FreeBSD esegue la rotazione in maniera automatica allo scadere di ogni ora, richiamando il programma newsyslog.
Questo programma viene pilotato dal suo file di configurazione /etc/newsyslog.conf. Questo file contiene una riga di configurazione per ogni file di log, con 8 colonne, due delle quali opzionali.
la prima colonna contiene il nome del file, la seconda, opzionale, contiene utente e gruppo (user:group) con i quali deve essere creato il file (se non si specificano il default è root:wheel), la terza specifica il modo con il quale deve essere creato il file, nella classica forma dei tre digit ottali. Solitamente si usa 600 per garantire la massima riservatezza.
La quarta colonna decide il numero di file da tenere nel processo di rotazione. Ad esempio nel caso del maillog questa colonna contiene 7. La quinta colonna permette di specificare una misura in KByte oltre la quale il file di log viene ruotato, ad esempio 100 vuol dire 100 KByte. Specificando * diciamo al programma di non limitare l’ampiezza del log.
La sesta colonna contiene la schedulazione di quando eseguire le rotazioni programmate. L’impostazione di questo campo è piuttosto complessa e vi invito a consultare man newsyslog.conf per avere informazioni più dettagliate. Per adesso considerate che è possibile specificare una data precisa (tipo 20051201T010000 = 1/12/2005 alle 01:00.00), oppure qualcosa tipo @T000000 (abbreviato in @T00) che significa tutti i giorni alle ore 00:00.00 (cioè mezzanotte).
Oppure un formato del tipo $M1D0 = il primo giorno del mese (M1) a mezzanotte (D0), oppure $D0=tutti i giorni a mezzanotte, o anche $W3D16 = tutti i mercoledi (W3) alle 16, o $W0 = tutte le domeniche a mezzanotte.
Infine specificando solo * è possibile ignorare la schedulazione e fare in modo che il log venga rotato solo in funzione della dimensione.
La settima colonna contiene uno o più flags, tra cui i più gettonati sono:
J = Usa bzip2 per archiviare il log
Z = Usa gzip per archiviare il log
B = Il file di log è binario quindi newsyslog non deve alterarlo
C = Se il file di log non esiste, crealo
Infine l’ottava e la nona colonna sono opzionali e servono per utilizzi avanzati.
Ad esempio se volessimo ruotare il file /var/log/localnetwork.log di cui sopra, dovremmo aggiungere questa riga a /etc/newsyslog.conf:/var/log/localnetwork.log 600 3 100 @T00 J
Grazie a questa riga il file verrebbe ruotato al raggiungimento dei 100KByte, e comunque ogni notte a mezzanotte, e conservato per 3 rotazioni in formato bzip2.
