Bug 710628

Summary:	Unbound cannot read root-hints anymore
Product:	[Fedora] Fedora EPEL	Reporter:	Cedric Devillers <cde>
Component:	unbound	Assignee:	Paul Wouters <pwouters>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	el5	CC:	pwouters
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-04-16 21:33:02 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Cedric Devillers 2011-06-03 21:12:08 UTC

Description of problem:

Since ldns update (1.6.8), unbound cannot start anymore if configured to read root-hints file.

Version-Release number of selected component (if applicable):

unbound-1.4.4-1

How reproducible:

Always

Steps to Reproduce:
1. download root-hints here : http://www.internic.net/zones/named.root
2. use config setting : root-hints: "/etc/unbound/named.cache" in unbound.conf
3. Try to start unbound.
  
Actual results:

Unbound fail to start ;

Jun  3 18:22:23 alu-prod-monitoring unbound: [1890:0] error: reading root hints /etc/unbound/named.cache 87: Empty line was returned
Jun  3 18:22:23 alu-prod-monitoring unbound: [1890:0] error: Could not set root or stub hints
Jun  3 18:22:23 alu-prod-monitoring unbound: [1890:0] error: iterator: could not apply configuration settings.
Jun  3 18:22:23 alu-prod-monitoring unbound: [1890:0] error: module init for module iterator failed
Jun  3 18:22:23 alu-prod-monitoring unbound: [1890:0] fatal error: failed to setup modules

Expected results:

Unbound should be able to read root-hints file and start

Additional info:

This bug reports upstream talks about the problem : http://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=337

As suggested there, i've tried to rebuild the unbound srpm, and indeed that fixes the problem.
So unbound for epel should be rebuilt when ldns is updated.
To my opinion, an unbound update to latest 1.4 stable tarball should be a good thing too.

Comment 1 Paul Wouters 2011-06-07 01:42:50 UTC

Yes, I was waiting on ldns-1.6.10 to go play another round of ldns,nsd,unbound updates. I will tackle these over the next few days

Comment 2 Paul Wouters 2011-09-22 02:16:44 UTC

updates to 1.4.13 are in testing now. Let me know if this fixes your issue.

Comment 3 Cedric Devillers 2011-09-28 16:25:53 UTC

I've just upgraded a couple of servers to 1.4.13, and so far so good.

One thing : a "yum update unbound" does not update unbound-libs. Maybe it should be a good idea to be sure those two packages are on the same version.

Comment 4 Paul Wouters 2011-10-06 02:23:02 UTC

I wondered why rpm didnt pick up the dependancy itself, and noticed:

[paul@bofh unbound]$ ldd /usr/sbin/unbound
	linux-vdso.so.1 =>  (0x00007fff7f2cb000)
	libssl.so.10 => /usr/lib64/libssl.so.10 (0x00000031daa00000)
	libldns.so.1 => /usr/lib64/libldns.so.1 (0x00007eff9623e000)
	libevent-1.4.so.2 => /usr/lib64/libevent-1.4.so.2 (0x0000003137e00000)
	librt.so.1 => /lib64/librt.so.1 (0x0000003e24a00000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003e24200000)
	libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003f54600000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00000031da600000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e23a00000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003e23600000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003e30e00000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003e30200000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003e2f200000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003e30600000)
	libz.so.1 => /lib64/libz.so.1 (0x0000003e24600000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x000000313cc00000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003e25a00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003e23200000)
	libutil.so.1 => /lib64/libutil.so.1 (0x0000003e34e00000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003e23e00000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003e31200000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003e2fa00000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003e25200000)

Meaning unbound is not dynamically linking libunbound, but staticly including it.... so updating unbound-libs won't actually update it.

I'll look into this, this is not good!

Comment 5 Paul Wouters 2011-10-11 22:33:51 UTC

Talked to upstream. It can be addressed using configure --enable-allsymbols but that also exports the internal-only functions.

I'll open a new bug for this, and address this in the next release by adding that hardcoded dependency, while trying to convince upstreadm not to produce static builds per default.

I'll close this bug once the last update reaches stable
https://admin.fedoraproject.org/updates/FEDORA-2011-13945