ondrej.kuznik(a)acision.com wrote: > On 07/07/2011 03:26 PM, ondrej.kuznik(a)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.