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

Re: (ITS#3616) Syncrepl and rootless installations

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


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