Bug 86491

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20030102

Description of problem:
Default behaviour of logrotate is to rename all logfile.i.gz to logfile.(i+1).gz
and then rotate the current copy to logfile.1.gz. This is fine as long as you
don't use tripwire on your system. If you do, tripwire will see that all backup
copies have changed and want to have them recommited to the database which may
enable someone to temper with them until the next tripwire database update.

An approach would be to just rotate the current logfile to logfile.(n+1).gz with
n being the last logfile copy. This way the logfile copy number would simply be
counted upwards indefinitely or until some reset is done. Since old backup
copies don't change any more tripwire would only see one new backup file and a
changed current logfile which changes all the time anyway. If an old copy is
expunged, tripwire would notice it's gone and show just one deleted file.

This could be incorporated as a config file option so it can be enabled for
logfiles it is desired for.

Version-Release number of selected component (if applicable):
3.5.2, 3.5.4, 3.6.8

How reproducible:
Always

Steps to Reproduce:
# ls -la /var/log/auth*
-rw-------    1 root     root         9036 Mar 23  2003 auth
-rw-------    1 root     root         2030 Mar 17  2003 auth.1.gz
# /usr/sbin/logrotate /etc/logrotate.conf

Actual Results:  # ls -la /var/log/auth*
-rw-------    1 root     root            0 Mar 23  2003 auth
-rw-------    1 root     root         1022 Mar 23  2003 auth.1.gz
-rw-------    1 root     root         2030 Mar 17  2003 auth.2.gz

Expected Results:  # ls -la /var/log/auth*
-rw-------    1 root     root            0 Mar 23  2003 auth
-rw-------    1 root     root         2030 Mar 17  2003 auth.1.gz
-rw-------    1 root     root         1022 Mar 23  2003 auth.2.gz


Additional info: