Replicate ldap domains automatically

[Jan Kowalsky]

Hi all,

we are running ldap replication for our kolab domains which works fine.
Until now we configured all manual. But kolab webadmin brings
functionality for doing this for every new domain which is added by the
webadmin. If I understand right, the only prerequisite should be one
already configured replication and that the other ldap-server is
reachable with same directory manager credentials

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?

And how to achive this? Anyone have an Idea? This part of kolab is not
one of the best documentated.

Best Regards
Jan

[Jan Kowalsky]

Post by 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:
https://docs.kolab.org/deployment-guide/hosted-kolab-groupware-deployment.html?highlight=domain_base_dn#setting-a-domain-base-dn

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
example.org 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

[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

Post by Jan Kowalsky

Post by 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.
https://docs.kolab.org/deployment-guide/hosted-kolab-groupware-deployment.html?highlight=domain_base_dn#setting-a-domain-base-dn
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
example.org 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
_______________________________________________
users mailing list
https://lists.kolab.org/mailman/listinfo/users

[Jan Kowalsky]

I wrote a bug report: https://git.kolab.org/T3283

Post by 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

Post by Jan Kowalsky

Post by 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.
https://docs.kolab.org/deployment-guide/hosted-kolab-groupware-deployment.html?highlight=domain_base_dn#setting-a-domain-base-dn
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
example.org 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