The Kolab Daemon¶
The Kolab daemon kolabd (running as the kolabd service) is the Kolab Groupware component that synchronizes mutations made in LDAP against IMAP.
The following mutations are taken in to account:
Kolab User Creation¶
A Kolab user is created when a new LDAP object is created under the base dn configured for a parent domain, which is either;
kolab_user_base_dnin the domain-specific section of kolab.conf(5),
user_base_dnin the domain-specific section of kolab.conf(5),
base_dnin the domain-specific section of kolab.conf(5),
the detected root dn for a domain.
This is usually
ou=People,$root_dn, where $root_dn of course is the root
dn for the directory tree that corresponds with the parent domain.
Kolab user entries match the filter setting for Kolab users, either;
kolab_user_filtersetting in the domain-specific section of kolab.conf(5),
kolab_user_filtersetting in the generic
[ldap]section of kolab.conf(5),
user_filtersetting in the domain-specific section of kolab.conf(5),
user_filtersetting in the generic
[ldap]section of kolab.conf(5),
For these new objects, the following actions need to take place;
If configured, the recipient policy needs to be applied to the new entry,
If the user object was created through the Web Administration Panel, and a recipient policy was configured, then the API the Web Administration Panel addresses has already applied the recipient policy.
However, if the Web Administration Panel API was misconfigured, or the administrator creating the new user entry was allowed to override the default generated values, then the application of the recipient policy by the Kolab daemon will:
Change the primary email address attribute value,
Add those secondary email address attribute values that the recipient policy mandates for compliance.
If the recipient policy mandates any changes need to be made to the user object, such as the value for the
aliasattributes, a callback to LDAP needs to be issued, creating another Kolab User Modification notification to the daemon,
With the resulting set of attributes (modified if the recipient policy has had to, unmodified if not), a mailbox needs to be created for the new user,
For Cyrus IMAP Murder deployments, the Kolab daemon is normally configured to initially communicate with a Cyrus IMAP frontend server.
Unless the target mailbox server had already been supplied by LDAP, the Kolab daemon would create the mailbox using the connection to a Cyrus IMAP frontend, and await the mailbox entry to re-occur on said frontend.
At this point in time, the Cyrus IMAP Murder mailbox list will have set the
/shared/vendor/cmu/cyrus-imapd/servermetadata value to the server address of the backend IMAP server the mailbox was created on.
The Kolab daemon will then set
mailserver_attributeto this address.
Any configured additional default folders need to be created,
Any configured additional quota(root), annotations and ACLs for each of the default folders will need to be reflected,
The user needs to be subscribed to the initial set of folders created for, the account,
If not supplied by LDAP already, any configured default quota needs to be applied to the IMAP mailbox as well as communicated back to the new user object, in case of which a callback to LDAP needs to be issued, which would cause another Kolab User Modification notification to the daemon to be issued.
Kolab User Modification¶
Kolab User Deletion¶