I order to use miniupnpd with shorewall, the init script of iptables needs to provide firewall. "Please create a new bug about that, and mark it as a blocker for this bug. Once that has been fixed, I'll update the init script for miniupnpd." Reproducible: Always
I'm not understanding what the request is here. The init script for iptables loads any rules you have previously saved. You setup your iptables rules how you like then you run /etc/init.d/iptables save. Then when you reboot for example, the script will load those saved rules.
nvm. I see where you're trying to go now. You want /etc/init.d/iptables to have "provide firewall" so that things can depend on firewall. The issue I have is that its not that simple. You need something for IPv6 as well and ebtables since all those parts constitute a full firewall.
whether we have iptables "provide firewall", it's still in the end the user's problem to make sure they have all the services set up in order to provide the firewall right ? i don't think adding "provide firewall" here is harmful.
I agree with Cardoe here, and suggest that we ship a separate init script that does: depend() { want iptables ip6tables ebtables nftables provide firewall } Or even: /etc/conf.d/firewall:rc_want="iptables ip6tables ebtables nftables" /etc/init.d/firewall:#!/sbin/runscript (yes, just the ONE line in init.d/firewall). Then users with other tools to manage iptables can just tweak the rc_want list.
(In reply to Robin Johnson from comment #4) > > Or even: > /etc/conf.d/firewall:rc_want="iptables ip6tables ebtables nftables" > /etc/init.d/firewall:#!/sbin/runscript > (yes, just the ONE line in init.d/firewall). > > Then users with other tools to manage iptables can just tweak the rc_want > list. I like this option. I'm aware of another in tree "firewall" provider that would likely want to work with some of these knobs called net-firewall/firewalld.
(In reply to Robin Johnson from comment #4) if you want to go the stub firewall route, that'd be a file for openrc to ship then, not iptables
williamh: Any opinion which of openrc or netifrc should ship that stub firewall init? If you prefer openrc, please put it into the next release.
(In reply to Robin Johnson from comment #7) > williamh: > Any opinion which of openrc or netifrc should ship that stub firewall init? > If you prefer openrc, please put it into the next release. I don't have a problem with the idea of a stub script in OpenRC, but I am concerned about the design of this one. (In reply to Robin Johnson from comment #4) > I agree with Cardoe here, and suggest that we ship a separate init script > that does: > > depend() { > want iptables ip6tables ebtables nftables > provide firewall > } > > Or even: > /etc/conf.d/firewall:rc_want="iptables ip6tables ebtables nftables" > /etc/init.d/firewall:#!/sbin/runscript > (yes, just the ONE line in init.d/firewall). > > Then users with other tools to manage iptables can just tweak the rc_want > list. This means that all four of these tools will be run if they are installed, regardless of whether they are in a runlevel. Also, it means that the firewall service will succeed regardless of whether any of these tools succeed or not. Is that the intent?
> (In reply to Robin Johnson from comment #4) > > I agree with Cardoe here, and suggest that we ship a separate init script > > that does: > > > > depend() { > > want iptables ip6tables ebtables nftables > > provide firewall > > } > > > > Or even: > > /etc/conf.d/firewall:rc_want="iptables ip6tables ebtables nftables" > > /etc/init.d/firewall:#!/sbin/runscript > > (yes, just the ONE line in init.d/firewall). > > > > Then users with other tools to manage iptables can just tweak the rc_want > > list. > > This means that all four of these tools will be run if they are installed, > regardless of whether they are in a runlevel. Also, it means that the > firewall service will succeed regardless of whether any of these tools > succeed or not. Is that the intent? Ok, that's somewhat problematic as I'm wondering if part of it should be "(iptables OR ip6tables) XOR (nftables)", as well as should firewall be considered started if one of them legitimately failed (vs simply failing because you didn't create any rules yet).
(In reply to Robin Johnson from comment #9) > > (In reply to Robin Johnson from comment #4) > > > I agree with Cardoe here, and suggest that we ship a separate init script > > > that does: > > > > > > depend() { > > > want iptables ip6tables ebtables nftables > > > provide firewall > > > } > > > > > > Or even: > > > /etc/conf.d/firewall:rc_want="iptables ip6tables ebtables nftables" > > > /etc/init.d/firewall:#!/sbin/runscript > > > (yes, just the ONE line in init.d/firewall). > > > > > > Then users with other tools to manage iptables can just tweak the rc_want > > > list. > > > > This means that all four of these tools will be run if they are installed, > > regardless of whether they are in a runlevel. Also, it means that the > > firewall service will succeed regardless of whether any of these tools > > succeed or not. Is that the intent? > Ok, that's somewhat problematic as I'm wondering if part of it should be > "(iptables OR ip6tables) XOR (nftables)", as well as should firewall be > considered started if one of them legitimately failed (vs simply failing > because you didn't create any rules yet). It seems like a virtual firewall service does most of this. If iptables, ip6tables and nftables all provide firewall, users can select the ones they want to use by adding them to the appropriate runlevel. Also, they can remove providers from the virtual service by doing something like this in /etc/conf.d/{iptables,ip6tables,nftables}: rc_provide="!firewall"
Using "provide firewall" in your service scripts would also mean users could write custom service scripts that provide the firewall service.
Where are we on this?
Any news on this?
ping
So I guess, no news? ;-)
Not planned.
