On Mon, May 16, 2022 at 01:24:52PM +0200, William Edwards wrote: > On 'regular' >= Debian Buster systems, the alternative for xtables is > xtables-nft. These are compatibility layers to use the nf_tables backend > with xtables tooling and syntax. > > In GitHub issue #47, a ferm user proposed xtables-legacy be used directly. > ferm changed this behaviour with commit 47b78b6. This causes the xtables > backends to be used, rather than the nftables compatibility layers. The > rationale behind this change is that the xtables-legacy and xtables-nft > tools are not fully compatible. The number of reports related to this issue > is limited. > > The aforementioned commit, which changes the behaviour to use > xtables-legacy, was included in package version 2.5-1 (see Debian Bug report > #929416). ferm 2.5.1-1 is now the most recent package version in the stable > repository. As such, the current ferm package in the stable repository no > longer uses nftables (albeit by means of the compatibility layer). Yet users > are adviced to use the nf_tables backend. This effectively means that users > must phase out ferm before upgrading Debian. I believe this greatly > complicates the upgrade path. Especially as the general concensus seems to > be that ferm alternatives, and even the native nftables configuration > format, are currently missing useful features that ferm does provide. > > I doubt that the incompatibility between xtables-legacy outweighs this. I > propose commit 47b78b6 not be included in this package.
There is also https://github.com/MaxKellermann/ferm/pull/90 to address this and a new repository on https://gitlab.tuxis.nl/oss_public/ferm I am adding this here so that I don't forget this when I will eventually work on the ferm package as well. Greetings Marc
