9.5. syslog, eventi di sistema

9.5. `syslog`, eventi di sistema

9.5.1. Principi e meccanismi

Starting with Debian Bookworm, the rsyslog package is no longer installed by default, which in the past provided the default logging functionality. Instead, the log is provided by systemd's journal, which can be accessed by the journalctl(5) command.

There are situations, where it is necessary or desired to install rsyslog, though, e.g. to send all log messages to a central server. After installation, the rsyslogd daemon is responsible for collecting service messages coming from applications and the kernel, then dispatching them into log files (usually stored in the /var/log/ directory). It obeys the /etc/rsyslog.conf configuration file.

Ciascun messaggio di log è associato a un sottosistema di applicazioni (denominata "facility" nella documentazione):

auth e authpriv: per l'autenticazione;
cron: proviene da servizi di pianificazione delle attività, cron e atd;
daemon: interessa un demone senza alcuna classificazione speciale (DNS, NTP, ecc.);
ftp: riguarda il server FTP;
kern: messaggio proveniente dal kernel;
lpr: deriva dal sottosistema di stampa;
mail: proviene dal sottosistema per la posta elettronica;
news: messaggio del sottosistema Usenet (specialmente da un server NNTP, Network News Transfer Protocol, che gestisce i newsgroup);
syslog: messaggi dal server syslogd stesso;
user: messaggi utente (generico);
uucp: messaggi dal server UUCP (Unix to Unix Copy Program, un vecchio protocollo utilizzato in particolare per distribuire i messaggi di posta elettronica);
da local0 a local7: riservato per l'uso locale.

Ogni messaggio è anche associato a un livello di priorità. Ecco l'elenco in ordine decrescente:

emerg: "Aiuto!" C'è un'emergenza, il sistema è probabilmente inutilizzabile.
alert: affrettarsi, ogni ritardo può essere pericoloso, bisogna agire immediatamente;
crit: le condizioni sono critiche;
err: errore;
warn: avvertimento (potenziale errore);
notice: le condizioni sono normali, ma il messaggio è importante;
info: messaggio informativo;
debug: messaggio di debug.

9.5.2. Il file di configurazione

La sintassi del file /etc/rsyslog.conf viene specificata nella pagina di manuale rsyslog.conf(5), ma è anche disponibile documentazione in HTML presente nel pacchetto rsyslog-doc (/usr/share/doc/rsyslog-doc/html/index.html). Il principio generale è quello di scrivere coppie di "selettori" e "azioni". Il selettore definisce tutti i messaggi rilevanti, e le azioni descrivono come trattarli.

9.5.2.1. Sintassi del selettore

Il selettore è un elenco separato da punti e virgola di coppie sottosistema.priorità (esempio: auth.notice;mail.info). Un asterisco può rappresentare tutti i sottosistemi o tutte le priorità (esempi: *.alert o mail.*). Vari sottosistemi possono essere raggruppati, separandoli con una virgola (esempio: auth,mail.info). La priorità indicata copre anche i messaggi di priorità uguale o superiore: così auth.alert indica i messaggi del sottosistema auth con priorità alert o emerg. Se fatta precedere da un punto esclamativo (!), indica il contrario, in altre parole le priorità strettamente inferiori; auth.!notice, perciò, indica i messaggi emessi da auth con priorità info odebug. Se preceduto da un segno di uguale (=) corrisponde solo ed esclusivamente alla priorità indicata (auth.=notice riguarda solo i messaggi provenienti da auth con priorità notice).

Ogni elemento della lista sul selettore sovrascrive gli elementi precedenti. È così possibile limitare un insieme o escludere alcuni elementi da esso. Per esempio, kern.info;kern.!err significa i messaggi dal kernel con priorità compresa tra info e warn. La priorità none indica l'insieme vuoto (nessuna priorità), e può servire per escludere un sottosistema da un insieme di messaggi. Perciò, *.crit;kern.none indica tutti i messaggi con priorità uguale o superiore a crit che non provengono dal kernel.

9.5.2.2. Sintassi delle azioni

FONDAMENTALE La pipe con nome, una pipe persistente

Una pipe con nome è un particolare tipo di file che funziona come una pipe tradizionale (la pipe che si fa con il simbolo "|" sulla riga di comando), ma tramite un file. Questo meccanismo ha il vantaggio di essere in grado di collegare due processi indipendenti. Qualunque cosa scritta su una pipe con nome blocca il processo che scrive fino a che un altro processo tenta di leggere i dati scritti. Questo secondo processo legge i dati scritti dal primo, che può quindi riprendere l'esecuzione.

Un file di questo tipo viene creato con il comando mkfifo.

Le varie azioni possibili sono:

aggiungere il messaggio ad un file (esempio: /var/log/messages);
inviare il messaggio ad un server syslog remoto (esempio: @log.falcot.com);
inviare il messaggio ad una pipe con nome esistente (esempio: |/dev/xconsole);
inviare il messaggio ad uno o più utenti, se sono connessi (esempio: root,rhertzog);
inviare un messaggio a tutti gli utenti connessi (ad esempio: *);
scrivere il messaggio in una console di testo (ad esempio: /dev/tty8).

SICUREZZA Inoltro dei log

It is a good idea to record the most important logs on a separate machine (perhaps dedicated for this purpose), since this will prevent any possible intruder from removing traces of their intrusion (unless, of course, they also compromise this other server). Furthermore, in the event of a major problem (such as a kernel crash or a hard-drive failure), you have the logs available on another machine, which increases your chances of determining the sequence of events that caused the crash.

Per accettare messaggi di log inviati da altre macchine, è necessario configurare rsyslog: in pratica, è sufficiente attivare le voci già pronte all'uso in /etc/rsyslog.conf ($ModLoad imudp e $UDPServerRun 514).