[Logcheck-devel] Requesting clarification on a few things

[martin f krafft]

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>