Red Hat Bugzilla – Bug 52560
tripwire, default installation, breaks logrotate
Last modified: 2007-04-18 12:36:35 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-2smp i686; Nav) Description of problem: I selected to install tripwire as part of a custom installation. I have not run tripwire before, and it was my intention to install now, learn later, andstart using it later. I did my install last weekend. all this week I noticed that logrotate was not running. Upon checking the cron logs, I came across the following: Subject: Cron <root@lugs> run-parts /etc/cron.daily X-Cron-Env: <SHELL=/bin/bash> X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin> X-Cron-Env: <MAILTO=root> X-Cron-Env: <HOME=/> X-Cron-Env: <LOGNAME=root> /etc/cron.daily/tripwire-check: **** Error: Tripwire database for lugs not found. **** **** Run /etc/tripwire/twinstall.sh and/or tripwire --init. **** I take it that because tripwire fails in /etc/cron.daily, than all the other daily cron jobs fail to run. This is 2 bugs really, and BOTH should be fixed. 1) tripwire, as installed, should not be generating a failure in cron.daily - there are some checks to try to not run the tripwire cron if it is not setup but these are apparently inadequate. 2) the 2nd bug is in logrotate/cron. It really should not stop processing the daily (or hourly, for that matter) crons is one of them happens to fail. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. to reproduce the cron/logrotate problem, just introduce an error (any shell error) one of the cron.daily (or cron.hourly) scripts. note that selecting an earlierly executed one will have more effect than selecting the last cron script that gets executed. 2. to specifically check tripwire problem. do a CLEAN install and don't configure tripwire at all. the cron.daily should give the error that I got and posted above. 3. Actual Results: logrotate doesn't rotate the logs. Expected Results: an error in tripwire cron script really shouldn't inhibit logrotate. Additional info:
upon further investigation, several notes as the above need to be made. 1) the bad tripwire configuration does not break logrotate (the real problem w/ logrotate (I was having pacct filling /var/log) the problem is pacct's logrotate parameters this has been bugzilled as #52572
Tripwire should not be enabled if the user has not configured it properly first. The user needs to read the documentation for tripwire, configure it accordingly, then use it. I'm not sure what should be done on our end to make this easier, but I'm open to suggestions, and will investigate the issue further in a future release. I'm defering this for a future release.
*** This bug has been marked as a duplicate of 61855 ***