Bug 86491 - tripwire-friendly logfile rotation
tripwire-friendly logfile rotation
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: logrotate (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-24 05:16 EST by Michael Weiser
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version: 3.7.1-12
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-19 11:22:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
add option to count upwards when renaming logfiles (11.59 KB, patch)
2003-10-05 12:22 EDT, Michael Weiser
no flags Details | Diff

  None (edit)
Description Michael Weiser 2003-03-24 05:16:27 EST
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:
Comment 1 Elliot Lee 2003-03-24 12:43:24 EST
The Right Solution(tm) is to have tripwire ignore files, such as logfiles, which are expected 
to change.

I'm not planning to code the feature myself, but I would take a patch to implement your 
suggestion as a non-default option.
Comment 2 Michael Weiser 2003-10-05 12:22:25 EDT
Created attachment 94938 [details]
add option to count upwards when renaming logfiles

Sorry for taking so long to respond. I've sat down now and created a first
patch that adds a countup option to logrotate and last rotate index to the
state file. I've written tests for it and it seems to work but I know it at
least breaks the mailing of the dispose file because of operations odering in
rotateSingleLog. So before I dig any deeper into it I'd like to know if this is
the right direction to go. What d'you think?
Comment 3 Peter Vrabec 2005-09-07 11:21:04 EDT
see:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108775
Won't this "dateext" option help you?
Comment 4 Michael Weiser 2005-09-18 12:48:25 EDT
It does indeed. Thanks for getting back to me. This bug can be closed then. I'm
sorry I can't do it. My old bugzilla account seems to have expired.

Note You need to log in before you can comment on or make changes to this bug.