Adam Brandizzi schrieb:

Hi!

On 5/22/07, pkoelle@gmail.com pkoelle@gmail.com wrote:

...

I'd setup the central server as a syncrepl consumer to all the branch offices, with one database context for each. Optionally those can be glued together with back-ldap.

I tried it, but I've tried to replicate subtrees using SyncRepl, which does not work. Since then, I was thinking OpenLDAP 2.3 does not suport multiple SyncRepl configurations at all, but now I am wondering whether it is possible to create one SyncRepl instance for each database context... So, does LDAP support one SyncRepl directives for each database context?

from http://www.openldap.org/doc/admin23/syncrepl.html#Syncrepl%20Details

If a syncrepl specification is included in a database definition, slapd (8) launches a syncrepl engine as a slapd (8) thread and schedules its execution.

I read this as each database definition can have its own syncrepl statement. Hence the schema would be something like:

database bdb directory /var/lib/ldap/sub1 suffix dc=sub1,dc=example,dc=com ....more config....

syncrepl rid=001 ...more syncrepl stuff...

database bdb directory /var/lib/ldap/sub2 suffix dc=sub2,dc=example,dc=com ....more config....

syncrepl rid=002 ...more syncrepl stuff...

Anyway, this configuration seems to have a problem: AFAIK back-bdb (which is the backend we are using for actually storing the data) does not support multiple database contexts on OpenLDAP 2.3. Im I wrong? If not, has anyone an idea about how to handle it?

Use one "database" statement for each naming context

...

Using the chain overlay on the central server, writes will be internally redirected to the branch office and you won't have to deal with referrals manually. Of course, if the branch is down writes will fail...

But why should I redirect the write requests to the branch? Actually, the branchs will receive the write requests, and replicate it to the central. Am I missing something? Sorry, I am a bit newbie :)

That's just if you need to write to the central server (which is a slave from a replication point of view) and don't want to deal with referrals manually[1]. If you only write to the branch offices; no need for the chain overlay.

hth Paul

[1] If you try to write to a slave you'll get back a referral (hopefully) which is just a ldap URL which points to the master and you have to manually rebind to the master and retry the operation. It's hard to support referrals in a general way because you would need to make assumptions about the identities to use for the rebind etc., Hence most clients don't support referrals and the chain overlay is a very handy solution;)