Re: (ITS#3616) Syncrepl and rootless installations

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:19 PM 4/14/2005, Howard Chu wrote:
>Kurt D. Zeilenga wrote:
>
>>[Redirected to devel for discussion]
>>
>>At 08:33 AM 4/13/2005, rob@dsvr.net wrote:
>> 
>>
>>># head -n 10  slap_23.ldif
>>>dn:
>>>objectClass: locality
>>>objectClass: syncProviderSubentry
>>>structuralObjectClass: locality
>>>contextCSN: 20050304111037Z#000293#00#000000    
>>
>>A number of things concern me about this.
>>1) no entries (or subentries) DSEs can be named
>>with the empty DN, so 'locality' here makes no
>>sense.
>>
>>2) syncProviderSubentry should only be combined
>>with structural object class of subentry.  That
>>is, the purpose of this auxiliary class is to
>>indicate that the subentry holds sync provider
>>information.  If we're going to place that information
>>in an entry (as opposed to a subentry), then we
>>should use a different auxiliary class.
>> 
>I was being lazy and didn't feel like defining a new objectclass. I chose locality because it has no MUST attributes. I originally tried glue, which is somewhat closer to the original intent.
>
>>3) it seems there might be a chicken&egg problem
>>here, or at least a conflict between the true
>>entry (or root DSE) at the prefix and this
>>locality object.   It would seem it better to
>>modify the true object, but I assume that's not
>>done generally as that object may not have been
>>shadowed yet.
>> 
>Normally for a database with suffix "" there is no entry that corresponds to the suffix, so it will never get shadowed. Nor should it ever be.

Here I was referring to the general case (not the "" case).


>>It seems to me that in the general case, we
>>use manageDsaIT (as this information is specific
>>to the DSA) to add a "glue" entry + "syncProvider"
>>with the "contextCSN".   For the case where the
>>prefix (db suffix) is "", one should modify
>>the rootDSE to contain "syncProvider".  If one
>>wants these cases to be symetric, then have the
>>glue in the general case automatically created
>>so that the syncProvider+contextCSN can be added
>>via modify.
>I didn't use the actual rootDSE since that is not backed by any database backend, so it would be pointless. (I.e., the contextCSN would never be saved.)

Maybe store it as a glue entry in the underlying DB.

>The general case where the database suffix is non-empty already worked before so I don't think that needs to be changed in any way. Really since contextCSN is an operational attribute I didn't need to use the syncProviderSubentry objectclass here at all.

Likewise for the root DSE (and glue).

>I guess it would be convenient to set the rootDSE in addition ot the dummy entry, so that clients can query the rootDSE to retrieve the contextCSN if they want it. Right now it's pretty much invisible.

To modify as well?  Seems we need to glue it.