Conversation
The dynamically linked RHEL dockerd doesn't strictly need a dependency on nftables (because it doesn't link against libnftables.so). So, commit 1a73c6b didn't make it one. But, it'll already be installed in most places anyway, it'll be required when we deprecate iptables support, and it's needed to try out the experimental nftables support. So, make it a hard dependency now. Signed-off-by: Rob Murray <rob.murray@docker.com>
| %if %{undefined _no_libnftables} | ||
| # When dockerd is not linked against libnftables, the nftables package | ||
| # is not a hard requirement. | ||
| Requires: nftables |
There was a problem hiding this comment.
Not an expert on the nftables, so might be a silly question but Is it safe to unconditionally require nftables, even for systems that don't use it?
My worry is that just installing Docker could alter the configuration of the user system and e.g. stop using the existing iptables rules, or resulting in some conflict between iptables and nft?
There was a problem hiding this comment.
I don't think there's any conflict ... nftables, iptables-nft, and iptables can all be installed on a host.
Using iptables (legacy) and nftables / iptables-nft together in the same netns (mixing xtables and nftables) gets messy. But, even if a host's using legacy iptables, installing nftables won't cause a problem unless both are used.
And, this is RHEL 10 - so it'll probably have nftables, might have iptables-nft, and it's unlikely to have iptables-legacy (because they've moved the kernel module to kernel-modules-extra which "Provides kernel modules for rare hardware. Loading of the module is disabled by default.").
There was a problem hiding this comment.
We also discussed the next steps after this; once our nftables implementation is proven to be complete, we can move the iptables package to be "Recommended" or even less ("Suggests"), or could even be removed from the list.
There was a problem hiding this comment.
And, this is RHEL 10 ...
That was wrong, it's all-RHEL, not CentOS/Fedora because _no_libnftables is only defined for RHEL. But, even so, I think the change is safe.
There was a problem hiding this comment.
We also discussed the next steps after this; once our
nftablesimplementation is proven to be complete, we can move theiptablespackage to be "Recommended" or even less ("Suggests"), or could even be removed from the list.
In Debian at least, it sounds like nftables should be Recommends ("found in all but unusual installations") and iptables should be either Suggests or dropped.
4 participants
- What I did
The dynamically linked RHEL dockerd doesn't strictly need a dependency on nftables (because it doesn't link against libnftables.so). So, commit 1a73c6b didn't make it one.
But, it'll already be installed in most places anyway, it'll be required when we deprecate iptables support, and it's needed to try out the experimental nftables support.
So, make it a hard dependency now.
- Description for the changelog