[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
crash in syncprov.c at line 1858
- To: openldap-software@openldap.org
- Subject: crash in syncprov.c at line 1858
- From: Karsten Künne <kuenne@rentec.com>
- Date: Wed, 9 Jan 2008 21:16:21 -0500
- Content-disposition: inline
- Organization: Renaissance Technologies Corp.
- User-agent: KMail/1.9.6 (enterprise 20070831.706792)
Hi,
recently we ran into some problems with our OpenLDAP setup.
We're using syncrepl (not delta) and have two databases on the provider.
The first database is a LDAP database which accesses our AD and
is a subordinate of the main BDB database so that AD entries seamlessly
appear inside our main tree. The main database is replicated to
several consumers which also have the LDAP database for AD access
because we don't want to replicate the AD content in our servers.
Following are relevant pieces from our configuration:
provider:
database ldap
suffix "dc=ad,dc=our,dc=domain"
subordinate
[other directives like rootdn, uri ...]
chase-referrals yes
rebind-as-user yes
idassert-bind bindmethod=simple binddn="something" credentials="XXX"
mode=none
database bdb
suffix "dc=our,dc=domain"
[other stuff ...]
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 700
syncprov-reloadhint TRUE
(the syncprov is the last overlay)
consumer:
database ldap
suffix "dc=ad,dc=our,dc=domain"
subordinate
[other directives like rootdn, uri ...]
chase-referrals yes
rebind-as-user yes
idassert-bind bindmethod=simple binddn="something" credentials="XXX"
mode=none
database bdb
suffix "dc=our,dc=domain"
[other stuff ...]
syncrepl rid=1
provider=ldap://master.our.domain
type=refreshAndPersist
retry="10 10 300 +"
searchbase="dc=our,dc=domain"
filter="(objectclass=*)"
attrs="*,+"
schemachecking=off
scope=sub
bindmethod=sasl
saslmech=GSSAPI
authcid="something"
updateref ldap://master.our.domain
Now what happened is that the provider crashed with an assert at line 1858 in
syncprov.c. This is how this area looks like:
syncprov.c:
... 1856
if ( !rs->sr_entry ) {
assert( rs->sr_entry != NULL );
Debug( LDAP_DEBUG_ANY, "bogus referral in
context\n",0,0,0 );
return SLAP_CB_CONTINUE;
}
...
The reason for the crash is apparently that the search from the consumer went
into the LDAP database and accessed AD and AD did what it usually does and
sent back bogus referrals which triggered the assert :-(.
Now my question is, can we somehow avoid the replication search to travel into
the AD LDAP database and second, isn't the assert at that point kinda bogus?
It essentially tests for the same thing which the "if" statement before
already tested.
I also noticed that in our cn=config tree for the BDB database (which is what
we actually use for the configuration) the order of overlays in the provider
is:
{0}glue
{1}syncprov
Would it make a difference if we change that?
Karsten.
--
Another Glitch in the Call
------- ------ -- --- ----
(Sung to the tune of a recent Pink Floyd song.)
We don't need no indirection
We don't need no flow control
No data typing or declarations
Did you leave the lists alone?
Hey! Hacker! Leave those lists alone!
Chorus:
All in all, it's just a pure-LISP function call.
All in all, it's just a pure-LISP function call.