Bug 238320 - Update to 0.8 release series (patches attached)
Update to 0.8 release series (patches attached)
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: fail2ban (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
:
Depends On: 230191
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-29 06:22 EDT by Jonathan Underwood
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.8.0-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-03 04:07:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Updated spec file (2.09 KB, text/plain)
2007-04-29 06:23 EDT, Jonathan Underwood
no flags Details
Fix up init file (1.29 KB, patch)
2007-04-29 06:26 EDT, Jonathan Underwood
no flags Details | Diff
Set default jails sensibly (417 bytes, patch)
2007-04-29 06:27 EDT, Jonathan Underwood
no flags Details | Diff

  None (edit)
Description Jonathan Underwood 2007-04-29 06:22:57 EDT
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..
Comment 1 Jonathan Underwood 2007-04-29 06:23:53 EDT
Created attachment 153729 [details]
Updated spec file

Spec file for 0.7.9, leading to 0.8
Comment 2 Jonathan Underwood 2007-04-29 06:26:37 EDT
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.
Comment 3 Jonathan Underwood 2007-04-29 06:27:52 EDT
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.
Comment 4 Jonathan Underwood 2007-04-29 06:28:56 EDT
Also, please note that this version of fail2ban requires python >=2.4, whereas
the previous version worked with python 2.3.
Comment 5 Jonathan Underwood 2007-04-29 06:35:19 EDT
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?
Comment 6 Jonathan Underwood 2007-05-07 12:44:54 EDT
0.8.0 has now been released, and incoorporates the fix to the init file,
according to the CHANGELOG. 
Comment 7 Axel Thimm 2007-05-19 08:01:30 EDT
(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.
Comment 8 Jonathan Underwood 2007-05-21 06:56:57 EDT
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.

Comment 9 Axel Thimm 2007-05-21 19:09:31 EDT
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.
Comment 10 Jonathan Underwood 2007-05-22 05:26:07 EDT
(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 :)
Comment 11 Jonathan Underwood 2007-05-22 10:12:23 EDT
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.
Comment 12 Axel Thimm 2007-05-22 10:55:44 EDT
Argh, yes this went out too soon. I'll check with fedora-maintainers about the
announcement.
Comment 13 Jonathan Underwood 2007-05-22 13:25:10 EDT
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.
Comment 14 Axel Thimm 2007-05-22 13:50:46 EDT
(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
Comment 15 Jonathan Underwood 2007-05-22 14:00:05 EDT
(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. :)
Comment 16 Axel Thimm 2007-06-03 04:07:26 EDT
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 ;)
Comment 17 Jonathan Underwood 2007-06-04 05:59:26 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.