On Sun, Nov 18, 2018 at 07:51:13AM -0500, Jeremy Jackson wrote:
>
> On 2018-11-17 2:44 p.m., Florian Westphal wrote:
> > Jeremy Jackson <jerj@xxxxxxxxxxxx> wrote:
> > > I have a bash script which implements zone-based iptables firewall rules
> > > similar to firewalld or Cisco PIX. The key ingredient is the ability to
> > > iterate over a list of network interfaces, to create chains and rules for
> > > every input to output interface combination:
> > >
> > > I would like to do this with the nft utility or at least with a libnftables
> > > C library based utility.
> > >
> > > Would a contributed looping construct be welcomed into the nft utility? It
> > > already has variables. A minimal implementation would be a single keyword
> > > "permute-interfaces $iif $oif"
> > I find it hard to answer without any context of what this would look
> > like.
> >
> > In/Out Combinations would normally look similar to this:
> >
> > add rule filter forward meta iif . meta oif { "eth0" . "ppp0", "eth0 . "veth0" }
> >
> > (instead of { ... }, a named set could be used that can then be changed
>
> The iteration is what generates that set on the fly. Example:
>
> Given the set of interfaces in a named set $ifset { eth0, eth1, ppp0 }, the
> statement
OK, so goal is some sort of macro expansion if I understand correctly.
> permute-interfaces $ifset $ouput-set
>
> would produce $output-set containing
>
> eth0, eth1, : jump eth0-eth1-chain
>
> eth0, ppp0 : jump eth0-ppp0-chain
>
> eth1, eth0 : jump eth1-eth0-chain
>
> eth1, ppp0 : jump eth1-ppp0-chain
>
> ppp0, eth0: jump ppp0-eth0-chain
>
> ppp0, eth1 : jump ppp0-eth1-chain
This should be a concatenation, right? ie.
ppp0 . eth1
> I would like to avoid having to load another language interpreter to do such
> a trivial thing, when nft already has a parser built in.
Yes, having built-in stuff is the way to go. Note sure this is the
best way to express this. We can probably introduce loops for
expansions and add some built-in function to permute on a list of any
arbitrary datatype.
I would prefer we explore this rather than starting to add
datatype-specific macro-like features.
