I got the fail2ban from epel.
There were a number of issues relating to using a log file...
logwatch was looking for both fail2ban and fail2ban.log
logrotate file fail2ban added looked for fail2ban.log and then reset
itself to syslog
fail2ban itself went to syslog, over riding its fail2ban.log.
took a while, but I use /var/log/fail2ban now, that finally worked
through logrotates and logwatch.
Problem with centos variant of fail2ban:
logrotate causes all 'ban' actions to stop happening. I am pretty sure
it stops reading the logs but still functions.
Unban actions still keep showing up in the log, but the 'ban' actions
just stop. Program is running, but no longer working.
Long searches online show a million others with the same issue. Only way
to prevent it seems to be to add a reload or restart in the syslog file.
This is undesired due to losing all banned ips listed.
It happens as part of the logrotate. The logrotate file I have changed a
few times and recently tried this
postrotate
/usr/bin/fail2ban-client set logtarget /var/log/fail2ban
1>/dev/null || true
endscript
setting the logtarget, which the original called for changing it to
syslog and 2>dev/null || true
so what would you do? I imagine when logrotate happens and syslog
restarts something is causing fail2ban to stop working properly, but
still timing 'unbans'.
This is apparently a bug/problem for almost everyone of all distros.
Other than just uninstalling, the only way to make it work would be a
restart around 4 every morning, making any long term bans useless.
My last thought is to just throw the /var/log/fail2ban to be rotated by
syslog like maillog and the others..and not doing anything special.
Maybe it would just work.
I write here because I know there are hundreds of you and someone must
have figured out how to make fail2ban work for more than 24 hours
without a restart....
https://github.com/fail2ban/fail2ban/issues/44 2012/4/27 Bob Hoffman <bob at bobhoffman.com>:> I got the fail2ban from epel. > There were a number of issues relating to using a log file... > logwatch was looking for both fail2ban and fail2ban.log > logrotate file fail2ban added looked for fail2ban.log and then reset > itself to syslog > fail2ban itself went to syslog, over riding its fail2ban.log. > > took a while, but I use /var/log/fail2ban now, that finally worked > through logrotates and logwatch. > > Problem with centos variant of fail2ban: > > logrotate causes all 'ban' actions to stop happening. I am pretty sure > it stops reading the logs but still functions. > Unban actions still keep showing up in the log, but the 'ban' actions > just stop. Program is running, but no longer working. > > Long searches online show a million others with the same issue. Only way > to prevent it seems to be to add a reload or restart in the syslog file. > This is undesired due to losing all banned ips listed. > > It happens as part of the logrotate. The logrotate file I have changed a > few times and recently tried this > ? ? postrotate > ? ? ? /usr/bin/fail2ban-client set logtarget /var/log/fail2ban > 1>/dev/null || true > ? ? endscript > > setting the logtarget, which the original called for changing it to > syslog and 2>dev/null || true > > > so what would you do? I imagine when logrotate happens and syslog > restarts something is causing fail2ban to stop working properly, but > still timing 'unbans'. > > This is apparently a bug/problem for almost everyone of all distros. > Other than just uninstalling, the only way to make it work would be a > restart around 4 every morning, making any long term bans useless. > > My last thought is to just throw the /var/log/fail2ban to be rotated by > syslog like maillog and the others..and not doing anything special. > Maybe it would just work. > > I write here because I know there are hundreds of you and someone must > have figured out how to make fail2ban work for more than 24 hours > without a restart.... > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos