Immaginate come sarebbe la vita se un servizio critico andasse in panne pochi minuti fa, e voi foste chiamati a salvare la situazione. Tentate di riavviare il servizio, e semplicemente non ve lo dà. Non ci sono messaggi di errore, ma soprattutto, nessuna traccia di ciò che stava facendo prima di decidere di morire. Cento e una causa vi attraversa la mente, e vi rendete conto che non c’è modo di sapere in quale direzione andare. Forse si potrebbe riavviare il server del tutto. Solo forse.
Questo scenario è uno dei tanti in cui la registrazione può venire in vostro soccorso. Di solito, un software in esecuzione tiene un registro delle attività importanti relative al suo funzionamento per i posteri in un file. Qualsiasi cosa può essere conservata in un file di log in quanto aiuta gli sviluppatori e i sysadmin a sapere cosa è successo con un particolare pezzo di software dopo il fatto. I file di log sono anche usati da persone orientate alla sicurezza per rivedere l’accesso a particolari risorse. Nel networking o nella messaggistica, i file di log registrano il tempo in cui i messaggi sono stati inviati o ricevuti per riferimenti successivi.
I file di log, per definizione, continuano ad aumentare di dimensione a seconda della frequenza e della verbosità con cui vengono aggiornati. Per servire il loro scopo, sono normalmente aperti in modalità append e contengono timestamp per aiutare la risoluzione dei problemi e la forense. Tuttavia, questo pone un problema in quanto le grandi dimensioni dei file rendono il lavoro con i file di log un processo ingombrante sia per il sistema che per il revisore umano. I registri sono ruotati per mantenere i file di log tenibili. In parole povere, un nuovo file viene aperto mentre quello più vecchio viene chiuso e conservato o cancellato a seconda delle preferenze di progettazione. Questo evita che i log riempiano intere partizioni e mettano in ginocchio i sistemi nel processo. Potreste aver notato la rotazione dei log al lavoro su un sistema vicino. Guardate le date sui file boot.log.
In questo caso, quando si verifica una condizione specifica, il file corrente viene rinominato aggiungendo una data per identificarlo e tracciarlo, e viene aperto un nuovo file con il nome originale, pronto a ricevere i messaggi di log in arrivo.
Il logging in Linux (rsyslogd)
Come ci si potrebbe aspettare, il logging nei sistemi Linux, come il server CentOS 7 che sto usando per l’illustrazione, si basa su un demone per facilitare il logging. Rsyslogd è il nome del vecchio servizio affidabile ed è open-source. In realtà, non è così vecchio. È una versione migliorata del demone originale syslog, e possiede la capacità di elaborare rapidamente e inoltrare i log a qualsiasi posizione in una rete IP. Oltre a syslog e rsyslog, c’è syslog-ng, che è ancora un altro demone per gestire i log. Il gestore dei log di default dipende dalla distro che si sceglie. Rsyslog è presente di default in molte distro basate su Red Hat. Eseguite il seguente comando per verificarne la presenza e la versione sul vostro sistema:
rsyslogd -v
Siccome è un demone, è possibile controllare che sia attivo utilizzando systemd come segue:
systemctl status rsyslogd
Se, per qualsiasi motivo, non è in esecuzione, è possibile avviarlo tramite systemd.
Logrotate
Logrotate è un’utilità di Linux la cui funzione principale è – aspettate – ruotare i log. Se non è installato come parte dell’installazione predefinita del sistema operativo, può essere installato semplicemente eseguendo:
yum install logrotateIl file binario può essere localizzato a /bin/logrotate.
Installando logrotate, un nuovo file di configurazione viene messo nella directory /etc/ per controllare il comportamento generale dell’utilità quando viene eseguita. Inoltre, viene creata una cartella per i file di configurazione di snap-in specifici del servizio per richieste di rotazione dei log su misura. Più avanti su questo.
Lavoro cron giornaliero
Un cron lavoro viene eseguito quotidianamente per avviare l’utilità. Questo si ottiene mettendo una chiamata all’utilità nella cartella standard cron per i lavori giornalieri. Mentre le specifiche della chiamata sono fuori dallo scopo di questo articolo, basti dire che la chiamata è solo uno script Bash che esegue il logrotate binario, dicendo al sistema cosa fare in caso di errore.
Posizione standard dei file di log
I log su un sistema Linux possono essere posizionati ovunque i permessi lo permettano. Tuttavia, a causa del fatto che cambiano continuamente in dimensione e contenuto, per definizione, la gerarchia del file system prescrive che siano tenuti nella /var/log/ directory.
Lo screenshot qui sotto è una sbirciata al contenuto della mia /var/log directory.
File di configurazione ed esempi
/etc/logrotate.conf
Il primo file di cui prendere nota per quanto riguarda il funzionamento di logrotatelogrotate.conf. Questo file di configurazione contiene le direttive per la rotazione predefinita dei file di log. Se non c’è un insieme specifico di direttive, l’utilità agisce secondo le direttive di questo file.
Di seguito è riportato un esempio del contenuto del file di configurazione.
Passiamo attraverso alcune delle direttive per farci un’idea della flessibilità di logrotate. Graziosamente, l’autore dell’utilità ha messo abbastanza commenti per far partire un principiante. Potete anche vedere la pagina man per un’immersione più profonda. Le direttive weeklydateextcompresscreate, e rotate 4 dichiarano che i file di log devono essere ruotati settimanalmente, che la data di rotazione deve essere usata come suffisso identificativo dei file ruotati, che i file ruotati devono essere compressi, che un nuovo file deve essere creato per ricevere i log in arrivo, e che non devono essere tenuti più di quattro log. In altre parole, il quinto log più recente dovrebbe essere cancellato. Si noti inoltre che sul mio sistema, a causa della presenza del # prima della direttiva compress, la compressione è disabilitata per default.
C’è anche una direttiva per includere una particolare cartella: /etc/logrotate.d. Questa cartella è usata per le richieste di rotazione dei log specifiche del pacchetto. I pacchetti progettati per trarre vantaggio da logrotate rilasciano i file di configurazione in questa cartella. Questa modularità è in linea con lo spirito di Linux e migliora l’estensibilità dell’utilità. I file di configurazione contengono direttive simili e file di log personalizzati dove applicabile. Puoi anche creare il tuo file di configurazione per gestire qualsiasi file di log di tua scelta. Basta dare un nome al file, aggiungere il file di log da elaborare e metterlo in questa directory. Infine, ci sono direttive per i file di log senza pacchetti proprietari, come wtmp e altri file di log di sistema. La pagina man è piena di altre direttive, e per gli utenti che hanno esigenze di rotazione più specifiche, consiglio vivamente di darle un’occhiata.
/etc/logrotate.d
Fortunatamente, ho parlato considerevolmente della directory /etc/logrotate.d, quindi senza troppi giri di parole, lasciate che vi mostri il contenuto di questa directory per portare a casa le idee condivise in precedenza.
E per sicurezza, diamo un’occhiata al file di configurazione di Samba.
Si può notare quanto sia simile a logrotate.conf? Prima di chiudere il sipario su questo pezzo, passiamo in rassegna alcune delle direttive di questo file:
/var/log/samba/* – Il file di log da ruotare. In questo caso, è ogni file di log nella directory dei log di Samba.
notifempty – Direttiva che afferma che il file non dovrebbe essere ruotato se è vuoto.
olddir /var/log/samba/old – Posizione per memorizzare i vecchi log ruotati.
missingok – Impedisce che logrotate lanci un errore se il file di log manca.
copytruncate – Non chiudere il file di log. Fate una copia, che sarà il file ruotato e rinominato, e poi troncate il file di log a dimensione zero
Riuscite a indovinare cosa fa la direttiva sharedscripts? Non c’è bisogno di indovinare – consultate la pagina man.
Concludendo