Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 80064

Summary: logwatch misses reporting certain things it should catch
Product: [Retired] Red Hat Linux Reporter: Eric Hopper <eric-bugs>
Component: logwatchAssignee: Elliot Lee <sopwith>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: kilpatds
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75086
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-15 13:46:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 75086    
Bug Blocks:    

Description Eric Hopper 2002-12-19 14:06:09 UTC
Description of problem:
Logwatch doesn't properly report certain events that it should.  This is due to
a bug that causes shared scripts to be run in an undefined order.

I know this is fixed in the rawhide 4.0.3-3 package, but this should be released
as a patch to RedHat 8.0.

I rely on logwatch to give me accurate information in order that I might notice
security related problems.  In particular, I've managed to get the ssh worm
removed from many machines across the Internet because I've noticed its
signature in my logs.  Bugs in logging are a serious security issue.

Comment 1 Eric Hopper 2003-01-15 13:30:22 UTC
So, no making logging actually work in RH 8.0?  I don't care much as I've
installed the Rawhide version everywhere, but, it bothers me to think of all the
people relying on logs that are broken.


Comment 2 Elliot Lee 2003-01-15 13:46:26 UTC
Based on the current priority and number of items already waiting in the errata queue, no.