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;

  • the configured kolab_user_base_dn in the domain-specific section of kolab.conf(5),
  • the configured user_base_dn in the domain-specific section of kolab.conf(5),
  • the configured base_dn in 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;

  • the configured kolab_user_filter setting in the domain-specific section of kolab.conf(5),
  • the configured kolab_user_filter setting in the generic [ldap] section of kolab.conf(5),
  • the configured user_filter setting in the domain-specific section of kolab.conf(5),
  • the configured user_filter setting in the generic [ldap] section of kolab.conf(5),

usually (objectclass=kolabinetorgperson).

For these new objects, the following actions need to take place;

  1. If configured, the recipient policy needs to be applied to the new entry,

    Note

    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:

    1. Change the primary email address attribute value,
    2. Add those secondary email address attribute values that the recipient policy mandates for compliance.
  2. If the recipient policy mandates any changes need to be made to the user object, such as the value for the mail and/or alias attributes, a callback to LDAP needs to be issued, creating another Kolab User Modification notification to the daemon,

  3. 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,

    Note

    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/server metadata value to the server address of the backend IMAP server the mailbox was created on.

    The Kolab daemon will then set mailserver_attribute to this address.

  4. Any configured additional default folders need to be created,

    Note

    Any configured additional quota(root), annotations and ACLs for each of the default folders will need to be reflected,

  5. The user needs to be subscribed to the initial set of folders created for, the account,

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

  • acl cleanup

Kolab User Deletion

  • acl cleanup

Group Deletion

  • acl cleanup

Resource Creation

Resource Modification

Resource Deletion

Shared Folder Creation

Shared Folder Modification

Shared Folder Deletion