Add --no-legacy parameter#90
Conversation
Since commit 47b78b6, ferm always uses legacy xtables tools. This commit allows users to revert to the old behaviour.
Apparently, /usr/sbin/iptables-restore refers to the "nft" based tools on some installations, and those are incompatible enough that they sometimes break ferm. To fix this, explicitly, refer to the "legacy" tools. Closes #47
|
I would also like to have ferm co-exist with other nft-tables based tooling. If you create a iptables-legacy ruleset in the kernal, you can no longer use nft.. I don't mind sacrificing that some ferm idioms won't work. However I would suggest that such failures should be logged as bugs/issues against iptables-nft and friends. |
| if (!$option{no_legacy}) { | ||
| if ($name =~ /^(.*tables)(.*)$/) { |
There was a problem hiding this comment.
maybe reduce the diff here with a simpler:
| if (!$option{no_legacy}) { | |
| if ($name =~ /^(.*tables)(.*)$/) { | |
| if (!$option{no_legacy} and $name =~ /^(.*tables)(.*)$/) { |
|
@MaxKellermann any plans to get this merged? |
Check out https://gitlab.tuxis.nl/oss_public/ferm. It’s my version with this patch. |
Sadly this needs an account on that gitlab instance to even see the patch. Was there more work done on ferm other than this patch? If so, would commit on taking over ferm's upstream so that Debian could move to your repository as authoritative upstream source, since @MaxKellermann obviously has lost interest in ferm? |
I'm not opposed to maintaining upstream, but it would not be my top priority due to a lack of time, and comfort with the current solution. My patch is freely available, though, so I'd be happy to incorporate it elsewhere. My customised version is already built 'properly' using Quilt et al, so that should be no problem at all. The repository is currently publicly available on https://gitlab.tuxis.nl/pusher/ferm. For clarification: I the patch, and placed it on @tuxis-ie's GitLab instance. They have the infrastructure for a public apt repo in place, whereas all our repos are internal, and I don't want to make them partly available just for this patch. Aside from the
To nitpick a bit here: I wouldn't exactly say that @MaxKellermann has lost interest in ferm, as he has made the understandable case that ferm is a legacy tool for maintaining a legacy tool (iptables), of which the successor is nftables. However, I have to ascertain that ferm is much more practical in the real world compared to nftables' tooling. |
Yes/no. Sorry for being a lazy maintainer for so many years, but I'm struggling with keeping up with everything and work and the real world and so on, and ferm isn't my highest priority, so it's the first thing that starves. Yes, ferm is legacy, but yes, nftables is an inferior replacement. It's like they copied some of the ferm syntax, but forgot the other 90% of what made ferm better than iptables. That's sad. If I had enough time left, I would join the nftables team and improve it to make it a combined iptables+ferm successor - but I don't have that time. Those who want to keep on using ferm should team up and adopt maintainership. |
|
@MaxKellermann I didn't mean to attack or offend you. I fully understand and I share your opinion about nft. That thing simply is not finished and the developers don't agree about that. Other people are trying to keep ferm alive and I appreciate that as well as I appreciate your bringing ferm to where it is now. Thank you! |
If I want to take ownership, are you OK with transferring the project and the website? My company relies heavily on ferm (running it on 300+ servers, and have written a ton of automation around it), so I’d be willing to put in some work to take it over. I would find some co-maintainers, though. But at least I have a need for ferm, other than you nowadays, if I understand correctly. P.S. According to the changelog, 8 days ago, ferm turned 25 (and with that, it’s older than me 😬) |
6 participants
In issue #47, a user reported that "sometimes there are some issues" when using the
iptables-nfttools. These tools allow users to use the newer nf_tables backend while using the old xtables syntax, and therefore ferm. As a result, legacy xtables tools are now always used (from commit 47b78b6). This makes ferm unusable with nftables.@MaxKellermann argues that ferm should no longer be used in favour of nftables:
However, nftables misses features that ferm has. At the moment, ferm is still useful. I think it should be usable with nftables.
Commit 47b78b6 says that the
iptables-nfttools are "incompatible enough that they sometimes break ferm". This is only true in specific cases. This PR adds the--no-legacyparameter. This parameter allows users to revert to the old behaviour at their own risk, i.e. use whatever they've configured as an alternative foriptables, which isiptables-nfton Debian by default.