CentOS 7.9 and Weave 2.9.0

[rajch]

i meet some problem like this,i use centos 7.9 and weave 2.9.0,when i launch weave,it can not modify iptables and show error:
{"log":"FATA: 2025/02/06 00:51:28.780862 configuring iptables: ipt.Append(filter, FORWARD, [-i weave -o weave -j ACCEPT]): running [/sbin/iptables -t filter -I FORWARD 2 -i weave -o weave -j ACCEPT --wait]: exit status 4: iptables v1.8.10 (nf_tables): RULE_INSERT failed (No such file or directory): rule in chain FORWARD\n","stream":"stderr","time":"2025-02-06T00:51:28.780988029Z"}
iptables version is v1.4.21
i will try to test more

Originally posted by @SeesawLiu in #15

[rajch]

@SeesawLiu

This is, I guess, the result of weave defaulting to the nftables backend for iptables in v2.9.0. CentOS 7.9 was still on the legacy backend, I think.

Are you using weave with Docker or Kubernetes?

[Lathrox]

We see similar issues with running Ubuntu 22.04 when changing to iptables-legacy.

We are using weave with docker and when checking which iptables the weave container is pointing to it is /sbin/iptables -> xtables-nft-multi
We have set the env variable IPTABLES_BACKEND to legacy and confirmed that it is set in the container.

If it is some specific information you need then I can provide it.

[rajch]

We see similar issues with running Ubuntu 22.04 when changing to iptables-legacy.

We are using weave with docker and when checking which iptables the weave container is pointing to it is /sbin/iptables -> xtables-nft-multi We have set the env variable IPTABLES_BACKEND to legacy and confirmed that it is set in the container.

If it is some specific information you need then I can provide it.

Could you post the weave container log? Near the start of output, it shows which mode it uses. In the legacy mode, it uses a symbolic link called iptables-legacy instead op iptables.

[Lathrox]

weave log: See included file

$ docker exec weave ls -l /sbin/iptables
lrwxrwxrwx 1 root root 17 Dec 19 07:13 /sbin/iptables -> xtables-nft-multi

$ docker exec weave env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=vm1
WEAVE_PASSWORD=redacted
EXEC_IMAGE=rajchaudhuri/weaveexec:2.9.0
CHECKPOINT_DISABLE=1
IPTABLES_BACKEND=legacy
HOME=/root

For some reason my log doesn't include this message

weave/prog/weave-kube/launch.sh

Line 29 in 8397222

printf "iptables backend mode: %s\n" "$mode"

weave2.log

[rajch]

Multiple incompatibility issues have been found for weave 2.9.0 on CentOS 7.9. For now, you could downgrade to weave 2.8.10, by running:

weave reset --force
sudo curl -L https://reweave.azurewebsites.net/get-weave?version=2.8.10 -o /usr/local/bin/weave
weave launch

on all nodes.

[Lathrox]

Hi,

I found a mistake on my test vm with the weave2.log
I forgot to change the iptables to legacy.
See new weave3.log for the correct iptables on the host.

weave3.log

[rajch]

Hi,

I found a mistake on my test vm with the weave2.log I forgot to change the iptables to legacy. See new weave3.log for the correct iptables on the host.

weave3.log

I figured. Nevertheless, there are issues - the weave script handles the legacy iptables case correctly (without changing the iptables symlink in the container), but the weaveutil binary doesn't. I set up a small CentOS 7.9 cluster to test and discover this.

To correct it, I have to change the entry points of the weave and weaveexec images, which implement the docker plug-in. Luckily, the kubernetes plug-in already allows switching, even does it automatically if need be.

At this point, I am measuring the relative impacts of:

• Allowing full switch back to iptables legacy mode in the next version, by changing the entrypoints as described above.
• Having two sets of releases going forward: 2.8.x series with iptables legacy, and 2.9+.x with iptables nft
• Dropping iptables legacy support altogether (I wish. I only changed the default when multiple people, using more current distros like Alma and Rocky, reported issues. Sure enough, now people using older distros are affected.)

While that happens, could you please go back to using 2.8.10? That works fine on CentOS 7.9. I'll keep this issue open until the future direction is decided.