Please direct all followups to the ITS.
Emmanuel Duru wrote:
> -----Message d'origine-----
> De : Howard Chu [mailto:hyc@symas.com]
> emmanuel.duru(a)atosorigin.com wrote:
>> Full_Name: Emmanuel Duru
>> Version: 2.3.39
>> OS: Windows
>> URL:
ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (195.68.44.148)
>> I'm trying to set a directory architecture with a syncrepl push based
>> replication, as (partly) stated in the admin guide, chapter 16.1.1.
>> I have a provider slapd with bdb, an intermediate slapd with back-ldap,
> which
>> points to a consumer slapd with bdb.
>> First, I have to set an updateDN on the consumer slapd, else back-ldap
> gets a
>> "no user modification allowed" error on operational attributes
>> (structuralobjectclass, contextcsn) when it tries to update the consumer
> slapd
>
> That is expected.
>
>> (the admin guide says the opposite).
> I guess the Admin Guide has a bug then. What exact section are you
> referring to?
>
Section 16.1.1, the configuration example says twice :" # without the need
to write the UpdateDN before starting replication"
That is not what that comment means. That comment means that we *are* using an
updateDN. But, the entry corresponding to the updateDN we used in our example
doesn't need to be created in advance, because we already know that it's a
valid user on the target server. It was unfortunately taken out of context;
i.e. it was copied directly from test045 and without the other test045 config
file you have no way to see what it means. Definitely we should fix the
example here.
>> Then this does not work at all when modifying an entry,
because back-
> ldap gets a
>> "modify/delete: hasSubordinates: no such attribute" error when it
tries
> to
>> update the entry.
> That's also expected, since hasSubordinates is a dynamically generated
> operational attribute (and also read-only, as I recall). You need to
> exclude
> any dynamically generated operational attributes from the syncrepl search.
> E.g. 2.4's test045 specifically tests this scenario, and the syncrepl spec
> uses:
> syncrepl rid=1
> provider=ldap://localhost:9011/
> binddn="cn=Manager,dc=example,dc=com"
> bindmethod=simple
> credentials=secret
> searchbase="dc=example,dc=com"
> filter="(objectClass=*)"
>
> attrs="*,structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimes
> tamp,modifiersName,modifyTimestamp"
> schemachecking=off
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 5"
>
OK, my mistake.
> In general, while this is known to work in 2.3, you're better off using
> 2.4.
> (We intentionally did not include test045 in 2.3...)
I'm using 2.3 because I want to use "stable" version. I
will keep on using
it, until 2.4 becomes stable (which may occur before the end of my project).
In fact, my real need is this one: I have a backbone network with
non
OpenLDAP synchronized directories, and I want to use OpenLDAP directories in
front of this network, on each computer (at least for performance reasons,
until the network fully migrates to OpenLDAP directories). On the master
computer, I will use a master OpenLDAP directory, which replicates to the
non OpenLDAP directory with this syncrepl/back-ldap mechanism (all I need to
do is update the schema of the non OpenLDAP directory, I suppose). On the
slave computers, the non OpenLDAP directory should be provider, and the
OpenLDAP directory should be consumer, but I don't know yet how I will
manage to do this (of course the non OpenLDAP directory does not implement
syncrepl). It seems that syncrepl replication with back-ldap as provider
does not work, is it supposed to?
No. back-ldap doesn't know anything about syncrepl itself, it merely passes
requests thru from one server to another. Whatever server ultimately answers
the request must know how to act as a syncrepl provider, otherwise you get
nothing.
--
-- Howard Chu
Chief Architect, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/