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

Re: (ITS#3616) Syncrepl and rootless installations



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

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.

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.

Kurt