Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them

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.