Bug with iptables-legacy

Rocky Linux Tech Help
1

Hi

If I try to install iptables-legacy (from epel)

dnf install iptables-legacy
Last metadata expiration check: 3:43:21 ago on Tue Sep 10 10:39:03 2024.
Error: 
 Problem: conflicting requests
  - nothing provides (iptables-libs(x86-64) = 1.8.10-2.el9 or iptables-libs(x86-64) = 1.8.10-2.el9_1) needed by iptables-legacy-1.8.10-2.2.el9.x86_64 from epel
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

I need iptables-libs(x86-64) = 1.8.10-2.el9 or iptables-libs(x86-64) = 1.8.10-2.el9_1
But rocky won’t provide this version, only a newer one

dnf info iptables-libs
Last metadata expiration check: 3:53:52 ago on Tue Sep 10 10:39:03 2024.
Installed Packages
Name         : iptables-libs
Version      : 1.8.10
Release      : 4.el9_4
Architecture : x86_64
Size         : 1.7 M
Source       : iptables-1.8.10-4.el9_4.src.rpm
Repository   : @System
From repo    : baseos
Summary      : libxtables and iptables extensions userspace support
URL          : https://www.netfilter.org/projects/iptables
License      : GPLv2 and Artistic 2.0 and ISC
Description  : libxtables and associated shared object files
             : 
             : Libxtables provides unified access to iptables extensions in userspace. Data
             : and logic for those is kept in per-extension shared object files.

The bug is registred at RedHat 2310158 – Needs rebuild against iptables-libs-1.8.10-4
I think maybe only providing the iptables-libs-1.8.10-2.el9_1 in repo would solve the bug

It seems that has been done by AlmaLinux

Regards

2

The issue is that EPEL has not updated their package to work with current el9. That is something that EPEL has to handle.

The difference between Alma and Rocky is that currently Rocky keeps only latest versions of packages in official, mirrored repos. There is, however, a vault: Index of /vault/rocky/9.4/BaseOS/x86_64/os/Packages/i/

Do you have a particular reason to use legacy iptables? Can’t you translate your ruleset into nf_tables?

3

Thanks for the anwser

We use and combine close to forty ansible roles related to iptables on our servers and laptops, not only on Rocky Linux but also on Debian and Ubuntu.

With our Ansible roles, we can do some very fine iptables tuning, in order to meet a wide range of needs

In order to standardise our rules for all systems, we are keeping iptables for now. Change to nftable is planed for Debian 13, but it’s a lot of work and tests for our small team

I think the vault will be ok for a temporary fix of this bug

2 Likes
4

Hi

dnf install https://dl.rockylinux.org/vault/rocky/9.4/BaseOS/x86_64/os/Packages/i/iptables-libs-1.8.10-2.el9.x86_64.rpm https://dl.rockylinux.org/vault/rocky/9.4/BaseOS/x86_64/os/Packages/i/iptables-nft-1.8.10-2.el9.x86_64.rpm --allowerasing

did the job, we can wait for EPEL to update their package

5

I have the same problem and I would gladly simply remove iptables-legacy. However it turned out, iptables-legacy is required by podman-docker. podman-docker however is NOT an epel package but from appstream, so maybe docker-podman has to be rebuild as well?

6

If Rocky’s package requires package that is not in Rocky, then Rocky has a bug that you should report.

For comparison:

[x@AlmaLinux9 ~]$ dnf -q rq --requires --resolve podman-docker
bash-0:5.1.8-9.el9.x86_64
podman-4:4.9.4-10.el9_4.x86_64
[x@AlmaLinux9 ~]$ dnf -q rq --requires --resolve podman
bash-0:5.1.8-9.el9.x86_64
conmon-2:2.1.10-1.el9.x86_64
container-selinux-3:2.229.0-1.el9_3.noarch
containers-common-2:1-91.el9_4.x86_64
crun-0:1.14.3-1.el9.x86_64
fuse-overlayfs-0:1.13-1.el9.x86_64
glibc-0:2.34-100.el9_4.3.i686
glibc-0:2.34-100.el9_4.3.x86_64
gpgme-0:1.15.1-6.el9.x86_64
iptables-nft-0:1.8.10-4.el9_4.x86_64
libassuan-0:2.5.5-3.el9.x86_64
libgcc-0:11.4.1-3.el9.alma.1.x86_64
libgpg-error-0:1.42-5.el9.x86_64
libseccomp-0:2.5.2-2.el9.i686
libseccomp-0:2.5.2-2.el9.x86_64
netavark-2:1.10.3-1.el9.x86_64
nftables-1:1.0.9-1.el9.i686
nftables-1:1.0.9-1.el9.x86_64
runc-4:1.1.12-4.el9_4.x86_64
shadow-utils-subid-2:4.9-8.el9.x86_64
slirp4netns-0:1.2.3-1.el9.x86_64

[EDIT] Wait! I know what happens …

[x@AlmaLinux9 ~]$ dnf --enablerepo=epel -q rq --requires --resolve podman | grep -v i686
bash-0:5.1.8-9.el9.x86_64
conmon-2:2.1.10-1.el9.x86_64
container-selinux-3:2.229.0-1.el9_3.noarch
containers-common-2:1-91.el9_4.x86_64
crun-0:1.14.3-1.el9.x86_64
fuse-overlayfs-0:1.13-1.el9.x86_64
glibc-0:2.34-100.el9_4.3.x86_64
gpgme-0:1.15.1-6.el9.x86_64
gpgme1.22-0:1.22.0-2.el9.x86_64
iptables-legacy-0:1.8.10-2.2.el9.x86_64
iptables-nft-0:1.8.10-4.el9_4.x86_64
libassuan-0:2.5.5-3.el9.x86_64
libgcc-0:11.4.1-3.el9.alma.1.x86_64
libgpg-error-0:1.42-5.el9.x86_64
libseccomp-0:2.5.2-2.el9.x86_64
netavark-2:1.10.3-1.el9.x86_64
nftables-1:1.0.9-1.el9.x86_64
runc-4:1.1.12-4.el9_4.x86_64
shadow-utils-subid-2:4.9-8.el9.x86_64
slirp4netns-0:1.2.3-1.el9.x86_64

The podman requires feature iptables and both iptables-nft and iptables-legacy do provide it.
If EPEL is enabled, then dnf may pick the wrong package.

This is unambiguous:

dnf --disablerepo=epel install podman-docker
1 Like