[Logcheck-devel] Integrating rules from other packages back into logcheck

[maximilian attems]

On Fri, 03 Jun 2005, Eric Evans wrote:

> 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.

seconded.
 
> 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.

naaa,
other package maintainer don't care about logcheck rules.
they either get it by a random bug submitter or by patches
of one of us, and then they even get it wrong, 
see the ntpdate case.

as nice this assumptions sound and doesn't work in practice.
an active logcheck team can get much better quality.

 
> > 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.

just read latest changelog.

i discovered by chance as looking at a page form aj listing > 2 years old 
and searching for the word logcheck there.
 
> > 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.

again seconded.

very nice effects:
* drop dh_installlogcheck
* better support for log servers.

--
maks