Logcheck devel - Jun 2005 - Integrating rules from other packages back into logcheck

I'm not so sure that the policy of handing over responsibility for
package specific rules to package maintainers is a good idea. For
example, there have 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 may not have reported it.

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 (although we can reassign bugs). It's
also bad because we don't have any input in the rules that are created,
thus they may not be of the same quality as those included with
logcheck.

If we do have rules that are maintained by others, 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.

IMO having the rules from other packages integrated back into logcheck
would be simpler for end-users, mean that rules were of the same quality
as those in logcheck and I don't think that it will dramatically
increase our workload. 

The only reason to keep rules in other packages is that package
maintainers are able to update logcheck rules in time with a release,
whereas if they are included with logcheck there's a delay while the
rules are updated and a new version is released. I think a possible
delay is better than having rules which are not of the same standard as
those included with logcheck.

Thoughts?

-j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20050603/27ebcba9/attachment.pgp

On Fri, Jun 03, 2005 at 03:10:04AM +0100, Jamie L. Penman-Smithson muttered
these words:
> I'm not so sure that the policy of handing over responsibility for
> package specific rules to package maintainers is a good idea. For
> example, there have 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 may not have reported it.
> 
> 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 (although we can reassign bugs). It's
> also bad because we don't have any input in the rules that are created,
> thus they may not be of the same quality as those included with
> logcheck.
IMO, the more package maintainers we can get to manage their own rules,
the better. Not to save us work, but because they likely know the
software they are packaging better than we do.

There is nothing that says that we can't audit rules that are included
in other packages and submit patches to the BTS.
> If we do have rules that are maintained by others, 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.
Which bug was this? Was it actually filed against qpopper instead of
logcheck? If so, I can't see us avoiding this sort of mistake.
> IMO having the rules from other packages integrated back into logcheck
> would be simpler for end-users, mean that rules were of the same quality
> as those in logcheck and I don't think that it will dramatically
> increase our workload. 
> 
> The only reason to keep rules in other packages is that package
> maintainers are able to update logcheck rules in time with a release,
> whereas if they are included with logcheck there's a delay while the
> rules are updated and a new version is released. I think a possible
> delay is better than having rules which are not of the same standard as
> those included with logcheck.


-- 
Eric Evans
eevans at sym-link.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20050603/ac737ed5/attachment.pgp