Logcheck devel - Jul 2011 - Requesting clarification on a few things

All,

First off, for those who aren't aware, let me introduce myself.

I am a longtime Debian user (~15 years now) and systems/network guy in
my professional life.  Like most of you, I'm sure, I prefer to use free
software whenever possible.

I am also a newcomer to the logcheck project.  About three months ago, I
responded to madduck's now nearly two-year-old Request For Help[0] and
was added to the project.  In that time, I have made a few updates to
rules files in response to open bugs. 

A few days ago, Hannes (in a private email) sent me some comments (which
were most welcome and appreciated, by the way) and noted that he was
planning to release 1.3.14 soon.  I have a few questions, mostly
centered around the way things are done (with regard to logcheck), that
I hope the other team members can help me with.  I'd like to help close
out as many bugs as possible before 1.3.14 so I am requesting
clarification on several things.

One thing that Hannes mentioned was in response to commits 5f7da05[1]
and cf5e9d3[2] which I made to address bug #590559[3].  As he mentioned
in his email, webmin was removed from the Debian archive over five years
ago[4].  He Cc:'d madduck asking what the policy is for rules for
packages that have been removed from Debian.  My personal thought was
that since they were still there, they might as well be updated.  For
clarification and future reference, I am interested in knowing what the
policy is as well.

Regarding commit 6a4bf69[5] to close bug #616616[6], I updated a rule to
reflect an upstream change in the log message.  In this case, the
"old"
rule was for a (Postfix) package version that is no longer supported in
Debian, so it was removed and the new rule added.  In cases where this
occurs and the "old" version is still supported, I assume the right
thing to do would be to add the new rule and keep the old one as well
(until the package version is no longer supported).  Please correct me
if that is wrong.

Currently, I am trying to figure out the proper thing to do with regard
to bug #621373[7].  This is a request for two rules related to log
messages generated by avahi-daemon.  As of now, there are no rules in
logcheck-database for Avahi.  Is there some process for deciding if it
is appropriate to add them or do we just go ahead (which seems like the
logical decision to me).  Assuming this is correct, it should only be a
matter of creating the avahi-daemon file and adding the two rules I have
created (slightly modified from the original bug report).

Related to that, can I assume that the proper file to create would be
i.d.s/avahi-daemon instead of i.d.w/avahi-daemon?  Avahi is often
present on both servers and workstations so it would seem appropriate to
put it under i.d.s since those rules will get applied when REPORTLEVEL
is set to "workstation" as well as "server".

I have the necessary changes to close #621373 ready to go; I just need
to merge them into master and push them but am holding off until I
become more clear on "how things work" (hence, this email).

My next question is how is it decided whether or not to add, delete, or
update (whatever the case may be) rules in response to a request/bug
report?  I have read some bug reports (e.g. #564063[8]) where the
correct decision is not obvious.  Do we add the rules or not?  How do
you decide?

Bug #617232[9] mentions rules which match on IPv4 addresses but will not
match IPv6 addresses.  Should we begin updating rules so that both IPv4
and IPv6 addresses will be matched?  Is there a preferred methodology
for doing this, or is it okay to simply start working on it now?

On a side note, is it appropriate to add my own name to the list on the
main logcheck page[10]?  Maybe it's a little narcisstic, but I like
seeing my own name.  :)

Last, I am mostly operating under my own "best judgment".  Because
everything is in git, I have pretty much decided to simply do what I
think is right knowing that (if I'm wrong) the changes can quickly and
easily be reverted.  Thus, if you happen to see something I've done that
I shouldn't have, please feel free to revert back (an email letting me
know why would be appreciated too).  Until I get a better feel for how
things are done with regard to logcheck, I'll probably continue with
this line of thinking (unless I'm way off base, in which case you should
let me know).

This email turned out much longer than I anticipated but includes almost
everything I am unsure about.  Thanks for taking the time to read it,
and I will be most appreciative of any responses.

-Jeremy

-- 
Jeremy L. Gaddis

[0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539944
[1]: http://tinyurl.com/commit-5f7da05
[2]: http://tinyurl.com/commit-cf5e9d3
[3]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590559
[4]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343897
[5]: http://tinyurl.com/commit-6a4bf69
[6]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616616
[7]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621373
[8]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564063
[9]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617232

also sprach Jeremy L. Gaddis <jlgaddis at gnu.org> [2011.07.08.0624
+0200]:
> I am also a newcomer to the logcheck project.  About three months ago, I
> responded to madduck's now nearly two-year-old Request For Help[0] and
> was added to the project.  In that time, I have made a few updates to
> rules files in response to open bugs.
Thanks for joining the project, and welcome!
> One thing that Hannes mentioned was in response to commits
> 5f7da05[1] and cf5e9d3[2] which I made to address bug #590559[3].
> As he mentioned in his email, webmin was removed from the Debian
> archive over five years ago[4].  He Cc:'d madduck asking what the
> policy is for rules for packages that have been removed from
> Debian.  My personal thought was that since they were still there,
> they might as well be updated.  For clarification and future
> reference, I am interested in knowing what the policy is as well.
I do not think there is a policy. It makes sense to keep filters
around while any version of Debian still has a package (due to
backports), but when Debian does not have the package at all
anymore, then there is no real reason to carry over the weight?
> Currently, I am trying to figure out the proper thing to do with regard
> to bug #621373[7].  This is a request for two rules related to log
> messages generated by avahi-daemon.  As of now, there are no rules in
> logcheck-database for Avahi.  Is there some process for deciding if it
> is appropriate to add them or do we just go ahead (which seems like the
> logical decision to me).
It would make much more sense to distribute the filters in the
avahi-daemon package.
> Related to that, can I assume that the proper file to create would
> be i.d.s/avahi-daemon instead of i.d.w/avahi-daemon?  Avahi is
> often present on both servers and workstations so it would seem
> appropriate to put it under i.d.s since those rules will get
> applied when REPORTLEVEL is set to "workstation" as well as
> "server".
I really do not see a reason why one would have Avahi on a server,
so I'd tend to put it into the workstation pool. If you disagree,
then use your own judgement.
> My next question is how is it decided whether or not to add,
> delete, or update (whatever the case may be) rules in response to
> a request/bug report?  I have read some bug reports (e.g.
> #564063[8]) where the correct decision is not obvious.  Do we add
> the rules or not?  How do you decide?
We flip coins!

In general, we serve to make life better for our users. Hence
informational messages can and should be filtered.
> Bug #617232[9] mentions rules which match on IPv4 addresses but
> will not match IPv6 addresses.  Should we begin updating rules so
> that both IPv4 and IPv6 addresses will be matched?  Is there
> a preferred methodology for doing this, or is it okay to simply
> start working on it now?
Rather than hacking the regexps, this should really be done by
finally introducing macros/templates/patterns into rulefiles.
> On a side note, is it appropriate to add my own name to the list
> on the main logcheck page[10]?  Maybe it's a little narcisstic,
> but I like seeing my own name.  :)
If you contibute, your name should be shown if this is what you
want!

Thanks for your time and effort. I hope I answered all questions.

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"the intellect is not a serious thing, and never has been.
 it is an instrument on which one plays, that is all."
                                                        -- oscar wilde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see
http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL:
<http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20110708/102a2275/attachment.pgp>

On Fri, Jul 08, 2011 at 12:24:54AM -0400, Jeremy L. Gaddis
wrote:
> One thing that Hannes mentioned was in response to commits 5f7da05[1]
> and cf5e9d3[2] which I made to address bug #590559[3].  As he mentioned
> in his email, webmin was removed from the Debian archive over five years
> ago[4].  He Cc:'d madduck asking what the policy is for rules for
> packages that have been removed from Debian.  My personal thought was
> that since they were still there, they might as well be updated.  For
> clarification and future reference, I am interested in knowing what the
> policy is as well.
As far as I know there is no policy for that.

The problem with keeping rules of obsolete packages or package versions
is that each (obsolete) rule slows down logcheck (at least as long as #602494
has not been fixed). Additionally it implies more work for the maintainers.

Furthermore there are some criteria in the SUBMITTING RULES section of
README.logcheck-database.gz: 

    Unfortunately, we don't have the time to add and update rules for
    everything, therefore the following exceptions apply:

    *  Debug messages
    *  Messages produced by software not included in Debian
    *  Temporary messages which are due to a bug in the package
    *  Messages related to daemon startups and shutdowns

    Please do not file bugs related to these messages.

Following point two the webmin rule should be deleted.

Maybe we can work out a policy about which rules should be included in
logcheck-database and which not?
> Regarding commit 6a4bf69[5] to close bug #616616[6], I updated a rule to
> reflect an upstream change in the log message.  In this case, the
"old"
> rule was for a (Postfix) package version that is no longer supported in
> Debian, so it was removed and the new rule added.  In cases where this
> occurs and the "old" version is still supported, I assume the
right
> thing to do would be to add the new rule and keep the old one as well
> (until the package version is no longer supported).  Please correct me
> if that is wrong.
In my opinion we should keep the rules as long as the package version is
supported in oldstable. 
> Currently, I am trying to figure out the proper thing to do with regard
> to bug #621373[7].  This is a request for two rules related to log
> messages generated by avahi-daemon.  As of now, there are no rules in
> logcheck-database for Avahi.  Is there some process for deciding if it
> is appropriate to add them or do we just go ahead (which seems like the
> logical decision to me).  Assuming this is correct, it should only be a
> matter of creating the avahi-daemon file and adding the two rules I have
> created (slightly modified from the original bug report).
For the first rule please see my answer to your "Ho do you decide?"
question below.

For the second rule you might consider to adjust the rule in
i.d.p/logcheck to be more generic.
> Related to that, can I assume that the proper file to create would be
> i.d.s/avahi-daemon instead of i.d.w/avahi-daemon?  Avahi is often
> present on both servers and workstations so it would seem appropriate to
> put it under i.d.s since those rules will get applied when REPORTLEVEL
> is set to "workstation" as well as "server".
Using avahi-daemon on a server is unusual, so I would tend to put the
rules to i.d.w/avahi-daeomn.
> My next question is how is it decided whether or not to add, delete, or
> update (whatever the case may be) rules in response to a request/bug
> report?  I have read some bug reports (e.g. #564063[8]) where the
> correct decision is not obvious.  Do we add the rules or not?  How do
> you decide?
In my opinion logcheck should filter only such messages which are
informational and aren't caused by an error. In other words messages
which could require any reaction by the administrator (eg adding local
rules or fix the causing issue) should not be filtered by default.  I
close only such bugs for packages which I know, so I can estimate if the
message is only informational.
> Bug #617232[9] mentions rules which match on IPv4 addresses but will not
> match IPv6 addresses.  Should we begin updating rules so that both IPv4
> and IPv6 addresses will be matched?  Is there a preferred methodology
> for doing this, or is it okay to simply start working on it now?
Before replacing the patterns randomly, #174331 should be fixed.
> On a side note, is it appropriate to add my own name to the list on the
> main logcheck page[10]?  Maybe it's a little narcisstic, but I like
> seeing my own name.  :)
You contribute to logcheck, so I think it is reasonable to add yourself to the
list of active developers. 

Greetings

Hannes