The firewalld autopkgtest fail in disco on what looks like an iptables issue
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/f/firewalld/20190315_154203_ef4d6@/log.gz
'Mar 15 15:41:39 autopkgtest firewalld[1691]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.2 (nf_tables):
line 4: RULE_REPLACE failed (No such file or directory): rule in chain INPUT
line 4: RULE_REPLACE failed (No such file or directory): rule in chain OUTPUT'
That looks like the issue reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694 which is fixed in upstream iptables
https://git.netfilter.org/iptables/commit/?id=947c51c95
That fix seems to depends on git master changes from libnftnl
https://git.netfilter.org/libnftnl/log/
('chain: Support per chain rules list' and following commits)
Unsure at this point what's best disco, if we should start looking at backporting those changes?
I took a look at this and found that:
a) firewalld root-unittests autopkgtests fail when using either iptables 1.6 or 1.8 in release due to https:/
b) firewalld smoke-with-
c) someone in the Debian bug https:/
d) firewalld in 0.6.3-5 introduced the dependency on iptables 1.8.1 and dropped the recommends on ebtables. Dropping this and keeping iptables at 1.6 results in allowing smoke-with-
e) adjust iptables.postinst to use a lower update-alternatives priority such that iptables-legacy is used results in allowing smoke-with-
Attempting to cherrypick all the patches to try to fix this is too regression-prone IME (indeed, there was one known regression with the patches; who knows how many more are lurking at the tip of upstream). I also don't want to take a git snapshot for similar reasons. I would much rather wait for upstream to release 1.8.3, much like Debian is.
This leaves us with 3 options:
a) leave 1.6 in disco and adjust the firewalld packaging to not require 1.8
b) adjust 1.8 in disco to prefer the legacy iptables commands instead of nft
c) keep everything as is and ignore the firewalld error. This is how Debian Buster is going to release
Since this represents a real bug in iptables, I think 'c' is out. While 'b' is an option, it is less well tested and I prefer 'a'. Once iptables 1.8.3 is out and/or Debian fixes 914694, then we can pull 1.8 into the archive. We will definitely want 1.8 in for 20.04 LTS.
I will remove 1.8 from disco-proposed and upload a firewalld with the adjusted Depends/Recommends, but someone else should look at the firewalld autopkgtest ipset regression.