On Monday 12 January 2015 08:51:54 Eric Dumazet wrote: > On Mon, 2015-01-12 at 17:39 +0100, Patrick Schaaf wrote: > > > > Not to comment on the ifalias thing, which I think is unneccessary, > > too, but matching on interface names instead of only ifindex, is > > definitely needed, so that one can establish a full ruleset before > > interfaces even exist. That's good practise at boottime, but also > > needed for dynamic interface creation during runtime. > > Please do not send html messages : Your reply did not reach the lists.
Sigh. Sorry... > Then, all you mention could have been solved by proper userspace > support. > > Every time you add an interface or change device name, you could change > firewalls rules if needed. Nothing shocking here. That is totally impractical, IMO. Interfaces come and go through many different actions. There's the admin downing and upping stuff like bridges or bonds. There's stuff like libvirt / KVM / qemu creating and destroying interfaces. In all these cases, in my practise, I give the interfaces useful names to that I can prefix-match them in iptables rules. Dynamically modifying the ruleset for each such creation and destruction, would be a huge burden. The base ruleset would need suitable "hooks" where these rules were inserted (ordering matters!). The addition would hardly be atomic (with traditional iptables, unless done by generating a whole new ruleset and restoring). The programs (e.g. libvirt) would need to be able to call out to these specially crafted rule generator scripts. The admin would need to add them as pre/post actions to their static (manual) interface configuration. Loading and looking at the ruleset before bringing up the interface would be impossible. Note that I do fully agree that it's sad that iptables rules waste all that memory for each and every rule! I remember musing about improving that in talks with Harald Welte back in the 90ies. A simple match would be perfectly fine for me. Only having ifindex support, isn't. best regards Patrick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
