ondrej.kuznik@acision.com wrote:

On 07/07/2011 03:26 PM, ondrej.kuznik@acision.com wrote:

...

ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c has an example of such overlay. To try it, initialize the overlay and add these entries:

dn: olcTestAttrOne=zero,$OVERLAY_DN objectclass: olcTestOne

dn: olcTestAttrTwo=one,$OVERLAY_DN objectclass: olcTestTwo

dn: olcTestAttrOne=two,$OVERLAY_DN objectclass: olcTestOne

dn: olcTestAttrTwo=three,$OVERLAY_DN objectclass: olcTestTwo

After a restart compare the output of slapcat -n0 with the output of ldapsearch -b cn=config, you should see at least one different entry. You might also try to modify the entries before and after the restart. For those that do not match you get "no such object" as the dn is no longer in the ldif database.

The issue is in bconfig.c:4726, the code treats all siblings as part of one ordering (contrary to what http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html implies since cn=config seems to treat everything as X-ORDERED 'SIBLINGS'), while back-ldif orders them accordingly. Also its caller (config_ldif_resp) does not expect any reordering to be necessary, after all it should be (and is) reading a valid cn=config db, so the entry renaming then never gets propagated to back-ldif causing this desync.

This ITS still appears to me to be invalid. bconfig treats all siblings *of the same type* as a single ordering. Your demonstration code is claiming your entries are all of the same type, even though they aren't. I.e., all entries in cn=config of a given type have only one distinguished naming attribute. You have used olcTestAttrOne and olcTestAttrTwo for the same type, so cn=config doesn't distinguish them in its sort order.