Re: nftables support for nspawn/networkd

[Florian Westphal <fw@xxxxxxxxx>]

Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
> > To simplify the prototype I modified the API to drop the 'always NULL' arguments
> > to focus on what is actually used.
> 
> If there's indeed stuff that isn't used I think a patch that removes
> support for them altogether would be very welcome.

Great.  I will split that from the nftables related work and submit a PR
for it.

> > 5. this currently replaces the libiptc backend.
> >    Alternatives are a compile time or run-time switch.
> 
> Ideally, if both backends are compiled in we'd pick the right one
> automatically.

OK, that is doable.

> > If you want to retain the libiptc backend in any case: Do you have suggestions
> > on how to toggle this? Would a configure switch be enough?
> 
> I'd post this as RFC PR on github, and CC @mbiebl, who's our
> downstream Debian maintainer, he might have a perspective on the
> future of non-nftables iptables.

Will do, thanks.

> BTW, is there any perspective of using sd-netlink as library backend
> for the interaction with the kernel side of things?

I extended sd-netlink with support for nfnetlink for this to work, so
instead of RTNETLINK+GENETLINK there is now an nfnetlink backend as
well.

>From your comments so far I would guess an acceptable solution would
be to retain the '--with-libiptc' switch, but build the
nfnetlink/nftables backend unconditionally.

Then, if nftables initialisation fails (e.g. because kernel was
built without nftables support), fall back to libiptc/iptables-classic.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel