Re: (ITS#3616) Syncrepl and rootless installations

[Howard Chu <hyc@symas.com>]

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.

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

> Kurt 
>
>
>
>  


--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support