Fail2Ban Issues after FreePBX 6.12.65-28 Update

We ran the 6.12.65-28 update from 6.12.65-26 and Fail2Ban would not start automatically, with reboot or GUI.

Ran yum updates and nothing was found

Ran yum reinstall fail2ban
Ran yum remove fail2ban
Ran yum install fail2ban

no changes with package

After running service restart in GUI, error came back about glob /var/log/vsftpd.log

Created that file (as a blank file) just to get the service restarted

now #service fail2 restart generates
Stopping fail2ban: [ OK ]
Starting fail2ban: WARNING ‘ignoreregex’ not defined in ‘Definition’. Using default one: ‘’
[ OK ]

and in the FreePBX System Status Fail2Ban shows with a question mark icon and says “Unable to detect service status”

Any idea on this, I have the same problem.

Seems latest fail2ban has made some changes with log files being required to be their. Can someone report a bug at and we can get it resolved.

The packager would normally make sure a package is bug free. In

fail2ban.noarch 0:0.8.8-108.shmz65.1.121

that is the esteemed

Bryan Walters [email protected]

perhaps he should have first crack at it as without doubt he will see the bug before any “user” :wink:

Lets add a mention @GameGamer43 so he gets a copy of this.

Yes as instated they changed some things it appears and was not caught as our servers all have the log files created.

Please open a bug report. Forums are not for reporting bugs.

I’m sorry, I don’t understand, if “they changed something” ( I assume you mean and not the packagers) , how would that reflect in any way a problem for a static Redhat Package managed by Bryan and distributed by Sangoma, if they passed the QA phase they should work no ?

Further, was it not you that moved the 6.12.65-28 update forward to “on-deck” status from pending “QA” status , so generally your ultimate opinion as the CTO officer imprimatur is that it is working correctly, no ? and are you still sure about all that?

Forums are perhaps not for reporting bugs, but very good at noticing bad software being released, the two should not be treated the same. Or the lag of days as a “user” learned how to get an an account and how to “report a bug” would be not the hours that it would take with sentient beings watching, if fail2ban is not running that would surely be a BIG BUG requiring an immediate fix, unlike the “pending” unfixed fail2ban bugs in the bug tracker that just make some of it not work :wink: no?

The issue here is in fail2ban 0.8.14 fail2ban upstream now fails to start if a log file it should monitor is not there. The FTP log file is not created until someone starts FTP and that is something they pick to do in sysadmin if they want to enable FTP and on our dev boxes it was started so their was a log file so it was never picked up in Q/A. We have published a new fail2ban that will verify all log files are their on install and if not touch the file to create it so fail2ban will start.

As stated this would of been resolved last week had a bug report been opened as it would of been picked up by a developer. Please make sure to use the issue tracker for all bugs regardless of how small or large they are. That is where all the devs monitor issues.