On Sat, 05 May 2018, Timo Aaltonen wrote:
On 05.05.2018 10:53, Alexander Bokovoy wrote:
> On la, 05 touko 2018, Timo Aaltonen via FreeIPA-users wrote:
>>
>> Hi,
>>
>> Named is crashing here on start, but not if I disable the dyndb part of
>> named.conf. So I assume it's not getting data out of ldap correctly (or
>> correct data), and this from slapd logs might suggest so:
>>
>> [05/May/2018:09:42:02.566222364 +0300] conn=23 op=3 SRCH
>> base="cn=dns,dc=foo,dc=bar" scope=2
>>
filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=host.foo.bar)))"
>> attrs=ALL
>> [05/May/2018:09:42:02.568886490 +0300] conn=23 op=3 RESULT err=0
>> tag=101 nentries=2 etime=0.0002800470
>> [05/May/2018:09:42:02.715423436 +0300] conn=24 op=-1 fd=96 closed - B1
>> [05/May/2018:09:42:02.716084255 +0300] conn=23 op=-1 fd=95 closed
>> error 104 (Connection reset by peer) - TCP connection reset by peer.
>>
>> looking at the install logs everything seemed to go fine until it
>> started named, and ldapsearch doesn't provide any hints either..
> Any stacktrace?
Sure:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007fe56ee3e801 in __GI_abort () at abort.c:79
#2 0x000055e3cba8ee57 in assertion_failed (file=<optimized out>, line=<optimized
out>, type=<optimized out>,
cond=<optimized out>) at ../../../bin/named-pkcs11/main.c:229
#3 0x00007fe57024a7fa in isc_assertion_failed (file=file@entry=0x7fe570cea548
"../../../lib/dns-pkcs11/view.c",
line=line@entry=962, type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7fe570cea728 "view->zonetable != ((void *)0)") at
../../../lib/isc-pkcs11/assertions.c:49
#4 0x00007fe570c5c2aa in dns_view_addzone (view=view@entry=0x7fe56035a780,
zone=<optimized out>)
at ../../../lib/dns-pkcs11/view.c:962
#5 0x000055e3cbaaca77 in configure_zone (config=config@entry=0x7fe571340bc8,
zconfig=0x7fe57133d970,
vconfig=vconfig@entry=0x7fe57133d010, mctx=mctx@entry=0x55e3cd9c6380,
view=view@entry=0x7fe56035a780,
viewlist=viewlist@entry=0x7fe56900f980, aclconf=0x7fe57131a0b0,
added=isc_boolean_false,
old_rpz_ok=isc_boolean_false, modify=isc_boolean_false) at
../../../bin/named-pkcs11/server.c:5661
#6 0x000055e3cba707d1 in configure_view (view=0x7fe56035a780,
viewlist=viewlist@entry=0x7fe56900f980,
config=0x7fe571340bc8, vconfig=vconfig@entry=0x7fe57133d010,
cachelist=cachelist@entry=0x7fe56900f9a0,
bindkeys=0x7fe571344970, mctx=0x55e3cd9c6380, actx=0x7fe57131a0b0,
need_hints=isc_boolean_false)
at ../../../bin/named-pkcs11/server.c:3416
#7 0x000055e3cbab9309 in load_configuration (filename=<optimized out>,
server=server@entry=0x7fe571318010,
first_time=first_time@entry=isc_boolean_true) at
../../../bin/named-pkcs11/server.c:8003
#8 0x000055e3cbabaf33 in run_server (task=<optimized out>, event=<optimized
out>)
at ../../../bin/named-pkcs11/server.c:8672
#9 0x00007fe570271b59 in dispatch (manager=0x7fe57130f010) at
../../../lib/isc-pkcs11/task.c:1140
#10 run (uap=0x7fe57130f010) at ../../../lib/isc-pkcs11/task.c:1312
#11 0x00007fe56f7eb6db in start_thread (arg=0x7fe569010700) at pthread_create.c:463
#12 0x00007fe56ef1f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> The LDAP search result with 2 entries suggests it might be a replication
> conflict. At least the search is expecting to get a single entry back,
> it seems.
this is a single server, no replicas
Looking at the trace, it is failing in the
named code itself. We don't see any
traces of bind-dyndb-ldap here but sinze it is assert(view->zonetable !=
NULL), it is most likely a result of the bind-dyndb-ldap returning an
empty zone somehow.
Not sure what could be done other than debugging it with gdb...
--
/ Alexander Bokovoy