Bug 508171

Summary: fail2ban is not compatible with python 2.6.
Product: [Fedora] Fedora Reporter: Stefan Jensen <sjensen>
Component: fail2banAssignee: Axel Thimm <axel.thimm>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 11CC: ADent123, eddie, neleo
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.8.4-23.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-04 04:03:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Stefan Jensen 2009-06-25 21:17:48 UTC
Description of problem:

startup and shutdown showed up errors in logs.

Version-Release number of selected component (if applicable):

fail2ban-0.8.3-19.fc11.noarch
iptables-1.4.3.1-1.fc11.x86_64
iptables-ipv6-1.4.3.1-1.fc11.x86_64

How reproducible:

Always

Steps to Reproduce:

1. install fail2ban
2. start/stop fail2ban
3. tail -f /var/log/fail2ban.log
  
Actual results:

on start:

==> fail2ban.log <==
2009-06-25 23:06:06,265 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.3
2009-06-25 23:06:06,266 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,267 fail2ban.jail   : INFO   Creating new jail 'ssh-iptables'
2009-06-25 23:06:06,269 fail2ban.jail   : INFO   Jail 'ssh-iptables' uses Gamin
2009-06-25 23:06:06,290 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,291 fail2ban.filter : INFO   Added logfile = /var/log/secure
2009-06-25 23:06:06,292 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,292 fail2ban.filter : INFO   Set maxRetry = 5
2009-06-25 23:06:06,293 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,294 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,295 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,295 fail2ban.filter : INFO   Set findtime = 600
2009-06-25 23:06:06,296 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,296 fail2ban.actions: INFO   Set banTime = 86400
2009-06-25 23:06:06,297 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,302 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,308 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,313 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,320 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,327 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,335 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,344 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,352 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,353 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,353 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,354 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,354 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,355 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,356 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,356 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,357 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,357 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,358 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,359 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,359 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,360 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,360 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,361 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,361 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,362 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,362 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:06,363 fail2ban.jail   : INFO   Jail 'ssh-iptables' started
2009-06-25 23:06:06,376 fail2ban.server : ERROR  Unexpected communication error
2009-06-25 23:06:07,401 fail2ban.filter : WARNING Unable to find a corresponding IP address for 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
2009-06-25 23:06:07,431 fail2ban.filter : WARNING Unable to find a corresponding IP address for 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
2009-06-25 23:06:07,809 fail2ban.filter : WARNING Unable to find a corresponding IP address for 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
2009-06-25 23:06:07,812 fail2ban.filter : WARNING Unable to find a corresponding IP address for 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
2009-06-25 23:06:07,813 fail2ban.filter : WARNING Unable to find a corresponding IP address for 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX

on stop:

2009-06-25 23:06:14,895 fail2ban.jail   : INFO   Jail 'ssh-iptables' stopped
Exiting Fail2ban
cannot release un-aquired lock
Traceback (most recent call last):
  File "/usr/bin/fail2ban-server", line 126, in start
    self.__server.start(self.__conf["socket"], self.__conf["force"])
  File "/usr/share/fail2ban/server/server.py", line 98, in start
    logSys.info("Exiting Fail2ban")
  File "/usr/lib64/python2.6/logging/__init__.py", line 1033, in info
    self._log(INFO, msg, args, **kwargs)
  File "/usr/lib64/python2.6/logging/__init__.py", line 1141, in _log
    self.handle(record)
  File "/usr/lib64/python2.6/logging/__init__.py", line 1151, in handle
    self.callHandlers(record)
  File "/usr/lib64/python2.6/logging/__init__.py", line 1188, in callHandlers
    hdlr.handle(record)
  File "/usr/lib64/python2.6/logging/__init__.py", line 664, in handle
    self.release()
  File "/usr/lib64/python2.6/logging/__init__.py", line 618, in release
    self.lock.release()
  File "/usr/lib64/python2.6/threading.py", line 136, in release
    raise RuntimeError("cannot release un-aquired lock")
RuntimeError: cannot release un-aquired lock

Expected results:

no erros in log. Maybe ignore ipv6 addresses and a hint, that ipv6 is currently not supported.

Additional info:

none.

Comment 1 Leo 2009-07-16 10:08:05 UTC
This seems to be a problem with Python 2.6. On Fedora 10 with Python 2.5 everything is working fine. Even other distributions (SuSE, Ubuntu) have the same problem:

https://bugs.launchpad.net/ubuntu/+source/fail2ban/+bug/372304

There is an bug entry on the fail2ban bug tracker, but this bug is not assigned and still open since april 2009!

http://sourceforge.net/tracker/index.php?func=detail&atid=689044&aid=2774318&group_id=121032

Seems that no one wants to fix it :-(

Regards,
Leo

Comment 2 Axel Thimm 2009-07-16 11:46:04 UTC
Thanks for the pointers!

I linked our bug to launchpad so there is some cross-distro notification in case someone finds a fix.

A workaround mentioned is to "simply" use python 2.5, but we do not have 2.5 in a compatibility package.

Comment 3 Arthur Dent 2009-08-20 12:50:45 UTC
The original author, Cyril Jaquier, of fail2ban claims he is still interested in working on f2b but is busy with other projects.

There is another developer willing to take on the reins of f2b or to fork it.

It might be worth discussing the matter directly with either of them.

Here is some correspondence to that effect:
http://sourceforge.net/mailarchive/forum.php?thread_name=4A83348D.6090305%40buanzo.com.ar&forum_name=fail2ban-users

Comment 4 Leo 2009-08-27 14:12:53 UTC
Thanks for the link, Arthur!

I have contacted Arturo Busleiman (a.k.a Buanzo), who has recently offered his assistance in the fail2ban-users mailing list, and asked him to fix the bug. He answered very quickly:

=== snip ===

I actually wanted to rewrite the whole of it, but make it compatible with fail2ban's rules.d files  ;) 

Problem is, I don't know if I can invest the time on it without any financial benefits. I live in Argentina, am an independent professional, and I have no company or group to back me up at all. And it's quite a difficult time. I try to do more than my best (if you take a look at my blog's archive, you'll notice my involvement in the FLOSS community since 1994....), but sometimes I need to put a foot down and say 'can I use my time, NOW, with this?'. I wished the answer could always be yes.

=== snip ===

Therefore I told him that there is no rewrite necessary. Only a quick fix is needed to keep the project alive. Today he has requested access to the projects sources :-)

http://sourceforge.net/apps/trac/sourceforge/ticket/4334

Perhaps there is a light at the end of the tunnel.

We'll see ...

Comment 5 Axel Thimm 2009-08-27 16:48:14 UTC
*** Bug 517266 has been marked as a duplicate of this bug. ***

Comment 6 Leo 2009-08-31 16:47:28 UTC
Good news!!!

The project is still alive: Arturo Busleiman (a.k.a Buanzo) is now one of the fail2ban developers and Cyril Jaquier is working on fail2ban as well. For further details see

http://sourceforge.net/mailarchive/forum.php?thread_name=4A9A7658.6010200%40buanzo.com.ar&forum_name=fail2ban-users

Buanzo has commited some patches to SVN and I have already tested them on Fedora 11. Seems that all problems are fixed now. There have to be done some more testing (with other distributions) but I hope there will be a new release in the near future ...

If you are interested in testing the newest/unstable version of fail2ban you can use the nightly build from http://www.fail2ban.org/nightly/ (direct link is http://www.fail2ban.org/nightly/fail2ban-FAIL2BAN-0_8.tar.bz2). But you have to wait for the nightly build from 2009-09-01 (or use a SVN snapshot) because some patches have been commited today (i.e. after the current nightly build).

Regards,
Leo

Comment 7 Axel Thimm 2009-08-31 20:12:48 UTC
Thanks, that's great news!

I will push a build very soon to catch the f12 beta, as well as fixing the f11 packages! Any svn cut is better than what we have now :)

Comment 8 Leo 2009-09-01 15:48:58 UTC
I have successfully tested the nightly build [01-Sep-2009 03:01] of fail2ban on

- Fedora 11
- CentOS 5.3
- Debian 5.0 "lenny"
- openSUSE 11.1

(all four systems up-to-date, i.e. with the most recent updates installed)

Everything is working fine with all of them :-)

I have already informed Buanzo and he answered me:

":D I'm glad! We will release a new version ASAP, probably this very week."

At this point I would like to thank Buanzo for his great work!

Leo

Comment 9 Fedora Update System 2009-09-04 04:02:57 UTC
fail2ban-0.8.3-22.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Arthur Dent 2009-09-04 15:34:43 UTC
Thank you Axel,

OK - I am a pretty happy camper at this stage. There is one thing I find a little strange however.

I had a few selinux avcs with the previous version of F2B for which I created a local policy module. Having allowed yum to update F2B this morning I got a slew of new selinux avcs.

The original policy module looked like this:

require {
	type iptables_t;
	type system_mail_t;
	type fail2ban_t;
	class unix_stream_socket { read write };
}

#============= iptables_t ==============
allow iptables_t fail2ban_t:unix_stream_socket { read write };

#============= system_mail_t ==============
allow system_mail_t fail2ban_t:unix_stream_socket { read write };




Using audit2allow these are the additional policies I needed to add after this morning's update:

require {
	type system_mail_t;
	type fail2ban_t;
	type usr_t;
	type syslogd_t;
	type iptables_t;
	class unix_dgram_socket { read write sendto };
	class file read;
}

#============= fail2ban_t ==============
allow fail2ban_t self:unix_dgram_socket write;
allow fail2ban_t syslogd_t:unix_dgram_socket sendto;

#============= iptables_t ==============
allow iptables_t fail2ban_t:unix_dgram_socket { read write };

#============= system_mail_t ==============
allow system_mail_t fail2ban_t:unix_dgram_socket { read write };
allow system_mail_t usr_t:file read;


Combining the two gives me a monster policy that makes me wonder whether I am doing the right thing in allowing all these things.

Why should the new release need so many additional rules?


Thanks for all you work on this....

Mark

Comment 11 Leo 2009-09-08 10:28:35 UTC
Just to keep you informed: the new release of fail2ban is out now!

http://sourceforge.net/mailarchive/message.php?msg_name=4AA55F99.3020405%40fail2ban.org

Regards,
Leo

Comment 12 Axel Thimm 2009-09-09 04:14:15 UTC
(In reply to comment #10)

> OK - I am a pretty happy camper at this stage. There is one thing I find a
> little strange however.
> 
> I had a few selinux avcs with the previous version of F2B [...]

> Combining the two gives me a monster policy that makes me wonder whether I am
> doing the right thing in allowing all these things.
> 
> Why should the new release need so many additional rules?

My selinux foo is quite limited, the only changes come from upstream, there is no (re)packaging done necessitating any of this. f2b is quite selinux agnostic and creates a few issues (actually almost all open f2b bugs are selinux related).

(In reply to comment #11)
> Just to keep you informed: the new release of fail2ban is out now!

Thanks! I'll update the packages!

Comment 13 Arthur Dent 2009-09-09 13:17:35 UTC
OK - Here's the odd thing...

I have (or I should say had) the yum rpm package of F2B installed on my F11 system. This required a slew of selinux local policies to work - and even more after the update.

To do my testing of the bugfixes by Buanzo and Cyril I created a F11 vmware virtual machine because I didn't want to risk tinkering with my production box. I used the tarball that they released and it all worked fine inside the VM. After posting my message above about the selinux problem it occurred to me that I had selinux in the default Enforcing mode in the VM and I had no problems. I certainly did not need to create any local selinux policies.

Now that v.0.8.4 is available I decided to to wait for you to package it but use the tarball instead.

I uninstalled v.0.8.3 with "yum erase fail2ban" and then I removed my local selinux policy (semodule -r myfail2ban). I installed F2B v.0.8.4 from the tarball and, running with the same init.d script, using the same logfile and the same socket, the same configuration files and the same jail definitions, writing to the same syslog and sending alert emails to the same user - I get *NO* selinux avcs! None. Not one...

I don't pretend to understand this (I thought the rpm simply placed the same python scripts in the same places as the tarball install?) but I have to say I won't be returning to the rpm any time soon!

I am interested to hear if anyone else has a similar experience - or is it just my system that's screwy?

Thanks for all the effort that everyone puts into this project. Much appreciated...

Mark

Comment 14 Arthur Dent 2009-09-09 13:36:13 UTC
(In reply to comment #13)

Sorry - fumblefingers and fumblebrain...

> Now that v.0.8.4 is available I decided to to wait for you to package it but
                                          ^^ not
> use the tarball instead.

> I uninstalled v.0.8.3 with "yum erase fail2ban" and then I removed my local
> selinux policy (semodule -r myfail2ban). I installed F2B v.0.8.4 from the
> tarball and, running with the same init.d script, using the same logfile and
> the same socket, the same configuration files and the same jail definitions,
> writing to the same syslog and sending alert emails to the same user - I get
> *NO* selinux avcs! None. Not one...

I should also have made it clear that I am now talking about my production F11 machine - NOT the vmware VM testing enironment.

So - for the avoidance of doubt - I am now running the 0.8.4 version, istalled from the tarball - on my production machine, with no local selinux policies and getting no selinux avcs; whereas on the very same machine using, for the most part, the very same files I previously had a ton of selinux problems...

Mark

Comment 15 Axel Thimm 2009-09-11 09:37:11 UTC
(In reply to comment #13)
> OK - Here's the odd thing...
> 
> I have (or I should say had) the yum rpm package of F2B installed on my F11
> system. This required a slew of selinux local policies to work - and even more
> after the update.
> 
> To do my testing of the bugfixes by Buanzo and Cyril I created a F11 vmware
> virtual machine because I didn't want to risk tinkering with my production box.
> I used the tarball that they released [...]

You are comapring 0.8.3 with the neccessary python 2.6 fixes as given by upstream in a pre-0.8.4 svn cut vs the rela 0.8.4 release. I think this may make a difference, so please check out the latest package that will have 0.8.4 in the version and that is coming soon.

If there are any selinux issues, please compare with the already open bugs and if it's something new/different please open a new bug (e.g. don't add to the python 2.6 bug any more comments, this particular bug has been fixed).

Comment 16 Fedora Update System 2009-09-11 10:57:23 UTC
fail2ban-0.8.4-23.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-23.fc11

Comment 17 Fedora Update System 2009-09-11 10:57:43 UTC
fail2ban-0.8.4-23.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-23.fc10

Comment 18 Fedora Update System 2009-09-15 07:50:04 UTC
fail2ban-0.8.4-23.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2009-09-15 07:56:18 UTC
fail2ban-0.8.4-23.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.