https://fedoraproject.org/wiki/Changes/iptables-nft-default == Summary == Make iptables-nft the preferred iptables variant. == Owner == * Name: [[User:psutter| Phil Sutter]] * Email: psutter@xxxxxxxxxx == Detailed Description == <code>iptables-nft</code> package provides alternative implementations of iptables, ip6tables, ebtables and arptables and associated save and restore commands. These use nftables internally while providing the same look'n'feel as the original tools. Users may choose between both implementations using <code>alternatives</code> tool. Upstream considers the traditional implementations legacy and therefore renamed the binaries adding '-legacy' suffix. In Fedora, same has been done to <code>arptables</code> and <code>ebtables</code> packages, namely renaming them to <code>arptables-legacy</code> and <code>ebtables-legacy</code>. Legacy <code>iptables</code> and <code>ip6tables</code> remain in <code>iptables</code> package, which in fact is the only one other packages depend upon. To change the status quo, two measures are planned: === Raise priority of nft-variants in <code>alternatives</code> === Currently, legacy variants are installed with priority 10 and nft variants with priority 5. This must be changed as otherwise installing <code>iptables-legacy</code> in a system with <code>iptables-nft</code> installed would change the active alternative (since they are in automatic mode by default). On the other hand, existing systems using legacy variants should not be changed by a system update. Therefore nft variants' priorities should be chosen to match legacy ones. === Rename <code>iptables</code> package === New name should be <code>iptables-legacy</code> which aligns with ebtables and arptables and reflects upstream status. To resolve dependencies, <code>Provides: iptables</code> statement will be added to <code>iptables-nft</code> package. This should automatically change the default variant to nft. == Benefit to Fedora == * RHEL8 ships nft-variants exclusively, make Fedora align with that by default while still providing the option to fall back to legacy tools. * New features and improvements are likely to hit nft-variants due to the possibility nftables backend allows for. Although at this point some legacy features (e.g. ebtables among match) are still missing, others are already there (like, e.g. xtables-monitor tool) or are being upstreamed right now (improved tool performance when dealing with large rulesets). == Scope == * Proposal owners: Changes are rather simple: Rename <code>iptables</code> package, add <code>Provides:</code> line to <code>iptables-nft</code> package, change priorities used when calling <code>alternatives</code>. * Other developers: N/A The changed tools may cause regressions among packages using them and it affects only new installations (or those manually switched over). So while no explicit effort is required from them, they should be made aware of the change so they take a possible regression in iptables into account, quickly test against legacy variant and file a ticket (or complain to the right person) if that fixes the problem. * Release engineering: [https://pagure.io/releng/issue/8934 #8934] * Policies and guidelines: No change required * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Due to the package rename and <code>Provides:</code> line, upgrades will pull in <code>iptables-nft</code> package. But due to the equal alternatives priorities, existing choices won't be changed and so existing installations shouldn't be harmed (apart from forced installation of <code>iptables-nft</code> package). Sadly, there are a few known issues, like e.g. missing support for ebtables broute table or among match and a few iptables targets/matches. Users depending on such features are advised to install <code>iptables-legacy</code> package and switch variants using <code>alternatives</code>. == How To Test == Any users of iptables/ebtables/arptables should switch to nft-variants using alternatives tool (if necessary) and check that everything works as before. Any issues should be reported despite the known compatibility issues described above since knowledge about who uses the missing features is valuable information for both up- and downstream. == User Experience == Ideally look'n'feel shouldn't change. Since iptables-nft does not need a lock file anymore, no problems with stale xtables-lock or parallel iptables calls in different mount namespaces are expected anymore. Given the changes currently being upstreamed, users dealing with large rulesets should see a performance increase when manipulating the ruleset (lower run-times of iptables or iptables-restore, packet processing speed should not really change). == Dependencies == Other packages depending on iptables: * NFStest * clatd * ctdb * fail2ban-server * firewalld * fwsnort * iptstate * libvirt-daemon-driver-network * libvirt-daemon-driver-nwfilter * moby-engine * nfacct * origin * podman * psad * python3-ipatests * ravada * rkt * shorewall * shorewall-init * shorewall-lite * shorewall6 * shorewall6-lite * sshuttle * sslsplit * ufw Since nft-variants are supposed to be drop-in replacements, no outside contribution is needed in order to perform this change. == Contingency Plan == * Contingency mechanism: Nothing needs to be done, the change should be atomic. * Contingency deadline: N/A * Blocks release? No == Documentation == * https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools * Man pages: ** [http://man7.org/linux/man-pages/man8/xtables-nft.8.html xtables-nft.8] ** [http://man7.org/linux/man-pages/man8/xtables-legacy.8.html xtables-legacy.8] ** [http://man7.org/linux/man-pages/man8/xtables-monitor.8.html xtables-monitor.8] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
