Bug 985567

Summary: RFE: backport systemd journal support (or update to 0.9.0), make journal default datasource
Product: [Fedora] Fedora Reporter: Matthew Miller <mattdm>
Component: fail2banAssignee: Orion Poplawski <orion>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: axel.thimm, daniel, herrold, jonathan.underwood, orion, sauchter, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://github.com/fail2ban/fail2ban/issues/318
Whiteboard:
Fixed In Version: 0.9-3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-27 15:26:44 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:

Description Matthew Miller 2013-07-17 19:00:39 UTC
See upstream patch https://github.com/fail2ban/fail2ban/pull/82 

In Fedora 19 and on, the systemd journal is always there. However, /var/log/messages could be configured differently or even removed. No package owns /var/log/messages, so making it a dependency is hard. Instead, let's configure our fail2ban to use the systemd journal directly.

Comment 1 Orion Poplawski 2013-08-09 03:45:17 UTC
I'm building fail2ban-0.9-0.1.gitd529151.fc20 now.  I've not yet made the journal the default - I'd like to get more testing on that first.  I have added a requires on systemd-python to bring in journal support though.

Comment 2 Matthew Miller 2013-08-09 16:12:19 UTC
I'm okay with more testing. Maybe turn it on in Rawhide after the branch?

Comment 3 Orion Poplawski 2013-08-09 16:47:02 UTC
Just depends on when things are ready.  I can't get systemd backend to work at the moment.  See the URL/upstream bug.

Comment 4 Zbigniew Jędrzejewski-Szmek 2013-10-11 12:47:25 UTC
So, what's the status here?

Comment 5 Orion Poplawski 2013-10-12 02:39:59 UTC
I've packaged a git snapshot of the upcoming 0.9 release in F20+ that can use the systemd back end, and that seems to work.  I have not done extensive testing though so feedback is welcome.  0.9 hopefully will released not too far from now.  I don't want to make systemd the default backend with out more testing.

Comment 6 Daniel Black 2014-03-15 01:41:01 UTC
apologies for the massive 0.9.0 delay.

We've finally done a upstream release. Up to you now Orion

Comment 7 Orion Poplawski 2014-03-18 00:37:26 UTC
I'm hung up on some test failures, but will get 0.9 built soon.  I'd like to get some testing on that, then push 0.9 to F20, then perhaps enable systemd by default for rawhide.  I'm not sure how much I want to deviate from upstream in this regard though.

Comment 8 Orion Poplawski 2014-03-18 00:50:19 UTC
Built without tests for now.

Comment 9 Daniel Black 2014-03-18 01:08:22 UTC
Sorry about the test failures.

> how much I want to deviate from upstream in this regard though.

Given there's non-linux systems using fail2ban we'll probably not do it by default. You could do a /etc/fail2ban/jail.d/00-systemd.conf with the following however.

[sshd]
backend=systemd

[otherjournaljail]
backend=systemd

Comment 10 Orion Poplawski 2014-03-19 21:30:57 UTC
We're considering spliting fail2ban into many sub-packages.  One would be a fail2ban-systemd package with:

/etc/fail2ban/jail.d/00-systemd.conf:
[DEFAULT]
backend=systemd

This would be installed by default, but could be removed.

Daniel - Is it important for the file to be 00-systemd.conf for ordering purposes, or could it be fedora-systemd.conf?

Comment 11 Daniel Black 2014-03-20 00:01:06 UTC
> Daniel - Is it important for the file to be 00-systemd.conf for ordering purposes, or could it be fedora-systemd.conf?

The files in .d/* directory are parsed in order by filename. fedora-systemd.conf will work just as well. We've pretty much documented that .conf files are for packagers/distro maintainers and users can overide with .local files if desired.

> We're considering spliting fail2ban into many sub-packages.

are you considering a filter and action sub-packages? Considering how independent these are from the core that maybe something we can support upstream too.