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.