On Fr, 19.06.20 16:14, Florian Westphal (fw@xxxxxxxxx) 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 _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel