My attempt at renaming iptables RPM into iptables-legacy identified 'packagereq' statements in comps to be problematic. Apparently there is a networkmanager-submodules group which lists 'iptables'. This is because NetworkManager realizes connection sharing via calls to 'iptables' command. The latter though may be provided by either iptables-nft or iptables-legacy (formerly 'iptables') RPMs. With Fedora defaulting to iptables-nft (in alternatives) since 32, that packagereq should be changed accordingly.
https://pagure.io/fedora-comps/pull-request/655
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
Given a Fedora 35 container image with no iptables pre-installed, if I try to install podman dnf prefers to pull iptables-legacy instead of iptables-nft. However, this is not always reproducible, as "dnf install firewalld" prefers iptables-nft, as expected. Steps to reproduce the problem: # cat /etc/os-release NAME="Fedora Linux" VERSION="35 (Container Image)" [...] # dnf list --installed | grep -P '(iptables|nft)' iptables-legacy-libs.x86_64 1.8.7-13.fc35 @fedora iptables-libs.x86_64 1.8.7-13.fc35 @fedora # dnf install podman Last metadata expiration check: 0:00:19 ago on Tue Jan 4 17:38:31 2022. Dependencies resolved. ======================================================================================================================== Package Architecture Version Repository Size ======================================================================================================================== Installing: podman x86_64 3:3.4.4-1.fc35 updates 12 M Installing dependencies: conmon x86_64 2:2.0.30-2.fc35 fedora 56 k containernetworking-plugins x86_64 1.0.1-1.fc35 fedora 8.7 M containers-common noarch 4:1-32.fc35 updates 76 k criu x86_64 3.16.1-2.fc35 updates 529 k criu-libs x86_64 3.16.1-2.fc35 updates 31 k crun x86_64 1.4-1.fc35 updates 183 k dbus-libs x86_64 1:1.12.20-5.fc35 fedora 152 k dnsmasq x86_64 2.86-3.fc35 updates 333 k fuse-common x86_64 3.10.5-1.fc35 fedora 8.3 k fuse3 x86_64 3.10.5-1.fc35 fedora 54 k fuse3-libs x86_64 3.10.5-1.fc35 fedora 92 k iptables-legacy x86_64 1.8.7-13.fc35 fedora 53 k jansson x86_64 2.13.1-3.fc35 fedora 44 k libbsd x86_64 0.10.0-8.fc35 fedora 104 k libnet x86_64 1.2-4.fc35 fedora 57 k libnftnl x86_64 1.2.0-2.fc35 fedora 82 k libslirp x86_64 4.6.1-2.fc35 fedora 72 k nftables x86_64 1:1.0.0-1.fc35 fedora 373 k protobuf-c x86_64 1.4.0-1.fc35 fedora 35 k shadow-utils-subid x86_64 2:4.9-8.fc35 updates 89 k yajl x86_64 2.1.0-17.fc35 fedora 37 k Installing weak dependencies: catatonit x86_64 0.1.7-1.fc35 updates 316 k fuse-overlayfs x86_64 1.7.1-2.fc35 fedora 72 k podman-gvproxy x86_64 3:3.4.4-1.fc35 updates 3.7 M podman-plugins x86_64 3:3.4.4-1.fc35 updates 2.6 M slirp4netns x86_64 1.1.12-2.fc35 fedora 55 k Transaction Summary ======================================================================================================================== Install 27 Packages [...] As you notice, iptables-legacy is automatically proposed instead of iptables-nft.
Hi Giovanni, (In reply to Giovanni Grieco from comment #3) [...] > As you notice, iptables-legacy is automatically proposed instead of > iptables-nft. In firewalld.spec, there is: | Suggests: iptables-nft Since podman.spec does not have it, dnf falls back to iptables-legacy (probably just due to alphabetic ordering). Does it matter to you? If so, is explicitly installing iptables-nft feasible as a workaround? Cheers, Phil
Hi Phil, > is explicitly installing iptables-nft feasible as a workaround? Indeed, adding iptables-nft to the dnf install command works around this issue. > Since podman.spec does not have it, dnf falls back to iptables-legacy (probably just due to alphabetic ordering). Does it matter to you? This behavior goes against F32 change request to "make iptables-nft the preferred iptables variant" [1]. As the list of providers is ordered alphabetically, how do we make a variant of a program the default one if dnf automatically picks the first one? Here's the list of affected packages beyond podman: # for pkg in $(dnf repoquery --whatdepends iptables); do INSTALLS_LEGACY=$(false | dnf install $pkg 2>/dev/null | grep iptables-legacy); if [[ ! -z $INSTALLS_LEGACY ]]; then echo $pkg; fi; unset INSTALLS_LEGACY; done Last metadata expiration check: 0:25:28 ago on Thu Jan 6 16:28:53 2022. NFStest-0:2.1.5-12.fc35.noarch WALinuxAgent-0:2.3.1.1-2.fc35.noarch clatd-0:1.5-8.fc35.noarch ctdb-2:4.15.0-13.fc35.x86_64 ctdb-2:4.15.3-0.fc35.x86_64 fwsnort-0:1.6.5-22.fc35.noarch iptables-compat-0:1.8.7-13.fc35.x86_64 iptables-services-0:1.8.7-13.fc35.noarch iptables-utils-0:1.8.7-13.fc35.x86_64 iptstate-0:2.2.6-13.fc35.x86_64 libvirt-daemon-driver-network-0:7.6.0-3.fc35.x86_64 libvirt-daemon-driver-network-0:7.6.0-5.fc35.x86_64 libvirt-daemon-driver-nwfilter-0:7.6.0-3.fc35.x86_64 libvirt-daemon-driver-nwfilter-0:7.6.0-5.fc35.x86_64 moby-engine-0:20.10.11-1.fc35.x86_64 moby-engine-0:20.10.8-1.fc35.x86_64 nfacct-0:1.0.1-16.fc35.x86_64 nsntrace-0:4-4.fc35.x86_64 origin-0:3.11.2-4.fc35.x86_64 podman-3:3.4.0-1.fc35.x86_64 podman-3:3.4.4-1.fc35.x86_64 psad-0:2.4.6-10.fc35.noarch python3-ipatests-0:4.9.7-2.fc35.noarch python3-ipatests-0:4.9.8-1.fc35.noarch ravada-0:1.0.3-1.fc35.noarch shorewall-0:5.2.8-4.fc35.noarch shorewall-0:5.2.8-5.fc35.noarch shorewall-init-0:5.2.8-4.fc35.noarch shorewall-init-0:5.2.8-5.fc35.noarch shorewall-lite-0:5.2.8-4.fc35.noarch shorewall-lite-0:5.2.8-5.fc35.noarch shorewall6-0:5.2.8-4.fc35.noarch shorewall6-0:5.2.8-5.fc35.noarch shorewall6-lite-0:5.2.8-4.fc35.noarch shorewall6-lite-0:5.2.8-5.fc35.noarch sshuttle-0:1.0.5-4.fc35.noarch sslsplit-0:0.5.5-6.fc35.x86_64 ufw-0:0.35-23.fc35.noarch Do you think it would be ok to tell package maintainers to add "Suggests: iptables-nft"? Isn't there a better approach to address the problem? Thanks, Giovanni References: [1] https://bugzilla.redhat.com/show_bug.cgi?id=1774046
(In reply to Giovanni Grieco from comment #5) > > is explicitly installing iptables-nft feasible as a workaround? > Indeed, adding iptables-nft to the dnf install command works around this > issue. Is the workaround feasible for your use-case? > > Since podman.spec does not have it, dnf falls back to iptables-legacy (probably just due to alphabetic ordering). Does it matter to you? > This behavior goes against F32 change request to "make iptables-nft the > preferred iptables variant" [1]. As the list of providers is ordered > alphabetically, how do we make a variant of a program the default one if dnf > automatically picks the first one? The assumption is that firewalld will be present in all flavors and therefore the suggested variant installed. Explicitly requesting iptables-nft will change existing systems upon update for no reason. I filed that change request and one aspect of it is to not transition existing systems unvoluntarily. > Here's the list of affected packages beyond podman: > # for pkg in $(dnf repoquery --whatdepends iptables); do > INSTALLS_LEGACY=$(false | dnf install $pkg 2>/dev/null | grep > iptables-legacy); if [[ ! -z $INSTALLS_LEGACY ]]; then echo $pkg; fi; unset > INSTALLS_LEGACY; done Thanks for compiling this list. I assume all of those packages work well with either of the two variants, so the unspecific 'Depends: iptables' is correct IMO. > Do you think it would be ok to tell package maintainers to add "Suggests: > iptables-nft"? Isn't there a better approach to address the problem? It shouldn't cause any harm, so I guess it's fine. I don't know of any better approach which would cover your use-case. Cheers, Phil
Hi Phil, (In reply to Phil Sutter from comment #6) > (In reply to Giovanni Grieco from comment #5) > > > is explicitly installing iptables-nft feasible as a workaround? > > Indeed, adding iptables-nft to the dnf install command works around this > > issue. > > Is the workaround feasible for your use-case? Yes, I think it is feasible for this particular use-case. Thanks for your valuable suggestions! Giovanni