Re: System log monitor

[Steve <tarka@zip.com.au>]

"Rene" == Rene Mayrhofer <rene.mayrhofer@vianova.at> writes:
> 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.

Fair enough.
 
> 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.

I was thinking that these would be catted together with a package
header.  However, I think my previous suggestion (run package checks
in parallel) probably isn't that hot in reflection.  The problem is
that general warnings would be repeated in all package runs.  This
could be fixed by running the output through sort|uniq, but this is
pushing it for a process that runs once an hour on a busy system.

With packages having their own violations/ignore files you can add a
separate header to each one. So a logcheck pass would look like ..

  Security Violations
  =-=-=-=-=-=-=-=-=-=
  <result of running through violations/violations.ignore>

  (package foo) Violations
  =-=-=-=-=-=-=-=-=-=-=
  <result of running through foo.violations/ignore>

  Unusual System Events
  =-=-=-=-=-=-=-=-=-=-=
  <The rest>

So the whole logcheck process looks like (modified from the logcheck
INSTALL file) ...

  logcheck.sh executes hourly ----> 
  logcheck.sh executes logtail on log files ----> 
  logtail parses off any text from the last time it was run ---> 
  logcheck greps text for system attack messages ---> 
      logcheck greps text for <foo> system attack messages --->
  logcheck greps text for security violations --->
  logcheck greps text for security violations to ignore --->
      logcheck greps text for <foo> violations --->
      logcheck greps text for <foo> violations to ignore --->
      <etc...>
  logcheck greps text for all messages to ignore. ---> 
      logcheck greps text for <foo> messages to ignore --->
      <etc...>
  any messages found are mailed to system admin.

So the update-logcheck script can cat together just the ignore files,
and preprocess the per-package violation.ignore files for blank-line
errors.  Alternatively, if doing separate runs of package violation
checks proves to much of a performance hit then these could catted
together by update-logcheck, but you loose the nice per-package
violations reports.

Admittedly, separate violations files may be more of a modification to
logcheck than debian policy allows, in which case I've been prattling
inanely :)  Then using update-logcheck to generate violations/ignore
files that don't require altering logcheck is definitely the neatest
solution.

Unfortunately, none of this solves the overall problem of packages
introducing badly formed ignore rules.  In the end is suppose you will
just have to trust subsystems to perform sensible checks and not be
too general, and file bug-reports against those that don't.

Enough rambling for today :)

Cheers,
Steve