Bug 75086 - logwatch does not generate messages for all configured categories
logwatch does not generate messages for all configured categories
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: logwatch (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
: Security
Depends On:
Blocks: 80064
  Show dependency treegraph
 
Reported: 2002-10-04 05:59 EDT by Manfred Hollstein
Modified: 2008-05-01 11:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-10-15 09:37:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/messages file used to run logwatch with (995.22 KB, text/plain)
2002-10-04 06:04 EDT, Manfred Hollstein
no flags Details
Expected results - generated with RHL 7.3's perl-5.6.1 (18.21 KB, text/plain)
2002-10-04 06:07 EDT, Manfred Hollstein
no flags Details
Results generated on the same system from the same messages, but using the standard perl-5.8.0 (2.24 KB, text/plain)
2002-10-04 06:08 EDT, Manfred Hollstein
no flags Details

  None (edit)
Description Manfred Hollstein 2002-10-04 05:59:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809

Description of problem:
I'm using the standard configuration for logwatch from a new RHL 8.0
installation. On RHL 7.3 (using perl-5.6.1-34.99.6) logwatch is
generating messages for all sort of categories such as "Automount",
"Kernel", "ModProbe", "Named", "Samba", "Connections", and "SSHD".

On the same 8.0 system (using perl-5.8.0-55) only the categories
"Samba" and "Connections" are generated, the others are missing.

Version-Release number of selected component (if applicable):
logwatch-2.6-8  (+ perl-5.8.0-55)

How reproducible:
Always

Steps to Reproduce:
1.Stick the attached messages file into "/var/log/messages"
2.Run "logwatch" as root
3.Look at the generated email
	

Actual Results:  Details for categories "Automount", "Kernel", "ModProbe",
"Named", and "SSHD" are missing!

Expected Results:  Details for all configured categories should be shown.

Since details from the kernel are missing (such as attacks to the
firewall etc.), I'd rate this "Security related".

Additional info:

FWIW, I traced this issue down to an "incompatibility" of logwatch
with the perl version shipped with RHL 8.0. Using the version from RHL 7.3
(by creating two symbolic links such as

  "ln -sf /7.3/usr/bin/perl /usr/bin/perl" and
  "ln -s /7.3/usr/lib/perl5/5.6.1 /usr/lib/perl5")

instead, enables logwatch to print details for all categories again. See the
attached files for details:

1. /var/log/messages    This one is the logfile I used to run logwatch with
2. logwatch-message-generated-by-perl-5.6.1-34.99.6.txt  This contains
      the messages as I expect them to be
3. logwatch-message-generated-by-perl-5.8.0-55.txt   This one contains
      the messages generated by the standard RHL-8.0 installation
      and from the same /var/log/messages file
Comment 1 Manfred Hollstein 2002-10-04 06:04:25 EDT
Created attachment 78584 [details]
/var/log/messages file used to run logwatch with
Comment 2 Manfred Hollstein 2002-10-04 06:07:05 EDT
Created attachment 78585 [details]
Expected results - generated with RHL 7.3's perl-5.6.1
Comment 3 Manfred Hollstein 2002-10-04 06:08:30 EDT
Created attachment 78586 [details]
Results generated on the same system from the same messages, but using the standard perl-5.8.0
Comment 4 Douglas Kilpatrick 2002-10-08 11:00:41 EDT
See also but 72809

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72809

The basic problem is a dependency issue.  The filters are dependant on each
other: One filter removes the time stamps, the other assumes the time stamps are
there.

You can "fix" it for RHL 8.0 by futzing with sort/reverse when the keys when
constructing the filter list for running the individual logwatch scripts. 
Obviously, this isn't the correct answer...

There are only two filters actually used, "OnlyService" and "RemoveHeaders", so
its easy to randomly get the right order from the hash table.  However ... It
really needs depenency info.
Comment 5 Need Real Name 2002-10-08 17:06:37 EDT
The missing firewall info needs further comment.  The firewall rules created by 
lokkit does not do any logging.  In addition, the kernel service in logwatch 
can only parse ipchains logs - and since iptables is now used in 8.0, it will 
no longer work even if dropped packets were logged.
Comment 6 Manfred Hollstein 2002-10-09 02:47:59 EDT
I'm not using a firewall generated by lokkit. Due to whatever constraints I'm
still using my good'n'ole ipchains firewall. Look at the attached messages
file.
Comment 7 Need Real Name 2002-10-15 09:37:18 EDT
ICK!  Never rely on the raw order of items in a hash.  In Perl 5.8.0, they changed the hash
algorithm.

This needs to be fixed properly.  However, for people that HAVE to get this working, this is a
quick and dirty patch that works (but it is crappy programming, so don't attribute it to me).
This relies on the fact that by chance, the desired order of operations of "shared" scripts
happens to be their alphabetical order.

In the script /etc/log.d/scripts/logwatch.pl change lines 474 and 527 (or, you can do a search
on the keyword "reverse" as it only appears in the script twice).  Change "reverse" to "sort"
both in both locations.

The proper fix is not to store these items in a hash, but rather in an array and use that order (or
its reverse).  However, the above "reverse" to "sort" fix can be made more robust and "proper"
by renaming the scripts in the shared area from"scriptname" to "XX-scriptname" where XX is
a numeric that identifies the order (similar to the /etc/rc.d/rcX.d script order).
Comment 8 Elliot Lee 2002-10-16 14:02:04 EDT
Logwatch 4.0 fixes
Comment 9 Eric Hopper 2002-12-19 08:56:55 EST
If you can do it, this needs to be released as a patch.  I think missing log
messages represents a grave security risk.

You could argue that people who pay attention to the logs will notice the
missing bits and come find this bug, but I think that's expecting people to
spend an unreasonable amount of effort.

I'm creating a new open bug on this.

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