[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
- From: hyc@symas.com
- Date: Thu, 12 Jan 2012 11:29:03 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Howard Chu wrote:
> 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.
Additionally, you have hijacked the Cft_Overlay type for your custom entries,
even though that type is reserved for actual overlay config entries. You
should be using Cft_Misc for your custom entries. All of the other Cft_* types
are reserved for all of the built in cn=config objectclasses.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/