[Bug 1832297] Re: usrmerge changes path of iptables - please update libvirt on a merge of 1.8.1-x

[Christian Ehrhardt ]

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+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).


** Changed in: libvirt (Ubuntu)
       Status: Invalid => Triaged

** Changed in: iptables (Ubuntu)
       Status: Fix Released => New

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1832297

Title:
  usrmerge changes path of iptables - please update libvirt on a merge
  of 1.8.1-x

Status in Ubuntu Cloud Archive:
  New
Status in iptables package in Ubuntu:
  New
Status in libvirt package in Ubuntu:
  Triaged

Bug description:
  Libvirt has now the paths for ip-/ip6-/eb-tables set in d/rules (by Debian)
    /usr/sbin/ebtables
    /usr/sbin/iptables
    /usr/sbin/ip6tables
    
  But those paths are changing over time, most liikely due to usermerge activities.

  Bionic (as common backport target)
  iptables 1.6.1-2ubuntu2              => /sbin
  ebtables 2.0.10.4-3.5ubuntu2         => /sbin

  Eoan 
  iptables 1.6.1-2ubuntu3              => /sbin 
  ebtables 2.0.10.4+snapshot20181205-3 => /usr/sbin

  Debian
  iptables 1.8.2-4  => all in /usr/sbin
  ebtables (bin merged into the above)

  Due to that while merging libvirt I adapted to the current situation in Eoan for now.
  But this is only catched in build time tests and even there only listed as skip (binary not found) not as fail.
  Further at least the autopkgtests won't excercise this path, so once someone is merging the more recent iptables to Eoan this will somewhat silently break.

  For awareness I opened this bug against libvirt & iptables so that the
  one merging the latter is aware to drop [1] of the former for a
  rebuild.

  [1]: https://git.launchpad.net/~libvirt-
  maintainers/ubuntu/+source/libvirt/commit/?id=deccb0d6e761ec36a19083f3b4e52e64ac65a6f2

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1832297/+subscriptions