Re: Building a centralized database from various LDAP servers

["pkoelle@gmail.com" <pkoelle@gmail.com>]

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