Bug 1317240 - RFE: add firewall.target
RFE: add firewall.target
Status: NEW
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
Blocks: 1317243 1317244 1317246 1266512 1379141
  Show dependency treegraph
Reported: 2016-03-13 05:46 EDT by Jonathan Underwood
Modified: 2018-03-14 17:10 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Underwood 2016-03-13 05:46:15 EDT
Description of problem:

In order to solve various issues with restarting the firewall and dependent services such as fail2ban with correct ordering, and also to allow for different firewall implementations (firewalld, iptables, shorewall...), it was proposed on the systemd-devel list[1] to have a firewall.target file with contents:

# /usr/lib/systemd/system/firewall.target


[1] https://lists.freedesktop.org/archives/systemd-devel/2016-March/036021.html

Could this target be added? I deally we'd add it to F24 and F25, but I realize F24 might be too far along.
Comment 1 Marcos Mello 2016-03-13 06:42:03 EDT

If fixed, firewall.target will not be required.
Comment 2 Jonathan Underwood 2016-03-13 06:56:12 EDT
(In reply to Marcos Mello from comment #1)
> https://github.com/systemd/systemd/issues/2830
> If fixed, firewall.target will not be required.

Well, if that issue is "fixed", I think firewall.target still has utility as an integration point for firewall and related services. 

But, I also think that issue is unlikely to be "fixed", as it seems, to me, that Conflicts and PartOf are be behaving as designed in that example. But I am not a systemd developer, so what do I know :)
Comment 3 Zbigniew Jędrzejewski-Szmek 2016-03-13 18:26:30 EDT
Can you explain what problem you are trying to solve and why network-pre.target is not sufficient?
Comment 4 Jonathan Underwood 2016-03-13 18:32:30 EDT
The problem we're trying to solve is detailed in BZ #1266512, which blocks this bug. Further discussion is in the link given in Comment #1.

In summary: we need fail2ban to be restarted if the firewall service is restarted for some reason - fail2ban works by asking the firewall manager to insert iptables rules to block hosts. If the firewall managing service is restarted, the rules that were added for fail2ban are lost. 

The desire to restart fail2ban when the firewall is restarted would be simple if there was only a single firewall manager. But, life is complicated by the fact that the firewall service could be provided by firewalld, or the iptables service, or shorewall, or some other firewall managing service.

network-pre.target is irrelevant to this purpose.
Comment 5 Jonathan Underwood 2016-10-01 16:25:39 EDT
Any thoughts?
Comment 6 Jonathan Underwood 2016-10-02 08:09:00 EDT
Note also this followup message:

Comment 7 Orion Poplawski 2016-10-03 17:16:46 EDT
Something similar was discussed here: https://bugs.freedesktop.org/show_bug.cgi?id=80169

Seems like we got close to a firewall.target before it got dropped.

Still an issue with fail2ban, see bug #1379141

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