[Logcheck-devel] Integrating rules from other packages back into logcheck

[Eric Evans]

On Wed, Jun 08, 2005 at 12:55:25PM +0200, maximilian attems muttered these words:
> you haven't proposed an alternative, have you?

After rereading the thread, it appears that we can summarize the 
problems as follows:

1. There are various issues pertaining to the quality of the rules in 
   comparison to those distributed in logcheck proper.
   
2. Mis-filed bug reports are creating additional work and unnecessary 
   delays.

3. Users running logcheck to produce summaries on central logging 
   servers do not have all the rules that correspond to their log 
   output.

For (1) there were several speculations as to why this is, and they all 
seem to point to people issues rather than technical ones, either 
maintainers can't create quality rules, or they won't. (2) is also a 
people issue, but as both Maks and Jamie have pointed out, it is 
compounded by confusion about which package a given rule belongs to. (3) 
is clearly a technical problem, one that stems from the fact that the 
rules are spread out across 51 packages.

 
#3: Centralized logging
-----------------------
I don't think that logcheck was designed for centralized logging, and 
I'm reasonably confident that those using it that way represent the 
exception rather than rule. If we are to make these configurations
supported, then there will be more work required of us than the mere
aggregation of all rules into a single package.

There was talk on this list not long ago about creating some tools to
extract rules from packages in the archive for use in distributing 
logcheck outside of Debian. IMO, that would be a good compromise.


#2: Mis-filed bug reports
-------------------------
I honestly don't think pulling all rules under the logcheck-database
umbrella is going to fix this. It *might* help a little, but confusion
about which package to report a bug against is something that effects 
the entire project and I don't think there's a silver bullet for it. 

We might see some improvement in this area by just making some attempt
to educate people more. 


#1: Inconsistent rule quality
-----------------------------
This is the one that seems to be the point of greatest contention. It also
happens to be the one I feel most confident we can improve upon.

Proposition A: Make it easy

    #174331 is a wishlist bug from about 2 1/2 years ago requesting macro
    support. In it, the submitter provides a patch for adding macro 
    support to pattern files. Jon Middleton seemed receptive to the idea 
    at the time, but had the idea that this functionality should go into 
    dh_installlogcheck.
    
    I'm guessing that what Jon had in mind was the creation of patterns
    containing macros that would be translated to proper regex in the 
    installed file. I think this is good idea.
    
    To that end, I hacked together a little proof-of-concept to show how 
    that might work. 
    
    http://people.debian.org/~eevans/rule-preprocessing/
    
    The file meta-tags is a perl hash that defines the macros. Tags like
    @IPV4_ADDR@, @DNS_FQDN@, and @INT@ are mapped to regular expressions
    for an IP address, fully qualified hostname, and integer respectively. 
    
    A file like rules.in is created that replaces each item in a line of 
    log output that is variable, with one of the macros from "meta-tags". 
    The result is something that can be more easily parsed by eye balls, 
    and can be constructed by people who haven't developed the ability to
    think in regex.
    
    Running mkrules substitutes macros for the defined regex, escapes a
    few problem characters, strips white space off the end of the line, 
    then anchors the regex with "$".
    
    In essence we'd be creating a new, more accessible way of writing 
    rules that created a layer of abstraction to hide the gory details of
    regular expressions. Maintainers could write their rules in the new 
    format and dh_installlogcheck would take care of the hard work when
    the package was built.
    
    This would also have the added benefits of creating consistency among
    all logcheck rules, and would centralize a great deal of pattern 
    maintenance.


Proposition B: Communicate

    We could open up a dialog with others in the project, starting with
    the maintainers of the 50 packages that already supply their own
    rules. Among the things we could ask them:

    o "Do you use logcheck on any machines you maintain?"
    
    o "Why do you maintain your own rules, is it something that you
       are motivated to do, or do you feel compelled to do so?"
       [Any developer that felt it more of burden than a joy could be
       asked if they were interested in having us take them over]

    o "Would you be interested in joining the logcheck team, even if it
       where only for the purpose of maintaining the rules that apply to
       your other package(s)?"

    o "What can we do to make the task easier for you?"

    o ...


Comments welcome.

-- 
Eric Evans
eevans at sym-link.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20050609/f59775ab/attachment.pgp