Summary: | fail2ban is not compatible with python 2.6. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stefan Jensen <sjensen> |
Component: | fail2ban | Assignee: | Axel Thimm <axel.thimm> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 11 | CC: | 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: |
Description
Stefan Jensen
2009-06-25 21:17:48 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 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. 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 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 ... *** Bug 517266 has been marked as a duplicate of this bug. *** 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 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 :) 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 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. 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 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 (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! 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 (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 (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). 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 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 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. 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. |