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

[Richard Bos]

Bernhard,

thanks you for taking the time to answer this question.  It's appreciated and 
much things much clearer for me!

Op donderdag 13 april 2006 13:46, schreef Bernhard Reiter:
> If I remember correctly, we do not have something like
> http://kroupware.kolab.org/technical-1.0.1-html/c421.html
> Thought we would need to check the architecture document again.

Ah thanks that provides a nice overview indeed.

> > I think that it works in the following (I make assumptions here and there
> > and would be nice if wrong assumptions are corrected):
> > - admin adds a user via the web interface (which may be located
> >   on the master server or on a slave system).  The user data is submitted
> >   by the admin, as a result of this, the data is added to the master ldap
> >   server.
>
> Yes, 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)).

> > - The master ldap server replicates the data to the slaves.
>
> Yes.

And the slaves can be used by the users for queries ;)

> > Among the
> >   slaves there is the kolab daemon (kolabd) listening to the replicated
> > ldap data.  Kolabd creates on the appropriate slave the cyrus email
> > account.
>
> Almost. Kolabd always listens to the local openldap.
> So kolabd on the slave listens to the slave openldap, not the master.

Okay.

> > - 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). 

> 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?  Does the home server 
checks that it is the only one left in the ldap db?

-- 
Richard Bos
Without a home the journey is endless