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.
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
updates to 1.4.13 are in testing now. Let me know if this fixes your issue.
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.
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!
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