[Logcheck-devel] [ttroxell at debian.org: Re: Logcheck rules from other packages]

[Todd Troxell]

I'm not sure if this message ever made it to you, Jamie.  I had a reverse DNS
problem shortly after it was sent.

----- Forwarded message from Todd Troxell <ttroxell at debian.org> -----

Date: Wed, 1 Jun 2005 01:22:18 -0400
From: Todd Troxell <ttroxell at debian.org>
To: "Jamie L. Penman-Smithson" <jamie at silverdream.org>
Subject: Re: Logcheck rules from other packages

Hey Jamie,

On Mon, May 30, 2005 at 09:57:32PM +0100, Jamie L. Penman-Smithson wrote:
> Hey Todd,
> 
> I'm not so sure about the policy of handing over responsibility for
> package specific rules to some maintainers is a good idea. For example,
> there has been one or two bugs against the supplied logcheck rules with
> packages which could have lead to vast amounts of messages being
> ignored. If a script kiddy was attempting to break in to the system at
> the same time, logcheck wouldn't have reported it.

Yeah, I'm not crazy about the idea of relying on rules from other maintainers
either.  Maybe dh_installlogcheck could run some simple sanity checks on the
rules from other packages before they are installed.

An idea I've had in working on pylogcheck for dealing with this is somehting I
was calling "directors"

Syslog message prefixes to the corresponding rule file, so lines like:

^Jun  102:16:32 localhost dhcpd.*$

would be directed to (and processed only by the dhcpd rule file.)

Certainly there are complications with this, and I never actually planned to
implement it in Logcheck proper, but it's something to think about, I guess.

I'm not really sure how the policy change would go down...  I'd love to see
some algorithms for sanitizing rules.  I am not sure how much of this is
possible, but they would be useful in the future for web-based rule
submission and whatnot.

> My point is not all maintainers knowledge of regular expressions is the
> same. Exporting responsibility over rules is good in that it reduces our
> workload. It's bad however because it makes it harder for end-users to
> know where they should file bugs, sure we can reassign bugs. It's also
> bad because we don't have any input in the rules that are created, they
> may not be of the same quality as those included with logcheck.
> 
> Another thing, if we have rules that are maintained by others (not the
> logcheck team), we should make it crystal clear which rules are included
> in logcheck and which rules are included in other packages. The bugs
> filed against qpopper (that were three years old) were filed in the
> wrong place, somehow we need to make it clearer that say, bugs in
> qpopper logcheck rules should be filed against logcheck. Then again, if
> we include the rules from other packages in logcheck again, this problem
> will cease to exist.

Maybe add some docs to the tune of "please run dpkg -S $RULEFILE before
submitting a bug."

Cheers,
-- 
[   Todd J. Troxell                                         ,''`.
      Student, Debian GNU/Linux Developer, SysAdmin, Geek  : :' :
      http://debian.org || http://rapidpacket.com/~xtat    `. `' 
                                                             `-     ]



----- End forwarded message -----

-- 
[   Todd J. Troxell                                         ,''`.
      Student, Debian GNU/Linux Developer, SysAdmin, Geek  : :' :
      http://debian.org || http://rapidpacket.com/~xtat    `. `' 
                                                             `-     ]