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.
-
hyc＠symas.com