Printable View
why is it that logs that haven't changed come up with a differant inode with ever run of tripwire:
Modified object name: /var/log/cron/errors.1.gz
Property: Expected Observed
------------- ----------- -----------
* Inode Number 312199 311981
Modified object name: /var/log/cron/errors.2.gz
Property: Expected Observed
------------- ----------- -----------
* Inode Number 312047 312199
Since nobody has responded, I'll take a stab at it.
First thing that came to mind: Does this exclusively happen with these cron logs, or other files as well.
If cron exclusively, how is cron configured?
from cron man page ( FC3 )Could something like this be happening? Or am I way off base?Quote:
SIGNALS
On receipt of a SIGHUP, the cron daemon will close and reopen its log
file. This is useful in scripts which rotate and age log files. Nat-
urally this is not relevant if cron was built to use syslog(3).
I don't know what system you use but i use Red Hat 9 and tripwire shows changes
to inode even if they are not changed because of RH automatic log cycling. At least this
is my case.
Yes. Tripwire is ( at least on my systems ) set up to ignore size changes of log files ( allows them to grow ), but will identify changes in ownership, addition or deletion of log files, etc.Quote:
... because of RH automatic log cycling.
As the log rotates ( depends how and when each log is set up to rotate; by date, size, etc. ) it gives the older files larger numbers.
for instance,
maillog Dec 07
maillog.1 Dec 04
maillog.2 Nov 28
maillog.3 Nov 21
maillog.4 Nov 13
The listed date is the date is was last used. During each rotation the name is changed ( the larger the extension, the older the file ) , but not the date. So in the above example, maillog is currently in use, maillog.1 was last used last Sunday Dec 4 when the log rotated, maillog.2 was last used the Sunday before that ( Nov 28 ), but at that time was named maillog.1, renamed to maillog.2 this past Sunday, etc.
Since he didn't include a date, I assumed ( silly me ) that this wasn't an issue. But it may very well be what he is looking at.