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.
Karsten Künne wrote:
Hi,
recently we ran into some problems with our OpenLDAP setup.
What version?
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.
The assert is probably bogus now, yes. That section of code was triggered so rarely that I needed to know if it happened at all, and why. (That assert was added November 2004. You're the first person to encounter it in more than 3 years.) Now we know - it happens when getting garbage back from AD...
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?
The answer to all questions of this nature is "try it and see."
On Thursday 10 January 2008 20:41:40 Howard Chu wrote:
Karsten Künne wrote:
Hi,
recently we ran into some problems with our OpenLDAP setup.
What version?
We're still at 2.3.37 but I checked CVS and the assert was still in there.
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.
The assert is probably bogus now, yes. That section of code was triggered so rarely that I needed to know if it happened at all, and why. (That assert was added November 2004. You're the first person to encounter it in more than 3 years.) Now we know - it happens when getting garbage back from AD...
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?
The answer to all questions of this nature is "try it and see."
I'll give it a shot. Logically it makes more sense to first provide the sync to the consumers and then glue the AD stuff together.
Karsten.
openldap-software@openldap.org
-
Howard Chu -
Karsten Künne