Bug 864998

Summary: fail2ban improperly logging to syslog as kern.emerg
Product: [Fedora] Fedora Reporter: Matthew Miller <mattdm>
Component: fail2banAssignee: Axel Thimm <axel.thimm>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: admiller, axel.thimm, jonathan.underwood, jonathon.anderson, maxamillion, orion, redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 845802 Environment:
Last Closed: 2012-12-17 22:23:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 845802    

Description Matthew Miller 2012-10-10 15:16:22 UTC
+++ This bug was initially created as a clone of Bug #845802 +++

Description of problem:

We have fail2ban configured with loglevel = 3, logtarget = SYSLOG; but fail2ban is logging to syslog with kern.emerg priority.

kern.emerg<0>: Aug  1 18:08:44 gate1 ?<28>fail2ban.actions: WARNING [ssh-iptables] Unban 10.228.1.11

Effectively, this means that such messages are logged to all user consoles, due to the default rsyslog config on RHEL6.

*.emerg  *


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

RHEL6.3, fail2ban-0.8.4-28.el6.noarch

How reproducible:

Always.

Steps to Reproduce:
1. Install fail2ban and configure for ssh banning
2. Invoke a ban (or wait for an unban)
  
Actual results:

Message is logged to syslog as an emergency.

Expected results:

Message is logged as info (loglevel 3).

--- Additional comment from redhat-bugzilla.org on 2012-08-15 00:29:23 EDT ---

This appears to have been fixed in fail2ban 0.8.7:

https://github.com/fail2ban/fail2ban/issues/32

--- Additional comment from jonathon.anderson.sa on 2012-08-28 04:33:06 EDT ---

> This appears to have been fixed in fail2ban 0.8.7 

It looks like the latest in EPEL is 0.8.4(-28).  What needs to happen to get this fix backported, or get fail2ban upgraded?

--- Additional comment from admiller on 2012-10-05 11:29:06 EDT ---

I don't maintain this package for "Fedora proper", only EPEL and I would like not to have EPEL be ahead of Fedora, please file a request for the Fedora package to be updated and I will happily follow suit.

Comment 1 Jonathon Anderson 2012-10-13 06:21:15 UTC
> please file a request for the Fedora package

It looks like you've done this at 864998.  Thank-you for following-up.

Comment 2 Jonathon Anderson 2012-10-13 06:22:58 UTC
> It looks like you've done this at 864998.

And now I see I've replied to the wrong bug, with the wrong bug id.

Oh, well.  You guys are doing great.  Thanks.

Comment 3 Orion Poplawski 2012-12-17 22:23:18 UTC
This is a python issue and is fine in Fedora.