Working config in eoan, bind9 fails after upgrade to fossa

Bug #1874568 reported by Lawrence
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
bind-dyndb-ldap (Ubuntu)
Fix Released
Undecided
Unassigned
Focal
In Progress
Undecided
Timo Aaltonen
bind9 (Ubuntu)
Confirmed
Undecided
Unassigned
Focal
In Progress
Undecided
Timo Aaltonen

Bug Description

Configuration was working in Eoan. Just upgraded to Fossa. Bind9(named) will not start. Syslog show the following:

Apr 23 16:55:58 ltserver2 named[1611]: starting BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>
Apr 23 16:55:58 ltserver2 named[1611]: running on Linux x86_64 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020
Apr 23 16:55:58 ltserver2 named[1611]: built with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-OLooom/bind9-9.16.1=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
Apr 23 16:55:58 ltserver2 named[1611]: running as: named -f -u bind
Apr 23 16:55:58 ltserver2 named[1611]: compiled by GCC 9.3.0
Apr 23 16:55:58 ltserver2 named[1611]: compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
Apr 23 16:55:58 ltserver2 named[1611]: linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
Apr 23 16:55:58 ltserver2 named[1611]: compiled with libxml2 version: 2.9.10
Apr 23 16:55:58 ltserver2 named[1611]: linked to libxml2 version: 20910
Apr 23 16:55:58 ltserver2 named[1611]: compiled with json-c version: 0.13.1
Apr 23 16:55:58 ltserver2 named[1611]: linked to json-c version: 0.13.1
Apr 23 16:55:58 ltserver2 named[1611]: compiled with zlib version: 1.2.11
Apr 23 16:55:58 ltserver2 named[1611]: linked to zlib version: 1.2.11
Apr 23 16:55:58 ltserver2 named[1611]: ----------------------------------------------------
Apr 23 16:55:58 ltserver2 named[1611]: BIND 9 is maintained by Internet Systems Consortium,
Apr 23 16:55:58 ltserver2 named[1611]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Apr 23 16:55:58 ltserver2 named[1611]: corporation. Support and training for BIND 9 are
Apr 23 16:55:58 ltserver2 named[1611]: available at https://www.isc.org/support
Apr 23 16:55:58 ltserver2 named[1611]: ----------------------------------------------------
Apr 23 16:55:58 ltserver2 named[1611]: adjusted limit on open files from 524288 to 1048576
Apr 23 16:55:58 ltserver2 named[1611]: found 2 CPUs, using 2 worker threads
Apr 23 16:55:58 ltserver2 named[1611]: using 2 UDP listeners per interface
Apr 23 16:55:58 ltserver2 named[1611]: using up to 21000 sockets
Apr 23 16:55:58 ltserver2 named[1611]: loading configuration from '/etc/bind/named.conf'
Apr 23 16:55:58 ltserver2 named[1611]: reading built-in trust anchors from file '/etc/bind/bind.keys'
Apr 23 16:55:58 ltserver2 named[1611]: looking for GeoIP2 databases in '/usr/share/GeoIP'
Apr 23 16:55:58 ltserver2 named[1611]: using default UDP/IPv4 port range: [32768, 60999]
Apr 23 16:55:58 ltserver2 named[1611]: using default UDP/IPv6 port range: [32768, 60999]
Apr 23 16:55:58 ltserver2 named[1611]: listening on IPv4 interface enp3s0, <LocalIPAddress>#53
Apr 23 16:55:58 ltserver2 named[1611]: IPv6 socket API is incomplete; explicitly binding to each IPv6 address separately
Apr 23 16:55:58 ltserver2 named[1611]: listening on IPv6 interface lo, ::1#53
Apr 23 16:55:58 ltserver2 named[1611]: listening on IPv6 interface enp3s0, <IP6Address>%2#53
Apr 23 16:55:58 ltserver2 named[1611]: unable to set effective uid to 0: Operation not permitted
Apr 23 16:55:58 ltserver2 named[1611]: generating session key for dynamic DNS
Apr 23 16:55:58 ltserver2 named[1611]: unable to set effective uid to 0: Operation not permitted
Apr 23 16:55:58 ltserver2 named[1611]: sizing zone task pool based on 0 zones
Apr 23 16:55:58 ltserver2 named[1611]: none:100: 'max-cache-size 90%' - setting to 3513MB (out of 3903MB)
Apr 23 16:55:58 ltserver2 named[1611]: set up managed keys zone for view _default, file 'managed-keys.bind'
Apr 23 16:55:58 ltserver2 named[1611]: loading DynDB instance 'MY_FULLY_Qualified_LOCAL_DNS_NAME' driver '/usr/lib/bind/ldap.so'
Apr 23 16:55:58 ltserver2 named[1611]: failed to dynamically load instance 'MY_FULLY_Qualified_LOCAL_DNS_NAME' driver '/usr/lib/bind/ldap.so': /usr/lib/bind/ldap.so: undefined symbol: cfg_parse_buffer2 (failure)
Apr 23 16:55:58 ltserver2 named[1611]: dynamic database 'dns.schapker.athome' configuration failed: failure
Apr 23 16:55:58 ltserver2 named[1611]: loading configuration: failure
Apr 23 16:55:58 ltserver2 named[1611]: exiting (due to fatal error)
Apr 23 16:55:58 ltserver2 systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE
Apr 23 16:55:58 ltserver2 systemd[1]: named.service: Failed with result 'exit-code'.

(I have attempted to remove personal identifiable information above. That's shouldn't hamper diagnosis of this issue)

Based on the error, I presume some code is missing somewhere.

I believe "/usr/lib/bind/ldap.so" comes from bind-dyndb-ldap package. I'm not "new" to Linux, but I do not regularly create bugs, so I'm not certain what else may be necessary.

This is kind of an issue for me as now I do not have a working DNS server since the upgrade. Any assistance would be greatly appreciated!

These are the "bind9" packages I have installed:
bind9-dnsutils/focal,now 1:9.16.1-0ubuntu2 amd64 [installed,automatic]
bind9-dyndb-ldap/focal,now 11.2-1build2 amd64 [installed]
bind9-host/focal,now 1:9.16.1-0ubuntu2 amd64 [installed,automatic]
bind9-libs/focal,now 1:9.16.1-0ubuntu2 amd64 [installed,automatic]
bind9-utils/focal,now 1:9.16.1-0ubuntu2 amd64 [installed,automatic]
bind9/focal,now 1:9.16.1-0ubuntu2 amd64 [installed,automatic]

(fresh upgrade from Eoan to Focal, with no known deviations from Focal packages)

Larry Schapker

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Yes, it won't work until it has been ported to 9.16, and that didn't make it in focal, but probably as an SRU later.

Are you running freeipa-server? Did you not notice it's not even available in focal?

Changed in bind-dyndb-ldap (Ubuntu):
status: New → Confirmed
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

So I think bind9 should've added a Breaks: bind-dyndb-ldap, but we can still add that.

The only short-term solution is to downgrade bind9, not sure if the eoan packages actually work on focal still, but at least they install. First you need to have an entry for eoan main in /etc/apt/sources.list and run apt update:

echo 'deb http://archive.ubuntu.com/ubuntu/ eoan-updates main restricted' >> /etc/apt/sources.list
apt update

and then downgrade bind9:

apt install bind9=1:9.11.5.P4+dfsg-5.1ubuntu2.1 bind9utils=1:9.11.5.P4+dfsg-5.1ubuntu2.1 libbind9-161=1:9.11.5.P4+dfsg-5.1ubuntu2.1 libisccc161=1:9.11.5.P4+dfsg-5.1ubuntu2.1 libisccfg163=1:9.11.5.P4+dfsg-5.1ubuntu2.1 liblwres161=1:9.11.5.P4+dfsg-5.1ubuntu2.1

Changed in bind (Ubuntu):
status: New → Confirmed
Revision history for this message
Lawrence (larryschapker) wrote :

I am running with OpenLdap (slapd). I will attempt to downgrade using your instructions. One way or another, we'll get it remedied.

Thank you!!!

Revision history for this message
Lawrence (larryschapker) wrote :

I would like to add that I required to turn off "Unattended-Upgrade" because the next morning, bind9 was back to version 9.16.

Go to: https://help.ubuntu.com/community/AutomaticSecurityUpdates?_ga=2.129122693.848380658.1588022835-388947123.1587602982#Determining_the_current_configuration

I just made this change, so I hope it doesn't circumvent me again tomorrow... <grin>

Revision history for this message
Balint Reczey (rbalint) wrote :

@larryschapker You can blacklist packages in unattended-upgrades or mark them for all APT operations (also honored by unattended-upgrades):

$ sudo apt-mark hold hello
hello set on hold.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bind-dyndb-ldap - 11.4-1

---------------
bind-dyndb-ldap (11.4-1) unstable; urgency=medium

  * New upstream release.
  * bind-9.16-support.diff: Dropped, upstream.

 -- Timo Aaltonen <email address hidden> Fri, 18 Sep 2020 12:01:09 +0300

Changed in bind-dyndb-ldap (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

bind needs to provide bind9-dev again

Changed in bind (Ubuntu Focal):
assignee: nobody → Timo Aaltonen (tjaalton)
status: New → In Progress
Changed in bind-dyndb-ldap (Ubuntu Focal):
assignee: nobody → Timo Aaltonen (tjaalton)
status: New → In Progress
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

and then bind-dyndb-ldap should be backported from groovy, there's no point in cherry-picking stuff

Timo Aaltonen (tjaalton)
affects: bind (Ubuntu) → bind9 (Ubuntu)
Revision history for this message
F. H. (hoeze) wrote :

Is there any update yet?
I would really need freeipa in 20.04.

Revision history for this message
Stephen Winnall (winnall) wrote :

I have this problem too (see https://answers.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+question/695714). My first attempt at backporting from Groovy failed. It looks like it might need Groovy’s libc6 too, which seems a bit like a show stopper...

Is anyone working on this?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.