Re: [PATCH 2/3] x_tables: Use also dev->ifalias for interface matching

[Patrick McHardy]

On 12.01, Patrick Schaaf wrote:
> 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.

devgroups seem like the best solution for this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/