bind9-dyndb-ldap has unmet dependencies

[Jan Graichen]

[ Impact ]

There is a tight coupling between src:bind-dyndb-ldap and src:bind9, such that everytime bind9 is updated, even if it's a simple no-change rebuild, src:bind-dyndb-ldap has to be rebuilt too.

This is often forgotten, leading to multiple repeated bugs against src:bind-dyndb-ldap.

The fix for now is to rebuild src:bind-dyndb-ldap, and to avoid it from happening again, add a DEP8 test to it so that a src:bind9 update won't be released without this rebuild.

Ideally this coupling shouldn't be that tight, and some ideas are floating around (see [1], [2], and [3]). But for now, I think this is the quickest way to avoid hitting this problem again in the near future.

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503
2. https://pagure.io/bind-dyndb-ldap/issue/225
3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21

[ Test Plan ]

The fix is to rebuild the src:bind-dyndb-ldap package with the current src:bind9 in the archive for the affected ubuntu release.

With the build succeeding, and the dyndb-ldap DEP8 test also passing, the verification can be considered successfull.

[ Where problems could occur ]

With this new DEP8 change, a bind9 update can be blocked by a bind-dyndb-ldap failure to build or run with it.

While this is exactly the intent (not leave a broken bind-dyndb-ldap package in the release), there is a history indicating that bind-dyndb-ldap can be late in catching up to bind9 changes. We may reach a situation where an important bind9 security update, for example, will be blocked by a failing dyndb-ldap test, and it may be difficult to fix bind-dyndb-ldap in time, specially if the security update is under embargo and the bind-dyndb-ldap developers do not yet have details of the changes.

[ Other Info ]
See also bug https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650 which adds the same test to the src:bind9 package.

[Original Description]

bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap:

    ~# apt install bind9 bind9-dyndb-ldap
    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    Some packages could not be installed. This may mean that you have
    requested an impossible situation or if you are using the unstable
    distribution that some required packages have not yet been created
    or been moved out of Incoming.
    The following information may help to resolve the situation:

    The following packages have unmet dependencies:
     bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed
    E: Unable to correct problems, you have held broken packages.

    ~# apt-cache policy bind9
    bind9:
    Installed: (none)
    Candidate: 1:9.18.1-1ubuntu1.1
    Version table:
        1:9.18.1-1ubuntu1.1 500
            500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
            500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        1:9.18.1-1ubuntu1 500
            500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

    ~# apt-cache policy bind9-dyndb-ldap
    bind9-dyndb-ldap:
    Installed: (none)
    Candidate: 11.9-5build2
    Version table:
        11.9-5build2 500
            500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

[Martin Cheatle (beyond990)]

I'm having the same issue on ARM based packages.

bind01:~$ sudo apt install bind9-dyndb-ldap
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed
E: Unable to correct problems, you have held broken packages.
bind01:~$ apt-cache policy bind9
bind9:
  Installed: 1:9.18.1-1ubuntu1.1
  Candidate: 1:9.18.1-1ubuntu1.1
  Version table:
 *** 1:9.18.1-1ubuntu1.1 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy-updates/main arm64 Packages
        500 http://ports.ubuntu.com/ubuntu-ports jammy-security/main arm64 Packages
        100 /var/lib/dpkg/status
     1:9.18.1-1ubuntu1 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
bind01:~$ apt-cache policy bind9-dyndb-ldap
bind9-dyndb-ldap:
  Installed: (none)
  Candidate: 11.9-5build2
  Version table:
     11.9-5build2 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy/universe arm64 Packages

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[rwruck (robert-tweerlei)]

Requirements have diverged further:

bind9 : Depends: bind9-libs (= 1:9.18.1-1ubuntu1.3)
bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1)

[Andreas Hasenack (ahasenack)]

This is being fixed in bug #2003586, and the package is already in proposed:

https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.9-5ubuntu0.22.04.1
https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-1ubuntu0.22.10.1

Unfortunately the changes file doesn't list this bug, so it won't be auto-closed once it hits updates (which I'm working on right now). Please, if you can test the package when it's in updates (or proposed right now), add a comment here.

[Michael Makalkin (regul8or)]

Hope it's a right place to ask. Found this thread trying to install bind9-dyndb-ldap. Trying to replicate a process in https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/2003586/comments/11 have the following:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy

# apt list | grep bind9

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

bind9-dev/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 amd64
bind9-dnsutils/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-doc/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 all
bind9-dyndb-ldap/jammy-updates 11.9-5ubuntu0.22.04.1 amd64
bind9-host/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-libs/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-utils/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 amd64
bind9/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 amd64
bind9utils/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 all
libbind9-161/jammy 1:9.11.19+dfsg-2.1ubuntu3 amd64

# cat <<EOF >/etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list
> # Enable Ubuntu proposed archive
> deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed restricted main multiverse universe
> EOF

# cat /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list
# Enable Ubuntu proposed archive
deb http://archive.ubuntu.com/ubuntu/ jammy-proposed restricted main multiverse universe

# apt update && apt dist-upgrade -y
...

# apt install -y bind9-dyndb-ldap
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.12-0ubuntu0.22.04.1) but 1:9.18.12-0ubuntu0.22.04.2 is to be installed
E: Unable to correct problems, you have held broken packages.

# apt list | grep bind9

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

bind9-dev/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 amd64
bind9-dnsutils/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-doc/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 all
bind9-dyndb-ldap/jammy-updates 11.9-5ubuntu0.22.04.1 amd64
bind9-host/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-libs/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-utils/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 amd64
bind9/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 amd64
bind9utils/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 all
libbind9-161/jammy 1:9.11.19+d...

[Andreas Hasenack (ahasenack)]

bind-dyndb-ldap was changed[1] to always require an exact bind version:

d/rules:
BIND9_LIBS_VER = $(shell dpkg-query -f='$${Version}\n' -W bind9-libs)
...
override_dh_gencontrol:
 dh_gencontrol -- \
  -V'bind9-libs:Version=$(BIND9_LIBS_VER)'

d/control[2]:
Depends: ${misc:Depends}, ${shlibs:Depends},
 bind9 (>= 9.11),
 bind9-libs (= ${bind9-libs:Version}),

This was done in version 11.9-5[3].

At first glance, for a stable release, I think this dependency could be relaxed to a >=. But to do that, I would like to see a dep8 test that exercises this package together with bind9. Probably in the bind9 source package, because that is the one that always gets updated.

1. https://git.launchpad.net/ubuntu/+source/bind-dyndb-ldap/tree/debian/rules#n24
2. https://git.launchpad.net/ubuntu/+source/bind-dyndb-ldap/tree/debian/control#n22
3. https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.9-5

[Andreas Hasenack (ahasenack)]

I'll rebuild this, and also add DEP8 tests where appropriate (here and/or in bind9 itself), so that this gets caught before another such update is released. That will also help to determine if we still need the strict Depends (=), instead of perhaps something like ">=".

[Andreas Hasenack (ahasenack)]

Adding bind9 to track an added DEP8 test to it.

[Andreas Hasenack (ahasenack)]

Bug about the dep8 tests: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/2032650

[Andreas Hasenack (ahasenack)]

Summary:

# focal

focal's src:bind-dyndb-ldap situation is more complicated, a simple rebuild won't fix it. In focal we have two bind9 sources: src:bind9-libs, and src:bind9, at very different versions. Focal's bind-dyndb-ldap does not work with the version of src:bind9 shipped there, hence src:bind9-libs being available at a lower version. This allows src:bind-dyndb-ldap to build, but it doesn't load correctly into bind9's server at runtime. I don't even know if it can be made to work. TBD

# jammy and later

A simple rebuild fixes it. I checked if we can relax the bind9-libs dependency, but even if we could, it won't help: src:bind9 in jammy and later produces very specific libraries, with the full ubuntu version in their soname:

$ objdump -x /lib/x86_64-linux-gnu/libisc-9.18.12-0ubuntu0.22.04.2-Ubuntu.so | grep SONAME
  SONAME libisc-9.18.12-0ubuntu0.22.04.2-Ubuntu.so

So even a simple no-change rebuild of src:bind9 in these releases will change the soname, and will require a src:bind-dyndb-ldap rebuild to link with the new one.

The plan for jammy and later, therefore, is to add a dep8 test to these packages (src:bind-dyndb-ldap and src:bind9) which will load the ldap.so module into bind. This will block a src:bind9 update without an accompaining src:bind-dyndb-ldap update, because the test will fail without a rebuild.

This is a bit awkward: a package in universe can now block the release of a critical package like bind9 (if the test fails). If we ever get into a situation where a bind9-dyndb-ldap bug (where just a rebuild is not enough to get the test to pass) blocks a critical bind9 update, we will have to override the test.

[Andreas Hasenack (ahasenack)]

There is nothing to do in the bind9 package, so marking that task as invalid. The DEP8 test was added to bind in a separate bug (#2032650).

[Andreas Hasenack (ahasenack)]

Given that the soname in bind9-libs is an exact copy of the package version, including the ubuntu suffix, it will change with even a no-change rebuild:

$ objdump -x usr/lib/x86_64-linux-gnu/libbind9-9.18.12-0ubuntu0.22.04.3~local1-Ubuntu.so | grep SONAME
  SONAME libbind9-9.18.12-0ubuntu0.22.04.3~local1-Ubuntu.so

Note the "~local1" I added for a local rebuild.

That means that even if I force an install of bind9-dyndb-ldap to ignore the Depends line, as if I had relaxed the Depends version, it will still search for the exact bind9 soname it was built with and fail:

$ ldd /usr/lib/bind/ldap.so|grep "not found"
 libdns-9.18.12-0ubuntu0.22.04.1-Ubuntu.so => not found
 libisc-9.18.12-0ubuntu0.22.04.1-Ubuntu.so => not found

Therefore, the "fix" for this bug for now is to rebuild bind-dyndb-ldap everytime bind9 is updated :/ The added DEP8 test will block migration until that is done.

There were some discussions in debian, where this situation is also happening, in bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 and others. One option was to move[2] src:bind-dyndb-ldap into src:bind9 itself, so they get built together, but there are licenses incompatibilities. Timo asked[1] src:bind-dyndb-ldap upstream if they could change the license.

1. https://pagure.io/bind-dyndb-ldap/issue/225
2. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21#note_389188

[Andreas Hasenack (ahasenack)]

Fixed in mantic with the rebuild in https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-6build1

[Andreas Hasenack (ahasenack)]

So in focal we get this missing symbol:

04-Sep-2023 14:33:22.532 failed to dynamically load instance 'ldap_zone' driver '/usr/lib/bind/ldap.so': /usr/lib/bind/ldap.so: undefined symbol: cfg_parse_buffer2 (failure)

That comes from the libisccfg library. If I link with it, however, we get:

04-Sep-2023 14:34:10.260 loading DynDB instance 'ldap_zone' driver '/usr/lib/bind/ldap.so'
04-Sep-2023 14:34:10.269 registering library from dynamic ldap driver, 0x7f88631220d0 != 0x7f884600b010.
04-Sep-2023 14:34:10.269 registering dynamic ldap driver for ldap_zone.
04-Sep-2023 14:34:10.264 mem.c:731: fatal error:
04-Sep-2023 14:34:10.264 malloc failed: Cannot allocate memory
04-Sep-2023 14:34:10.264 exiting (due to fatal error in library)

[Andreas Hasenack (ahasenack)]

The focal situation explained in the last comments above is still more complicated than originally thought. Looks like bind-dyndb-ldap never really worked in focal.

Some options:
a) fire up gdb, and see where exactly it's failing. It could be a symbol clash, an incorrect library being linked in, just incompatible code, or something else;
b) backport a new bind-dyndb-ldap version what works with bind9 9.16.x as shipped in focal. The problem is that src:bind9 in focal does not provide a dev package, so where are no header files nor development libraries to link with. A new binary package built from src:bind9 in focal would have to be created, like bin:bind9-dev that exists in jammy and later.

Given the above, and the fact that there is another LTS where bind-dyndb-ldap works (after this update here in the bug), we think it's not worth it to attempt to fix bind-dyndb-ldap for focal.

If the situation changes (perhaps a patch becomes available, or another solution different from (a) and (b) above, or there is a strong demand to have this fixed in focal), then this can be re-evaluated.

[Timo Aaltonen (tjaalton)]

Hello Jan, or anyone else affected,

Accepted bind-dyndb-ldap into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-4ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Timo Aaltonen (tjaalton)]

Hello Jan, or anyone else affected,

Accepted bind-dyndb-ldap into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.9-5ubuntu0.22.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Michael Makalkin (regul8or)]

Hello Timo,

Tested installing bind9-dyndb-ldap on jammy from -proposed with the following outline:

- enable proposed archive
- install bind9-dyndb-ldap. Dependencies are installed from either jammy-updates/main or jammy/main
- configure apt to allow selective installs of packages from proposed

Everything went smoothly, looks like it's working for now. Those are installed packages:

apt list | grep bind9

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

bind9-dev/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 amd64
bind9-dnsutils/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-doc/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 all
bind9-dyndb-ldap/jammy-proposed,now 11.9-5ubuntu0.22.04.2 amd64 [installed]
bind9-host/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-libs/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9-utils/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9/jammy-updates,jammy-security,now 1:9.18.12-0ubuntu0.22.04.2 amd64 [installed,automatic]
bind9utils/jammy-updates,jammy-security 1:9.18.12-0ubuntu0.22.04.2 all
libbind9-161/jammy 1:9.11.19+dfsg-2.1ubuntu3 amd64

[Timo Aaltonen (tjaalton)]

thanks for testing

[Andreas Hasenack (ahasenack)]

Lunar verification

DEP8 results are green: https://ubuntu-archive-team.ubuntu.com/proposed-migration/lunar/update_excuses.html#bind-dyndb-ldap

Build OK in all arches: https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-4ubuntu0.1

Also did a quick manual install of the proposed package:
$ sudo apt install bind9-dyndb-ldap -t lunar-proposed -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  bind9 bind9-utils dns-root-data
Suggested packages:
  bind-doc
The following NEW packages will be installed:
  bind9 bind9-dyndb-ldap bind9-utils dns-root-data

(...)
$ apt-cache policy bind9-dyndb-ldap
bind9-dyndb-ldap:
  Installed: 11.10-4ubuntu0.1
  Candidate: 11.10-4ubuntu0.1
  Version table:
 *** 11.10-4ubuntu0.1 500
        500 http://br.archive.ubuntu.com/ubuntu lunar-proposed/universe amd64 Packages
        100 /var/lib/dpkg/status
     11.10-4 500
        500 http://br.archive.ubuntu.com/ubuntu lunar/universe amd64 Packages

No installation errors:
$ dpkg -l bind9-dyndb-ldap
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-================-================-============-=================================
ii bind9-dyndb-ldap 11.10-4ubuntu0.1 amd64 LDAP back-end plug-in for BIND

lunar verification succeeded

[Andreas Hasenack (ahasenack)]

For the jammy verification:

DEP8 tests are green:
https://ubuntu-archive-team.ubuntu.com/proposed-migration/jammy/update_excuses.html#bind-dyndb-ldap

Package built correctly in all arches: https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.9-5ubuntu0.22.04.2

And was test-installed in comment #18

Jammy verification succeeded.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bind-dyndb-ldap - 11.9-5ubuntu0.22.04.3

---------------
bind-dyndb-ldap (11.9-5ubuntu0.22.04.3) jammy-security; urgency=medium

  * No-change rebuild for bind9 security update.

 -- Marc Deslauriers <email address hidden> Wed, 20 Sep 2023 15:58:12 -0400

[Michael Makalkin (regul8or)]

Successfully installed 11.9-5ubuntu0.22.04.3 from jammy-updates

[Andreas Hasenack (ahasenack)]

This was fix released for lunar on https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-4ubuntu0.1