108.2 Lezione 1

Certificazione:

LPIC-1

Versione:

5.0

Argomento:

108 Servizi Essenziali di Sistema

Obiettivo:

108.2 Logging di sistema

Lezione:

1 di 2

Introduzione

I log possono essere i migliori amici di un amministratore di sistema. I log sono file (di solito file di testo) dove tutti gli eventi di sistema e di rete sono cronologicamente registrati dal momento in cui il sistema viene avviato. La gamma di informazioni che si possono trovare nei log include virtualmente ogni aspetto del sistema: tentativi di autenticazione falliti, errori di programma e di servizio, host bloccati dal firewall e altri ancora. Come si può immaginare, i log rendono la vita degli amministratori di sistema molto più facile quando si parla di risoluzione dei problemi, controllo delle risorse, rilevamento di comportamenti anomali dei programmi e così via.

In questa lezione discuteremo uno dei più comuni ambienti di logging attualmente presenti nelle distribuzioni GNU/Linux: rsyslog. Studieremo i diversi tipi di log che esistono, dove sono memorizzati, quali informazioni includono e come queste informazioni possono essere ottenute e filtrate. Discuteremo anche di come i log possono essere conservati in server centralizzati attraverso reti IP, la rotazione dei log e il ring buffer del kernel.

Il Log di Sistema

Nel momento in cui il kernel e i diversi processi nel sistema iniziano a funzionare e a comunicare tra loro, vengono generate molte informazioni sotto forma di messaggi che sono — per la maggior parte — inviati ai log.

Senza i log, la ricerca di un evento accaduto su un server genererebbe di sicuro grandi mal di testa agli amministratori di sistema: da qui l’importanza di avere un modo standardizzato e centralizzato di tenere traccia di qualsiasi evento di sistema. I registri sono determinanti e rivelatori quando si tratta di risoluzione dei problemi e sicurezza e sono fonti di dati affidabili per comprendere le statistiche di sistema e fare previsioni di tendenza.

Lasciando da parte systemd-journald (che discuteremo nella prossima lezione), il logging è stato tradizionalmente gestito da tre principali servizi dedicati: syslog, syslog-ng (syslog new generation) e rsyslog (“the rocket-fast system for log processing”). rsyslog ha portato importanti miglioramenti (come il supporto RELP) ed è diventato la scelta più popolare al giorno d’oggi. Ognuno di questi servizi raccoglie messaggi da altri servizi e programmi e li memorizza in file di log, tipicamente sotto /var/log. Tuttavia, alcuni servizi si prendono cura dei propri log (prendi come esempio il server web Apache HTTPD o il sistema di stampa CUPS). Allo stesso modo, il kernel Linux usa un ring buffer in-memory per memorizzare i suoi messaggi di log.

Note	`RELP` sta per Reliable Event Logging Protocol ed estende la funzionalità del protocollo syslog per fornire una consegna affidabile dei messaggi.

Dato che rsyslog è diventato lo strumento di logging de facto in tutte le principali distro, ci concentreremo su di esso per questa lezione. rsyslog utilizza un modello client-server. Il client e il server possono vivere sullo stesso host o su macchine diverse. I messaggi sono inviati e ricevuti in un particolare formato e possono essere conservati in server centralizzati rsyslog attraverso reti IP. Il demone di rsyslog — rsyslogd — lavora insieme a klogd (che gestisce i messaggi del kernel). Nelle prossime sezioni verranno discussi rsyslog e la sua infrastruttura di logging.

Note	Un demone è un servizio che funziona in background. Si noti la `d` finale nei nomi dei demoni: `klogd` o `rsyslogd`.

Tipi di Log

Poiché i log sono dati variabili, normalmente si trovano in /var/log. Approssimativamente, possono essere classificati in system logs e service or program logs.

Vediamo alcuni log di sistema e le informazioni che conservano:

/var/log/auth.log: Attività relative ai processi di autenticazione: utenti registrati, notifiche sudo, cron job, tentativi di login falliti, ecc.
/var/log/syslog: Un file centralizzato per praticamente tutti i log catturati da rsyslogd. Poiché include così tante informazioni, i log sono distribuiti in altri file secondo la configurazione fornita in /etc/rsyslog.conf.
/var/log/debug: Informazioni di debug dai programmi.
/var/log/kern.log: Messaggi del kernel.
/var/log/messages: Messaggi informativi che non sono relativi al kernel ma ad altri servizi. È anche la destinazione predefinita del log del client remoto in un’implementazione centralizzata del server di log.
/var/log/daemon.log: Informazioni relative a demoni o servizi in esecuzione in background.
/var/log/mail.log: Informazioni relative al server di posta elettronica, per esempio postfix.
/var/log/Xorg.0.log: Informazioni relative all’ambiente grafico Xorg.
/var/run/utmp and /var/log/wtmp: Accessi riusciti
/var/log/btmp: Tentativi di login falliti, per esempio attacco brute force via ssh.
/var/log/faillog: Tentativi di autenticazione falliti.
/var/log/lastlog: Data e ora degli ultimi accessi dell’utente.

Vediamo invece adesso alcuni esempi di log di servizio:

/var/log/cups/: Directory per i log del Common Unix Printing System. Include comunemente i seguenti file di log predefiniti: error_log, page_log e access_log.
/var/log/apache2/ or /var/log/httpd: Directory per i log di Apache Web Server. Di solito include i seguenti file di log predefiniti: access.log, error_log, e other_vhosts_access.log.
/var/log/mysql: Directory per i log di MySQL - Relational Database Management System. Include comunemente i seguenti file di log predefiniti: error_log, mysql.log e mysql-slow.log.
/var/log/samba/: Directory per i log del protocollo Session Message Block (SMB). Di solito include i seguenti file di log predefiniti: log., log.nmbd e log.smbd.

Note	Il nome esatto e il contenuto dei file di log possono differire nelle varie distribuzioni Linux. Esistono anche log particolari per distribuzioni specifiche come `/var/log/dpkg.log` (contenente informazioni relative ai pacchetti `dpkg`) in Debian GNU/Linux e le sue derivate.

Leggere i Log

Per leggere i file di log, prima devi assicurarti di essere l’utente root o di avere i permessi di lettura sul file. Puoi usare una varietà di utility come:

less o more

Paginatori che permettono di visualizzare e scorrere una pagina alla volta:

root@debian:~# less /var/log/auth.log
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:49:46 debian sshd[905]: Accepted password for carol from 192.168.1.65 port 44296 ssh2
Sep 12 18:49:46 debian sshd[905]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Sep 12 18:49:46 debian systemd-logind[331]: New session 2 of user carol.
Sep 12 18:49:46 debian systemd: pam_unix(systemd-user:session): session opened for user carol by (uid=0)
(...)

zless o zmore

Lo stesso di less e more, ma usato per i log che sono compressi con gzip (una funzione comune di logrotate):

root@debian:~# zless /var/log/auth.log.3.gz
Aug 19 20:05:57 debian sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/sbin/shutdown -h now
Aug 19 20:05:57 debian sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Aug 19 20:05:57 debian lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event2 (Power Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event3 (Sleep Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event4 (Video Bus)
Aug 19 23:50:49 debian systemd-logind[333]: New seat seat0.
Aug 19 23:50:49 debian sshd[409]: Server listening on 0.0.0.0 port 22.
(...)

tail

Visualizza le ultime righe di un file (il valore predefinito è 10 righe). La potenza di tail risiede - in larga misura - nell’opzione -f, che mostrerà dinamicamente le nuove righe man mano che vengono aggiunte al file:

root@suse-server:~# tail -f /var/log/messages
2019-09-14T13:57:28.962780+02:00 suse-server sudo: pam_unix(sudo:session): session closed for user root
2019-09-14T13:57:38.038298+02:00 suse-server sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/messages
2019-09-14T13:57:38.039927+02:00 suse-server sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
2019-09-14T14:07:22+02:00 debian carol: appending new message from client to remote server...

head

Visualizza le prime righe di un file (il valore predefinito è 10 righe):

root@suse-server:~# head -5 /var/log/mail
2019-06-29T11:47:59.219806+02:00 suse-server postfix/postfix-script[1732]: the Postfix mail system is not running
2019-06-29T11:48:01.355361+02:00 suse-server postfix/postfix-script[1925]: starting the Postfix mail system
2019-06-29T11:48:01.391128+02:00 suse-server postfix/master[1930]: daemon started -- version 3.3.1, configuration /etc/postfix
2019-06-29T11:55:39.247462+02:00 suse-server postfix/postfix-script[3364]: stopping the Postfix mail system
2019-06-29T11:55:39.249375+02:00 suse-server postfix/master[1930]: terminating on signal 15

grep

Utilità di filtraggio che permette di cercare stringhe specifiche:

root@debian:~# grep "dhclient" /var/log/syslog
Sep 13 11:58:48 debian dhclient[448]: DHCPREQUEST of 192.168.1.4 on enp0s3 to 192.168.1.1 port 67
Sep 13 11:58:49 debian dhclient[448]: DHCPACK of 192.168.1.4 from 192.168.1.1
Sep 13 11:58:49 debian dhclient[448]: bound to 192.168.1.4 -- renewal in 1368 seconds.
(...)

Come avrai notato, l’output viene stampato nel seguente formato:

Riferimento temporale
Nome dell’host da cui è partito il messaggio
Nome del programma/servizio che ha generato il messaggio
Il PID del programma che ha generato il messaggio
Descrizione dell’azione che ha avuto luogo

Ci sono alcuni esempi in cui i log non sono testo, ma file binari e — di conseguenza — è necessario usare comandi speciali per analizzarli:

/var/log/wtmp

Utilizza who (o w):

root@debian:~# who
root    pts/0        2020-09-14 13:05 (192.168.1.75)
root    pts/1        2020-09-14 13:43 (192.168.1.75)

/var/log/btmp

Utilizza utmpdump o last -f:

root@debian:~# utmpdump /var/log/btmp
Utmp dump of /var/log/btmp
[6] [01287] [    ] [dave     ] [ssh:notty   ] [192.168.1.75        ] [192.168.1.75   ] [2019-09-07T19:33:32,000000+0000]

/var/log/faillog

Utilizza faillog:

root@debian:~# faillog -a | less
Login       Failures Maximum Latest                   On

root            0        0   01/01/70 01:00:00 +0100
daemon          0        0   01/01/70 01:00:00 +0100
bin             0        0   01/01/70 01:00:00 +0100
sys             0        0   01/01/70 01:00:00 +0100
sync            0        0   01/01/70 01:00:00 +0100
games           0        0   01/01/70 01:00:00 +0100
man             0        0   01/01/70 01:00:00 +0100
lp              0        0   01/01/70 01:00:00 +0100
mail            0        0   01/01/70 01:00:00 +0100
(...)

/var/log/lastlog

Utilizza lastlog:

root@debian:~# lastlog | less
Username         Port     From             Latest
root                                       Never logged in
daemon                                     Never logged in
bin                                        Never logged in
sys                                        Never logged in
(...)
sync                                       Never logged in
avahi                                      Never logged in
colord                                     Never logged in
saned                                      Never logged in
hplip                                      Never logged in
carol            pts/1    192.168.1.75     Sat Sep 14 13:43:06 +0200 2019
dave             pts/3    192.168.1.75     Mon Sep  2 14:22:08 +0200 2019

Note	Ci sono anche strumenti grafici per leggere i file di log, per esempio: `gnome-logs` e `KSystemLog`.

Come i messaggi vengono trasformati in registri

Il seguente processo illustra come un messaggio venga scritto in un file di log:

Applicazioni, servizi e kernel scrivono messaggi in file speciali (socket e buffer di memoria), per esempio /dev/log o /dev/kmsg.
rsyslogd ottiene le informazioni dai socket o dai buffer di memoria.
A seconda delle regole trovate in /etc/rsyslog.conf e/o nei file in /etc/ryslog.d/, rsyslogd sposta le informazioni nel file di log corrispondente (tipicamente in /var/log).

Note	Un socket è un file speciale usato per trasferire informazioni tra diversi processi. Per elencare tutti i socket sul tuo sistema, puoi usare il comando `systemctl list-sockets --all`.

Strutture, Priorità e Azioni

Il file di configurazione di rsyslog è /etc/rsylog.conf (in alcune distribuzioni puoi anche trovare i file di configurazione in /etc/rsyslog.d/). È normalmente diviso in tre sezioni: MODULES, GLOBAL DIRECTIVES e RULES. Diamo loro un’occhiata esplorando il file rsyslog.conf nel nostro host Debian GNU/Linux 10 (buster). Puoi usare sudo less /etc/rsyslog.conf.

MODULES include il supporto del modulo per la registrazione, la gestione dei messaggi e la ricezione dei log via UDP/TCP:

#################
#### MODULES ####
#################

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

GLOBAL DIRECTIVES ci permettono di configurare un certo numero di cose come i log e i permessi delle directory di log:

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

RULES è dove entrano in gioco strutture (facilities), priorità (priorities) e azioni (actions). Le impostazioni in questa sezione dicono al demone di logging di filtrare i messaggi secondo certe regole e di registrarli o inviarli dove richiesto. Per capire queste regole, dovremmo prima spiegare i concetti di strutture e priorità di rsyslog. A ogni messaggio di log viene dato un numero di facility e una parola chiave associati al sottosistema interno di Linux che produce il messaggio:

Numero Parola Chiave Descrizione

0

kern

Linux kernel messages

1

user

User-level messages

2

mail

Mail system

3

daemon

System daemons

4

auth, authpriv

Security/Authorization messages

5

syslog

syslogd messages

6

lpr

Line printer subsystem

7

news

Network news subsystem

8

uucp

UUCP (Unix-to-Unix Copy Protocol) subsystem

9

cron

Clock daemon

10

auth, authpriv

Security/Authorization messages

11

ftp

FTP (File Transfer Protocol) daemon

12

ntp

NTP (Network Time Protocol) daemon

13

security

Log audit

14

console

Log alert

15

cron

Clock daemon

16 - 23

local0 through local7

Local use 0 - 7

Inoltre, a ogni messaggio viene assegnato un livello di priority:

Codice Gravità Parola chiave Descrizione

0

Emergency

emerg, panic

System is unusable

1

Alert

alert

Action must be taken immediately

2

Critical

crit

Critical conditions

3

Error

err, error

Error conditions

4

Warning

warn, warning

Warning conditions

5

Notice

notice

Normal but significant condition

6

Informational

info

Informational messages

7

Debug

debug

Debug-level messages

Ecco un estratto di rsyslog.conf dal nostro sistema Debian GNU/Linux 10 (buster) che include alcune regole di esempio:

###############
#### RULES ####
###############

# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

#
# Some "catch-all" log files.
#
*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none          -/var/log/messages

Il formato della regola è il seguente: <facility>.<priority> <action>

Il selettore <facility>.<priority> filtra i messaggi da abbinare. I livelli di priorità sono gerarchicamente inclusivi, il che significa che rsyslog troverà una corrispondenza per i messaggi dalla priorità specificata o superiore. <action> mostra quale azione intraprendere (dove inviare il messaggio di log). Ecco alcuni esempi per chiarezza:

auth,authpriv.*                 /var/log/auth.log

Indipendentemente dalla loro priorità (*), tutti i messaggi dalle strutture auth o authpriv saranno inviati a /var/log/auth.log.

*.*;auth,authpriv.none          -/var/log/syslog

Tutti i messaggi — indipendentemente dalla loro priorità (*) — da tutte le facility (*) — scartando quelli da auth o authpriv (da qui il suffisso .none) — saranno scritti in /var/log/syslog (il segno meno (-) prima del percorso previene eccessive scritture su disco). Nota il punto e virgola (;) per dividere il selettore e la virgola (,) per concatenare due strutture nella stessa regola (auth,authpriv).

mail.err                        /var/log/mail.err

I messaggi della facility mail con un livello di priority di error o superiore (critical, alert o emergency) saranno inviati a /var/log/mail.err.

*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug

I messaggi provenienti da tutte le facility con priority debug e nessun’altra (=) saranno scritti in /var/log/debug — escludendo qualsiasi messaggio proveniente dalle facility auth, authpriv, news e mail (nota la sintassi: ;\).

Inserimenti Manuali nel Registro di Sistema: `logger`

Il comando logger è utile per lo scripting di shell o per scopi di test. logger aggiungerà ogni messaggio che riceve a /var/log/syslog (o a /var/log/messages quando registra su un server di log centrale remoto, come vedrai più avanti in questa lezione):

carol@debian:~$ logger this comment goes into "/var/log/syslog"

Per visualizzare l’ultima riga in /var/log/syslog, usa il comando tail con l’opzione -1:

root@debian:~# tail -1 /var/log/syslog
Sep 17 17:55:33 debian carol: this comment goes into /var/log/syslog

`rsyslog` come Server di Log Centralizzato

Per spiegare questo argomento aggiungeremo un nuovo host alla nostra configurazione. Il layout è il seguente:

Ruolo Hostname OS Indirizzo IP

Central Log Server

suse-server

openSUSE Leap 15.1

192.168.1.6

Client

debian

Debian GNU/Linux 10 (buster)

192.168.1.4

Iniziamo a configurare il server. Prima di tutto, assicuriamoci che rsyslog sia attivo e funzionante:

root@suse-server:~# systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-17 18:45:58 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 832 (rsyslogd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─832 /usr/sbin/rsyslogd -n -iNONE

openSUSE dispone di un file di configurazione dedicato alla registrazione remota: /etc/rsyslog.d/remote.conf. Abilitiamo la ricezione dei messaggi dai client (host remoti) via TCP. Dobbiamo decommentare le linee che caricano il modulo e avviano il server TCP sulla porta 514:

# ######### Receiving Messages from Remote Hosts ##########
# TCP Syslog Server:
# provides TCP syslog reception and GSS-API (if compiled to support it)
$ModLoad imtcp.so  # load module
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
$InputTCPServerRun 514  # Starts a TCP server on selected port

# UDP Syslog Server:
#$ModLoad imudp.so  # provides UDP syslog reception
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
#$UDPServerRun 514  # start a UDP syslog server at standard port 514

Una volta fatto questo, dobbiamo riavviare il servizio rsyslog e controllare che il server sia in ascolto sulla porta 514:

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# netstat -nltp | grep 514
[sudo] password for root:
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      2263/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      2263/rsyslogd

Successivamente, dovremmo aprire le porte nel firewall e ricaricare la configurazione:

root@suse-server:~# firewall-cmd --permanent --add-port 514/tcp
success
root@suse-server:~# firewall-cmd --reload
success

Note	Con l’arrivo di openSUSE Leap 15.0, `firewalld` ha sostituito completamente il classico `SuSEFirewall2`.

Modelli e Condizioni di Filtro

Per default, i log del client saranno scritti nel file /var/log/messages del server — insieme a quelli del server stesso. Tuttavia, creeremo un modello (template) e una condizioni di filtro per fare in modo che i log del nostro client siano immagazzinati in cartelle proprie ben definite. Per fare ciò, aggiungeremo quanto segue a /etc/rsyslog.conf (o /etc/rsyslog.d/remote.conf):

$template RemoteLogs,"/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log"
if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
& stop

Template

Il modello corrisponde alla prima riga e permette di specificare un formato per i nomi dei log utilizzando la generazione dinamica dei nomi dei file. Un template consiste in:

Direttiva template ($template)
Nome del template (RemoteLogs)
Testo del template ("/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log")
Opzioni (facoltativo)

Il nostro modello si chiama RemoteLogs e il suo testo consiste nel percorso /var/log. Tutti i log del nostro host remoto andranno nella directory remotehosts, dove verrà creata una sottodirectory basata sull’hostname della macchina (%HOSTNAME%). Ogni nome di file in questa directory sarà composto dalla data (%$NOW%), la gravità (o priorità) del messaggio in formato testo (%syslogseverity-text%) e il suffisso .log. Le parole tra i segni di percentuale sono proprietà e ti permettono di accedere al contenuto del messaggio di log (data, priorità, ecc.). Un messaggio syslog ha un certo numero di proprietà ben definite che possono essere usate nei modelli. Queste proprietà sono accessibili — e possono essere modificate — dal cosiddetto property replacer che implica la loro scrittura tra i segni di percentuale.

Condizioni di Filtro

Le due righe rimanenti corrispondono alla condizione del filtro e alla sua azione associata:

Filtro basato sull’espressione (if $FROMHOST-IP=='192.168.1.4')
Azione (then ?RemoteLogs, & stop)

La prima linea controlla l’indirizzo IP dell’host remoto che invia il log e — se è uguale a quello del nostro client Debian — applica il modello RemoteLogs. L’ultima linea (& stop) garantisce che i messaggi non vengano inviati contemporaneamente a /var/log/messages (ma solo ai file nella directory /var/log/remotehosts).

Note	Per saperne di più su modelli, proprietà e regole, puoi consultare la pagina di manuale di `rsyslog.conf`.

Con la configurazione aggiornata, riavviamo nuovamente rsyslog e confermiamo che non c’è ancora una directory remotehosts in /var/log:

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# ls /var/log/
acpid             chrony     localmessages   pbl.log          Xorg.0.log
alternatives.log  cups       mail            pk_backend_zypp  Xorg.0.log.old
apparmor          firebird   mail.err        samba            YaST2
audit             firewall   mail.info       snapper.log      zypp
boot.log          firewalld  mail.warn       tallylog         zypper.log
boot.msg          krb5       messages        tuned
boot.omsg         lastlog    mysql           warn
btmp              lightdm    NetworkManager  wtmp

Il server è stato ora configurato. Ora configureremo il client.

Di nuovo, dobbiamo assicurarci che rsyslog sia installato e funzionante:

root@debian:~# sudo systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset:
   Active: active (running) since Thu 2019-09-17 18:47:54 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 351 (rsyslogd)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─351 /usr/sbin/rsyslogd -n

Nel nostro ambiente di esempio abbiamo implementato la risoluzione del nome sul client aggiungendo la linea 192.168.1.6 suse-server a /etc/hosts. Così, possiamo fare riferimento al server sia per nome (suse-server) sia per indirizzo IP (192.168.1.6).

Il nostro client Debian non ha un file remote.conf in /etc/rsyslog.d/, quindi applicheremo le nostre configurazioni in /etc/rsyslog.conf. Scriveremo la seguente linea alla fine del file:

*.* @@suse-server:514

Infine, riavviamo rsyslog.

root@debian:~# systemctl restart rsyslog

Ora, torniamo alla nostra macchina suse-server e controlliamo l’esistenza di remotehosts in /var/log:

root@suse-server:~# ls /var/log/remotehosts/debian/
2019-09-17.info.log  2019-09-17.notice.log

Abbiamo già due log in /var/log/remotehosts come descritto nel nostro modello. Per completare questa sezione eseguiamo tail -f 2019-09-17.notice.log su suse-server mentre inviamo manualmente un log dal nostro client Debian e confermiamo che i messaggi vengono aggiunti al file di log come previsto (l’opzione -t fornisce un tag per il nostro messaggio):

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)

carol@debian:~$ logger -t DEBIAN-CLIENT Hi from 192.168.1.4

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)
2019-09-17T21:04:21+02:00 debian DEBIAN-CLIENT: Hi from 192.168.1.4

Il Meccanismo di Rotazione dei Log

I Log vengono ruotati regolarmente, il che serve a due scopi principali:

Evitare che i vecchi file di log usino su disco più spazio del necessario.
Mantenere i log a una lunghezza gestibile per facilitare la consultazione.

L’utility incaricata della rotazione dei log è logrotate e il suo lavoro include azioni come spostare i file di log in un nuovo nome, archiviarli e/o comprimerli, a volte inviarli via email all’amministratore di sistema e infine cancellarli quando diventano vecchi. Ci sono varie convenzioni per nominare questi file di log ruotati (aggiungendo un suffisso con la data al nome del file, per esempio); tuttavia, aggiungere semplicemente un suffisso con un numero intero è la pratica più comune:

root@debian:~# ls /var/log/messages*
/var/log/messages  /var/log/messages.1  /var/log/messages.2.gz  /var/log/messages.3.gz  /var/log/messages.4.gz

Spieghiamo ora che cosa succederà nella prossima rotazione del registro:

messages.4.gz sarà cancellato e perso definitivamente.
Il contenuto di messages.3.gz sarà spostato in messages.4.gz.
Il contenuto di messages.2.gz verrà spostato in messages.3.gz.
Il contenuto di messages.1 sarà spostato in messages.2.gz.
Il contenuto di messages sarà spostato in messages.1 e messages sarà vuoto e pronto a registrare nuove voci di log.

Nota come — secondo le direttive logrotate che vedrai tra poco — i tre file di log più vecchi siano compressi, mentre i due più recenti no. Inoltre, conserveremo i log delle ultime 4-5 settimane. Per leggere i messaggi vecchi di 1 settimana, consulteremo messages.1 (e così via).

logrotate viene eseguito come processo automatico o cron job giornaliero attraverso lo script /etc/cron.daily/logrotate e legge il file di configurazione /etc/logrotate.conf. Questo file include alcune opzioni globali ed è ben commentato con ogni opzione introdotta da una breve spiegazione del suo scopo:

carol@debian:~$ sudo less /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

(...)

Come puoi vedere sono inclusi anche i file di configurazione in /etc/logrotate.d per pacchetti specifici. Questi file contengono — per la maggior parte — definizioni locali e specificano i file di log da ruotare (ricorda, le definizioni locali hanno la precedenza su quelle globali, e le definizioni successive sovrascrivono quelle precedenti). Quello che segue è un estratto di una definizione in /etc/logrotate.d/rsyslog:

/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Come puoi vedere, ogni direttiva è separata dal suo valore da spazi vuoti e/o da un segno opzionale di uguale (=). Le linee tra postrotate e endscript devono però apparire su linee a sé stanti. La spiegazione è la seguente:

rotate 4: Conserva 4 settimane di log.
weekly: Ruota i file di registro settimanalmente.
missingok: Non emette un messaggio di errore se il file di log è mancante; passa semplicemente a quello successivo.
notifempty: Non ruota il registro se è vuoto.
compress: Comprime i file di log con gzip (predefinito).
delaycompress: Posticipa la compressione del file di log precedente al prossimo ciclo di rotazione (efficace solo se usato in combinazione con compress). È utile quando non si può dire a un programma di chiudere il suo file di log e quindi potrebbe continuare a scrivere sul file di log precedente per un certo tempo.
sharedscripts: Relativo agli script prerotate e postrotate. Per evitare che uno script venga eseguito più volte, esegue gli script solo una volta indipendentemente da quanti file di log corrispondono a un dato schema (per esempio /var/log/mail/*). Gli script non verranno eseguiti se nessuno dei log nello schema richiede la rotazione. Inoltre, se gli script escono con errori, qualsiasi azione successiva non verrà eseguita per nessun log.
postrotate: Indica l’inizio di uno script postrotate.
invoke-rc.d rsyslog rotate > /dev/null: Usa /bin/sh per eseguire invoke-rc.d rsyslog rotate > /dev/null dopo la rotazione dei log
endscript: Indica la fine dello script postrotate.

Note	Per una lista completa di direttive e spiegazioni, consultare la pagina di manuale di `logrotate.conf`.

Il Kernel Ring Buffer

Poiché il kernel genera diversi messaggi prima che rsyslogd sia disponibile all’avvio, è necessario un meccanismo per registrare questi messaggi. È qui che entra in gioco il kernel ring buffer. È una struttura dati a dimensione fissa e — quindi — man mano che cresce con nuovi messaggi, i più vecchi spariranno.

Il comando dmesg visualizza il ring buffer del kernel. A causa della dimensione del buffer, questo comando è normalmente usato in combinazione con l’utilità di filtraggio del testo grep. Per esempio, per cercare i messaggi relativi ai dispositivi Universal Serial Bus:

root@debian:~# dmesg | grep "usb"
[    1.241182] usbcore: registered new interface driver usbfs
[    1.241188] usbcore: registered new interface driver hub
[    1.250968] usbcore: registered new device driver usb
[    1.339754] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.19
[    1.339756] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
(...)

Esercizi Guidati

Quali utility/comandi usereste nei seguenti scenari:

Scopo e file di log Utility

Leggere /var/log/syslog.7.gz

Leggere /var/log/syslog

Cercare la parola renewal in /var/log/syslog

Leggere /var/log/faillog

Leggere /var/log/syslog dinamicamente

Riorganizza le seguenti voci di log in modo che rappresentino un messaggio di log valido con la struttura appropriata:
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  L’ordine corretto è:
Quali regole aggiungereste a /etc/rsyslog.conf per realizzare ciascuna delle seguenti:
- Inviare tutti i messaggi dalla facility mail e una priorità/severità di crit (e superiore) a /var/log/mail.crit:
- Invia tutti i messaggi della facility mail con priorità alert e emergency a /var/log/mail.urgent:
- Eccetto quelli provenienti dai servizi cron e ntp, invia tutti i messaggi — indipendentemente dalla loro facility e dalla priorità — a /var/log/allmessages:
- Con tutte le impostazioni necessarie configurate prima, invia tutti i messaggi dalla facility mail a un host remoto il cui indirizzo IP è 192.168.1.88 usando TCP e specificando la porta predefinita:
- Indipendentemente dalla loro facility, inviare tutti i messaggi con la priorità warning (solo con la priorità warning) a /var/log/warnings evitando un’eccessiva scrittura sul disco:

Considera la seguente parte di /etc/logrotate.d/samba e spiega le diverse opzioni:

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Opzione Significato

weekly

missingok

rotate 7

postrotate

endscript

compress

delaycompress

notifyempty

Esercizi Esplorativi

Nella sezione “Modelli e Condizioni di Filtro” abbiamo usato un filtro basato su espressione come condizione di filtro. I filtri basati su proprietà sono un altro tipo di filtro esclusivo di rsyslogd. Traduci il nostro filtro basato su espressione in un filtro basato su proprietà:

Filtro Basato su Espressione Filtro Basato su Proprietà

if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
omusrmsg è un modulo integrato di rsyslog che facilita la notifica agli utenti (invia messaggi di log al terminale dell’utente). Scrivi una regola per inviare tutti i messaggi di tipo emergency di tutte le facility sia a root che all’utente standard carol.

Sommario

In questa lezione abbiamo imparato:

La registrazione dei log è cruciale per l’amministrazione del sistema.
rsyslogd è l’utility incaricata di mantenere i log ordinati e puliti.
Alcuni servizi si occupano dei propri log.
Sommariamente, i log possono essere classificati in log di sistema e log di servizio/programma.
Ci sono un certo numero di utility che sono convenienti per la lettura dei log: less, more, zless, zmore, grep, head e tail.
La maggior parte dei file di log sono file di testo semplice; tuttavia, c’è un piccolo numero di file di log binari.
Per quanto riguarda i log, rsyslogd riceve le informazioni rilevanti da file speciali (socket e buffer di memoria) prima di elaborarle.
Per classificare i log, rsyslogd usa regole in /etc/rsyslog.conf o /etc/rsyslog.d/*.
Ogni utente può inserire i propri messaggi nel log di sistema manualmente con l’utilità logger.
rsyslog permette di mantenere tutti i log attraverso le reti IP in un server di log centralizzato.
I modelli sono utili per formattare dinamicamente i nomi dei file di log.
Lo scopo della rotazione dei log è duplice: evitare che i vecchi log usino troppo spazio su disco e rendere gestibile la consultazione dei log.

Risposte agli Esercizi Guidati

Quali utility/comandi usereste nei seguenti scenari:

Scopo e file di log Utility

Leggere /var/log/syslog.7.gz

zmore o zless

Leggere /var/log/syslog

more o less

Cercare la parola renewal in /var/log/syslog

grep

Leggere /var/log/faillog

faillog -a

Leggere /var/log/syslog dinamicamente

tail -f

Riorganizza le seguenti voci di log in modo che rappresentino un messaggio di log valido con la struttura appropriata:
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  L’ordine corretto è:
  Sep 13 21:47:56 debian-server sshd[515]: Server listening on 0.0.0.0 port 22
Quali regole aggiungereste a /etc/rsyslog.conf per realizzare ciascuna delle seguenti:
- Inviare tutti i messaggi dalla facility mail e una priorità/severità di crit (e superiore) a /var/log/mail.crit:
  mail.crit /var/log/mail.crit
- Invia tutti i messaggi della facility mail con priorità alert e emergency a /var/log/mail.urgent:
  mail.alert /var/log/mail.urgent
- Eccetto quelli provenienti dai servizi cron e ntp, invia tutti i messaggi — indipendentemente dalla loro facility e dalla priorità — a /var/log/allmessages:
  *.*;cron.none;ntp.none /var/log/allmessages
- Con tutte le impostazioni necessarie configurate prima, invia tutti i messaggi dalla facility mail a un host remoto il cui indirizzo IP è 192.168.1.88 usando TCP e specificando la porta predefinita:
  mail.* @@192.168.1.88:514
- Indipendentemente dalla loro facility, inviare tutti i messaggi con la priorità warning (solo con la priorità warning) a /var/log/warnings evitando un’eccessiva scrittura sul disco:
  *.=warning -/var/log/warnings

Considera la seguente parte di /etc/logrotate.d/samba e spiega le diverse opzioni:

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Opzione Significato

weekly

Ruota i file di log su base settimanale.

missingok

Non emette un messaggio di errore se il log è mancante; continua con quello successivo.

rotate 7

Mantiene 7 settimane di arretrati.