On Tue, 10 Sep 2019, Julian Andres Klode wrote: > Hi folks, > > it turns out that lxd is broken by iptables now using the nft > based stuff, because lxd is still using the legacy one from > inside the snap. > > This provides a terrible experience because networking in lxd > is not working at all once you enable ufw.
Is this because ufw uses whatever is on the system (ie, nft default) and lxd is using whatever is in the snap (ie, historic iptables which with iptables 1.8 translates to 'iptables-legacy') and this means that both backends are in use, which results in a mixed view of things? The man pages for iptables-nft/iptables-legacy don't call this out as a problem, but README.Debian does: NOTE: make sure you don't mix iptables-legacy and iptables-nft rulesets in the same machine at the same time just for sanity and to avoid unexpected behaviours in your network. > I'd suggest we increase the priority of iptables-legacy for eoan, > so that it is the default, and move the switch to xtables-nft-based > one to next release. > > This will allow us to have working lxd networking, and gives > the lxd team some breathing room. This makes sense to me. Besides, there are still bugs trickling in where the nft backend isn't acting fully compatibly anyway. However, it would be nice to use the nft backend by default by 20.04, ie, at the opening of the cycle. That said, this is a very real immediate problem for snaps on 19.10+, Buster+ and Ubuntu Core (CC'ing Samuele and Michael specifically) since the only available bases are based on xenial and bionic and snaps can only stage-packages from xenial and bionic, so snaps that plugs 'firewall-control' (or classic snaps) will by definition by far tend to use 'legacy' (unless they build iptables from source). Even though the system might have the nft backend enabled. Furthermore, the man page for iptables-nft says that kernel >= 4.17 is required for the nft backend (but ISTR issues in Debian with > 4.19) and its entirely possible someone could be running a system with an older kernel with a newer user space (eg, core20 snap with bionic kernel snap). I'm not sure how to fix this. The only thing that seems reasonable is for snaps to only be able to use the correct one that matches the host/kernel. To pull that off snapd would need to examine the capabilities and configuration of the running system then bind mount iptables/etc from the host into runtime of the snap (the review-tools could flag if snaps ship these binaries). Alternatively, an iptables snapcraft part could be created that at runtime can interrogate whether to use the nft or legacy backends (or snapd exposes which backend is in use to the snap so it can decide). I suspect that Michael and Samuele will want to move the snap-specific parts of this discussion to the snapcraft forum, but +1 from me to prefer 'legacy' for the time being in Ubuntu. -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel