Red Hat Bugzilla – Bug 75086
logwatch does not generate messages for all configured categories
Last modified: 2008-05-01 11:38:04 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
Created attachment 78584 [details] /var/log/messages file used to run logwatch with
Created attachment 78585 [details] Expected results - generated with RHL 7.3's perl-5.6.1
Created attachment 78586 [details] Results generated on the same system from the same messages, but using the standard perl-5.8.0
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.
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.
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.
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).
Logwatch 4.0 fixes
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.