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

Re: entryUUID

At 09:59 AM 6/14/2005, Pierangelo Masarati wrote:
>Kurt D. Zeilenga wrote:
>
>>A change of subject seems in order...
>>
>>My initial concern with moving entryUUID generation out of
>>the frontend was that it might make implementation of manageDIT
>>capabilities a bit harder.
>>
>>Another concern would be to ensure that UUIDs generated for
>>entries are "reasonably unique".... and, for that, I have some
>>concerns with the use of uuid_create_from_name().  What were
>>you thinking of using as a name?  Is it "reasonable unique"?
>> 
>
>In principle, whatever.  DN at worst, but many vendors provide unique attrs in their DSAs, and many deployments keep reasonably unique counters in their data.
>
>I want to use syncrepl to easily build a "master" consumer out of third party DSAs that don't support all stuff required by syncrepl,


Hmmm....  not sure exactly what your trying to do.

I'd like slapd(8) to be slave off of anything.  If LDAPsync is not
available on the provider, I'd like syncrepl to use whatever is,
even if that means using basic LDAP operations.

When syncrepl uses say basic LDAP operations, saying a timestamp
based approach, then one can create entryUUIDs and entryCSNs
as needed.  The former can be arbitrary (if this slave maintains
a copy, or create_from_name otherwise (maybe with DN+createTimestamp)).
The latter can be produced from the timestamp (which, depending
how one designs the mechanism, should be enough).

Now, if your trying to chain an LDAPsync operation to a server
that doesn't support LDAPsync, I think the operation should
fail.

But then maybe I got confused by your use of DSA here... (especially
given your mention of back-sql below).

>the first of all the control itself, but also the structuralObjectClass (which I plan to compute out of the objectClass chain),

syncrepl shouldn't require structuralObjectClass (or even
objectClass).  That is, the consumer should work in face of
fractional entries.

>the entryCSN (which I plan to estimate from a timestamp whatever, or just to set to something higher than the current CSN, at worst, like it's currently done in back-sql), but I need to be able to generate repeatable entryUUIDs (the "reasonably unique" is essentially intended within a context, and it's an issue I'll need to think about; unless I can do something "absolutely unique" and two-way like in back-sql using tables and rows ids, I need a general way to use the DN, at least one-way; the other can be done somehow programmatically).

Okay, but not sure if there is sufficient overlap here to put
this in an overlay.  Seems that we'll have two kinds of backends.
Ones which expect the frontend to maintain these attributes
and those which, for whatever reason, what to maintain these
themself.  Seems we need a backend flag to advise the frontend
what to do.  If 0, the frontend would generate them.  If 1,
the frontend would assume the backend does.


>Currently, as a testbed, I'm using OpenLDAP 2.1 as provider, so none of the above is available and I need to be able to create all of them.
>
>p.
>
>
>   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497