Re: fail2ban vs. syslogd compression
Ok, thanx to everybody for the advice. I am no step closer to a solution
however. I see different routes:
1) Clarify if it is really true that the message "last message repeated \d+
times" does not always refer to the last message, as suggested in one post.
I thought that syslogd's raison d'etre was exactly to provide a unified
tracking system for log messages, so it really should know where it's
messages came from and should take great pains in keeping its output sound.
Otherwise, that would be a serious bug, wouldn't it? If the messages are
reliable, which I tend to assume, then the obvious patch to fail2ban should
work. Unfortunately I can't read greek, so I don't know if more detailed
problems are mentioned in the referred to post from greek lug.
2) The other idea is to keep seperate temporary logs, with
anti-syslog-compression. it really raises the effort needed to maintain the
system (thus makes it likely to break).
When I find some time, I'll get in touch with the fail2ban-developers. I am
back on the list once I head something useful.