On a CentOS 6.7 system that's been running fail2ban for a long time, we recently started seeing this: ct 28 19:00:59 <servername> fail2ban.action[17561]: ERROR iptables -w -D INPUT -p tcp --dport ssh -j f2b-SSH#012iptables -w -F f2b-SSH#012iptables -w -X f2b-SSH -- stderr: "iptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\n"
My manager thinks it might have been due to the recent update. I, however, am extremely confused, as in neither in the manpage, nore fail2ban --help, do I find *ANY* reference to a -w flag.
Anyone have a clue here?
mark
This should probably be a bug report for the fail2ban EPEL maintainer, the problem was introduced in version 0.9.3
From the file /etc/fail2ban/action.d/iptables-common.conf
... # Option: lockingopt # Notes.: Option was introduced to iptables to prevent multiple instances from # running concurrently and causing irratic behavior. -w was introduced # in iptables 1.4.20, so might be absent on older systems # See https://github.com/fail2ban/fail2ban/issues/1122 # Values: STRING lockingopt = -w ...
Now, CentOS 6.7 has iptables 1.4.7 and the "wait" option does not seem to have been backported by RedHat, so the EPEL package for EL6 should probably not have this as the default.
My workaround was to create a file /etc/fail2ban/action.d/iptables-common.local that contains ... [Init] lockingopt = ...
-Thomas
________________________________________ From: centos-bounces@centos.org centos-bounces@centos.org on behalf of m.roth@5-cent.us m.roth@5-cent.us Sent: Thursday, October 29, 2015 7:51 AM To: CentOS Subject: [CentOS] Semi-OT: fail2ban issue
On a CentOS 6.7 system that's been running fail2ban for a long time, we recently started seeing this: ct 28 19:00:59 <servername> fail2ban.action[17561]: ERROR iptables -w -D INPUT -p tcp --dport ssh -j f2b-SSH#012iptables -w -F f2b-SSH#012iptables -w -X f2b-SSH -- stderr: "iptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\niptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for more information.\n"
My manager thinks it might have been due to the recent update. I, however, am extremely confused, as in neither in the manpage, nore fail2ban --help, do I find *ANY* reference to a -w flag.
Anyone have a clue here?
mark
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
In article 1446132814771.22431@slac.stanford.edu, Eriksson, Thomas thomas.eriksson@slac.stanford.edu wrote:
This should probably be a bug report for the fail2ban EPEL maintainer, the problem was introduced in version 0.9.3
From the file /etc/fail2ban/action.d/iptables-common.conf
... # Option: lockingopt # Notes.: Option was introduced to iptables to prevent multiple instances from # running concurrently and causing irratic behavior. -w was introduced # in iptables 1.4.20, so might be absent on older systems # See https://github.com/fail2ban/fail2ban/issues/1122 # Values: STRING lockingopt = -w ...
Now, CentOS 6.7 has iptables 1.4.7 and the "wait" option does not seem to have been backported by RedHat, so the EPEL package for EL6 should probably not have this as the default.
My workaround was to create a file /etc/fail2ban/action.d/iptables-common.local that contains ... [Init] lockingopt = ...
Looks like it has been fixed in the update fail2ban-0.9.3-1.el6.1
Cheers Tony
Tony Mountifield wrote:
In article 1446132814771.22431@slac.stanford.edu, Eriksson, Thomas thomas.eriksson@slac.stanford.edu wrote:
This should probably be a bug report for the fail2ban EPEL maintainer, the problem was introduced in version 0.9.3
From the file /etc/fail2ban/action.d/iptables-common.conf
... # Option: lockingopt # Notes.: Option was introduced to iptables to prevent multiple instances from # running concurrently and causing irratic behavior. -w was introduced # in iptables 1.4.20, so might be absent on older systems # See https://github.com/fail2ban/fail2ban/issues/1122 # Values: STRING lockingopt = -w ...
Now, CentOS 6.7 has iptables 1.4.7 and the "wait" option does not seem to have been backported by RedHat, so the EPEL package for EL6 should probably not have this as the default.
My workaround was to create a file /etc/fail2ban/action.d/iptables-common.local that contains ... [Init] lockingopt = ...
Looks like it has been fixed in the update fail2ban-0.9.3-1.el6.1
Thanks to Thomas, and I created the .local file. Thanks to Tony, and I just updated fail2ban, checked iptables-common.conf, and then rm'd the .local file.
mark
-
Eriksson, Thomas -
m.roth＠5-cent.us -
tony＠softins.co.uk