/usr/sbin/ebtables is managed by update alternatives.
But iptables continues to surprise.
In an sbuild build env of Eoan I get:
# which ebtables iptables ip6tables
/usr/sbin/ebtables
/sbin/iptables
/sbin/ip6tables
While in an Eoan container I have:
# which ebtables iptables ip6tables
/usr/sbin/ebtables
/usr/sbin/iptables
/usr/sbin/ip6tables
Let me recycle the container as it might have some old crap.
No it stays the same...
Both are on 2.0.10.4+snapshot20181205-1ubuntu1 / 1.6.1-2ubuntu3.
To make that three a Eoan VM as of today has the same as the container.
All of them (sbuild+lxd+vm) have the non usr path in the package itself.
dpkg -L iptables | grep 'bin\/iptables$'
/sbin/iptables
And the /usr/sbin path that exists in the container
Hmm, something in the container and the VM brings that /usr/sbin mapping to work which fails in the build environment, maybe because it is "just" a chroot?
/var/lib/dpkg/info/iptables.* has no further magic maintscripts that would explain.
For now in libvirt lets set the real paths as carried by iptables packages.
This will keep us on the safe side.
But that also means we are back at my initial assumption that on an iptables 1.8.1 merge one might want to remove that (unless /sbin/iptables is kept as compat, then I can clear it next cycle).
Hmm interesting ...
/usr/sbin/ebtables is managed by update alternatives.
But iptables continues to surprise.
In an sbuild build env of Eoan I get:
# which ebtables iptables ip6tables
/usr/sbin/ebtables
/sbin/iptables
/sbin/ip6tables
While in an Eoan container I have:
# which ebtables iptables ip6tables
/usr/sbin/ebtables
/usr/sbin/iptables
/usr/sbin/ip6tables
Let me recycle the container as it might have some old crap.
No it stays the same...
Both are on 2.0.10. 4+snapshot20181 205-1ubuntu1 / 1.6.1-2ubuntu3.
To make that three a Eoan VM as of today has the same as the container.
All of them (sbuild+lxd+vm) have the non usr path in the package itself.
dpkg -L iptables | grep 'bin\/iptables$'
/sbin/iptables
And the /usr/sbin path that exists in the container
Hmm, something in the container and the VM brings that /usr/sbin mapping to work which fails in the build environment, maybe because it is "just" a chroot?
/var/lib/ dpkg/info/ iptables. * has no further magic maintscripts that would explain.
For now in libvirt lets set the real paths as carried by iptables packages.
This will keep us on the safe side.
But that also means we are back at my initial assumption that on an iptables 1.8.1 merge one might want to remove that (unless /sbin/iptables is kept as compat, then I can clear it next cycle).