Bug 178387 - logwatch http service reports wrong status codes
logwatch http service reports wrong status codes
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: logwatch (Show other bugs)
4.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Ivana Varekova
:
Depends On:
Blocks: 189992 FAST4.5APPROVED
  Show dependency treegraph
 
Reported: 2006-01-19 18:32 EST by Elluminate Operations
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2006-0631
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-06 09:54:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Elluminate Operations 2006-01-19 18:32:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Description of problem:
Logwatch is updated and the rpm makes a backup copy of the /etc/log.d/scripts/services/http service and calls it http.orig. The http.orig file is still processed which supercedes the settings in http. You then get unknow n service requests that have status codes less than 400.

Version-Release number of selected component (if applicable):
logwatch-5.2.2-1.EL4.1

How reproducible:
Didn't try

Steps to Reproduce:
1.
2.
3.
  

Additional info:

I think all files in logwatch's services directory get processed by default. The should probably have an extension on them like ".conf" and only conf files get processed. When an update occurs than any files that get backed up by the update process will not get processed because they will look like "http.conf.orig", for example.
Comment 1 Kenn Humborg 2006-04-04 23:49:23 EDT
It's not the rpm upgrade process that creates the .orig files.

If you do rpm -ql logwatch you'll see httpd.orig (and sendmail.orig)
are included in the actual RPM.

It looks like the .orig files are created when applying patches at
RPM _build_ time, and the %files section of the SPEC file isn't 
excluding them.

By the way, I agree with the comment that logwatch should define a 
special conf file suffix, but that would be a much bigger job...
At a minimum, it should ignore suffixes similar to the way /etc/rc.d/rc
does:

        # Reject backup files and files generated by rpm.
        case "$1" in
                *.rpmsave|*.rpmorig|*.rpmnew|*~|*.orig)
                        return 1
                        ;;
        esac
Comment 6 Ivana Varekova 2006-04-27 09:44:46 EDT
Thank you for your bug report.
The fixed version is on
http://people.redhat.com/varekova/logwatch-5.2.2-2.EL4.test.src.rpm
Could you please test this version?
There are fixed other 5 bugs (the complete list of fixed bugs is on
http://people.redhat.com/varekova/work.html).
Comment 7 Kenn Humborg 2006-04-28 04:08:34 EDT
Installed.  I'll have to wait until tomorrow to see if it works.
Comment 8 Kenn Humborg 2006-05-01 00:38:58 EDT
Not fully fixed.  


 ################### LogWatch 5.2.2 (06/23/04) #################### 
       Processing Initiated: Sat Apr 29 04:02:03 2006
       Date Range Processed: yesterday
     Detail Level of Output: 0
          Logfiles for Host: XXXX.bluetree.ie
 ################################################################ 

 --------------------- httpd Begin ------------------------ 

A total of 19 unidentified 'other' records logged
  GET /valid/url HTTP/1.1 with response code(s) 200 1 responses
  GET /valid/url HTTP/1.1 with response code(s) 200 1 responses
...

There is a difference.  With the previous version, the number
of responses was always doubled.  The above would have shown
up as:

A total of 19 unidentified 'other' records logged
  GET /valid/url HTTP/1.1 with response code(s) 200 2 responses
  GET /valid/url HTTP/1.1 with response code(s) 200 2 responses

But it's still reporting all successful GETs.

Comment 9 Ivana Varekova 2006-05-05 07:30:17 EDT
The difference which you describes (the number of logs is half) is due to
another bug (bug 167925) in http service in logwatch - in the test version
(comment 6) there is this bug fixed.  
There are not reported all succesfull GETs - there are only reported logs which
are not known to logwatch (the url does not contain known sequence) - these logs
should be in section "unidentified 'other' records logged".
Comment 10 Kenn Humborg 2006-05-07 05:16:48 EDT
You are right.  These are showing up as "unidentified 'other' records logged".

What's the recommended way to make these URLs known to logwatch
(preferably without editing the stock logwatch config files)?

Comment 11 Kenn Humborg 2006-05-17 05:17:23 EDT
I've eliminated the successful GETs from the 
"unidentified 'other' records logged" section by setting
this option to 1 in /etc/log.d/conf/services/http.conf:

# Flag to ignore 4xx and 5xx error messages as possible hack attempts
#
# Set flag to 1 to enable ignore
# or set to 0 to disable
$HTTP_IGNORE_ERROR_HACKS = 1

From the description, it looks like it's not really intended to
do this, but it works for me for now.
Comment 16 Red Hat Bugzilla 2006-09-06 09:54:17 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0631.html

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