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 _______________________________________________ Logcheck-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/logcheck-devel
