Why should this be disabled in Fedora?

(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> Why should this be disabled in Fedora?

Using libiptc is not a compatible method of manipulating netfilter, especially
in light of iptables-nft being the default iptables variant meanwhile. Ideally
systemd would refer to firewalld for such tasks, but with PR#17026[1] talking
to nftables directly is an option at least.

[1] https://github.com/systemd/systemd/pull/17026

I assumed that the two backends can coexist, and the right one is selected on the running system.
Fedora still has support for iptables, even if it is not the default, no?

(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> I assumed that the two backends can coexist, and the right one is selected
> on the running system.

Well, using both at the same time is a bad idea, but that's probably not what
you had in mind with "coexist". Users choose between the two via Alternatives.
There is no libiptc equivalent though, so that doesn't change magically. Using
it may be fine (if iptables-legacy is active), but mostly not (new installs use
nft variant by default).

> Fedora still has support for iptables, even if it is not the default, no?

*Legacy* iptables, but indeed it does. With libiptc, the situation is pretty
ugly though, as there is no equivalent. If systemd called iptables command for
instance, things would "just work". Regarding the use of nftables in
systemd-nspawn, one could say doing that on a system with legacy backend active
is equivalently inappropriate as using libiptc on a system with nft backend
active. And this doesn't even take concurrent users into account.

Let me reiterate:
systemd never calls any executables directly. So let's not talk about the iptables executable
and alternatives, it's not directly relevant.

Systemd either does some nftables setup using netlink directly, or (if compiled in),
does iptables setup using libiptc. Right now, both backends are available, and
nftables is preferred, i.e. it is probed first.

Hence my question: why should this be disabled? Is it to fix an issue where the iptables
backend is used when it shoudln't, or to remove  a dependency that is effectively unused,
or what?

Could you provide any real issues caused by the libiptc backend?

Note, it is already commented by Zbignew in the above, the libiptc backend is used as a fallback when we cannot use nf_tables through netlink.
If I understand correctly, that happens only when the corresponding kernel modules are not installed, but all required kernel modules are provided by kernel-core.rpm.
So, only situation I can imagine when the libiptc backend is used is when an image created without the modules (ie, copying binaries manually rather than using rpm) runs in a vm or so.

Anyway, without any clear reproducers, we cannot take any actions about this...

(In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> Let me reiterate:
> systemd never calls any executables directly. So let's not talk about the
> iptables executable
> and alternatives, it's not directly relevant.

The problem is mixed use of legacy iptables or libiptc and iptables-nft or
nftables. For that matter, alternatives configuration is as relevant as systemd
behaviour or firewalld configuration.

> Systemd either does some nftables setup using netlink directly, or (if
> compiled in),
> does iptables setup using libiptc. Right now, both backends are available,
> and
> nftables is preferred, i.e. it is probed first.

This is good to know. So installations running without nftables installed are
fine and so are those with nftables installed and in use. The only problematic
scenario is usage of legacy iptables by users while nftables is installed. In
that case, users won't see the rules added by systemd.

> Hence my question: why should this be disabled? Is it to fix an issue where
> the iptables
> backend is used when it shoudln't, or to remove  a dependency that is
> effectively unused,
> or what?

My concern was with mixed use of the technologies causing confusion as each is
invisible to the other. Though given that systemd defaults to nftables if
available means removing support for legacy iptables (via libiptc) won't
improve the situation - in fact, it causes trouble if nftables is not
available.

(In reply to Yu Watanabe from comment #6)
[...]
> Anyway, without any clear reproducers, we cannot take any actions about
> this...

Yes, I agree. And with the given systemd default I don't think there's much to
improve, at least not with feasible effort. Assuming that legacy iptables will
eventually lose relevance, this remaining compatibility problem will fade as
well.

I'll therefore close this ticket, sorry for the noise.

This will be done in rawhide now.

This was done a while back. Let's close this.