/var/log/apache2/error.log
/var/log/exim4/mainlog
...
Il problema e' che questi nuovi file sono ignorati da logcheck, che
continua ad usare solo i log originali.
Avevo pensato ad un problema di permessi, ma mi smbra tutto ok (tutti
log del gruppo adm).
Idee?
--
Ciao, L.
(Linux User #332241)
--------------------
Spero di morire nel sonno, come mio nonno,
e non gridando, come i suoi passeggeri.
-- Laura De Carlo <Laura_D...@iridium.it>
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Domanda stupida, hai fatto il restart di logcheck per fargli rileggere
la configurazione?
Che report level hai? non è che i tuoi file di ignore dicono di
ignorare ogni messaggio dentro questi file?
Ciao Fabrizio
> Idee?
Scusate se mi intrometto, non so come risolvere il tuo problema.
Visto che si parla di logcheck volevo chiederti/vi se riesco a
risolvere il mio di "problema".
Dunque io ho questi messaggi in syslog che vorrei ignorare:
Mar 28 06:31:49 mir smartd[4915]: Device: /dev/hda, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 253 to 252
Mar 28 08:01:49 mir smartd[4915]: Device: /dev/hda, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 252 to 253
Ho messo questa riga in un file in /etc/logcheck/ignore.d.server
^\w{3} [ :0-9]{11} [._[:alnum:]-] *.*SMART Prefailure Attribute: 8 Seek_Time_Performance changed*.*$
Questo non dovrebbe fare in modo che logcheck ignori i messaggi di cui
sopra? Perché mi continuano ad arrivare e-mail da logcheck?
Nella configurazione ho REPORTLEVEL="server"
Qualcuno sa svelarmi il mistero?
> On 3/28/07, Leonardo Cosmai <leonard...@ngi.it> wrote:
> > Ciao, ho installato su una etch logcheck, e aggiunto nel file
> > logcheck.logfiles altre due o tre logfiles da monitorare:
> > /var/log/apache2/error.log
> > /var/log/exim4/mainlog
> > Il problema e' che questi nuovi file sono ignorati da logcheck, che
> > continua ad usare solo i log originali.
> >
> > Avevo pensato ad un problema di permessi, ma mi smbra tutto ok
> > (tutti log del gruppo adm).
>
> Domanda stupida, hai fatto il restart di logcheck per fargli rileggere
> la configurazione?
restart di logcheck, ma si fa??
> Che report level hai? non è che i tuoi file di ignore dicono di
> ignorare ogni messaggio dentro questi file?
sicuramente no..ad esempio in error.log di apache ci vanno a finire gli
errori php.
PS: anche se eseguo a linea di comando logcheck -o -t -d l'unico file
che viene preso in considerazione e /var/log/syslog
PPS: su altri due server sarge, la stessa configurazione funziona da
anni.
> Ciao Fabrizio
Grazie
--
Ciao, L.
(Linux User #332241)
--------------------
La giovinezza non puo' scusare tutto.
-- Dr. Janice Lester (nel corpo di Kirk),
"Turnabout Intruder" (TOS), data astrale 5928.5
>
> Dunque io ho questi messaggi in syslog che vorrei ignorare:
>
> Mar 28 06:31:49 mir smartd[4915]: Device: /dev/hda, SMART Prefailure
> Attribute: 8 Seek_Time_Performance changed from 253 to 252 Mar 28
di massima, perché non configuri smart in modo che non ti scocci al
riguardo? Disabilita l'attributo che ti infastidisce. Vedi esempi in
smartd.conf.
A.
p.s.: al limite stoppalo del tutto :)
> PS: anche se eseguo a linea di comando logcheck -o -t -d l'unico file
> che viene preso in considerazione e /var/log/syslog
stavo guardando la configurazione che ho io sui miei server e io lo
faccio girare con i parametri
logcheck -s -u -c /etch/logcheck/logcheck.conf
forse perché anche io a suo tempo sono incorso nello stesso tuo
problema che non mi leggeva i file di configurazione
Prova a farlo girare con l'overrule della configurazione e vedi se ti
va e con il parametro impostato a livello server.
A me gira regolarmente con quei parametri.
P.s. io per farlo girare faccio eseguire nello script di cron un su
all'utente logcheck.
Ciao F.
> io proverei due cose:
>
> * semplificare la regexp sopra per vedere se e` un problema di regexp;
> per esempio brutalmente usare solo
> SMART Prefailure Attribute: 8 Seek_Time_Performance changed
Allora ho provato a mettere questa linea:
SMART Prefailure Attribute: 8 Seek_Time_Performance changed
ma ancora non funzia. Per chiarire le cose ecco come faccio:
Ho trovato su qualche readme questo:
To test new rules, you can grep your log file, and remove trailing
space with something like this:
sed -e 's/[[:space:]]*$//' /var/log/syslog | egrep \
'^\w{3} [ :0-9]{11} oempc wwwoffled\[[0-9]+\]: WWWOFFLE (On|Off)line\.$'
If the log line is displayed, then your regex works.
Quando lancio questo comando la linea viene vista, quindi in teoria è
corretta.
Però se lancio:
su -s /bin/bash -c "/usr/sbin/logcheck -o -t" logcheck
Questo mi riporta sempre:
Security Events
=-=-=-=-=-=-=-=
Mar 28 06:31:49 mir smartd[4915]: Device: /dev/hda, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 253 to 252
Mar 28 08:01:49 mir smartd[4915]: Device: /dev/hda, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 252 to 253
Mar 28 16:47:18 mir smartd[4915]: Device: /dev/hda, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 252 to 253
Non riesco proprio a capire dove sbaglio. Forse testare la linea con
sed/grep non è affidabile? Ci sono altri modi?
>
> * eseguire logchek sotto strace p[er assicurarsi che il file di conf in
> cui hai messo la regexp sia realmente usato
Beh, non capisco molto l'output di strace.
Il file di prova è /etc/logcheck/ignore.d.server/ciccio
Ho lanciato logcheck così:
su -s /bin/bash -c "strace /usr/sbin/logcheck -o -t" logcheck &> log
Risultato:
cat log|grep ciccio
read(3, "ciccio\n", 128) = 7
stat64("/etc/logcheck/ignore.d.server/ciccio", {st_mode=S_IFREG|0640, st_size=161, ...}) = 0
Sembra ok, sbaglio?
Oooooopppsss. Lo dico a bassa voce: avevo impostato i permessi di
logcheck.logfiles a root.root 640, quindi logcheck usava il log di
fallback: /var/log/syslog appunto.
--
Ciao, L.
(Linux User #332241)
--------------------
"Si', ho cercato di impiccarmi. Ma non ce l'ho fatta... ogni volta che
ci provavo mi sentivo soffocare!"
-- Zuzzurro & Gaspare
> Allora ho provato a mettere questa linea:
> SMART Prefailure Attribute: 8 Seek_Time_Performance changed
Oh signur, ho trovato il problema...
E' la parola Prefailure, o meglio failure.
Infatti logcheck, indipendentemente dalle regole che uno può avere,
considera come gravi e quindi segnala tutte le righe che hanno parole
presenti nei file in /etc/logcheck/violations.d
Infatti in /etc/logcheck/violations.d/logcheck c'è la parola failure e
quindi mi beccava le linee di smartd.
Per risolvere ho messo in /etc/logcheck/violations.ignore.d/mattia la
parola Prefailure e adesso finalmente le ignora.
Mamma mia, logcheck è una giungla.
Grazie a tutti per l'aiuto!