Closed FrostyX closed 3 weeks ago
copr-be-dev has iptables-nft and beaker tests passed and it's working fine - we should try reboot copr-be-dev and observate the machine, then do it with crossed fingers on prod.
also do this for internal copr
^ do this explicitly in ansible
iptables-legacy vs iptables-nft: https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-their-relationship-with-nftables
On all Fedora Copr servers (both STG and production) I did:
$ dnf install iptables-nft
$ dnf erase iptables-legacy
$ systemctl restart iptables
$ iptables -V
iptables v1.8.9 (nf_tables)
$ iptables -L
Which should IMHO do the switch. I tried rebooting all STG machines and they all came back up and were able to build packages. I also tried disconnecting from SSH on production machines and reconnecting again to make sure the new iptables doesn't cut us off from SSH.
^ do this explicitly in ansible
I tried grepping iptables-nft
and nftables
in the ansible repo and it found nothing. So I decided to swap the packages manually on servers without using ansible. We should check that the iptables-legacy
package wasn't pulled in again when we upgrade our servers from F39 to F40 or F41.
I did the same for internal Copr, so I think we can close now.
FTR, I messed up, and accidentally erased iptables-legacy
with all the dependencies from internal Copr production backend before installing iptables-nft
. I ran the playbook to install them back - it install some of them but not all. It didn't seem to break anything though, it still builds fine.
@nirik tried to uninstall
iptables-legacy
from copr-be-dev and it removed many unexpected packages. When I ran the playbook,iptables-legacy
got pulled back in. Something depends on it. The solution was to installiptables-nft
first, then removeiptables-legacy
, and then run the playbook again.At this moment
iptables-legacy
is still present on copr-be production.