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

[Jamie L. Penman-Smithson]

On Sat, 2005-06-04 at 15:01 -0500, Eric Evans wrote:
<snip>
> > 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.
> 
> My first thought when reading this was, "Do we have a metric for often
> they get it right?". Rather than asking it, I did a little research and
> here is what I found.
<snip>
> - Of the 101 files, I found 77 of them to not meet the
>   conventions/standards of the logcheck team, (~76%). This accounts for 
>   about 1050 of 1156 total rules, (~90%).

Although they may be "rough" statistics, they prove the point I'm trying
to make.

> This was a very loosely conducted audit. I spent no more than a few
> seconds looking at each file so it pretty much only reflects obvious
> mistakes. However, it is worth noting that the majority of the ones I
> found "non-conforming" didn't appear to miss the target by much. The
> most common error was not providing a match of the complete line,
> starting with the timestamp, and ending with a "$".

Whether they are minor errors or not, they are still errors. They
wouldn't be happening at all if these rules were included in logcheck.

> One thing that I feel compelled to ask is, are our standards really 
> appropriate, or better yet, are there things we could to do make rules
> maintenance easier on developers? For example, if the most common 
> mistake is the omission of a match on the timestamp, maybe we should be 
> prepending that ourselves for every syslog generated log we parse.

Yes, I think our standards are appropriate. The standards are there to
ensure that we consistently produce high quality packages.

I don't think we should be holding maintainers hands and fixing
completely broken rules that shouldn't be anywhere near logcheck, which
sounds like:

"Sure, it's totally okay if you ignore every conceivable log message
produced by $DAEMON, we'll fix it for you!" 

Prevention is better than a cure.

> > as nice this assumptions sound and doesn't work in practice.
> > an active logcheck team can get much better quality.
> 
> You may be right, but I feel relatively certain that this should not be
> the case. There just aren't enough people on the logcheck team to match
> the collective expertise of the maintainers of these packages.
> 
> I'd really like to see us put our heads together to come up with some
> ideas for fixing the problem and making maintainer included rules an
> asset rather than a, (perceived?), curse.

They are an albatross around our necks. Maintainers really don't care
about logcheck rules. On that point, why should they? Why should they
have to learn how to write regular expressions anyway?

It doesn't matter that we don't have experts in every package in Debian
on the logcheck team, what matters is that users know where to submit
omissions in the rules that we provide. That way, we keep our rules up
to date, users know where to submit rules (the logcheck-database
package) - instead of having to find out which package $FILENAME comes
from.

There's also another problem, running logcheck on a logserver without
those fifty packages (which include their own rules) means you get
unneeded messages from logcheck. The only way to rectify this is to
manually copy them from these packages and repeat it every time the
rules get updated.

The way to fix these problems is to merge these rules back into
logcheck:
- It's easier for end-users
- It's easier for maintainers
- It's a minimal increase in workload for us
- It means that there won't be rules that cause security holes by
ignoring .*

-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/20050605/c294fa2d/attachment.pgp