martin f krafft <[email protected]> wrote: > also sprach Jeremy L. Gaddis <[email protected]> [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 [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/logcheck-devel
