bh: doc/architecture server.sgml,1.37,1.38

[cvs at kolab.org]

Author: bh

Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv11300/architecture

Modified Files:
	server.sgml 
Log Message:
Add section with a description of the ldap changes between versions 2.0
and 2.1 of the Kolab server


Index: server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/server.sgml,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -d -r1.37 -r1.38
--- server.sgml	1 Aug 2006 16:21:09 -0000	1.37
+++ server.sgml	9 Aug 2006 12:55:43 -0000	1.38
@@ -685,6 +685,227 @@
 <para>Further attributes can be easily added to the object class as the project advances and
  other requirements are identified.</para>
 </sect2>
+
+<sect2><title>LDAP-Changes for Kolab Server 2.1</title>
+  <para>
+    This section describes the changes in the LDAP structure that have
+    been made between version 2.0 and 2.1 of the Kolab server.  The main
+    difference between the two versions is the support for multiple
+    email-domains.  The implementation of that feature in Kolab is
+    relatively simple and the LDAP changes to accommodate this feature
+    have been kept to a minimum.
+  </para>
+
+
+  <sect3><title>Multidomainsupport</title>
+    <para>
+      Multidomainsupport affects the following places in the LDAP
+      structure immediately:
+    </para>
+    <itemizedlist>
+      <listitem>
+	<para>
+	  The domains the kolab server is responsible for.
+	</para>
+	<para>
+	  All domains are listed in the Kolab configuration object (dn:
+	  k=kolab,<base-dn>) in the attribute postfix-mydestination
+	  postfix-mydestination defines which domains the postfix MTA is
+	  reponsible for.
+	</para>
+      </listitem>
+
+      <listitem>
+	<para>
+	  Domain-maintainers
+	</para>
+	<para>
+	  Domain-maintainers are internal Accounts which have basically
+	  the same permissions as maintainers, with the exception that
+	  they only have access to a subset of the domains of the Kolab
+	  server.  To which domains a domain-maintainer has write access
+	  to is defined by the domain objects.
+	</para>
+	<para>
+	  There is one domain object for each domain and is represented
+	  by an LDAP entry under 
+	  <programlisting>
+            dn: cn=domains,cn=internal,<base-dn>
+            cn: domains
+            objectClass: top
+            objectClass: kolabNamedObject
+	  </programlisting>
+	  with the following structure:
+	  <programlisting>
+            dn: cn=<domain>,cn=domains,cn=internal,<base-dn>
+            objectClass: top
+            objectClass: kolabGroupOfNames
+            cn: <domain>
+	  </programlisting>
+	</para>
+
+	<para>
+	  The members of this kolabGroupOfNames are the
+	  domain-maintainers who have access to the accounts of this
+	  domain.
+	</para>
+	<para>
+	  Since "members" is a MUST attribute of kolabGroupOfNames, at
+	  least one member has to be given.  In a standard Kolab
+	  installation this is the manager accout (dn:
+	  cn=manager,cn=internal,<base-dn>).
+	</para>
+	<para>
+	  Kolab's web-admin interface creates the domain objects when
+	  the first domain maintainers are defined.
+	</para>
+	<para>
+	  Every domain-maintainer is an LDAP-objekt of the form:
+	  <programlisting>
+            dn: cn=<CN>,cn=internal,<base-dn>
+            objectClass: top
+            objectClass: inetOrgPerson
+            objectClass: kolabInetOrgPerson
+            sn: <SN>
+            cn: <CN>
+            userPassword:: <pwd>
+            uid: <uid>
+	  </programlisting>
+	</para>
+	<para>
+	  Like maintainers and admins, domain-maintainer are members of
+	  a special kolabGroupOfNames:
+	  <programlisting>
+	    dn: cn=domain-maintainer,cn=internal,<base-dn>
+            cn: domain-maintainer
+            objectClass: top
+            objectClass: kolabGroupOfNames
+	  </programlisting>
+	</para>
+	<para>
+	  In a stand kolab installation, the only member of this group
+	  is the manager account.
+	</para>
+	<para>
+	  Domain-maintainers are only used by kolab's web-admin
+	  interface.  Installation that use some other means to
+	  administrate the server may ignore domain-maintainers.
+	</para>
+	<para>
+	  Which accounts, distribution lists, etc. belong to which
+	  domain is described in the sections below.
+	</para>
+      </listitem>
+    </itemizedlist>
+  </sect3>
+
+  <sect3><title>Associating Accounts with Domains</title>
+    <para>
+      A kolab account belongs to the domain that is used as the domain
+      of its primary email address, that is, the value of the "mail"
+      attribute.
+    </para>
+  </sect3>
+
+  <sect3><title>Distributionlists</title>
+    <para>
+      In Kolab server 2.1, the CN of a distributionlist is its
+      email-address.  In version 2.0 it was only the local part of the
+      email-address (the part before the @).  This was changed in 2.1 to
+      make it possible to have multiple distribution lists with the same
+      local names in different domains.
+    </para>
+    <para>
+      A distributionlist belongs to the domain that is used as the
+      domain in the value of the "mail" attribute.
+    </para>
+  </sect3>
+
+  <sect3><title>Resource Manager</title>
+    <para>
+      The attribute kolabEncryptedPassword is no longer used in version
+      2.1.  In Kolab Server 2.0 it was used by the resource manager to
+      have write access to the calendar folders of resource and group
+      accounts.  In 2.1 the resource manager always uses the calendar
+      user for this.
+    </para>
+  </sect3>
+
+  <sect3><title>Shared Folders</title>
+    <para>
+      The object class kolabSharedFolder has two new attributes:
+    </para>
+    <variablelist>
+      <varlistentry><term>kolabFolderType</term>
+	<listitem>
+	  <para>
+	    Defines the value of the IMAP annotation "folder-type" as
+	    used for the resource folders of normal kolab accounts.
+	    More details about this attribute can be found in the file
+	    kolab2.schema shipped with Kolab server 2.1.
+	  </para>
+	</listitem>
+      </varlistentry>
+      <varlistentry><term>alias</term>
+	<listitem>
+	  <para>
+	    This attribute is not used yet by Kolab.
+	  </para>
+	</listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>
+      Furthermore, just as for distributionlists, in Kolab version 2.1
+      the domain is now part of the CN aufgenommen.  Instead of simply
+      <foldername> as in 2.0, it's now <foldername>@<domain>.
+    </para>
+
+    <para>
+      The domain given in the CN is the domain to which the shared
+      folder belongs.  Note that this is different from to accounts and
+      distributionlists where the domain is taken from the "mail"
+      attribute.
+    </para>
+  </sect3>
+
+  <sect3><title>Postfix Relayport</title>
+    <para>
+      The kolab configuration object (dn: k=kolab,<base-dn>) has a
+      new attribute, postfix-relayport.  This is the port of the
+      relayhost for the postfix MTA.  This attribute is used in
+      main.cf.template.
+    </para>
+  </sect3>
+
+  <sect3><title>Other schema changes</title>
+    <para>
+      The object class kolabInetOrgPerson has a new attribute
+      kolabComment.  This is not used yet in Kolab.
+    </para>
+    <para>
+      The following attribute have been explicitly marked as "single
+      value":
+      <programlisting>
+	kolabFreeBusyFuture
+	kolabFreeBusyPast
+	kolabHomeMTA
+	kolabVacationBeginDateTime
+	kolabVacationEndDateTime
+	kolabVacationResendInterval
+	kolabVacationReplyToUCE
+	kolabForwardKeepCopy
+	kolabForwardUCE
+	postfix-enable-virus-scan
+	postfix-allow-unauthenticated
+	cyrus-autocreatequota
+	cyrus-imap
+      </programlisting>
+    </para>
+  </sect3>
+</sect2>
+
+
 </sect1>
 
 <sect1><title> Postfix Mail Server </title>