Old:Configurare un server Syslog su Debian

Introduzione

In una serverfarm, ma anche in una piccola rete casalinga, può risultare molto utile riunire i log di tutte le macchine in un unico posto. Si possono in questo modo applicare funzioni di analisi, ricerca e statistica che, in un unico intervento, restituiranno lo stato di tutte le macchine della rete, e sarà inoltre possibile configurare un unico strumento per inviare messaggi di alert quando lo stato di una qualsiasi delle macchine monitorate subisce un'alterazione potenzialmente pericolosa.
Debian, come è lecito aspettarsi, mette a disposizione degli ottimi strumenti per creare un server di log centralizzato.

Installazione di Syslog-ng

Il server syslog che prenderemo in considerazione sarà Syslog-NG. Pur non essendo installato di default su sistemi Debian, dove invece si può trovare syslogd, questo demone presenta diversi vantaggi:

1. Le connessioni possono essere stabilite via TCP al posto di UDP
2. I log tra host syslog-ng possono essere inviati crittati
3. I log possono essere filtrati in base alla criticità del loro contenuto
4. Il demone stesso è altamente personalizzabile

Procediamo quindi alla sua installazione:

# apt-get install syslog-ng

L'installazione rimuoverà automaticamente il demone syslog instalalto di default.

Configurazione del server Syslog

Il file di configurazione di syslog-ng è /etc/syslog-ng/syslog-ng.conf. Occorre aprirlo con un editor e decommentare la linea:

udp();

in modo da abilitare il demone a ricevere log da client remoti.
In questa configurazione è stata presa in considerazione una semplice gestione dei log (di default salvati in /var/log), senza l'implementazione di un database di archiviazione. Si tenga comunque presente che le possibilità di gestione dei log sono molto più avanzate di quelle mostrate in questa guida.

Installazione di phpLogCon

Per facilitare la lettura e la gestione dei log è uso comune ricorrere a interfacce grafiche. Su server senza l'ambiente grafico X installato potrebbe essere comodo ricorrere a un'interfaccia scritta in PHP. La scelta in questa guida è caduta su phpLogCon (http://www.phplogcon.org/), che a mio avviso rappresenta un ottimo compromesso tra funzionalità e facilità di installazione/gestione. Prima di installare phpLogCon è necessario installare e configurare un ambiente LAMP, seguendo ad esempio le indicazioni riportare in questa guida: LAMP: Linux, Apache, MySQL e PHP.
Una volta terminata la configurazione dell'ambiente LAMP si può procedere all'installazione di phpLogCon. Si scarichi innanzitutto la versione più aggiornata dal sito ufficiale: http://www.phplogcon.org/downloads.
Quindi si scompatti l'archivio appena scaricato e si copi la directory src all'interno del nostro server Apache:

# tar -xzvf phplogcon-2.3.11.tar.gz
# cd phplogcon-2.3.11
# mv src /var/www

Prima di continuare con l'installazione di phpLogCon occorre rendere rendere leggibili a phpLogCon i files di log syslog. Creiamo innanzitutto un nuovo gruppo e aggiungiamo l'utente www-data a questo gruppo:

# groupadd logadmin
# usermod -a -G logadmin www-data

Verifichiamo quindi la buona riuscita dei comandi:

groups www-data

Ora apriamo con un editor il file /etc/logrotate.conf e cerchiamo la voce create, modificandola in:

create 640 root logadmin

In questo modo la prossima volta che logrotate verrà eseguito i log diventeranno leggibili di default anche per il nostro webserver.

Configurazione di logrotate

L'utility logrotate è pensata per semplificare l'amministrazione dei files di log. Logrotate permette la rotazione automatica, la compressione, l'eliminazione e l'invio per mail dei files di log; può inoltre essere impostato per l'esecuzione giornaliera, settimanale, mensile o quando i logs raggiungono una certa dimensione predefinita.
Per installare logrotate su Debian:

# apt-get install logrotate

A titolo di esempio possiamo osservare la directory del web server Apache2 su un sistema in cui logrotate è in funzione, /var/log/apache2

root@test:~# ls -1 /var/log/apache2/
access.log
access.log.1
access.log.2.gz
access.log.3.gz
access.log.4.gz
access.log.5.gz
error.log
error.log.1
error.log.2.gz
error.log.3.gz
error.log.4.gz
error.log.5.gz

Si possono notare i files di log attualmente in uso (access.log e error.log), i files di log del giorno precedente (access.log.1 e error.log.1) e i files dei giorni ancora precedenti, che di default vengono compressi e conservati per cinque settimane. Logrotate può essere schedulato utilizzando <cron>. La directory /etc/cron.daily contiene infatti gli script che vengono eseguiti automaticamente ogni giorno dal sistema. Qui si può trovare lo script di logrotate. Ogni giorno questo script, al momento dell'esecuzione, esamina due cose:

1. il file di configurazione /etc/logrotate.conf
2. la directory di configurazione /etc/logrotate.d

Questa directory contiene i files di configurzione per i servizi installati sul server. Per esempio sul server esaminato in precedenza troveremo il file /etc/logrotate.d/apache2.
Un tipico file di configurazione di logrotate è simile a questo:

/var/log/apache2/*.log {
        weekly
        missingok
        rotate 52
        compress
        delaycompress
        notifempty
        create 640 root adm
        sharedscripts
        postrotate
                if [ -f /var/run/apache.pid ]; then
                        /etc/init.d/apache restart > /dev/null
                fi
        endscript
}

Analizziamolo nel dettaglio:

1. /var/log/apache2/*.log indica i files che vengono interessati dal processo.
2. weekly: i files sono rotati ogni settimana. Alternativa: daily
3. rotate nn: saranno conservati non più di nn files
4. compress: i files saranno compressi con gzip. Alternativa: nocompress
5. delaycompress: non comprime i log del giorno prima.
6. notifempty: non esegue la rotazione se il file è vuoto. Alternativa: ifempty
7. create xx user group:

         o If we have to create the new file give it the given mode, owner, and group.
   * sharedscripts
         o Run any given prerotate or postrotate script for each logfile individually. Opposite: nosharedscripts.
   * postrotate + endscript
         o Anything between these is executed after the rotation process. Opposite : prerotate

The upshot of this script is that any file which matches /var/log/apache2/*.log is rotated every week, compressed, if it's non-empty. The new file is created with the file mode of 640, and after the rotation has finished the server is restarted.

If we wish to install a local service which creates a logfile we can cause it to be rotated very easily, just by adding a new logrotate configuration file.

Assuming we have a new service "web" which produces its output in /var/log/web/output.log we can cause this to be rotated every day with a script like this:

/var/log/web/*.log {

 daily

 missingok

 rotate 7

 compress

 delaycompress

 create 640 web web

 sharedscripts

    /etc/init.d/web restart

 endscript

}

This will:

   * Run daily.
   * Keep no more than 7 days worth of logfiles at any one time.
   * Not complain if there is a logfile missing.
   * Compress the older files, but not yesterdays.
   * Create the new logfiles as being owned by the user and group fred.
   * Restart the service after rotating the logfiles.

Default /etc/logrotate.conf file as follows

1. see "man logrotate" for details

1. rotate log files weekly

weekly

1. keep 4 weeks worth of backlogs

rotate 4

1. create new (empty) log files after rotating old ones

create

1. uncomment this if you want your log files compressed

1. compress

1. packages drop log rotation information into this directory

include /etc/logrotate.d

1. no packages own wtmp, or btmp -- we'll rotate them here

/var/log/wtmp {

   missingok

   monthly

   create 0664 root utmp

   rotate 1

}

/var/log/btmp {

   missingok

   monthly

   create 0664 root utmp

   rotate 1

}

1. system-specific logs may be configured here