https://fedoraproject.org/wiki/Changes/iptables-nft-default
== Summary == Make iptables-nft the preferred iptables variant.
== Owner == * Name: [[User:psutter| Phil Sutter]] * Email: psutter@redhat.com
== 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]
Hi Kevin,
I just noticed we didn't finish discussing the package rename proposal in related releng issue[1]:
On Wed, Oct 30, 2019 at 05:02:08PM -0400, Ben Cotton wrote: [...]
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.
My motivation for the rename is to abstract 'iptables' keyword other packages depend upon if they need (an implementation of) iptables.
With matching Alternatives priorities, the first installed variant package wins and with given lexical ordering, if both legacy and nft variants are installed by default Alternatives will point at legacy.
I want to avoid this (and also avoid legacy being installed if not used) by making sure a 'Requires: iptables' in any package may be satisfied by iptables-nft package as well. If adding 'Provides: iptables' to the latter is sufficient, that's fine with me.
If my assumptions are correct, I assume there is still a 'Suggests: iptables-nft' required in an always installed package like fedora-release, right? Also, which package would that be? I don't see fedora-release package being used for these things.
Cheers, Phil
On Mon, Jan 06, 2020 at 06:02:12PM +0100, Phil Sutter wrote:
Hi Kevin,
I just noticed we didn't finish discussing the package rename proposal in related releng issue[1]:
On Wed, Oct 30, 2019 at 05:02:08PM -0400, Ben Cotton wrote: [...]
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.
My motivation for the rename is to abstract 'iptables' keyword other packages depend upon if they need (an implementation of) iptables.
With matching Alternatives priorities, the first installed variant package wins and with given lexical ordering, if both legacy and nft variants are installed by default Alternatives will point at legacy.
I want to avoid this (and also avoid legacy being installed if not used) by making sure a 'Requires: iptables' in any package may be satisfied by iptables-nft package as well. If adding 'Provides: iptables' to the latter is sufficient, that's fine with me.
That should work yeah, but also might need Obsoletes to handle upgrades? (ie, remove the old 'iptables' package in favor of 'iptables-nft')
If my assumptions are correct, I assume there is still a 'Suggests: iptables-nft' required in an always installed package like fedora-release, right? Also, which package would that be? I don't see fedora-release package being used for these things.
Not that I know of, Theres several places base sort of packages get installed via: comps groups and kickstarts. It looks like iptables is in the networkmanager-submodules comps group, and I don't see it in kickstarts, but might be it's pulled via firewalld by anaconda or the like?
kevin
Hi Kevin,
On Tue, Jan 07, 2020 at 10:16:05AM -0800, Kevin Fenzi wrote:
On Mon, Jan 06, 2020 at 06:02:12PM +0100, Phil Sutter wrote:
I just noticed we didn't finish discussing the package rename proposal in related releng issue[1]:
On Wed, Oct 30, 2019 at 05:02:08PM -0400, Ben Cotton wrote: [...]
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.
My motivation for the rename is to abstract 'iptables' keyword other packages depend upon if they need (an implementation of) iptables.
With matching Alternatives priorities, the first installed variant package wins and with given lexical ordering, if both legacy and nft variants are installed by default Alternatives will point at legacy.
I want to avoid this (and also avoid legacy being installed if not used) by making sure a 'Requires: iptables' in any package may be satisfied by iptables-nft package as well. If adding 'Provides: iptables' to the latter is sufficient, that's fine with me.
That should work yeah, but also might need Obsoletes to handle upgrades? (ie, remove the old 'iptables' package in favor of 'iptables-nft')
I don't want to move people from legacy iptables over to nft during upgrade, that may cause unexpected side-effects.
So your question depends upon whether iptables package is renamed or not. If not, nothing needs to be done to preserve upgrades. If it is, I'll go with a compat subpackage just as I did for arptables and ebtables earlier.
My point in this thread is to clarify whether it is really possible to establish my goals without renaming iptables package into iptables-legacy and if so how many hacks are required.
If my assumptions are correct, I assume there is still a 'Suggests: iptables-nft' required in an always installed package like fedora-release, right? Also, which package would that be? I don't see fedora-release package being used for these things.
Not that I know of, Theres several places base sort of packages get installed via: comps groups and kickstarts. It looks like iptables is in the networkmanager-submodules comps group, and I don't see it in kickstarts, but might be it's pulled via firewalld by anaconda or the like?
Yes, firewalld depends on 'iptables'. My big question is how to make that dependency prefer iptables-nft (assuming it 'Provides: iptables').
Cheers, Phil
On Thu, Jan 9, 2020 at 5:15 AM Phil Sutter psutter@redhat.com wrote:
Hi Kevin,
On Tue, Jan 07, 2020 at 10:16:05AM -0800, Kevin Fenzi wrote:
On Mon, Jan 06, 2020 at 06:02:12PM +0100, Phil Sutter wrote:
I just noticed we didn't finish discussing the package rename proposal in related releng issue[1]:
On Wed, Oct 30, 2019 at 05:02:08PM -0400, Ben Cotton wrote: [...]
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.
My motivation for the rename is to abstract 'iptables' keyword other packages depend upon if they need (an implementation of) iptables.
With matching Alternatives priorities, the first installed variant package wins and with given lexical ordering, if both legacy and nft variants are installed by default Alternatives will point at legacy.
I want to avoid this (and also avoid legacy being installed if not used) by making sure a 'Requires: iptables' in any package may be satisfied by iptables-nft package as well. If adding 'Provides: iptables' to the latter is sufficient, that's fine with me.
That should work yeah, but also might need Obsoletes to handle upgrades? (ie, remove the old 'iptables' package in favor of 'iptables-nft')
I don't want to move people from legacy iptables over to nft during upgrade, that may cause unexpected side-effects.
So your question depends upon whether iptables package is renamed or not. If not, nothing needs to be done to preserve upgrades. If it is, I'll go with a compat subpackage just as I did for arptables and ebtables earlier.
My point in this thread is to clarify whether it is really possible to establish my goals without renaming iptables package into iptables-legacy and if so how many hacks are required.
If my assumptions are correct, I assume there is still a 'Suggests: iptables-nft' required in an always installed package like fedora-release, right? Also, which package would that be? I don't see fedora-release package being used for these things.
Not that I know of, Theres several places base sort of packages get installed via: comps groups and kickstarts. It looks like iptables is in the networkmanager-submodules comps group, and I don't see it in kickstarts, but might be it's pulled via firewalld by anaconda or the like?
Yes, firewalld depends on 'iptables'. My big question is how to make that dependency prefer iptables-nft (assuming it 'Provides: iptables').
Requires: iptables Suggests: iptables-nft
Hi Neal,
On Thu, Jan 09, 2020 at 06:44:22AM -0500, Neal Gompa wrote:
On Thu, Jan 9, 2020 at 5:15 AM Phil Sutter psutter@redhat.com wrote:
[...]
Yes, firewalld depends on 'iptables'. My big question is how to make that dependency prefer iptables-nft (assuming it 'Provides: iptables').
Requires: iptables Suggests: iptables-nft
Ah, cool. Adding the Suggests: line to firewalld didn't come to mind. In order to gain a bit of confidence, I played with dnf: If legacy iptables and ebtables are installed, installing firewalld doesn't pull iptables-nft. If OTOH none of arp-, eb- or iptables* is installed, installing firewalld pulls in iptables-nft as a dependency. Sounds like just what I wanted to achieve!
Thanks, Phil
Resurrecting this old thread.
On Thu, Jan 16, 2020 at 1:09 PM Phil Sutter psutter@redhat.com wrote:
Hi Neal,
On Thu, Jan 09, 2020 at 06:44:22AM -0500, Neal Gompa wrote:
On Thu, Jan 9, 2020 at 5:15 AM Phil Sutter psutter@redhat.com wrote:
[...]
Yes, firewalld depends on 'iptables'. My big question is how to make that dependency prefer iptables-nft (assuming it 'Provides: iptables').
Requires: iptables Suggests: iptables-nft
Ah, cool. Adding the Suggests: line to firewalld didn't come to mind. In order to gain a bit of confidence, I played with dnf: If legacy iptables and ebtables are installed, installing firewalld doesn't pull iptables-nft. If OTOH none of arp-, eb- or iptables* is installed, installing firewalld pulls in iptables-nft as a dependency. Sounds like just what I wanted to achieve!
AIUI, we made the change to use iptables-nft as the default with F32. We also decided that existing iptables-legacy users shouldn't be moved to iptables-nft during an upgrade.
However, I think that new installations are still defaulting to iptables-legacy. The group "Common NetworkManager Submodules" pulls in `iptables` which seems to pull in iptables-legacy by default.
This feels like an oversight and should be fixed. Is this correct?
regards,
bex
Thanks, Phil _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Wed, 2021-10-20 at 18:39 +0200, Brian (bex) Exelbierd wrote:
Resurrecting this old thread.
On Thu, Jan 16, 2020 at 1:09 PM Phil Sutter psutter@redhat.com wrote:
Hi Neal,
On Thu, Jan 09, 2020 at 06:44:22AM -0500, Neal Gompa wrote:
On Thu, Jan 9, 2020 at 5:15 AM Phil Sutter psutter@redhat.com wrote:
[...]
Yes, firewalld depends on 'iptables'. My big question is how to make that dependency prefer iptables-nft (assuming it 'Provides: iptables').
Requires: iptables Suggests: iptables-nft
Ah, cool. Adding the Suggests: line to firewalld didn't come to mind. In order to gain a bit of confidence, I played with dnf: If legacy iptables and ebtables are installed, installing firewalld doesn't pull iptables-nft. If OTOH none of arp-, eb- or iptables* is installed, installing firewalld pulls in iptables-nft as a dependency. Sounds like just what I wanted to achieve!
AIUI, we made the change to use iptables-nft as the default with F32. We also decided that existing iptables-legacy users shouldn't be moved to iptables-nft during an upgrade.
However, I think that new installations are still defaulting to iptables-legacy. The group "Common NetworkManager Submodules" pulls in `iptables` which seems to pull in iptables-legacy by default.
This feels like an oversight and should be fixed. Is this correct?
I agree we should probably change that, but I'm not sure it's so straightforward...I just ran an F35 install (Workstation package set installed from Server netinst, as it happens) and it got iptables-nft, not iptables-legacy. I'll have a look at a live instance later.
Hi!
On Wed, Oct 20, 2021 at 01:40:35PM -0700, Adam Williamson wrote:
On Wed, 2021-10-20 at 18:39 +0200, Brian (bex) Exelbierd wrote:
[...]
AIUI, we made the change to use iptables-nft as the default with F32. We also decided that existing iptables-legacy users shouldn't be moved to iptables-nft during an upgrade.
However, I think that new installations are still defaulting to iptables-legacy. The group "Common NetworkManager Submodules" pulls in `iptables` which seems to pull in iptables-legacy by default.
This feels like an oversight and should be fixed. Is this correct?
I just had a bright moment! It told me to check fedora-comps: Indeed the above issue was reported[1] and fixed[2] for F35.
I agree we should probably change that, but I'm not sure it's so straightforward...I just ran an F35 install (Workstation package set installed from Server netinst, as it happens) and it got iptables-nft, not iptables-legacy. I'll have a look at a live instance later.
I take this as an unintended verification of said fix. :)
Thanks, Phil
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1957346 [2] https://pagure.io/fedora-comps/c/9d4f353233619f36f03f6c78331cc4246e12a7c3?br...
On Thu, Oct 21, 2021 at 3:23 AM Phil Sutter psutter@redhat.com wrote:
Hi!
On Wed, Oct 20, 2021 at 01:40:35PM -0700, Adam Williamson wrote:
On Wed, 2021-10-20 at 18:39 +0200, Brian (bex) Exelbierd wrote:
[...]
AIUI, we made the change to use iptables-nft as the default with F32.
We
also decided that existing iptables-legacy users shouldn't be moved to iptables-nft during an upgrade.
However, I think that new installations are still defaulting to iptables-legacy. The group "Common NetworkManager Submodules" pulls in `iptables` which seems to pull in iptables-legacy by default.
This feels like an oversight and should be fixed. Is this correct?
I just had a bright moment! It told me to check fedora-comps: Indeed the above issue was reported[1] and fixed[2] for F35.
Thank you for catching the update is already in the works.
Does this also remove iptables-compat? I gather from its description it should have been removed by now.
I also can't help but wonder what the impact of this change will be on OSTree users. Will they be force upgraded from iptables to nftables through the removal?
regards,
bex
I agree we should probably change that, but I'm not sure it's so straightforward...I just ran an F35 install (Workstation package set installed from Server netinst, as it happens) and it got iptables-nft, not iptables-legacy. I'll have a look at a live instance later.
I take this as an unintended verification of said fix. :)
Thanks, Phil
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1957346 [2] https://pagure.io/fedora-comps/c/9d4f353233619f36f03f6c78331cc4246e12a7c3?br... _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi Bex,
On Thu, Oct 21, 2021 at 12:58:11PM +0200, Brian (bex) Exelbierd wrote:
On Thu, Oct 21, 2021 at 3:23 AM Phil Sutter psutter@redhat.com wrote:
On Wed, Oct 20, 2021 at 01:40:35PM -0700, Adam Williamson wrote:
On Wed, 2021-10-20 at 18:39 +0200, Brian (bex) Exelbierd wrote:
[...]
AIUI, we made the change to use iptables-nft as the default with F32.
We
also decided that existing iptables-legacy users shouldn't be moved to iptables-nft during an upgrade.
However, I think that new installations are still defaulting to iptables-legacy. The group "Common NetworkManager Submodules" pulls in `iptables` which seems to pull in iptables-legacy by default.
This feels like an oversight and should be fixed. Is this correct?
I just had a bright moment! It told me to check fedora-comps: Indeed the above issue was reported[1] and fixed[2] for F35.
Thank you for catching the update is already in the works.
Does this also remove iptables-compat? I gather from its description it should have been removed by now.
The -compat package is merely there as transitioning aid during updates. It provides no functionality at all. The relevant pieces are:
* nftables - the successor to (old) iptables, all new, no bounds
* iptables-legacy - the old iptables, not related to nftables at all
* iptables-nft - a drop-in replacement to -legacy, using nftables with (some) legacy matches/targets
The decision between legacy and nft variants of iptables happens via alternatives. Switching should not be noticeable to users apart from corner-cases.
I also can't help but wonder what the impact of this change will be on OSTree users. Will they be force upgraded from iptables to nftables through the removal?
A key point in the above is that 'dnf update' won't change the currently used variant on a system. New installs should default to iptables-nft, though. I'm not familiar with ostree, so I can't tell if this promise holds there. If it doesn't and we can fix it in RPM, please let me know (or just file a ticket so we can track it).
Cheers, Phil
-
Adam Williamson -
Ben Cotton -
Brian (bex) Exelbierd -
Kevin Fenzi -
Neal Gompa -
Phil Sutter