#8934 Make iptables-nft the default iptables variant
Closed: Fixed 3 years ago by kevin. Opened 4 years ago by psutter.

  • Describe the issue

Currently there is legacy iptables, ip6tables, ebtables and arptables and their
nftables-based drop-in replacements in iptables-nft package. Users may choose
between both using alternatives tool.

Right now, legacy tools take precedence, reflected by alternatives priority and
the fact that packages depending on 'iptables' which is fulfilled by legacy
iptables package (due to the name).

Plan is to rename iptables package into "iptables-legacy", add "Provides:
iptables" to iptables-nft package and make alternatives priorities the same.
This should cause iptables-nft to be pulled in by default as a dependency and
neither change alternatives choice of existing systems using legacy iptables
when upgrading nor that of new systems when additionally installing
legacy-iptables.

Does the above make sense to you? Do you see problems with the depicted
migration plan?

  • When do you need this?

ASAP, but not the most pressing issue. I'm proposing the change for Fedora 32.

  • When is this no longer needed or useful?

After Fedora 32 release?

  • If we cannot complete your request, what is the impact?

My change request won't be accepted by FESCo.


Plan is to rename iptables package into "iptables-legacy", add "Provides:
iptables" to iptables-nft package and make alternatives priorities the same.
This should cause iptables-nft to be pulled in by default as a dependency and
neither change alternatives choice of existing systems using legacy iptables
when upgrading nor that of new systems when additionally installing
legacy-iptables.

This won't work. iptables-legacy is sorted before iptables-nft. What you really want is to add Suggests: iptables-nft somewhere like fedora-release.

Plan is to rename iptables package into "iptables-legacy", add "Provides:
iptables" to iptables-nft package and make alternatives priorities the same.
This should cause iptables-nft to be pulled in by default as a dependency and
neither change alternatives choice of existing systems using legacy iptables
when upgrading nor that of new systems when additionally installing
legacy-iptables.

This won't work. iptables-legacy is sorted before iptables-nft. What you really want is to add Suggests: iptables-nft somewhere like fedora-release.

My understanding is that "iptables" won't be provided by iptables-legacy package in that name anymore. Is this assumption wrong or am I missing something else?

My understanding is that "iptables" won't be provided by iptables-legacy package in that name anymore. Is this assumption wrong or am I missing something else?

Ah, this wasn't clear to me. In that case, it would do the trick. But does it really worth changing packages for this? Simply add Suggests to fedora-release package and that's it?

My understanding is that "iptables" won't be provided by iptables-legacy package in that name anymore. Is this assumption wrong or am I missing something else?

Ah, this wasn't clear to me. In that case, it would do the trick. But does it really worth changing packages for this? Simply add Suggests to fedora-release package and that's it?

Well, packages depend on 'iptables'. I could add 'Provides: iptables' to iptables-nft package, but I guess then your first concern applies which is iptables package takes precedence due to lexical ordering. I would like to make new installations use iptables-nft though and not harm existing ones, which is why I decided to set alternatives priorities to the same values.

Fedora installs firewalld by default which depends on iptables. Would the 'Suggests' line really do the trick and make iptables-nft get installed by default? If so, that's totally fine with me!

Do we need iptables-legacy anymore?

Also, if we're going to do package preferences, we should use a scheme similar to Mageia and OpenMandriva, where there is a -pkgprefs subpackage of the repos package with all the preferences, and that fedora-repos would require it as a dependency.

yes, they will.

OK. And will legacy iptables package be installed by defualt as well or does a "Provides: iptables" in iptables-nft prevent that? The problem is if we have both installed by default, the one that comes first wins due to the same priorities in alternatives.

Do we need iptables-legacy anymore?

Yes, there are still a few known issues (e.g. ebtables-nft does not support broute table yet), so there may be cases where people want to switch to legacy tools. Although we don't offer this option in RHEL8, I don't think we should restrict Fedora users that much.

Fedora installs firewalld by default which depends on iptables. Would the 'Suggests' line really do the trick and make iptables-nft get installed by default? If so, that's totally fine with me!

It does depend on iptables, but it's switched to nftables now, so I am not sure why it still has the iptables dep.

Anyhow, I think this ticket would be best discussed on the devel list when the change is announced... if you are just filing to see releng impact, I don't think there is going to be any.

Fedora installs firewalld by default which depends on iptables. Would the 'Suggests' line really do the trick and make iptables-nft get installed by default? If so, that's totally fine with me!

It does depend on iptables, but it's switched to nftables now, so I am not sure why it still has the iptables dep.
Anyhow, I think this ticket would be best discussed on the devel list when the change is announced... if you are just filing to see releng impact, I don't think there is going to be any.

Firewalld still depends on iptables because users may still switch back to iptables backend. My concern is merely with making sure iptables-legacy won't be pulled in due to such dependencies. I agree, discussing on fedora-devel list is more appropriate. Thanks!

I'm gonna close this now. Please re-open if you think there's further releng work here.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Looks like this didn't work out as expected: In a fresh Fedora32 install with default options, I see both iptables and iptables-nft installed. According to 'alternatives --list', arptables and ebtables links point at nft variants while iptables link points at iptables-legacy.

Can you tell what went wrong? I couldn't find out why iptables package was still pulled in although iptables-nft has "Provides: iptables" and firewalld has "Suggests: iptables-nft".

Metadata Update from @psutter:
- Issue status updated to: Open (was: Closed)

4 years ago

I just upgraded from Fedora 31 to 32 using sudo dnf system-upgrade download --refresh --releasever=32

$ rpm -qa | grep iptables
iptables-1.8.4-7.fc32.x86_64
iptables-libs-1.8.4-7.fc32.x86_64
$ iptables --version
iptables v1.8.4 (legacy)

iptables-nft didn't get installed and didn't become the default.

Hi Omair,

I just upgraded from Fedora 31 to 32 using sudo dnf system-upgrade download --refresh --releasever=32
[...]
iptables-nft didn't get installed and didn't become the default.

This is expected behaviour, an upgrade or manual install of iptables-nft package should not change the active variant. Otherwise we would risk destabilising the system.

The problem is that in a new installation iptables-nft is not the default variant. And what's worse, variant choice is inconsistent with regards to arptables and ebtables packages.

I'm not sure what went wrong here. ;(

@ignatenkobrain any ideas?

Where are we with this? Did we ever figure it out/fix it?

@kevin I just did a quick test install of F33 (server, minimal): No legacy tools are installed, alternatives points at nft variants for all of iptables, ebtables and arptables. So everything as expected!
No idea why this was broken in (the beta of) F32 I tested 10 months ago, but it looks fine now.
Thanks for following up, this ticket may be closed from my side.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata