[Date Prev][Date Next] [Chronological] [Thread] [Top]

crash in syncprov.c at line 1858



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.