From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050721 CentOS/1.0.6-1.4.1.centos4 Firefox/1.0.6 Description of problem: I found two issues with parsing httpd's ssl_access_log log files and all httpd's archived log files. The /etc/log.d/scripts/services/http is passed both access_log and ssl_access_log (see /etc/log.d/conf/logfiles/http.conf). However, because of the way log lines are broken into components, it fails to parse ssl_access_log. I have a small patch to fix the problem. It probably isn't the best example of efficient Perl programming. I'll add it as attachment (it also has detection of "awstats" exploit added since there are robots activly looking for that exploit in the wild, however might not be good idea on sites that actually use awstats script). In /etc/log.d/conf/logfiles/http.conf there is misconfiguration for Archive files. Becasue of that "--archives" option doesn't work for http log files. It looks for archive files in /var/log/archiv/httpd, instead of /var/log/httpd where they are stored on Red Hat Linux systems (RHEL and Fedora). This four lines should be added to archive section: Archive = httpd/access_log.* Archive = httpd/*access_log.* Archive = httpd/access_log.*.gz Archive = httpd/*access_log.*.gz See also /etc/log.d/conf/logfiles/messages.conf as reference, which has correct configuration for messages logfile. Version-Release number of selected component (if applicable): logwatch-5.2.2-1 How reproducible: Always Steps to Reproduce: 1. logwatch --print --service http --range all 2. logwatch --print --service http --range all --archives Actual Results: Pages accessed over SSL not reported. Archives missing. Expected Results: Both "normal" and SSL access reported. Access stored in archives reported. Additional info:
Created attachment 118646 [details] simple patch This is just a simple quick-fix. Probably very bad example of Perl programming. However, it works ;-)
Hello, I agree with the second problem. The pathes without archive/ directory should be added to http.conf too. But I can't reproduce your first problem or I perhaps misunderstood your explanation. Could you please attach your ssl_access_log file, which create wrong logwatch output. Thank you.
The first problem is that ssl_access_log has two fields less than access_log (referrer and agent are missing). Therefore regular expression that is built for access_log does not work for ssl_access_log. For example, consider following line from ssl_access_log: 1.2.3.4 - - [06/Sep/2005:14:50:01 -0500] "GET / HTTP/1.1" 202 212 Current http script will not report it. The workaround (or even final solution) could be chaning default log format for ssl_access_log (by adding referrer and agent). I'll attach a small Perl script that demonstrates the problem more clearly.
Created attachment 118711 [details] testcase This is a small Perl script that demonstrates the problem. Variable $pattern is built the same way as in current http script. @patterns array is my addition (from proposed patch). $line[0] is a line from access_log, $line[1] is a line from ssl_access_log. Note how matching against $pattern fails for $line[1]. If $pattern was used to populate @parsed_line array, you end up with an empty array (regex failed to match), and therefore current http script does not report anything from ssl_access_log.
Created attachment 118752 [details] Proposed patch. Thank you for your notices. I agree with your description of the first problem too. Your patch is right, it is the first part of the proposed patch. In the second problem, there is one more thing. Each access_log log is used twice. The second part of the proposed patch fix this problem and your problem with missed ssl_access_log logs too.
Created attachment 118753 [details] Proposed patch containing bug 159567 patch. logwatch-5.2.2-1 http script contains one other bug (159567) patch for this bug is in bug page. Attached patch contains bug 159567 patch and patch for this bug. Both bugs are quite near, and they affected each other. Could you please test this patch.
Yup, it appears to be working.
Great. thank you. I think http script with this patch creates correct transparent output. If you find some problem with logwatch http script with this patch (comment 6) please attach some comment.
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