[Date Prev][Date Next]
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 notExactly. But I don't want to touch syncrepl (I mean --- the consumer code).
available on the provider, I'd like syncrepl to use whatever is,
even if that means using basic LDAP operations.
I'd rather have a layer that massages consumer's requests and (unaweare
producer's responses to match OpenLDAP's consumer's needs.
When syncrepl uses say basic LDAP operations, saying a timestampOK, we are along the same line here as well. However, I see, for
example, that SunOne
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).
appears to generate a nsUniqueId that looks like
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 serverIt does already! But if I mask the remote server by means of a layer
that doesn't support LDAPsync, I think the operation should
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!
So why is the consumer explicitly requesting structuralObjectClass in
the attribute list?
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
Not sure I get this point. My intention is to leave the consumer code
exactly as it is now;
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.
<consumer: OpenLDAP 2.3>
<replication proxy: OpenLDAP 2.3 + "syncproxy" overlay that massages
consumer requests and producer responses>
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497