Re: [JunkMail] (ITS#5393) syncrepl push based replication with back-ldap fails

[hyc@symas.com]

Please direct all followups to the ITS.

Emmanuel Duru wrote:
>
>> -----Message d'origine-----
>> De : Howard Chu [mailto:hyc@symas.com]

>> emmanuel.duru@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/