Steve wrote: > > "Rene" == Rene Mayrhofer <[EMAIL PROTECTED]> writes: > > This is a small followup to my last message. After thinking a bit > > about it, I think it might be better (performance-wise and when > > multiple files include the same rules - this will happen during the > > transitition period when packages start to bring logcheck rules > > files, but when they are still covered by the logcheck-shipped > > defaults) to use an update-logcheck script (like update-modules) > > that pre-generates the rules for logcheck.sh. Then they do not have > > to be generated during run-time and therefore some fancy sorting and > > filtering of duplicates can be done without getting performance > > problems. > > I agree that this would be useful, but mainly as it would be a good > place to filter out the dreaded blank-lines in ignore files. Yes, that's also a good point. Nearly forgot it.
> However, > WRT duplicates, if you have duplicate rule I think you would have a > problem, as that would imply that those rules were too general. I am thinking about rules that are shipped with logcheck at the moment, but will be shipped with the package they belong to in the future. During the transition period, it might (and probably) will happen, that for some time, both logcheck and the other package contain the same rules. > One issue that occurs to me is the danger of one badly formed ignore > regexp for a package can strip real violations out of other package > violations. Package-specific violations and ignores should be done in > separate scans i.e. system-wide common violations and ignores are > scanned for first, and then the resulting output is run though each > group of package-specific violations and ignore rules *separately*, > rather than in series. Hmm, but how would you then decide, which of the separate output should be sent to the administrator ? When e.g. the logcheck package brings some rules to filter most common messages, and the administrator really does not want to see them, then logcheck has to run the common output through these rules before sending them to the admin (I hope I have understood you correctly). At the moment, I can not see how the separated results could be "unified" before mailing them. My only idea idea of implementing this is that the update-logcheck strip just collects all rules (e.g. for ignore) and puts them in one file, cutting out blank-lines and duplicates. But you have definitely a good point here. How can it be prevented that some package messes up with a security relevant package ? Maybe I should only allow rules that start with the package name ? I don't think that this would work (even when all daemon packages had the same name as the running daemon), because that would be too much of a restriction. E.g. the isdnutils package should bring rules, that filter out the kernel isdn messages (like my "workstation" default configuration is doing it now). Comments ? Rene
