[Kolab-devel] OpenLDAP replication issues: slurpd vs syncrepl

[Martin Konold]

Am Sonntag, 12. Februar 2006 12:33 schrieb Fabio Pietrosanti:

Hi Fabio,

I don'z think that syncrepl is a benefit even with 80 000 users currently. If 
time tells that syncrepl is much more robust than slurpd (which could be the 
case because the architecture is more robust) I am willing to have a look at 
it for this single reason.

In short the amount of LDAP data is small, mostly read and seldom written and 
is required in all  locations with the current Kolab model.


> This would give many improvement:
> - security
>   With syncrepl is possible to specificy parameters for what have to be
> replicate and where.

Currently Kolab needs all data anyway.

>    It should be possible to replicate to slave server B only the users
> that have KolabHomeServer: B .

No, e.g. for public folders access control all users arer required on all 
servers.

>    Or it should be replicated the whoole ldap database but without the
> "password" for "non local users".

If you don't trust in the physical security of Kolab servers you are in 
trouble anyway. 

In general you may though avoid the password hashes entirely when relying on a 
third party authentification mechanism. (SASL is your friend.)

> - network performance
>   Only the data needed to allow a slave server to work should be
> replicated.

I don't buy this mainly because the amount of data for LDAP replication is 
negligible.

> - cyrus performance
>   Only mailboxes of local users should be created.

For proper ACLs it is benefitial if the cyrus imapd knows about all users. 
Performance should not be affected by this. Can you provide any measurements?

> - kolab design simplicity enanchments
>    Slurpd should be used only for kolabd notification but not for
> replica, leaving this task to the more feature rich syncrepl.

How will this simplify the Kolab design?

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker