[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