lunedì 30 maggio 2011

File di log "/var/log/messages" mancante in Ubuntu Natty Narwhal

[click here for reading this blog post in english]

A seguito di un'installazione ex-novo di Linux Ubuntu 11.04 (Natty Narwhal) mi sono accorto che il file /var/log/messages non c'era (!). Ho altresì constatato che è stata una scelta voluta!
I mantainer del kernel della comunità Ubuntu (o Canonical) hanno preso questa decisione (fornendo un file di configurazione di rsyslog di default che non abilita la scrittura di messages) sostenendo che in tal modo si evita di duplicare linee di log in due file (/var/log/syslog e /var/log/messages).
Francamente e per esser chiaro, disapprovo completamente questa decisione: è vero che si possono avere linee di log duplicate, in quanto alcune di queste vengono scritte in entrambi i file "syslog" e "messages", ma lo scopo di questi file è sensibilmente diverso, pertanto non trovo corretto mischiarli insieme, sostanzialmente per due ragioni: 

  1. /var/log/messages non è solo una convenzione, bensì è divenuto uno standard per tutti i sistemi *nix/linux (Indipendentemente che si parli di distribuzioni di classe desktop o di classe server).
    /var/log/syslog è invece un audit log, pertanto verranno scritti log di qualsiasi cosa (tipo processi di  cron o at, messggi di "informazioni" non strettamente di "warning", e così via ...)
    /var/log/messages è generalmente il file in cui gli applicativi scrivono eventuali messaggi di warning, anche se non strettamente inerenti il kernel, messaggi di boot (non-kernel) simili alle informazioni ottenibili con il comando 'dmesg'. Questo è generlmente IL file principale da visionare, quando si ha l'impressione che qualcosa non stia andando come dovrebbe, o per verificare che il sistema e tutti gli applicativi principali stiano girando in maniera corretta!
  2. Tutti gli applicativi standard e i programmi (incluso applicazioni di terze parti, non fornite con la distribuzione, ecc.), programmi di monitoraggio, analizzatori e monitor di rete, ambienti SNMP (come Hobbit, Nagios, ecc.) generalmente intercettano stati ed eventuali condizioni d'errore leggendo questo file. Non ritengo neanche che sia una buona soluzione creare un link simbolico tra syslog e messages, in quanto i succitati programmi e/o processi sarebbero costretti ad analizzare inutilmente milioni di linee di log in più, rischiando così di incidere negativamente alle prestazioni di tutto il sistema.
Penso che né Canonical né la comunità Ubuntu possa decidere di apportare una variazione ad uno schema standard dall'oggi al domani (per lo meno senza aver preso in esame la cosa con una commissione mondiale sugli standard - vedi ANSI, ISO, ecc. - che ne valuterà l'opportunità). 
Comunque qui di seguito elenco i passi per ripristinare la scrittura del file /var/log/messages come in passato:
  • editare il file /etc/rsyslog.d/50-default.conf (con "sudo vi /etc/rsyslog.d/50-default.conf" se si è loggati come utenti non-root)
  • Cambiare il seguente paragrafo:
...
#
# 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
....
con questo

....
#
# 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
....

(in altre parole, togliere il commento dalle linee sotto 'Some "catch-all" log files.')

  •  far ripartire il demone rsyslog con il seguente comando:
        sudo restart rsyslog
  • Fatto! Ora /var/log/messages sarà nuovamente scritto come nelle release precedenti.
Comunque, mi auguro che questo fastidioso (anche se apparentemente innocuo) problema venga sistemato in Oneiric (e secondo me potrebbe essere anche candidata come  patch per natty-backports)

Cordiali saluti,
Gabriele
http://www.gabrielezappi.net
GNU/Linux user #380098

Nessun commento:

Posta un commento