- Tags for different rule types
- is-a-server
- has-proftpd
- ipv6-enabled
- Ultra-simple filtering mechanism
- Like syslog-summary, but can define many filters
- Each filter is just a path to a script that reads stdin, writes stdout
- (Filter might be a bad word for it. Munging, ascii graphs, etc)
- Not enabled by default, intended to give admin more flexibility
- perhaps something like /etc/logcheck/filters.d/ and run-parts
would help solve things like #241526 (i.e. a way to ignore messages only if they don't occur more than N times)
Might be good to strip unhelpful bits. E.g. firewall (iptables) logs tend to show lots of lines with the MAC address of the external local interface in it which only makes the line about 20-25% longer; if this could be filtered to reduce it to MAC=XY: …:WZ instead, replacing the intermediate blobs to ellipsis, that'd make the report a lot more readable. (Note: I had to add a space after the XY: to avoid turning it into an IW link – can the bang_meta config option be set so we can suppress links???)
- Bayesian filtering
- Create an interface that will allow logcheck to accept admin input (a simple WWW server on a nonstandard port, with a password check, would do)
- Admin can then mark mailed messages as "this one wasn't interesting". Logcheck could then learn what messages to ignore. (Should be more reliable than regex matching - regexes tend to be buggy.)
- Admin might also look into the list of ignored messages and mark some as "hey, this one should have been sent to me!".
- Important: give diagnostics why a message was sent or not. Diagnostic information might include: "Message matched rule such-and-so", "Message was manually marked as important/unimportant", "Bayesian relevance was such-and-so" (the latter message maybe even with references to the messages that had an influence on the Bayesian score).
- Flexibility
- run-parts is is not obviously portable to Solaris. As logcheck depends on run-parts, it also is not portable.
- Per log file configuration. Some admins split the syslog files up per incoming stream. Limiting the checks to those for that stream would improve performance on busy systems.
Collect logs as root, but do all parsing and filtering and mailing as logcheck user. Some systems (SUSE Linux 10.0) save logs as root:root 0600 and fiddling around with logrotate is going to end nowhere (MatthiasAndree).