From: Patrick McHardy <kaber@trash.net>
To: Patrick Schaaf <netdev@bof.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Richard Weinberger <richard@nod.at>,
davem@davemloft.net, coreteam@netfilter.org,
netfilter-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, bhutchings@solarflare.com,
john.fastabend@gmail.com, herbert@gondor.apana.org.au,
vyasevic@redhat.com, jiri@resnulli.us, vfalico@gmail.com,
therbert@google.com, edumazet@google.com,
yoshfuji@linux-ipv6.org, jmorris@namei.org, kuznet@ms2.inr.ac.ru,
kadlec@blackhole.kfki.hu, pablo@netfilter.org, kay@vrfy.org,
stephen@networkplumber.org
Subject: Re: [PATCH 2/3] x_tables: Use also dev->ifalias for interface matching
Date: Mon, 12 Jan 2015 17:22:57 +0000 [thread overview]
Message-ID: <20150112172257.GG17329@acer.localdomain> (raw)
In-Reply-To: <2868544.UBk2Y85taW@rofl>
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.
next prev parent reply other threads:[~2015-01-12 17:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-11 20:52 [RFC] Make predictable/persistent network interface names more handy Richard Weinberger
2015-01-11 20:52 ` [PATCH 1/3] net: Make interface aliases available for general usage Richard Weinberger
2015-01-11 22:40 ` Stephen Hemminger
2015-01-11 22:43 ` Richard Weinberger
2015-01-11 20:52 ` [PATCH 2/3] x_tables: Use also dev->ifalias for interface matching Richard Weinberger
2015-01-12 16:04 ` Eric Dumazet
2015-01-12 16:12 ` Richard Weinberger
2015-01-12 16:32 ` Jan Engelhardt
2015-01-12 16:46 ` Eric Dumazet
[not found] ` <1425960.ovH4s7sjue@rofl>
2015-01-12 16:51 ` Eric Dumazet
2015-01-12 17:19 ` Patrick Schaaf
2015-01-12 17:22 ` Patrick McHardy [this message]
2015-01-12 17:41 ` Patrick Schaaf
2015-01-11 20:52 ` [PATCH 3/3] x_tables: Factor out 16bit aligment ifname_compare() Richard Weinberger
2015-01-11 20:59 ` Joe Perches
2015-01-11 21:02 ` Richard Weinberger
2015-01-11 21:14 ` Joe Perches
2015-01-11 21:30 ` Richard Weinberger
2015-01-11 21:39 ` Joe Perches
2015-01-11 21:42 ` Richard Weinberger
2015-01-12 2:50 ` David Miller
2015-01-12 8:18 ` Richard Weinberger
2015-01-12 8:40 ` Joe Perches
2015-01-11 22:23 ` Jan Engelhardt
2015-01-11 22:42 ` [RFC] Make predictable/persistent network interface names more handy Stephen Hemminger
2015-01-11 22:47 ` Richard Weinberger
2015-01-11 22:51 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150112172257.GG17329@acer.localdomain \
--to=kaber@trash.net \
--cc=bhutchings@solarflare.com \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=jiri@resnulli.us \
--cc=jmorris@namei.org \
--cc=john.fastabend@gmail.com \
--cc=kadlec@blackhole.kfki.hu \
--cc=kay@vrfy.org \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@bof.de \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=richard@nod.at \
--cc=stephen@networkplumber.org \
--cc=therbert@google.com \
--cc=vfalico@gmail.com \
--cc=vyasevic@redhat.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).