[Kolab-devel] Kolab/LDAP.pm: breaks master/slave sync

[Bernhard Reiter]

Hi Stephan,
Hi Stuart,

it looks like a remedy for issue257 would be to have
Kolab/LDAP.pm be ready to write everything 
to $ldap_master and read only from $ldap
so that a slave could read from the replicated openldap,
but writes into the master ldap.

Am I missing something here?
Bernhard

On Wednesday 21 July 2004 02:05, Bernhard Reiter wrote:
> New submission from Bernhard Reiter <bernhard at intevation.de>:
>
> Development server 20040720:
>
> Deleting users on a master slave setup
> brings both directories out of sync.
>
> Master server: m.test.net
> Slave server:  s.test.net
>
> If you delete a user on m.test.net,
> this users gets two deleteflags, like:
>
> deleteflag: m.test.net
> deleteflag: s.test.net
>
> Next this gets replicated to both ldaps.
> Both ldaps replicate to the local kolab daemons.
> On the master the kolabd will remove the mailbox
> and then remove the deleteflag: m.test.net
> leaving the object in, because deleteflag: s.test.net
> is still there.
>
> The last operation gets replicated to the slave ldap server.
> Now only deleteflag: s.test.net is in there and the slave
> deletes this one and then completely removes this object.
>
> However this is not communicated back to the master!
> So in the master our object is still "waiting to be deleted".
>
> Possible solutions: Make the Kolagd on the slave
> write changes only directly to the master.
>
> ----------
> assignedto: steffen
> messages: 924
> nosy: bernhard, bh, martin, steffen
> priority: critical
> status: unread
> title: deletion breaks master/slave sync
> ________________________________________________
> Kolab issue tracker <kolab-issues at intevation.de>
> <https://intevation.de/roundup/kolab/issue257>
> ________________________________________________
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel