[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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
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.

Ondrej Kuznik

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.