martin f krafft madd...@debian.org wrote:
also sprach Jeremy L. Gaddis jlgad...@gnu.org [2011.07.08.0624 +0200]:
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???
Right. I was a bit confused since webmin had long ago been removed, yet
the filters for it was still present. Makes sense to me to remove it.
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.
I agree. In an ideal world, I think logcheck-database wouldn't contain
much besides filters for kernel messages. All of the other filters (for
specific software) would be included in the respective packages.
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.
I agree with you totally and I wouldn't personally run Avahi on any of
my servers, but I've seen it done. Workstation it is.
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.
From what I gathered (either from the archives or the wiki, I forget
which), it seems that this idea has been floating around for a while but
hasn't really taken off yet. Is anyone [interested in] leading this
effort?
Thanks for your time and effort. I hope I answered all questions.
I appreciate the reply, martin. You've basically reinforced my previous
thought which was use your best judgment. If I make the wrong
decision, well, that's what git revert is for.
Thanks,
-j
--
Jeremy L. Gaddis
___
Logcheck-devel mailing list
Logcheck-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/logcheck-devel
