[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Building a centralized database from various LDAP servers

Adam Brandizzi schrieb:

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.


[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;)