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

[Eric Evans]

On Sun, Jun 05, 2005 at 12:57:24AM +0100, Jamie L. Penman-Smithson muttered these words:
> Although they may be "rough" statistics, they prove the point I'm trying
> to make.

I went looking for more data to determine if the problem was as large 
as everyone seemed to believe, and thought it appropriate to share the 
results.

I understand the problem better now, but I still think the proposed 
solution is a little rash for a first step.

[ ... ]

> > 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'm not questioning motivations, I am asking you to take a step back and
look at it objectively. Could we do something different in order to make
things easier on others and achieve the same or better results?

> 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!" 

Do you submit bug reports for issues not pertaining to logcheck? If so,
do you ever submit patches with these reports? How would you respond to
a maintainer that felt the rules he was including were the rightful 
domain of his package and not logcheck? What if he didn't trust us to 
determine what output was appropriate to exclude?

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

What makes you assume that "they" don't already understand regular
expressions? What makes you think they don't care about logcheck rules?

I would argue that if they took the time to include a set of rules in
their package that they *do* care. I also have a great deal of 
confidence in the abilities of Debian maintainers, and I refuse to 
believe that regular expressions are beyond the capabilities of everyone
*except* the logcheck devel team.

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

Bugs are incorrectly assigned to the wrong package all the time, I
really don't see this as a valid reason. If it is really that much of a
burden, I will volunteer to personally follow up on all incorrectly 
assigned bugs.

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

I don't think logcheck was ever really designed to accommodate this. 
However, I am not specifically arguing in favor of having the rules 
installed from other packages as much as I am arguing in favor of 
engaging other maintainers, and encouraging them to take some ownership
of the rules that are related to the packages they maintain.

Maybe we could give commit access to the CVS repository on Alioth to
every maintainer that wishes to contribute rules for their package. Maybe
we could request access to their SCM, or accept patches to their rules
via an email to the list. Anything other than a message that is bound to
sound like, "Your rules suck, and we are tired of getting your bugs".

Can we at least elicit the opinion of a wider audience, (the maintainers
of the 50 packages already supplying rules at the least), and be open to
their suggestions? I will volunteer for this task as well if no one else
is interested.

> 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


-- 
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/20050604/3e9ebd18/attachment.pgp