Replicate ldap domains automatically

Jan Kowalsky jankow at
Sun Dec 10 01:40:59 CET 2017

I wrote a bug report:

Am 08.12.2017 um 17:58 schrieb Jan Kowalsky:
> Well, while this works fine with Multimaster-Replication between 2
> hosts, but it doesn't with three hosts. Neither  if multimaster
> replication is configured between each of them nor if there ist
> replication between ldap0 and ldap1 and replication between ldap1 and ldap2.
> In each case I end up with two replication agreement objects which have
> different cn names but have the same nsDS5ReplicaHost.
> Anybody has experiences with this replication scenario with more than
> two host?
> Any hint welcome.
> Kind Regards
> Jan
> Am 06.12.2017 um 14:20 schrieb Jan Kowalsky:
>> ok, found out so far:
>> Am 06.12.2017 um 13:15 schrieb Jan Kowalsky:
>>> Hi all,
>>> While the replication of the domain databases works in fact - this isn't
>>> true for the cn=kolab,cn=config tree. So the domain data are available
>>> but the domain itself (as associated domain) isn't known to kolab as
>>> long as we don't add it on the other ldap server manually.
>>> So probably it's necessary to replicate also the cn=kolab,cn=config
>>> tree. But actually I don't get this to work. Is it necessary to have
>>> ldap data of cn=kolab,cn=config in database instead of ldif in
>>> /etc/dirsrv/slapd-.../dse.ldif?
>> Yes this is the fact.
>> Here is written something about:
>> So we have to change the domain_base_dn to a location which resides
>> inside the database. For example to ou=Domains,dc=example,dc=org if
>> is our priary domain.
>> We just can take the objects from /etc/dirsrv/slapd-INSTANCE/dse.ldif
>> (with domainrelatedobject) and manipulate them for the new
>> ou=Domains,dc=example,dc=org instead of cn=kolab,cn=config
>> Now we have to configure postfix, cyrus, roundcube ... to use the new
>> domain_base_dn.
>> Anybody has some more hints what's important to consider?
>> Kind regards
>> Jan

More information about the users mailing list