Page MenuHomePhorge
Files F117755866

kolab-daemon.rst
No OneTemporary
Actions

Authored By
Unknown
Size
5 KB
Referenced Files
None
Subscribers
None

kolab-daemon.rst
View Options

.. _and_kolab-daemon:
================
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:
* :ref:`and_kolab-daemon_kolab-user-creation`,
* :ref:`and_kolab-daemon_kolab-user-modification`,
* :ref:`and_kolab-daemon_kolab-user-deletion`,
* :ref:`and_kolab-daemon_kolab-group-deletion`,
* :ref:`and_kolab-daemon_resource-creation`,
* :ref:`and_kolab-daemon_resource-modification`,
* :ref:`and_kolab-daemon_resource-deletion`,
* :ref:`and_kolab-daemon_shared-folder-creation`,
* :ref:`and_kolab-daemon_shared-folder-modification`,
* :ref:`and_kolab-daemon_shared-folder-deletion`,
.. _and_kolab-daemon_kolab-user-creation:
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 :manpage:`kolab.conf(5)`,
* the configured ``user_base_dn`` in the domain-specific section of
:manpage:`kolab.conf(5)`,
* the configured ``base_dn`` in the domain-specific section of
:manpage:`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 :manpage:`kolab.conf(5)`,
* the configured ``kolab_user_filter`` setting in the generic ``[ldap]``
section of :manpage:`kolab.conf(5)`,
* the configured ``user_filter`` setting in the domain-specific section of
:manpage:`kolab.conf(5)`,
* the configured ``user_filter`` setting in the generic ``[ldap]``
section of :manpage:`kolab.conf(5)`,
usually ``(objectclass=kolabinetorgperson)``.
For these new objects, the following actions need to take place;
#. 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:
#. 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 ``mail`` and/or ``alias`` attributes, a
callback to LDAP needs to be issued, creating another
:ref:`and_kolab-daemon_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,
.. 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.
#. 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,
#. 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 :ref:`and_kolab-daemon_kolab-user-modification` notification
to the daemon to be issued.
.. _and_kolab-daemon_kolab-user-modification:
Kolab User Modification
=======================
* acl cleanup
.. _and_kolab-daemon_kolab-user-deletion:
Kolab User Deletion
===================
* acl cleanup
.. _and_kolab-daemon_group-deletion:
Group Deletion
=================
* acl cleanup
.. _and_kolab-daemon_resource-creation:
Resource Creation
=================
.. _and_kolab-daemon_resource-modification:
Resource Modification
=====================
.. _and_kolab-daemon_resource-deletion:
Resource Deletion
=================
.. _and_kolab-daemon_shared-folder-creation:
Shared Folder Creation
======================
.. _and_kolab-daemon_shared-folder-modification:
Shared Folder Modification
==========================
.. _and_kolab-daemon_shared-folder-deletion:
Shared Folder Deletion
======================

File Metadata

Mime Type
text/plain
Expires
Sat, Apr 4, 8:20 AM (1 w, 6 d ago)
Storage Engine
local-disk
Storage Format
Raw Data
Storage Handle
d3/a5/323c94619574e410c124290a77e3
Default Alt Text
kolab-daemon.rst (5 KB)

Event Timeline