On 10/17/24 6:44 AM, Jaron Kent-Dobias wrote:
On Thursday, 17 October 2024 at 04:31 (-0500), David C. Rankin wrote:
On 10/17/24 3:35 AM, gerard.bigot@xxxxxxxxx wrote:
nftables is able to respond to iptables commands through the compatibility
layer.
iptables-nft is the packet for you.
I'm glad that's there, but then I have to ask myself, why would I want to
run iptables via nftables through a compatibility layer when I can just run
iptables itself?
The other issue I see there is if a bug or issue pops up. Then is it due to
iptables or the nft compatibility layer?
It's worth noting that nftables is not a newfangled piece of external software
– it's been mainlined in the Linux kernel since 2013, and was intended to be
the successor to legacy iptables.
If nftables automatically uninstalls iptables as an indirect dependency, then
no, the default should not change. That would seem to break every Arch system
currently using iptables.
Other than "it's newer", I can't see what is driving the push for a change in
defaults. The package is there if you prefer it, just like if you prefer nginx
over apache or clang over gcc.
From reading, it seems nftables is just larger and more complex netfilter
project (and yes it does more -- if you need it). Both iptables and nftables
are actively developed, so it's not like one is deprecated.
Why push for a change in default where iptables fits Arch's KISS philosophy
and nftables is there if you need something more?
Has there been any testing to ensure iptables-nft works with all combinations
of iptables, ipset and fail2ban setups?
How would the change work anyway. Would pacman -Syu fail if you answered "No"
to replace iptables with nftables?
Just the thoughts I had considering the change.
--
David C. Rankin, J.D.,P.E.
