[Date Prev][Date Next]
Re: [JunkMail] (ITS#5393) syncrepl push based replication with back-ldap fails
Please direct all followups to the ITS.
Emmanuel Duru wrote:
>> -----Message d'origine-----
>> De : Howard Chu [mailto:email@example.com]
>> firstname.lastname@example.org wrote:
>>> Full_Name: Emmanuel Duru
>>> Version: 2.3.39
>>> OS: Windows
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (220.127.116.11)
>>> 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,
>>> 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
>> 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
>>> 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
>>> 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
>> any dynamically generated operational attributes from the syncrepl search.
>> E.g. 2.4's test045 specifically tests this scenario, and the syncrepl spec
>> syncrepl rid=1
>> retry="5 5 300 5"
> OK, my mistake.
>> In general, while this is known to work in 2.3, you're better off using
>> (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
-- 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/