usrmerge changes path of iptables - please update libvirt on a merge of 1.8.1-x (also affects backports to undo that path change)

[Christian Ehrhardt ]

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

[Christian Ehrhardt  (paelzer)]

For further awareness I added a UCA task as back in Bionic the paths are again different.
There also ebtables (which means all three binaries) are in /sbin/

That means on backports to Bionic this path needs to be adapted to match.

[Christian Ehrhardt  (paelzer)]

Hmm things seem to have raced in my build envs and containers.
Fortunately Eoan is already completed

# which ebtables iptables ip6tables
/usr/sbin/ebtables
/usr/sbin/iptables
/usr/sbin/ip6tables

Ok then I can make libvirt to use these now, but this is still important to know for backports to Bionic.

[Christian Ehrhardt  (paelzer)]

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 5.4.0-0ubuntu1

---------------
libvirt (5.4.0-0ubuntu1) eoan; urgency=medium

  * Merged with Debian git 5.3.0-1~1.gbp7b1637 and upstreams 5.4 release
    Among many other new features and fixes this includes fixes for:
    LP: #1759509 - virsh dompmwakeup fails to wake VM from dompmsuspend state
    Remaining changes:
    - Disable libssh2 support (universe dependency)
    - Disable firewalld support (universe dependency)
    - Set qemu-group to kvm (for compat with older ubuntu)
    - Additional apport package-hook
    - Autostart default bridged network (As upstream does, but not Debian).
      In addition to just enabling it our solution provides:
      + do not autostart if subnet is already taken (e.g. in guests).
      + iterate some alternative subnets before giving up
    - d/p/ubuntu/Allow-libvirt-group-to-access-the-socket.patch: This is
      the group based access to libvirt functions as it was used in Ubuntu
      for quite long.
      + d/p/ubuntu/daemon-augeas-fix-expected.patch fix some related tests
        due to the group access change.
      + d/libvirt-daemon-system.postinst: add users in sudo to the libvirt
        group.
    - ubuntu/parallel-shutdown.patch: set parallel shutdown by default.
    - Update Vcs-Git and Vcs-Browser fields to point to launchpad
    - Xen related
      - d/p/ubuntu/ubuntu-libxl-qemu-path.patch: this change was split. The
        section that adapts the path of the emulator to the Debian/Ubuntu
        packaging is kept.
      - d/p/ubuntu/ubuntu-libxl-Fix-up-VRAM-to-minimum-requirements.patch: auto
        set VRAM to minimum requirements
      - d/p/ubuntu/xen-default-uri.patch: set default URI on xen hosts
      - Add libxl log directory
      - libvirt-uri.sh: Automatically switch default libvirt URI for users on
        Xen dom0 via user profile (was missing on changelogs before)
    - d/p/ubuntu/apibuild-skip-libvirt-common.h: drop libvirt-common.h from
      included_files to avoid build failures due to duplicate definitions.
    - Update README.Debian with Ubuntu changes
    - Enable some additional features on ppc64el and s390x (for arch parity)
      + systemtap, zfs, numa and numad on s390x.
      + systemtap on ppc64el.
    - d/t/control, d/t/smoke-qemu-session: fixup smoke-qemu-session by making
      vmlinuz available and accessible (Debian bug 848314)
    - d/t/control, d/t/smoke-lxc: fix up lxc smoke test isolation
    - d/p/ubuntu/ubuntu_machine_type.patch: accept ubuntu types as pci440fx
    - Further upstreamed apparmor Delta, especially any new one
      Our former delta is split into logical pieces and is either Ubuntu only
      or is part of a continuous upstreaming effort.
      Listing related remaining changes in debian/patches/ubuntu-aa/:
      + 0001-apparmor-Allow-pygrub-to-run-on-Debian-Ubuntu.patch: apparmor:
        Allow pygrub to run on Debian/Ubuntu
      + 0003-apparmor-libvirt-qemu-Allow-read-access-to-overcommi.patch:
        apparmor, libvirt-qemu: Allow read access to overcommit_memory
      + 0007-apparmor-libvirt-qemu-Allow-owner-read-access-to-PRO.patch:
        apparmor, libvirt-qemu: Allow owner read acc...

[Christian Ehrhardt  (paelzer)]

First of all I beg your pardon, I'm sure there was a similar discussion recently but I only find this bug which is older. I think it was something paride found, so maybe it was on IRC?

Well I tried to proactively let you know via this bug months before anyway :-)

Well wherever that other recent discussion was I was made aware that people are affected
o/ gpiccoli

You (UCA) really have to fix this on backporting, just change the path override in d/rules.

For people affected the workaround for now is:
$ sudo ln -s /sbin/iptables /usr/sbin/iptables
$ sudo ln -s /sbin/ebtables /usr/sbin/ebtables
If you do that after libvirt is already installed do:
$ sudo systemctl restart libvirtd

The latter (or the install) will then auto-start the network as intended.

[Christian Ehrhardt  (paelzer)]

FYI - brought up again in bug 1853013
There it now is finally addressed it seems.

[Chris MacNaughton (chris.macnaughton)]

I'm marking this Fix Release as the bug is resolved in the duplicate that paelzer noticed