Hey guys,
I had some issues with fail2ban when running more than 1 jail.
So I wrote a patch or even workaround to get all chains into iptables.
It might be good enough to apply it into the next release but thats up to you... maybe you guys are able to find a better solution since I didn't spent much time into it.
action.py.patch
Hi idl0r, thanks for your patch - I nearly got crazy with this bug ...
This patch unfortunately breaks commands with multiline string arguments in them (e.g. sending an email notifications).
Original problem is with concurrent execution of iptables commands by separate threads (there is 1 thread per jail in fail2ban) upon jail initiation. Possible solution is to sleep some random amount of time before executing the command. It could be accomplished with adding smth like
sleep ${RANDOM:0:1}.${RANDOM: -1:1}
to the beginning of actionstart/actionstop if you use bash for your shell
For more details see http://bugs.debian.org/554162
The fix with adding random sleeps is a workaround, but not the right long term fix. It's a design flaw to have the action{start,stop} executing in parallel IMO. Either they should be serialized, or a locking mechanism put in place to ensure that multiline commands are treated atomicly.
View and moderate all "patches Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Patches"
could you or someone please be a bit more specific i am experiencing this bug but cannot get it fixed by patching (indeed because of broken lines) and i do not understand how next patch is applied, because i don't know python
"Possible solution is to sleep some random amount of time before
executing the command. It could be accomplished with adding smth like
sleep ${RANDOM:0:1}.${RANDOM: -1:1}
to the beginning of actionstart/actionstop if you use bash for your shell"
View and moderate all "patches Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Patches"
I came up with a slightly different approach to fixing this bug. I changed executeCmd() to a classmethod instead of a staticmethod. I also created a lock as a class variable, which prevents two calls to os.system from running in parallel from any instance of the Action class. It is perhaps not the prettiest solution, but it is a very small change and I believe it addresses the root of the problem without causing any side effects.
I just modified the file in place on my system, but I can create and post a patch if anyone is interested.