[Kolab-devel] Question about the working of kolab's distributed concept

[Bernhard Reiter]

Am Donnerstag, 13. April 2006 23:35 schrieb Richard Bos:
> Op donderdag 13 april 2006 13:46, schreef Bernhard Reiter:

> > changes can only be made on the master ldap.
>
> But, the administrator or user may use a webinterface running on a slave
> (as that will modify the master ldap db (I assume)).

Yes, the slave webinterface will do the writes to the master ldap.

> > > - In case of deletion: admin deletes user via webinterface.  The
> > > master ldap server is told to remove the cyrus email account (hmm but
> > > how?). kolabd removes the cyrus email account, sets a kolabDeleteFlag
> > > (in the master ldap server).  As soon as this flag is  seen on the
> > > master, the corresponding record(s) is removed from master ldap server.
> > >  The master replicates this deletion and the data will be removed
> > >   from the slaves as well.
> >
> > This is not quite correct.
> > The admin interface sets the kolabDeleteFlag for each host in the ldap.
>
> So there can/will be many records of the type, during the delete phase:
> attributetype ( 1.3.6.1.4.1.19414.2.1.2
>   NAME 'kolabDeleteflag'
>   DESC 'Per host deletion status'
> The number of those records depend on the number of slaves (of course).

Yes.

> > The notification runs like in all other cases.
> > Each non-home server can now do cleanup and remove their entry from
> > kolabDeleteFlag. In the end, the home server of the user does the last
> > cleanup now now removes the cyrus account and the ldap object.
>
> What cleanups are to be done for non-home servers?  

Removing the cyrus mailbox information.
This is not much, but the funcationality is there for future uses.

> Does the home server 
> checks that it is the only one left in the ldap db?

Yes, of course, otherwise it could not delete the ldap objects
(if configured).


-- 
www.kolab-konsortium.com  Professional Maintenance, Consultancy and Support.