Description of problem:

Bug #1: In the setup area of the script we have the following...


my $archive_types = 
'(\.ace|\.bz2|\.cab|\.deb|\.dsc|\.ed2k|\.gz|\.hqx|\.md5|\.rar|\.rpm|\.sig|\.sign|\.tar|\.tbz2|\.tgz|\.Z|\
.zip)';


In particular, note that ".Z" is upper case. Naturally, this matches what a
compressed file looks like in most implementations. However, later in the
script we have this...

   $field{lc_url} = lc $field{url};

...followed a bit later by...

   ($field{base_url},$field{url_parms}) = split(/\?/,$field{"lc_url"});

So we see that base_url is being split out of a string that has been
shifted to lower case. Finally, in the section where we're categorizing and
tallying the URLs using pattern matching, we have this...

   } elsif ($field{base_url} =~ /$archive_types$/) {
      $archive_count += 1;
      $archive_bytes += $field{bytes_transfered};

The problem, of course, is that .Z files do not match the pattern because
the pattern is upper case but the URL has been downshifted. As a result,
all of the .Z files that get downloaded from my web site show up in the
daily logwatch report as exceptions, under the heading

  A total of <nnn> unidentified 'other' records logged

So, I can think of two ways to fix this

1) Change ".Z" to ".z" in the declaration of $archive_types, or

2) Change

   ($field{base_url},$field{url_parms}) = split(/\?/,$field{"lc_url"});

   to

   ($field{base_url},$field{url_parms}) = split(/\?/,$field{"url"});

IMHO, #2 is the better solution. If I understand the script correctly, you
have created lc_url mainly to check for typical exploit attempts, so you
want to downshift in order to compare the URL string with known exploit
strings. But I don't think it's correct to use lc_url elsewhere. What if
users happen to have other upper case file extensions and want to add them
to the script? This is true in my case, where we have lots of ".LZW"
compressed files. Those were also incorrectly showing up in the daily
report.

Ok, Bug #2: Consider the following block of code:


   if ($field{lc_url} =~ /$image_types$/) {
      $image_count += 1;
      $image_bytes += $field{bytes_transfered};
   } elsif ($field{base_url} =~ /$docs_types$/) {
      $docs_count += 1;
      $docs_bytes += $field{bytes_transfered};
   } elsif ($field{base_url} =~ /$archive_types$/) {
      $archive_count += 1;
      $archive_bytes += $field{bytes_transfered};
   } elsif ($field{base_url} =~ /$sound_types$/) {
      $sound_count += 1;
      $sound_bytes += $field{bytes_transfered};
   ...


Do you see the problem? In the very first comparison you're looking at
lc_url, but in all the rest (and the list continues beyond what I've shown
here) you're looking at base_url. I believe the first line should be

     if ($field{base_url} =~ /$image_types$/) {

Do you agree?


Version-Release number of selected component (if applicable):

  [root@opus services]# ident /etc/log.d/scripts/services/http
  /etc/log.d/scripts/services/http:
       $Id: http,v 1.13 2004/06/22 13:48:26 kirk Exp $
       $Log: http,v $
  [root@opus services]#


How reproducible:
Every time (every day)


Steps to Reproduce:
1. For example, create a compressed ".Z" file and place it on your web server.
2. Download the ".Z" file via a web browser.
3. Look at the logwatch report created the next day and see that the ".Z" file is incorrectly
reported as an exception.
  
Actual results:
Files with upper case file extensions are incorrectly being displayed in the daily logwatch
report under the heading "A total of 30 unidentified 'other' records logged".


Expected results:
It is valid for files on a web server to have upper case file extensions. They should not be
reported as exceptions by logwatch.

Additional info: