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.
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
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).
Installed. I'll have to wait until tomorrow to see if it works.
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.
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".
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)?
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.
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