[systemd-devel] nftables support for nspawn/networkd

Lennart Poettering lennart at poettering.net
Mon Jun 22 09:28:53 UTC 2020


On Fr, 19.06.20 16:14, Florian Westphal (fw at strlen.de) wrote:

> Hello.
>
> I have been working on an nftables backend as alternative (or
> replacement?) for the libiptc one.

I think such a backend would be very welcome. Best would be to submit
as PR on systemd gitub, to discuss/review this further.

> At this time, the prototype disables the existing libiptc backend and unconditionally
> uses the nft one. I did this for simplicity.
> This also means that the existing API (fw_add_...) is mostly the same.
> I say *mostly* because that API exposes more functionality (on iptables side)
> than is actually used, such as in/output interface names where all calles
> pass NULL.

While I personally would be fine with making this a compile time
choice I figure distros that want to be entirely generic would
probably not be too happy and would prefer that the two backends can
be selected at runtime (Debian...).

> 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.

> 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.

> 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.

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

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list