Description of problem: Hi Axel. Upstream is gearing up for a new release (0.8). There is a release candidate available (0.79), and I've fixed up the spec file and patches for this release. It would be nice to push 0.8 for FC6 and greater once 0.8 is released, I think. Some notes and thoughts: 1) I've removed the Requires for shorewall and tcp wrappers. There's no need to install shorewall as the package can work with the iptables firewall that ships with fedora. Similarly tcpwrappers is only needed if the user wants to mimic denyhosts behaviour with fail2ban (disabled by default), and is in any case pulled in with sshd. 2) I haven't included Requires: gamin in this package. The new fail2ban can use gamin to detect log file changes, rather than polling. The default configuration automatically decides whether to use gamin or poll, depending on whether gamin is installed. I can also see an argument for Requires: gamin, as using gamin is probably preferable over polling. 3) I've made some fixes to the shipped init file - I'll send these upstream too 4) There's still a problem with SElinux (BZ #230191), which can slow startup. Messages such as these: audit(1177841042.908:37): avc: denied { read write } for pid=11451 comm="iptables" name="[39714]" dev=sockfs ino=39714 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:system_r:initrc_t:s0 tclass=unix_stream_socket audit(1177841042.908:38): avc: denied { read write } for pid=11451 comm="iptables" name="[39933]" dev=sockfs ino=39933 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:system_r:initrc_t:s0 tclass=unix_stream_socket audit(1177841042.908:39): avc: denied { append } for pid=11451 comm="iptables" name="fail2ban.log" dev=sda2 ino=523206 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:object_r:var_log_t:s0 tclass=file audit(1177841042.910:40): avc: denied { read write } for pid=11452 comm="iptables" name="[39714]" dev=sockfs ino=39714 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:system_r:initrc_t:s0 tclass=unix_stream_socket audit(1177841042.911:41): avc: denied { read write } for pid=11452 comm="iptables" name="[39933]" dev=sockfs ino=39933 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:system_r:initrc_t:s0 tclass=unix_stream_socket audit(1177841042.911:42): avc: denied { append } for pid=11452 comm="iptables" name="fail2ban.log" dev=sda2 ino=523206 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:object_r:var_log_t:s0 tclass=file audit(1177841042.912:43): avc: denied { read write } for pid=11450 comm="iptables" name="[39714]" dev=sockfs ino=39714 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:system_r:initrc_t:s0 tclass=unix_stream_socket audit(1177841042.912:44): avc: denied { read write } for pid=11450 comm="iptables" name="[39933]" dev=sockfs ino=39933 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:system_r:initrc_t:s0 tclass=unix_stream_socket audit(1177841042.914:45): avc: denied { append } for pid=11450 comm="iptables" name="fail2ban.log" dev=sda2 ino=523206 scontext=user_u:system_r:iptables_t:s0 tcontext=user_u:object_r:var_log_t:s0 tclass=file Looking at http://www.nsa.gov/selinux/list-archive/0703/19806.cfm it seems Daniel Walsh is addressing this, but it's not yet in the FC6 policy. Files to follow..
Created attachment 153729 [details] Updated spec file Spec file for 0.7.9, leading to 0.8
Created attachment 153730 [details] Fix up init file This patch fixes the following problem with the init file: the shipped init file always reports [ OK ] when stopping the fail2ban-server process, even if it wasn't running. This patch also removes the socket file before starting the fail2ban-server - this would otherwise stop fail2ban starting when a machine has not shutdown cleanly.
Created attachment 153731 [details] Set default jails sensibly This modifies the default jails to activate a sshd iptables jail to be enabled by default, and also points fail2ban at /var/log/secure rather than /var/log/sshd.log.
Also, please note that this version of fail2ban requires python >=2.4, whereas the previous version worked with python 2.3.
One other thing to bear in mind: this version is quite a substantial rewrite compared to 0.6. Significantly, the configuration files from version 0.6 do not work with 0.8, and so updating from 0.6 would not preserve configuration - I'm not sure how that is best handled. I haven't made any efforts to do so, but perhaps you have an idea how to deal with that?
0.8.0 has now been released, and incoorporates the fix to the init file, according to the CHANGELOG.
(In reply to comment #5) > One other thing to bear in mind: this version is quite a substantial rewrite > compared to 0.6. Significantly, the configuration files from version 0.6 do not > work with 0.8, and so updating from 0.6 would not preserve configuration - I'm > not sure how that is best handled. I haven't made any efforts to do so, but > perhaps you have an idea how to deal with that? That's ugly. I don't know how to deal with that, I'll contact upstream.
Yes, I can't see an easy fix. I suppose what we're trying to avoid is Joe having a box with fail2ban 0.6 installed, running a yum update which installs 0.8, and the daemon stop working as Joe doesn't know he needs to reconfigure. Only two options I can see for that: 1) Introduce 0.8 at the beginning of a release (i.e F8 now). 2) Have a second package called fail2ban0.8.
At the beginning of a release would still break all people upgrading, so we only safe some pain. The cleanest way would be indeed to introduce a comaptibility package, have that alone in the repo for some time, so that one can be rather sure that all fail2ban 0.6 users are using "fail2ban-deprecated", and the introduce fail2ban-0.8. But that sounds perhaps too complicated. How about the following: fail2ban 0.8 checks in %pre whether fail2ban 0.6 is installed and bails out with a comment that 0.6 and 0.8 are not config-file compatible, so the user is asked to manually uninstall the old fail2ban. That won't get standing ovations either, but maybe it's the lesser evil. Or simply package as is and make an announcement, e.g. a heads-up two weeks before pushing the package onto the production repos.
(In reply to comment #9) > But that sounds perhaps too complicated. How about the following: fail2ban 0.8 > checks in %pre whether fail2ban 0.6 is installed and bails out with a comment > that 0.6 and 0.8 are not config-file compatible, so the user is asked to > manually uninstall the old fail2ban. Yes, I quite like this idea. Of course, it will get grumbles :) > > That won't get standing ovations either, but maybe it's the lesser evil. > > Or simply package as is and make an announcement, e.g. a heads-up two weeks > before pushing the package onto the production repos. I like this idea too. What about doing both of these things? Seems like the best of a lot of bad options to me :)
Um, Axel, on my work FC-6 box I just did a yum update which pulled in an update to fail2ban 0.8 from extras.. I can't help thinking this wasn't your intention? Since the cat is out of the bag, perhaps it would be good to sent an announcement somehow about the config-incompatible update.
Argh, yes this went out too soon. I'll check with fedora-maintainers about the announcement.
Hi Axel, Looking at the spec file you used, you didn't correct the following things (please see spec file in comment #1) 1. You have unecessary Requires: shorewall and tcpwrappers - these should be removed. 2. You're still patching the init file which is unecessary - as I mentioned this was fixed upstream between 0.7.9 and 0.8.0, and so this should be removed.
(In reply to comment #13) > 1. You have unecessary Requires: shorewall and tcpwrappers - these should be > removed. I hesitated to remove too much parts different than 0.6.x. > 2. You're still patching the init file which is unecessary - as I mentioned this > was fixed upstream between 0.7.9 and 0.8.0, and so this should be removed. But not the following, or is it? -# chkconfig: 345 92 08 +# chkconfig: - 92 08
(In reply to comment #14) > (In reply to comment #13) > > 1. You have unecessary Requires: shorewall and tcpwrappers - these should be > > removed. > > I hesitated to remove too much parts different than 0.6.x. > Understood. But the shorewall dependency really is totally unecessary and would leave me thinking "oh, crap, to use fail2ban I need to configure shorewall" if I was installing fail2ban for the first time (in fact, I went through that thought process with 0.6). > > 2. You're still patching the init file which is unecessary - as I mentioned this > > was fixed upstream between 0.7.9 and 0.8.0, and so this should be removed. > > But not the following, or is it? > -# chkconfig: 345 92 08 > +# chkconfig: - 92 08 > Oh, true, sorry, hadn't spotted that. :)
OK, so somehow this slipped out too soon, and there was no announcement either. Still noone complained, so this means that either noone uses this package, or that noone configures it ;)
Hi Axel, Haven't had chance to check you updates-testing package yet, but - have you removed the shorewall and tcpwrappers Requires? I really think they're unecessary and confusing.