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 [Unit] Description=Firewall StopWhenUnneeded=yes [Install] WantedBy=basic.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.
https://github.com/systemd/systemd/issues/2830 If fixed, firewall.target will not be required.
(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 :)
Can you explain what problem you are trying to solve and why network-pre.target is not sufficient?
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.
Any thoughts?
Note also this followup message: https://lists.freedesktop.org/archives/systemd-devel/2016-March/036022.html
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
Can we get an update on this?
I'm not seeing anything new to the matter ( as in role based targets like database,firewall,web etc not being frowned upon ) + Looking at Fail2ban, it should be using the type unit provided by nftables at this point, not pulling in "firewalld" I file bug for that...
Hmm, can somebody who knows what this is about submit a PR upstream at https://github.com/systemd/systemd? Actual code changes would be very small, this problem is mostly with documenting why this is needed and how to use it.
Before someone make PR's upstream ( against issue 2830? ) then it would be worth noting if upstreams views on introducing role based targets ( database, web server, directory server, firewall etc ) have changed? Introducing role based targets in Fedora ( and elsewhere since this would be implemented upstream presumably ) makes this a system-wide change in Fedora and presumably other distributions as well and requires changes to the packaging guidelines for those role based targets and a scope that will cover all components listening to ports ( component depends on firewall.target which either pulls in iptables or nftables )
I don't think it makes sense to keep this bug open here. As I said above: > can somebody who knows what this is about submit a PR upstream at https://github.com/systemd/systemd?