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

Re: entryUUID

Kurt D. Zeilenga wrote:

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

I'd like slapd(8) to be slave off of anything.

That's exactly what I was concerned about.

If LDAPsync is not
available on the provider, I'd like syncrepl to use whatever is,
even if that means using basic LDAP operations.

Exactly. But I don't want to touch syncrepl (I mean --- the consumer code).
I'd rather have a layer that massages consumer's requests and (unaweare of being)
producer's responses to match OpenLDAP's consumer's needs.

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

OK, we are along the same line here as well. However, I see, for example, that SunOne
appears to generate a nsUniqueId that looks like 3ec92655-bc6c11d9-8058fbf5-84bfa6ab
so I guess this is not something OpenLDAP's consumer can handle as is, and I don't want
to make the code hairy when not required; I'd rather move this type of mucking into a
separate, configurable layer that turns any type of unique identifier into our entryUUID.

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

It does already! But if I mask the remote server by means of a layer that makes
it act as a (refreshOnly) sync provider...

But then maybe I got confused by your use of DSA here...


(especially given your mention of back-sql below).

That was an example of how I made a dumb database act as a provider
by generating entryUUID from RDBMS indices and entryCSN... from nothing!

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.

So why is the consumer explicitly requesting structuralObjectClass in the attribute list?

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.

Not sure I get this point. My intention is to leave the consumer code exactly as it is now;

<consumer: OpenLDAP 2.3>

<replication proxy: OpenLDAP 2.3 + "syncproxy" overlay that massages consumer requests and producer responses>

<producer: whatever>


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497