Administrator_Guide/en-US
Jeroen van Meeuwen
vanmeeuwen at kolabsys.com
Tue Sep 4 20:24:11 CEST 2012
Administrator_Guide/en-US/Administrator_Guide.xml | 10
Administrator_Guide/en-US/Book_Info.xml | 40
Administrator_Guide/en-US/Combating_Spam.xml | 1318 +++++-----
Administrator_Guide/en-US/Configuring_the_Kolab_Server.xml | 266 +-
Administrator_Guide/en-US/Detailed_Kolab_Server_Overview.xml | 776 ++---
Administrator_Guide/en-US/Hosted_Kolab_Groupware_Setup.xml | 603 ++++
Administrator_Guide/en-US/Kolab_Web_Administration_Panel.xml | 658 ++--
Administrator_Guide/en-US/Preface.xml | 8
Administrator_Guide/en-US/Revision_History.xml | 38
Administrator_Guide/en-US/Tweaking_Tips_for_389_Directory_Server.xml | 230 -
Administrator_Guide/en-US/Tweaking_Tips_for_Cyrus_IMAP.xml | 302 +-
Administrator_Guide/en-US/Tweaking_Tips_for_Postfix.xml | 70
Administrator_Guide/en-US/Tweaking_Tips_for_Roundcube.xml | 348 +-
Administrator_Guide/en-US/Upgrading_Accounts_from_Kolab_Format_version_2.xml | 72
Administrator_Guide/en-US/Upgrading_Cyrus_IMAP_from_2.3_to_2.4.xml | 222 -
Administrator_Guide/en-US/Upgrading_from_Kolab_2_on_OpenPKG.xml | 500 +--
Administrator_Guide/en-US/Verifying_the_Installation.xml | 608 ++--
Administrator_Guide/en-US/chap-About_Kolab_Groupware.xml | 38
Administrator_Guide/en-US/part-Clients.xml | 8
Administrator_Guide/en-US/part-Kolab_Server.xml | 25
Administrator_Guide/en-US/sect-Kolab_Recipient_Policy_and_Web_Administration_Panel.xml | 2
21 files changed, 3373 insertions(+), 2769 deletions(-)
New commits:
commit 622e246331a3e0df2a0b0218c2cfd63c512a1f6e
Author: Jeroen van Meeuwen (Kolab Systems) <vanmeeuwen at kolabsys.com>
Date: Tue Sep 4 19:23:14 2012 +0100
Add a chapter on turning a regular Kolab Groupware deployment into a Hosted Kolab Groupware deployment
diff --git a/Administrator_Guide/en-US/Administrator_Guide.xml b/Administrator_Guide/en-US/Administrator_Guide.xml
index bad0d1a..6fe4f69 100644
--- a/Administrator_Guide/en-US/Administrator_Guide.xml
+++ b/Administrator_Guide/en-US/Administrator_Guide.xml
@@ -4,10 +4,10 @@
%BOOK_ENTITIES;
]>
<book>
- <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="part-Kolab_Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <!-- <xi:include href="part-Kolab_Clients.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> --> <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <index />
+ <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="part-Kolab_Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <!-- <xi:include href="part-Kolab_Clients.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> --> <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <index />
</book>
diff --git a/Administrator_Guide/en-US/Book_Info.xml b/Administrator_Guide/en-US/Book_Info.xml
index 2816fc4..6376136 100644
--- a/Administrator_Guide/en-US/Book_Info.xml
+++ b/Administrator_Guide/en-US/Book_Info.xml
@@ -4,28 +4,28 @@
%BOOK_ENTITIES;
]>
<bookinfo id="book-Administrator_Guide-Administrator_Guide">
- <title>Administrator Guide</title>
- <subtitle>short description</subtitle>
- <productname>Kolab Groupware</productname>
- <productnumber>3.0</productnumber>
- <edition>0</edition>
- <pubsnumber>0</pubsnumber>
- <abstract>
- <para>
- A short overview and summary of the book's subject and purpose, traditionally no more than one paragraph long. Note: the abstract will appear in the front matter of your book and will also be placed in the description field of the book's RPM spec file.
- </para>
+ <title>Administrator Guide</title>
+ <subtitle>short description</subtitle>
+ <productname>Kolab Groupware</productname>
+ <productnumber>3.0</productnumber>
+ <edition>0</edition>
+ <pubsnumber>0</pubsnumber>
+ <abstract>
+ <para>
+ A short overview and summary of the book's subject and purpose, traditionally no more than one paragraph long. Note: the abstract will appear in the front matter of your book and will also be placed in the description field of the book's RPM spec file.
+ </para>
- </abstract>
- <corpauthor>
- <inlinemediaobject>
- <imageobject>
- <imagedata fileref="images/title_logo.png" format="PNG" />
- </imageobject>
+ </abstract>
+ <corpauthor>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata fileref="images/title_logo.png" format="PNG" />
+ </imageobject>
- </inlinemediaobject>
+ </inlinemediaobject>
- </corpauthor>
- <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ </corpauthor>
+ <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</bookinfo>
diff --git a/Administrator_Guide/en-US/Combating_Spam.xml b/Administrator_Guide/en-US/Combating_Spam.xml
index 9942529..cd00ca2 100644
--- a/Administrator_Guide/en-US/Combating_Spam.xml
+++ b/Administrator_Guide/en-US/Combating_Spam.xml
@@ -4,723 +4,723 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Combating_Spam">
- <title>Combating Spam</title>
- <para>
- Kolab Groupware includes <application>SpamAssassin</application>, a fast, well-established anti-spam solution with a large community of supporters contributing not only to the code, but to rulesets as well.
- </para>
- <para>
- Combating spam is always a tricky situation. On the organizational level, a strategy has to be formulated to combat spam in order to achieve the maximum flexibility and effectiveness for individual users, separate organizations, and the deployment as a whole.
- </para>
- <para>
- A common deployment is to define deployment-wide user preferences and to use a single, deployment-wide set of rules for <application>SpamAssassin</application> to operate with -including Bayes database(s).
- </para>
- <para>
- The problems start when individual users mark legitimate email as spam, most notably the company newsletter or correspondation they have opted in some time ago, but wish to no longer receive. Users tend to ignore the long-term effects of marking these message as spam, if at all they are aware of any, and just want such messages out of their way.
- </para>
- <para>
- Common examples of the sort of messages that are often marked as spam while being legitimate traffic include:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- Newsletters, where users, rather then unsubscribe, mark legitimate messages as spam,
- </para>
-
- </listitem>
- <listitem>
- <para>
- Notifications from social networks such as from Google+, Facebook, Twitter, etc., where users, rather then adjust their notification preferences, mark legitimate messages as spam,
- </para>
-
- </listitem>
- <listitem>
- <para>
- Notifications from forums and/or services,
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
- <para>
- If enough users mark these messages as spam, the system will start to recognize these messages as spam, and other users may be prevented from receiving the same or similar messages in their INBOX.
- </para>
- <para>
- <application>Amavis</application>, the default content filter performing anti-virus and anti-spam, wraps around <application>SpamAssassin</application> to achieve this flexibility.
- </para>
- <para>
- Separate Bayes database(s) can be created on a per-recipient and per-policy-bank <application>SpamAssassin</application> configuration files and SQL Bayes usernames.
- </para>
- <para>
- Without over-complicating things, a common scenario sufficiently serving the anti-spam effort, includes the following aspects;
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- A <code>shared/Spam</code> folder is created, with permissions for all users to lookup, read, and insert messages. It is the intention users move or copy messages they think are spam into this folder.
- </para>
- <note>
- <para>
- Note that, optionally, the permissions for users to maintain the 'seen' state of messages could not be granted, which in combination with <literal>sharedseen</literal> could provide a mechanism that would allow users to view which messages have been learned as spam in the past.
- </para>
-
- </note>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
- <section id="sect-Administrator_Guide-Combating_Spam-Learning_About_New_Spam">
- <title>Learning About New Spam</title>
- <para>
- Optionally, find all folders named "Spam" or "Junk":
- </para>
- <para>
-
+ <title>Combating Spam</title>
+ <para>
+ Kolab Groupware includes <application>SpamAssassin</application>, a fast, well-established anti-spam solution with a large community of supporters contributing not only to the code, but to rulesets as well.
+ </para>
+ <para>
+ Combating spam is always a tricky situation. On the organizational level, a strategy has to be formulated to combat spam in order to achieve the maximum flexibility and effectiveness for individual users, separate organizations, and the deployment as a whole.
+ </para>
+ <para>
+ A common deployment is to define deployment-wide user preferences and to use a single, deployment-wide set of rules for <application>SpamAssassin</application> to operate with -including Bayes database(s).
+ </para>
+ <para>
+ The problems start when individual users mark legitimate email as spam, most notably the company newsletter or correspondation they have opted in some time ago, but wish to no longer receive. Users tend to ignore the long-term effects of marking these message as spam, if at all they are aware of any, and just want such messages out of their way.
+ </para>
+ <para>
+ Common examples of the sort of messages that are often marked as spam while being legitimate traffic include:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Newsletters, where users, rather then unsubscribe, mark legitimate messages as spam,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Notifications from social networks such as from Google+, Facebook, Twitter, etc., where users, rather then adjust their notification preferences, mark legitimate messages as spam,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Notifications from forums and/or services,
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <para>
+ If enough users mark these messages as spam, the system will start to recognize these messages as spam, and other users may be prevented from receiving the same or similar messages in their INBOX.
+ </para>
+ <para>
+ <application>Amavis</application>, the default content filter performing anti-virus and anti-spam, wraps around <application>SpamAssassin</application> to achieve this flexibility.
+ </para>
+ <para>
+ Separate Bayes database(s) can be created on a per-recipient and per-policy-bank <application>SpamAssassin</application> configuration files and SQL Bayes usernames.
+ </para>
+ <para>
+ Without over-complicating things, a common scenario sufficiently serving the anti-spam effort, includes the following aspects;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ A <code>shared/Spam</code> folder is created, with permissions for all users to lookup, read, and insert messages. It is the intention users move or copy messages they think are spam into this folder.
+ </para>
+ <note>
+ <para>
+ Note that, optionally, the permissions for users to maintain the 'seen' state of messages could not be granted, which in combination with <literal>sharedseen</literal> could provide a mechanism that would allow users to view which messages have been learned as spam in the past.
+ </para>
+
+ </note>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <section id="sect-Administrator_Guide-Combating_Spam-Learning_About_New_Spam">
+ <title>Learning About New Spam</title>
+ <para>
+ Optionally, find all folders named "Spam" or "Junk":
+ </para>
+ <para>
+
<screen>$ <userinput>find /var/spool/imap/ -type d -name "Spam" -o -name "Junk"</userinput></screen>
- </para>
- <note>
- <para>
- Finding all folders called "Spam" or "Junk" can potentially take a long time, depending on the size of the spool.
- </para>
+ </para>
+ <note>
+ <para>
+ Finding all folders called "Spam" or "Junk" can potentially take a long time, depending on the size of the spool.
+ </para>
+
+ </note>
+ <remark> We would like to do the very same through IMAP, with annotations / SPECIAL-USE. </remark>
+ <para>
- </note>
- <remark> We would like to do the very same through IMAP, with annotations / SPECIAL-USE. </remark>
- <para>
-
<screen>$ <userinput>sa-learn --spam /path/to/folder/[0-9]*.</userinput></screen>
- </para>
- <note>
- <para>
- <application>SpamAssassin</application> will not learn about messages it has learned about before. There's no requirement of purging or deleting the messages that <application>SpamAssassin</application> has learned about already, and purging or deleting those messages only helps to speed up the learning process run.
- </para>
-
- </note>
- <warning>
- <para>
- Do NOT delete the messages from the filesystem directly. Please refer to <xref linkend="sect-Administrator_Guide-Combating_Spam-Expiring_Messages_from_SpamHam_Shared_Folders" /> for ways to purge, expire and/or delete messages from spam folders in a sustainable way.
- </para>
-
- </warning>
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Preseeding_the_Bayes_Database">
- <title>Preseeding the Bayes Database</title>
- <para>
- As Bayes is only effective after it has learned about 200 messages, it is recommended to preseed the Bayes database with some high-quality ham and spam. Preseeding the Bayes database with some ham, and some spam, is done using the <emphasis>SpamAssassin Public Corpus</emphasis>. The public corpus consists of many messages qualified as ham and spam, collected from a variety of sources.
- </para>
- <para>
- The SpamAssassin Public Corpus can be found at <ulink url="http://spamassassin.apache.org/publiccorpus/" />.
- </para>
- <procedure id="proc-Administrator_Guide-Preseeding_the_Bayes_Database-Preseeding_the_Bayes_Database_using_SpamAssassin_Public_Corpus">
- <title>Preseeding the Bayes Database using SpamAssassin Public Corpus</title>
- <step>
- <para>
- Obtain the ham and spam archives:
- </para>
- <para>
-
+ </para>
+ <note>
+ <para>
+ <application>SpamAssassin</application> will not learn about messages it has learned about before. There's no requirement of purging or deleting the messages that <application>SpamAssassin</application> has learned about already, and purging or deleting those messages only helps to speed up the learning process run.
+ </para>
+
+ </note>
+ <warning>
+ <para>
+ Do NOT delete the messages from the filesystem directly. Please refer to <xref linkend="sect-Administrator_Guide-Combating_Spam-Expiring_Messages_from_SpamHam_Shared_Folders" /> for ways to purge, expire and/or delete messages from spam folders in a sustainable way.
+ </para>
+
+ </warning>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Preseeding_the_Bayes_Database">
+ <title>Preseeding the Bayes Database</title>
+ <para>
+ As Bayes is only effective after it has learned about 200 messages, it is recommended to preseed the Bayes database with some high-quality ham and spam. Preseeding the Bayes database with some ham, and some spam, is done using the <emphasis>SpamAssassin Public Corpus</emphasis>. The public corpus consists of many messages qualified as ham and spam, collected from a variety of sources.
+ </para>
+ <para>
+ The SpamAssassin Public Corpus can be found at <ulink url="http://spamassassin.apache.org/publiccorpus/" />.
+ </para>
+ <procedure id="proc-Administrator_Guide-Preseeding_the_Bayes_Database-Preseeding_the_Bayes_Database_using_SpamAssassin_Public_Corpus">
+ <title>Preseeding the Bayes Database using SpamAssassin Public Corpus</title>
+ <step>
+ <para>
+ Obtain the ham and spam archives:
+ </para>
+ <para>
+
<screen># mkdir -p /tmp/salearn
# cd /tmp/salearn
# wget --recursive --timestamping --no-directories --level=1 --reject=gif,png,html,=A,=D http://spamassassin.apache.org/publiccorpus/</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Extract the archives:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Extract the archives:
- </para>
- <para>
-
<screen># for archive in `ls -1 *.tar.bz2`; do tar jxf $archive; done</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ For all files in the ham directories, learn those messages as ham:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- For all files in the ham directories, learn those messages as ham:
- </para>
- <para>
-
<screen># sa-learn --progress --ham *ham*/*</screen>
- </para>
- <note>
- <para>
- The total number of messages is about 7000. Learning about all of them may take quite a while. We recommend running the command in a screen.
- </para>
-
- </note>
-
- </step>
- <step>
- <para>
- For all files in the spam directories, learn those messages as spam:
- </para>
- <para>
-
+ </para>
+ <note>
+ <para>
+ The total number of messages is about 7000. Learning about all of them may take quite a while. We recommend running the command in a screen.
+ </para>
+
+ </note>
+
+ </step>
+ <step>
+ <para>
+ For all files in the spam directories, learn those messages as spam:
+ </para>
+ <para>
+
<screen># sa-learn --progress --spam *spam*/*</screen>
- </para>
- <note>
- <para>
- The total number of messages is about 2500. Learning about all of them may take quite a while. We recommend running the command in a screen.
- </para>
-
- </note>
-
- </step>
-
- </procedure>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Trapping_Massive_Amounts_of_Spam">
- <title>Trapping Massive Amounts of Spam</title>
- <para>
- To learn about spam quickly, allow the Cyrus IMAP postuser to post into a shared folder that will be included in the regular <command>sa-learn</command> run.
- </para>
- <procedure id="proc-Administrator_Guide-Trapping_Massive_Amounts_of_Spam-Setting_a_Trap_for_Spam">
- <title>Setting a Trap for Spam</title>
- <step>
- <para>
- Set up the Cyrus IMAP postuser, using the <literal>postuser</literal> setting in <filename>/etc/imapd.conf</filename>.
- </para>
- <para>
- If, for example, the <literal>postuser</literal> is set to <literal>bb</literal>, the mail to <literal>bb+shared.blah</literal> will be delivered to the <literal>shared.blah</literal> folder.
- </para>
-
- </step>
- <step>
- <para>
- Create a folder such as <literal>shared/Spam</literal>
- </para>
-
- </step>
- <step>
- <para>
- Set permissions:
- </para>
- <para>
-
+ </para>
+ <note>
+ <para>
+ The total number of messages is about 2500. Learning about all of them may take quite a while. We recommend running the command in a screen.
+ </para>
+
+ </note>
+
+ </step>
+
+ </procedure>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Trapping_Massive_Amounts_of_Spam">
+ <title>Trapping Massive Amounts of Spam</title>
+ <para>
+ To learn about spam quickly, allow the Cyrus IMAP postuser to post into a shared folder that will be included in the regular <command>sa-learn</command> run.
+ </para>
+ <procedure id="proc-Administrator_Guide-Trapping_Massive_Amounts_of_Spam-Setting_a_Trap_for_Spam">
+ <title>Setting a Trap for Spam</title>
+ <step>
+ <para>
+ Set up the Cyrus IMAP postuser, using the <literal>postuser</literal> setting in <filename>/etc/imapd.conf</filename>.
+ </para>
+ <para>
+ If, for example, the <literal>postuser</literal> is set to <literal>bb</literal>, the mail to <literal>bb+shared.blah</literal> will be delivered to the <literal>shared.blah</literal> folder.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Create a folder such as <literal>shared/Spam</literal>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Set permissions:
+ </para>
+ <para>
+
<screen>cyradm> sam shared/Spam <postuser> p</screen>
- </para>
-
- </step>
- <step>
- <para>
- Submit / subscribe to known spam aggregators (search Google for "free email offers")
- </para>
-
- </step>
- <step>
- <para>
- Optionally, set the <literal>luser_relay</literal> option in Postfix, to trap all messages sent to non-existent recipients.
- </para>
-
- </step>
-
- </procedure>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Tweaking_Bayes_Scores">
- <title>Tweaking Bayes' Scores</title>
- <para>
- Bayes' score is dependent on the probability Bayes attaches of a message being spam. The rules used to match a message's probability of being spam are systematically prefixed with <literal>BAYES_</literal>, followed by the percentage of likelihood of the message being spam.
- </para>
- <para>
- Because there is rarely a 100% certainty of a message being spam, the highest percentage is 99%. By default, the configuration attaches a 3.5 score to this probability. Depending on the configuration value for <literal>$sa_tag2_level_deflt</literal> supplied in the Amavis configuration file, <literal>6.31</literal> by default, it is unlikely spam will reach the cut-off point of actually being marked as spam solely on the basis of Bayes' probability score.
- </para>
- <para>
- It is therefor recommended to increase the score attached to messages with a 99% probability of being spam to at least <literal>6.308</literal>, if not simply <literal>6.31</literal>. Using <literal>6.308</literal>, you configure spam to be tagged not solely on the basis of Bayes' 99% probability score, but request that in addition the message is recognized to be in HTML (and HTML only), and perhaps uses a big font –or similar patterns with a very small <literal>0.01</literal> score.
- </para>
- <para>
- Some spam has been submitted through systems listed at <ulink url="http://dnswl.org" />, a collaborative false positive protection mechanism, a default score of 1 is substracted from the total score. If this spam reaches you, consider increasing the score on <literal>BAYES_99</literal> with another one point.
- </para>
- <procedure id="proc-Administrator_Guide-Tweaking_Bayes_Scores-Adjusting_the_Score_for_BAYES_99">
- <title>Adjusting the Score for <literal>BAYES_99</literal></title>
- <step>
- <para>
- Edit <filename>/etc/mail/spamassassin/local.cf</filename>, and make sure the following line is present:
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Submit / subscribe to known spam aggregators (search Google for "free email offers")
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Optionally, set the <literal>luser_relay</literal> option in Postfix, to trap all messages sent to non-existent recipients.
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Tweaking_Bayes_Scores">
+ <title>Tweaking Bayes' Scores</title>
+ <para>
+ Bayes' score is dependent on the probability Bayes attaches of a message being spam. The rules used to match a message's probability of being spam are systematically prefixed with <literal>BAYES_</literal>, followed by the percentage of likelihood of the message being spam.
+ </para>
+ <para>
+ Because there is rarely a 100% certainty of a message being spam, the highest percentage is 99%. By default, the configuration attaches a 3.5 score to this probability. Depending on the configuration value for <literal>$sa_tag2_level_deflt</literal> supplied in the Amavis configuration file, <literal>6.31</literal> by default, it is unlikely spam will reach the cut-off point of actually being marked as spam solely on the basis of Bayes' probability score.
+ </para>
+ <para>
+ It is therefor recommended to increase the score attached to messages with a 99% probability of being spam to at least <literal>6.308</literal>, if not simply <literal>6.31</literal>. Using <literal>6.308</literal>, you configure spam to be tagged not solely on the basis of Bayes' 99% probability score, but request that in addition the message is recognized to be in HTML (and HTML only), and perhaps uses a big font –or similar patterns with a very small <literal>0.01</literal> score.
+ </para>
+ <para>
+ Some spam has been submitted through systems listed at <ulink url="http://dnswl.org" />, a collaborative false positive protection mechanism, a default score of 1 is substracted from the total score. If this spam reaches you, consider increasing the score on <literal>BAYES_99</literal> with another one point.
+ </para>
+ <procedure id="proc-Administrator_Guide-Tweaking_Bayes_Scores-Adjusting_the_Score_for_BAYES_99">
+ <title>Adjusting the Score for <literal>BAYES_99</literal></title>
+ <step>
+ <para>
+ Edit <filename>/etc/mail/spamassassin/local.cf</filename>, and make sure the following line is present:
+ </para>
+ <para>
+
<screen>score BAYES_99 7.308</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Reload or restart the <literal>amavisd-new</literal> service:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Reload or restart the <literal>amavisd-new</literal> service:
- </para>
- <para>
-
<screen># service amavisd-new restart</screen>
- </para>
-
- </step>
-
- </procedure>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Learning_about_Ham">
- <title>Learning about Ham</title>
- <para>
- It is important to not just learn about spam, but learn about ham, legitimate email messages, as well. When not learning about ham, the anti-spam system will become heavily biased towards spam, and ultimately classify all email messages as such.
- </para>
- <para>
- Learning about ham follows a slightly different doctrine then learning about spam. Most importantly, ham is not to be posted to a shared folder that everyone else can read the contents from. It is most commonly a "Not Junk" or "Ham" folder in one's personal namespace users are instructed to copy or move messages to, that have been classified as spam but are actually ham.
- </para>
- <para>
- It is recommended users are both instructed to use ham folders, as well as create them by default —regardless whether they are called "Ham" or "Not Junk" or equivalent localized version of such.
- </para>
- <para>
- Alternatively, you could learn about ham from people's INBOX folders.
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Expiring_Messages_from_SpamHam_Shared_Folders">
- <title>Expiring Messages from Spam/Ham (Shared) Folders</title>
- <para>
- When you share folders to which users can move or copy ham and/or spam messages, it is sensible to purge the contents of those folders regularly, or the folder size continues to increase indefinitely. Run the expiry after <command>sa-learn</command> has been run.
- </para>
- <note>
- <para>
- Running <command>ipurge</command> to purge mail folder messages occurs independent from setting <literal>expunge_mode</literal>, and independent from the <literal>expire</literal> annotation as well.
- </para>
- <para>
- Using the <literal>expire</literal> annotation is sufficient to purge the contents of the folder, as, with or without the <literal>expunge_mode</literal> setting having been set to delayed, rather then immediate, the Bayes database will only be updated with messages Bayes has not learned about before.
- </para>
-
- </note>
- <para>
- To purge the contents of a mailfolder, run ipurge:
- </para>
- <para>
-
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Learning_about_Ham">
+ <title>Learning about Ham</title>
+ <para>
+ It is important to not just learn about spam, but learn about ham, legitimate email messages, as well. When not learning about ham, the anti-spam system will become heavily biased towards spam, and ultimately classify all email messages as such.
+ </para>
+ <para>
+ Learning about ham follows a slightly different doctrine then learning about spam. Most importantly, ham is not to be posted to a shared folder that everyone else can read the contents from. It is most commonly a "Not Junk" or "Ham" folder in one's personal namespace users are instructed to copy or move messages to, that have been classified as spam but are actually ham.
+ </para>
+ <para>
+ It is recommended users are both instructed to use ham folders, as well as create them by default —regardless whether they are called "Ham" or "Not Junk" or equivalent localized version of such.
+ </para>
+ <para>
+ Alternatively, you could learn about ham from people's INBOX folders.
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Expiring_Messages_from_SpamHam_Shared_Folders">
+ <title>Expiring Messages from Spam/Ham (Shared) Folders</title>
+ <para>
+ When you share folders to which users can move or copy ham and/or spam messages, it is sensible to purge the contents of those folders regularly, or the folder size continues to increase indefinitely. Run the expiry after <command>sa-learn</command> has been run.
+ </para>
+ <note>
+ <para>
+ Running <command>ipurge</command> to purge mail folder messages occurs independent from setting <literal>expunge_mode</literal>, and independent from the <literal>expire</literal> annotation as well.
+ </para>
+ <para>
+ Using the <literal>expire</literal> annotation is sufficient to purge the contents of the folder, as, with or without the <literal>expunge_mode</literal> setting having been set to delayed, rather then immediate, the Bayes database will only be updated with messages Bayes has not learned about before.
+ </para>
+
+ </note>
+ <para>
+ To purge the contents of a mailfolder, run ipurge:
+ </para>
+ <para>
+
<screen>$ <userinput>/usr/lib/cyrus-imapd/ipurge -d 1 user/folder/name at domain.tld</userinput>
(...output abbreviated...)
$ <userinput>/usr/lib/cyrus-imapd/ipurge -i -d 1 user/folder/name at domain.tld</userinput></screen>
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Updating_the_Spam_Rules">
- <title>Updating the Spam Rules</title>
- <para>
- As part of the <application>SpamAssasin</application> package, a utility is provided to update the rulesets from channels configured.
- </para>
- <para>
- For systems on which either of the SpamAssassin daemon or Amavis daemon is running, the software packages automatically install a nightly cronjob to ensure the rules are updated frequently.
- </para>
- <para>
- The spam rulesets are updated using the <command>sa-update</command> command, supplying one or more <literal>--channel</literal> options specifying the names of the ruleset channels to update, and (optionally) one or more <literal>--gpgkey</literal> options specifying the Pretty Good Privacy keys to allow signatures on the rulesets to have been signed with.
- </para>
- <para>
- The cronjob that is installed by default, executes <command>sa-update</command> for all channels defined in <filename>/etc/mail/spamassassin/channels.d/</filename> with one file per channel.
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Bayes_SQL_Database_for_Distributed_Systems">
- <title>Bayes SQL Database for Distributed Systems</title>
- <para>
- If more then one system needs to make use of the Bayes database, consider using a network SQL Bayes database.
- </para>
- <procedure id="proc-Administrator_Guide-Bayes_SQL_Database_for_Distributed_Systems-Setting_Up_the_Bayes_Database">
- <title>Setting Up the Bayes Database</title>
- <step>
- <para>
- Create the database:
- </para>
- <para>
-
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Updating_the_Spam_Rules">
+ <title>Updating the Spam Rules</title>
+ <para>
+ As part of the <application>SpamAssasin</application> package, a utility is provided to update the rulesets from channels configured.
+ </para>
+ <para>
+ For systems on which either of the SpamAssassin daemon or Amavis daemon is running, the software packages automatically install a nightly cronjob to ensure the rules are updated frequently.
+ </para>
+ <para>
+ The spam rulesets are updated using the <command>sa-update</command> command, supplying one or more <literal>--channel</literal> options specifying the names of the ruleset channels to update, and (optionally) one or more <literal>--gpgkey</literal> options specifying the Pretty Good Privacy keys to allow signatures on the rulesets to have been signed with.
+ </para>
+ <para>
+ The cronjob that is installed by default, executes <command>sa-update</command> for all channels defined in <filename>/etc/mail/spamassassin/channels.d/</filename> with one file per channel.
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Bayes_SQL_Database_for_Distributed_Systems">
+ <title>Bayes SQL Database for Distributed Systems</title>
+ <para>
+ If more then one system needs to make use of the Bayes database, consider using a network SQL Bayes database.
+ </para>
+ <procedure id="proc-Administrator_Guide-Bayes_SQL_Database_for_Distributed_Systems-Setting_Up_the_Bayes_Database">
+ <title>Setting Up the Bayes Database</title>
+ <step>
+ <para>
+ Create the database:
+ </para>
+ <para>
+
<screen># mysql -e 'create database <emphasis>kolab_bayes</emphasis><footnote> <para>
- Replace with desired database name
- </para>
- </footnote>;'</screen>
-
- </para>
-
- </step>
- <step>
- <para>
- Create a user and grant the appropriate privileges:
- </para>
- <para>
-
+ Replace with desired database name
+ </para>
+ </footnote>;'</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Create a user and grant the appropriate privileges:
+ </para>
+ <para>
+
<screen># mysql -e "CREATE USER '<emphasis>kolab_bayes</emphasis><footnote> <para>
- Replace with desired username
- </para>
- </footnote>'@'%' IDENTIFIED BY PASSWORD '<emphasis>Welcome2KolabSystems</emphasis><footnote> <para>
- Replace with desired password
- </para>
- </footnote>';"</screen>
-
- </para>
-
- </step>
- <step>
- <para>
- Grant the appropriate privileges:
- </para>
- <para>
-
+ Replace with desired username
+ </para>
+ </footnote>'@'%' IDENTIFIED BY PASSWORD '<emphasis>Welcome2KolabSystems</emphasis><footnote> <para>
+ Replace with desired password
+ </para>
+ </footnote>';"</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Grant the appropriate privileges:
+ </para>
+ <para>
+
<screen># mysql -e "GRANT USAGE ON * . * TO '<emphasis>kolab_bayes</emphasis><footnote> <para>
- Replace with desired username
- </para>
- </footnote>'@'%' IDENTIFIED BY PASSWORD '<emphasis>Welcome2KolabSystems</emphasis><footnote> <para>
- Replace with desired password
- </para>
- </footnote>' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;"
+ Replace with desired username
+ </para>
+ </footnote>'@'%' IDENTIFIED BY PASSWORD '<emphasis>Welcome2KolabSystems</emphasis><footnote> <para>
+ Replace with desired password
+ </para>
+ </footnote>' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;"
# mysql -e "GRANT ALL PRIVILEGES on `<emphasis>kolab_bayes</emphasis><footnote> <para>
- Replace with desired database name
- </para>
- </footnote>` . * TO '<emphasis>kolab_bayes</emphasis><footnote> <para>
- Replace with desired username
- </para>
- </footnote>'@'%';"</screen>
-
- </para>
-
- </step>
- <step>
- <para>
- Reload the privileges:
- </para>
- <para>
-
+ Replace with desired database name
+ </para>
+ </footnote>` . * TO '<emphasis>kolab_bayes</emphasis><footnote> <para>
+ Replace with desired username
+ </para>
+ </footnote>'@'%';"</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Reload the privileges:
+ </para>
+ <para>
+
<screen># mysql -e 'FLUSH PRIVILEGES;'</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Download the latest Bayes Database SQL schema file from <ulink url="http://svn.apache.org/repos/asf/spamassassin/trunk/sql/bayes_mysql.sql">bayes_mysql.sql</ulink> (when using MySQL):
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Download the latest Bayes Database SQL schema file from <ulink url="http://svn.apache.org/repos/asf/spamassassin/trunk/sql/bayes_mysql.sql">bayes_mysql.sql</ulink> (when using MySQL):
- </para>
- <para>
-
<screen># wget <ulink url="http://svn.apache.org/repos/asf/spamassassin/trunk/sql/bayes_mysql.sql" /></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Insert this schema into the database:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Insert this schema into the database:
- </para>
- <para>
-
<screen># mysql <emphasis>kolab_bayes</emphasis><footnote> <para>
- Replace with database name used.
- </para>
- </footnote> < bayes_mysql.sql</screen>
-
- </para>
-
- </step>
-
- </procedure>
-
- <procedure id="proc-Administrator_Guide-Bayes_SQL_Database_for_Distributed_Systems-Migrating_Existing_Bayes_Databases">
- <title>Migrating Existing Bayes Database(s)</title>
- <step>
- <para>
- First, export any existing Bayes databases, run the following command (on each server with a Bayes database):
- </para>
- <para>
-
+ Replace with database name used.
+ </para>
+ </footnote> < bayes_mysql.sql</screen>
+
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <procedure id="proc-Administrator_Guide-Bayes_SQL_Database_for_Distributed_Systems-Migrating_Existing_Bayes_Databases">
+ <title>Migrating Existing Bayes Database(s)</title>
+ <step>
+ <para>
+ First, export any existing Bayes databases, run the following command (on each server with a Bayes database):
+ </para>
+ <para>
+
<screen># sa-learn --backup > <filename>/path/to/sa_backup.txt</filename></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ A recommended step, but completely optional, is to expire the current copy of the database:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- A recommended step, but completely optional, is to expire the current copy of the database:
- </para>
- <para>
-
<screen># sa-learn --clear</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Modify <filename>/etc/mail/spamassassin/local.cf</filename> to contain the following settings:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Modify <filename>/etc/mail/spamassassin/local.cf</filename> to contain the following settings:
- </para>
- <para>
-
<screen>bayes_store_module Mail::SpamAssassin::BayesStore::SQL
bayes_sql_dsn DBI:mysql:<emphasis>kolab_bayes</emphasis><footnote> <para>
- Replace with database name
- </para>
- </footnote>:<emphasis>mysql.domain.tld</emphasis><footnote> <para>
- Replace with MySQL server host address
- </para>
- </footnote>
+ Replace with database name
+ </para>
+ </footnote>:<emphasis>mysql.domain.tld</emphasis><footnote> <para>
+ Replace with MySQL server host address
+ </para>
+ </footnote>
bayes_sql_username <emphasis>kolab_bayes</emphasis><footnote> <para>
- Replace with the username for database access
- </para>
- </footnote>
+ Replace with the username for database access
+ </para>
+ </footnote>
bayes_sql_password <emphasis>Welcome2KolabSystems</emphasis><footnote> <para>
- Replace with the user password
- </para>
- </footnote>
+ Replace with the user password
+ </para>
+ </footnote>
bayes_sql_override_username root</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Import the exported Bayes database(s):
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Import the exported Bayes database(s):
- </para>
- <para>
-
<screen># sa-learn --restore <filename>/path/to/sa_backup.txt</filename></screen>
- </para>
-
- </step>
-
- </procedure>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Ensuring_Availability_of_Messages_Spam_Score">
- <title>Ensuring Availability of Messages' Spam Score</title>
- <para>
- For the purpose of troubleshooting, or in deployments with clients that have spam filtering capabilities, it is sensible to always insert the spam headers into email messages, both to avoid clients scanning the message again, as well as troubleshooting why mail may or may not have been filtered.
- </para>
- <para>
- To always insert the spam score into the message headers, find the line in <filename>/etc/amavisd/amavisd.conf</filename> that starts with <literal>$sa_tag_level_deflt</literal> and replace it with:
- </para>
- <para>
-
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Ensuring_Availability_of_Messages_Spam_Score">
+ <title>Ensuring Availability of Messages' Spam Score</title>
+ <para>
+ For the purpose of troubleshooting, or in deployments with clients that have spam filtering capabilities, it is sensible to always insert the spam headers into email messages, both to avoid clients scanning the message again, as well as troubleshooting why mail may or may not have been filtered.
+ </para>
+ <para>
+ To always insert the spam score into the message headers, find the line in <filename>/etc/amavisd/amavisd.conf</filename> that starts with <literal>$sa_tag_level_deflt</literal> and replace it with:
+ </para>
+ <para>
+
<screen>$sa_tag_level_deflt = -10;</screen>
- </para>
- <para>
- While the score is available from the log files should the level of logging verbosity have been increased, in some scenarios it is necessary to include the spam score regardless of the traffic being inbound or outbound. An example is a mail gateway for an unknown number of, or regularly changing, or dynamic, or large list of domain name spaces with both inbound and outbound traffic, which needs to be protected senders as well as receivers from spam.
- </para>
- <para>
- Normally only inbound traffic is tagged –if at all–, by recognizing the recipient domain name space as local. The setting <literal>@local_domains</literal> or, in later versions of Amavis, <literal>@local_domains_acl</literal> is used.
- </para>
- <para>
- In a default Kolab Groupware installation, the recipients are looked up in LDAP, and if an entry is found, Amavisd will also classify the domain as local – regardless of any <literal>@local_domains</literal> and/or <literal>@local_domains_acl</literal> setting.
- </para>
- <section id="sect-Administrator_Guide-Ensuring_Availability_of_Messages_Spam_Score-Adding_Spam_Headers_to_All_Messages">
- <title>Adding Spam Headers to All Messages</title>
- <para>
- To recognize all domain name spaces as local, edit <filename>/etc/amavisd/amavisd.conf</filename> and make sure the following settings are not configured:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <literal>@local_domains</literal>,
- </para>
-
- </listitem>
- <listitem>
- <para>
- <literal>@local_domains_acl</literal>, and
- </para>
-
- </listitem>
- <listitem>
- <para>
- any <literal>read_hash(\%local_domains)</literal> setting.
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
- <para>
- Ensure that the following setting is configured like so:
- </para>
- <para>
-
+ </para>
+ <para>
+ While the score is available from the log files should the level of logging verbosity have been increased, in some scenarios it is necessary to include the spam score regardless of the traffic being inbound or outbound. An example is a mail gateway for an unknown number of, or regularly changing, or dynamic, or large list of domain name spaces with both inbound and outbound traffic, which needs to be protected senders as well as receivers from spam.
+ </para>
+ <para>
+ Normally only inbound traffic is tagged –if at all–, by recognizing the recipient domain name space as local. The setting <literal>@local_domains</literal> or, in later versions of Amavis, <literal>@local_domains_acl</literal> is used.
+ </para>
+ <para>
+ In a default Kolab Groupware installation, the recipients are looked up in LDAP, and if an entry is found, Amavisd will also classify the domain as local – regardless of any <literal>@local_domains</literal> and/or <literal>@local_domains_acl</literal> setting.
+ </para>
+ <section id="sect-Administrator_Guide-Ensuring_Availability_of_Messages_Spam_Score-Adding_Spam_Headers_to_All_Messages">
+ <title>Adding Spam Headers to All Messages</title>
+ <para>
+ To recognize all domain name spaces as local, edit <filename>/etc/amavisd/amavisd.conf</filename> and make sure the following settings are not configured:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>@local_domains</literal>,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <literal>@local_domains_acl</literal>, and
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ any <literal>read_hash(\%local_domains)</literal> setting.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <para>
+ Ensure that the following setting is configured like so:
+ </para>
+ <para>
+
<screen language="Perl">$local_domains_re = new_RE( qr'.*' );</screen>
- </para>
- <para>
- Also disable the LDAP lookups, by removing the following settings:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <literal>$enable_ldap</literal>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <literal>$default_ldap</literal>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </section>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Default_Amavisd_Behaviour">
- <title>Default Amavisd Behaviour</title>
- <para>
- The default behaviour shown in a Kolab Groupware deployment depends on the default settings that come with the packages delivered mostly through native, distribution-specific software repositories. This chapter documents various aspects of the behaviour Kolab Groupware will show referring to the appropriate settings that will allow a system administrator to modify the behaviour.
- </para>
- <formalpara id="form-Administrator_Guide-Default_Amavisd_Behaviour-Adding_Spam_Information_Headers">
- <title>Adding Spam Information Headers</title>
- <para>
- Amavisd, by default, adds spam information headers only to messages that;
- </para>
-
- </formalpara>
- <para>
- <orderedlist>
- <listitem>
- <para>
- Are intended for delivery to local recipients,
- </para>
-
- </listitem>
- <listitem>
- <para>
- Get a spam score over <literal>2.0</literal> from <application>SpamAssassin</application>.
- </para>
- <para>
- The related setting is <literal>$sa_tag_level_deflt</literal> in <filename>/etc/amavisd/amavisd.conf</filename>.
- </para>
-
- </listitem>
-
- </orderedlist>
-
- </para>
- <formalpara id="form-Administrator_Guide-Default_Amavisd_Behaviour-Spam_Kill_Level">
- <title>Spam Kill Level</title>
- <para>
- The spam kill level controls which score spam must have been marked with before Amavisd considers the message to not be delivered to the intended recipient(s).
- </para>
-
- </formalpara>
- <para>
- Depending on your platform, the default for this score is <literal>6.31</literal> or <literal>6.9</literal>. When a message is marked with a spam score higher than or equal to this level, Amavisd will take "evasive action". See <xref linkend="sect-Administrator_Guide-Combating_Spam-Configuring_Amavis_Evasive_Action" /> for more information on configuring evasive actions.
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Combating_Spam-Configuring_Amavis_Evasive_Action">
- <title>Configuring Amavis Evasive Action</title>
- <para>
- You can control what "evasive action" Amavisd takes using the <literal>$final_spam_destiny</literal> and <literal>$final_virus_destiny</literal> settings in <filename>/etc/amavisd/amavisd.conf</filename>. The default is usually to discard the message, but the following options are available:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-D_PASS">
- <title>D_PASS</title>
- <para>
- The message is accepted for delivery to the intended recipient(s), despite having been scored passed the kill or cutoff level, and regardless of bad content.
- </para>
-
- </formalpara>
- <para>
- If a quarantine address has been configured, the quarantine address will receive a copy of the email. See <xref linkend="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine" /> to learn how to configure the quarantine address.
- </para>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-D_BOUNCE">
- <title>D_BOUNCE</title>
- <para>
- The message is not accepted for delivery to the intended recipient(s). A Delivery Status Notification stating delivery failure is sent out to the sender.
- </para>
-
- </formalpara>
- <para>
- If a quarantine address has been configured, the quarantine address will receive a copy of the email. See <xref linkend="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine" /> to learn how to configure the quarantine address.
- </para>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-D_REJECT">
- <title>D_REJECT</title>
- <para>
- The message is rejected by Amavisd, and while Amavisd sends out a 550 SMTP response to the Mail Transfer Agent, said Mail Transfer Agent is responsible for sending out the Delivery Status Notification, if any.
- </para>
-
- </formalpara>
- <para>
- If a quarantine address has been configured, the quarantine address will receive a copy of the email. See <xref linkend="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine" /> to learn how to configure the quarantine address.
- </para>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-D_DISCARD">
- <title>D_DISCARD</title>
- <para>
- The message is simply discarded by Amavisd. The sending Mail Transfer Agent will receive a positive SMTP delivery response, and Amavisd sends out no Delivery Status Notification, nor does it forward the message for delivery to the intended recipients.
- </para>
-
- </formalpara>
- <para>
- If a quarantine address has been configured, the quarantine address will receive a copy of the email. See <xref linkend="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine" /> to learn how to configure the quarantine address.
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
- <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine">
- <title>Configuring Quarantine</title>
- <para>
- Two separate quarantine forwarding addresses can be configured. One is for messages labeled as spam, another for messages suspected to contain a virus.
- </para>
-
- </formalpara>
- <para>
- A catchall address for spam can be configured by setting the <literal>$spam_quarantine_to</literal> setting to a valid recipient address in <filename>/etc/amavisd/amavisd.conf</filename>
- </para>
- <para>
- A catchall address for messages suspected of containing a virus can be configured by setting the <literal>$virus_quarantine_to</literal> setting to a valid recipient address in <filename>/etc/amavisd/amavisd.conf</filename>.
- </para>
-
- </section>
-
+ </para>
+ <para>
+ Also disable the LDAP lookups, by removing the following settings:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>$enable_ldap</literal>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <literal>$default_ldap</literal>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Default_Amavisd_Behaviour">
+ <title>Default Amavisd Behaviour</title>
+ <para>
+ The default behaviour shown in a Kolab Groupware deployment depends on the default settings that come with the packages delivered mostly through native, distribution-specific software repositories. This chapter documents various aspects of the behaviour Kolab Groupware will show referring to the appropriate settings that will allow a system administrator to modify the behaviour.
+ </para>
+ <formalpara id="form-Administrator_Guide-Default_Amavisd_Behaviour-Adding_Spam_Information_Headers">
+ <title>Adding Spam Information Headers</title>
+ <para>
+ Amavisd, by default, adds spam information headers only to messages that;
+ </para>
+
+ </formalpara>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Are intended for delivery to local recipients,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Get a spam score over <literal>2.0</literal> from <application>SpamAssassin</application>.
+ </para>
+ <para>
+ The related setting is <literal>$sa_tag_level_deflt</literal> in <filename>/etc/amavisd/amavisd.conf</filename>.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <formalpara id="form-Administrator_Guide-Default_Amavisd_Behaviour-Spam_Kill_Level">
+ <title>Spam Kill Level</title>
+ <para>
+ The spam kill level controls which score spam must have been marked with before Amavisd considers the message to not be delivered to the intended recipient(s).
+ </para>
+
+ </formalpara>
+ <para>
+ Depending on your platform, the default for this score is <literal>6.31</literal> or <literal>6.9</literal>. When a message is marked with a spam score higher than or equal to this level, Amavisd will take "evasive action". See <xref linkend="sect-Administrator_Guide-Combating_Spam-Configuring_Amavis_Evasive_Action" /> for more information on configuring evasive actions.
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Combating_Spam-Configuring_Amavis_Evasive_Action">
+ <title>Configuring Amavis Evasive Action</title>
+ <para>
+ You can control what "evasive action" Amavisd takes using the <literal>$final_spam_destiny</literal> and <literal>$final_virus_destiny</literal> settings in <filename>/etc/amavisd/amavisd.conf</filename>. The default is usually to discard the message, but the following options are available:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-D_PASS">
+ <title>D_PASS</title>
+ <para>
+ The message is accepted for delivery to the intended recipient(s), despite having been scored passed the kill or cutoff level, and regardless of bad content.
+ </para>
+
+ </formalpara>
+ <para>
+ If a quarantine address has been configured, the quarantine address will receive a copy of the email. See <xref linkend="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine" /> to learn how to configure the quarantine address.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-D_BOUNCE">
+ <title>D_BOUNCE</title>
+ <para>
+ The message is not accepted for delivery to the intended recipient(s). A Delivery Status Notification stating delivery failure is sent out to the sender.
+ </para>
+
+ </formalpara>
+ <para>
+ If a quarantine address has been configured, the quarantine address will receive a copy of the email. See <xref linkend="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine" /> to learn how to configure the quarantine address.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-D_REJECT">
+ <title>D_REJECT</title>
+ <para>
+ The message is rejected by Amavisd, and while Amavisd sends out a 550 SMTP response to the Mail Transfer Agent, said Mail Transfer Agent is responsible for sending out the Delivery Status Notification, if any.
+ </para>
+
+ </formalpara>
+ <para>
+ If a quarantine address has been configured, the quarantine address will receive a copy of the email. See <xref linkend="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine" /> to learn how to configure the quarantine address.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-D_DISCARD">
+ <title>D_DISCARD</title>
+ <para>
+ The message is simply discarded by Amavisd. The sending Mail Transfer Agent will receive a positive SMTP delivery response, and Amavisd sends out no Delivery Status Notification, nor does it forward the message for delivery to the intended recipients.
+ </para>
+
+ </formalpara>
+ <para>
+ If a quarantine address has been configured, the quarantine address will receive a copy of the email. See <xref linkend="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine" /> to learn how to configure the quarantine address.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <formalpara id="form-Administrator_Guide-Configuring_Amavis_Evasive_Action-Configuring_Quarantine">
+ <title>Configuring Quarantine</title>
+ <para>
+ Two separate quarantine forwarding addresses can be configured. One is for messages labeled as spam, another for messages suspected to contain a virus.
+ </para>
+
+ </formalpara>
+ <para>
+ A catchall address for spam can be configured by setting the <literal>$spam_quarantine_to</literal> setting to a valid recipient address in <filename>/etc/amavisd/amavisd.conf</filename>
+ </para>
+ <para>
+ A catchall address for messages suspected of containing a virus can be configured by setting the <literal>$virus_quarantine_to</literal> setting to a valid recipient address in <filename>/etc/amavisd/amavisd.conf</filename>.
+ </para>
+
+ </section>
+
</chapter>
diff --git a/Administrator_Guide/en-US/Configuring_the_Kolab_Server.xml b/Administrator_Guide/en-US/Configuring_the_Kolab_Server.xml
index 96d86d6..10e9c8a 100644
--- a/Administrator_Guide/en-US/Configuring_the_Kolab_Server.xml
+++ b/Administrator_Guide/en-US/Configuring_the_Kolab_Server.xml
@@ -4,105 +4,105 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Configuring_the_Kolab_Server">
- <title>Configuring the Kolab Server</title>
- <para>
- This chapter outlines some of the most common Kolab Groupware configuration topics found in real life.
- </para>
- <xi:include href="sect-Kolab_Recipient_Policy_and_Web_Administration_Panel.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <section id="sect-Administrator_Guide-Configuring_the_Kolab_Server-Optimizing_the_Web_Server">
- <title>Optimizing the Web Server</title>
- <section id="sect-Administrator_Guide-Optimizing_the_Web_Server-Accelerating_PHP_with_APC">
- <title>Accelerating PHP with APC</title>
- <para>
- Web server performance is greatly improved by caching the interpreted bytecode for the PHP applications using the Alternative PHP Cache (APC) extension from PECL. With APC enabled, PHP source code is compiled only once (per retention interval), and subsequent inclusions for or execution of said PHP source code is obtained directly from cache.
- </para>
- <para>
- To enable APC, install the <application>php-pecl-apc</application> package:
- </para>
- <para>
-
+ <title>Configuring the Kolab Server</title>
+ <para>
+ This chapter outlines some of the most common Kolab Groupware configuration topics found in real life.
+ </para>
+ <xi:include href="sect-Kolab_Recipient_Policy_and_Web_Administration_Panel.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <section id="sect-Administrator_Guide-Configuring_the_Kolab_Server-Optimizing_the_Web_Server">
+ <title>Optimizing the Web Server</title>
+ <section id="sect-Administrator_Guide-Optimizing_the_Web_Server-Accelerating_PHP_with_APC">
+ <title>Accelerating PHP with APC</title>
+ <para>
+ Web server performance is greatly improved by caching the interpreted bytecode for the PHP applications using the Alternative PHP Cache (APC) extension from PECL. With APC enabled, PHP source code is compiled only once (per retention interval), and subsequent inclusions for or execution of said PHP source code is obtained directly from cache.
+ </para>
+ <para>
+ To enable APC, install the <application>php-pecl-apc</application> package:
+ </para>
+ <para>
+
<screen># <userinput>yum -y install php-pecl-apc</userinput></screen>
- </para>
- <para>
- Then, edit <filename>/etc/php.d/apc.ini</filename> and set or consider setting any of the following options;
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <formalpara id="form-Administrator_Guide-Accelerating_PHP_with_APC-apc.enabled1">
- <title><literal>apc.enabled=1</literal></title>
- <para>
- Enable APC (1), or disable APC (0)
- </para>
-
- </formalpara>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Accelerating_PHP_with_APC-apc.stat0">
- <title><literal>apc.stat=0</literal></title>
- <para>
- Issue a <literal>stat()</literal> call to see if the file with PHP source code has changed since the last binary compilation. Disabling the <literal>stat()</literal> call is recommended for production environments, as calling <literal>stat()</literal> includes a write call to update the file's last access time (atime). Note that the update write call for the last access time can be prevented by mounting the relevant filesystem with the <literal>noatime</literal> option.
- </para>
-
- </formalpara>
- <note>
- <title>Changes to PHP Source Code Files with APC <literal>stat()</literal> Disabled</title>
- <para>
- Note that when APC is configured to not issue a <literal>stat()</literal> call to see if a PHP source code file is changed, changes to PHP source code files will only be included in subsequent execution after the APC cache has been cleared. The APC cache is cleared upon web server service reload, restart or using the PHP call <literal>apc_clear_cache()</literal>.
- </para>
-
- </note>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Accelerating_PHP_with_APC-apc.stat_ctime1">
- <title><literal>apc.stat_ctime=1</literal></title>
- <para>
- When issuing a <literal>stat()</literal> call to see if the file with PHP source code has changed, use the file's change time attribute as opposed to the default, the file's modification time attribute.
- </para>
-
- </formalpara>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Accelerating_PHP_with_APC-apc.include_once_override0">
- <title><literal>apc.include_once_override=0</literal></title>
- <para>
- While overriding the expensive system calls issued during an <literal>include_once()</literal> or <literal>require_once()</literal> call be the PHP source code, this option MUST NOT be enabled. See <ulink url="https://bugzilla.kolabsys.com/show_bug.cgi?id=113" /> for more information.
- </para>
-
- </formalpara>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </section>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Configuring_the_Kolab_Server-Using_the_Kolab_Perl_Libraries_on_a_non_Kolab_System">
- <title>Using the Kolab Perl Libraries on a non-Kolab System</title>
- <para>
- When using the <application>perl-Kolab</application> libraries on a system that is not a Kolab server itself, please be aware the perl-Kolab libraries expect and/or require certain settings to be available that are not really relevant for normal operations. This section explains which settings are expected and/or required, how to configure them and what the implications are.
- </para>
- <para>
- An example use-case scenario –to install and use the Kolab perl libraries on a system that is not a Kolab server– is, where user provisioning scripts are executed outside of Kolab, and require interfacing with Kolab's IMAP server components to manage user or shared mailboxes.
- </para>
- <formalpara id="form-Administrator_Guide-Using_the_Kolab_Perl_Libraries_on_a_non_Kolab_System-Recommended_Settings">
- <title>Recommended Settings</title>
- <para>
- The following is a snippet of the configuration file <filename>/etc/kolab/kolab.conf</filename> that prevents perl errors from being printed to <code>stderr</code>;
- </para>
-
- </formalpara>
- <para>
-
+ </para>
+ <para>
+ Then, edit <filename>/etc/php.d/apc.ini</filename> and set or consider setting any of the following options;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Accelerating_PHP_with_APC-apc.enabled1">
+ <title><literal>apc.enabled=1</literal></title>
+ <para>
+ Enable APC (1), or disable APC (0)
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Accelerating_PHP_with_APC-apc.stat0">
+ <title><literal>apc.stat=0</literal></title>
+ <para>
+ Issue a <literal>stat()</literal> call to see if the file with PHP source code has changed since the last binary compilation. Disabling the <literal>stat()</literal> call is recommended for production environments, as calling <literal>stat()</literal> includes a write call to update the file's last access time (atime). Note that the update write call for the last access time can be prevented by mounting the relevant filesystem with the <literal>noatime</literal> option.
+ </para>
+
+ </formalpara>
+ <note>
+ <title>Changes to PHP Source Code Files with APC <literal>stat()</literal> Disabled</title>
+ <para>
+ Note that when APC is configured to not issue a <literal>stat()</literal> call to see if a PHP source code file is changed, changes to PHP source code files will only be included in subsequent execution after the APC cache has been cleared. The APC cache is cleared upon web server service reload, restart or using the PHP call <literal>apc_clear_cache()</literal>.
+ </para>
+
+ </note>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Accelerating_PHP_with_APC-apc.stat_ctime1">
+ <title><literal>apc.stat_ctime=1</literal></title>
+ <para>
+ When issuing a <literal>stat()</literal> call to see if the file with PHP source code has changed, use the file's change time attribute as opposed to the default, the file's modification time attribute.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Accelerating_PHP_with_APC-apc.include_once_override0">
+ <title><literal>apc.include_once_override=0</literal></title>
+ <para>
+ While overriding the expensive system calls issued during an <literal>include_once()</literal> or <literal>require_once()</literal> call be the PHP source code, this option MUST NOT be enabled. See <ulink url="https://bugzilla.kolabsys.com/show_bug.cgi?id=113" /> for more information.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Configuring_the_Kolab_Server-Using_the_Kolab_Perl_Libraries_on_a_non_Kolab_System">
+ <title>Using the Kolab Perl Libraries on a non-Kolab System</title>
+ <para>
+ When using the <application>perl-Kolab</application> libraries on a system that is not a Kolab server itself, please be aware the perl-Kolab libraries expect and/or require certain settings to be available that are not really relevant for normal operations. This section explains which settings are expected and/or required, how to configure them and what the implications are.
+ </para>
+ <para>
+ An example use-case scenario –to install and use the Kolab perl libraries on a system that is not a Kolab server– is, where user provisioning scripts are executed outside of Kolab, and require interfacing with Kolab's IMAP server components to manage user or shared mailboxes.
+ </para>
+ <formalpara id="form-Administrator_Guide-Using_the_Kolab_Perl_Libraries_on_a_non_Kolab_System-Recommended_Settings">
+ <title>Recommended Settings</title>
+ <para>
+ The following is a snippet of the configuration file <filename>/etc/kolab/kolab.conf</filename> that prevents perl errors from being printed to <code>stderr</code>;
+ </para>
+
+ </formalpara>
+ <para>
+
<screen>kolab_usr: kolab
kolab_musr: kolab
kolab_rusr: kolab
@@ -110,42 +110,42 @@ kolab_grp: kolab
kolab_mgrp: kolab
kolab_rgrp: kolab</screen>
- </para>
- <para>
- In a traditional Kolab deployment, these settings are used with the configuration management utilities. On a server that is not a Kolab server, naturally the configuration management does not apply. However, the Kolab perl libraries still require these settings to be available for errors to be suppressed.
- </para>
- <para>
- Please see <ulink url="https://bugzilla.kolabsys.com/show_bug.cgi?id=114" /> for more information.
- </para>
- <formalpara id="form-Administrator_Guide-Using_the_Kolab_Perl_Libraries_on_a_non_Kolab_System-Required_Settings">
- <title>Required Settings</title>
- <para>
- The following are settings required;
- </para>
-
- </formalpara>
- <para>
- <itemizedlist>
- <listitem>
- <formalpara id="form-Administrator_Guide-Using_the_Kolab_Perl_Libraries_on_a_non_Kolab_System-connect_addr">
- <title><literal>connect_addr</literal></title>
- <para>
- The connection address for the Kolab perl libraries. Currently this is being used for IMAP connections.
- </para>
-
- </formalpara>
- <para>
- See <ulink url="https://bugzilla.kolabsys.com/show_bug.cgi?id=112">Bugzilla #112: <emphasis>Use of connect_addr, local_addr, bind_addr and bind_any</emphasis></ulink> and <ulink url="https://bugzilla.kolabsys.com/show_bug.cgi?id=115">Bugzilla #115: <emphasis>NEW</emphasis></ulink> for more information.
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </section>
-
+ </para>
+ <para>
+ In a traditional Kolab deployment, these settings are used with the configuration management utilities. On a server that is not a Kolab server, naturally the configuration management does not apply. However, the Kolab perl libraries still require these settings to be available for errors to be suppressed.
+ </para>
+ <para>
+ Please see <ulink url="https://bugzilla.kolabsys.com/show_bug.cgi?id=114" /> for more information.
+ </para>
+ <formalpara id="form-Administrator_Guide-Using_the_Kolab_Perl_Libraries_on_a_non_Kolab_System-Required_Settings">
+ <title>Required Settings</title>
+ <para>
+ The following are settings required;
+ </para>
+
+ </formalpara>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Using_the_Kolab_Perl_Libraries_on_a_non_Kolab_System-connect_addr">
+ <title><literal>connect_addr</literal></title>
+ <para>
+ The connection address for the Kolab perl libraries. Currently this is being used for IMAP connections.
+ </para>
+
+ </formalpara>
+ <para>
+ See <ulink url="https://bugzilla.kolabsys.com/show_bug.cgi?id=112">Bugzilla #112: <emphasis>Use of connect_addr, local_addr, bind_addr and bind_any</emphasis></ulink> and <ulink url="https://bugzilla.kolabsys.com/show_bug.cgi?id=115">Bugzilla #115: <emphasis>NEW</emphasis></ulink> for more information.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
</chapter>
diff --git a/Administrator_Guide/en-US/Detailed_Kolab_Server_Overview.xml b/Administrator_Guide/en-US/Detailed_Kolab_Server_Overview.xml
index 96c79bb..1d80c8d 100755
--- a/Administrator_Guide/en-US/Detailed_Kolab_Server_Overview.xml
+++ b/Administrator_Guide/en-US/Detailed_Kolab_Server_Overview.xml
@@ -4,394 +4,394 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Detailed_Kolab_Server_Overview">
- <title>Detailed Kolab Server Overview</title>
- <para>
- The Kolab Server consists of various 3rd-party OpenSource components as well as some kolab specific components which provide the glue between those. Most of the 3rd-party components can be exchanged, such as the IMAP-Server.
- </para>
- <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-EMail_Directory_Service">
- <title>EMail-/Directory-Service</title>
- <section id="sect-Administrator_Guide-EMail_Directory_Service-Postfix">
- <title>Postfix</title>
- <para>
- Postfix is an <emphasis>MTA</emphasis> (Mail Transfer Agent), responsible for the transport and distribution of emails.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- URL: <ulink url="http://www.postfix.org">www.postfix.org</ulink>
- </para>
-
- </listitem>
- <listitem>
- <para>
- Documentation: <ulink url="http://www.postfix.org/documentation.html">Postfix Documentation</ulink>
- </para>
-
- </listitem>
-
- </itemizedlist>
- <formalpara id="form-Administrator_Guide-Postfix-Services">
- <title>Services:</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <application>postfix</application>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </formalpara>
- <formalpara id="form-Administrator_Guide-Postfix-Configuration_files">
- <title>Configuration files:</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <filename>/etc/postfix/main.cf</filename>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <filename>/etc/postfix/master.cf</filename>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <filename>/etc/postfix/ldap/alias_maps.cf</filename>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <filename>/etc/postfix/ldap/local_recipient_maps.cf</filename>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <filename>/etc/postfix/ldap/mydestination.cf</filename>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <filename>/etc/postfix/ldap/virtual_alias_maps.cf</filename>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <filename>/etc/postfix/ldap/virtual_alias_maps_mailenabled_distgroups.cf</filename>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <filename>/etc/postfix/ldap/virtual_alias_maps_mailenabled_dynamic_distgroups.cf</filename>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </formalpara>
- <formalpara id="form-Administrator_Guide-Postfix-Logfiles">
- <title>Logfiles</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <filename>/var/log/logfile</filename>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </formalpara>
- <formalpara id="form-Administrator_Guide-Postfix-Commands">
- <title>Commands</title>
- <para>
- /etc/init.d/postfix restart
- </para>
-
- </formalpara>
-
- </section>
-
- <section id="sect-Administrator_Guide-EMail_Directory_Service-Cyrus_IMAP">
- <title>Cyrus-IMAP</title>
- <para>
- The <application>Cyrus-IMAP</application> server is a scalable, fast IMAP server.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- URL: <ulink url="http://www.cyrusimap.org/">www.cyrusimap.org/</ulink>
- </para>
-
- </listitem>
- <listitem>
- <para>
- Documentation: <ulink url="http://www.cyrusimap.org/docs/cyrus-imapd/">Cyrus Documentation</ulink>
- </para>
-
- </listitem>
-
- </itemizedlist>
- <formalpara id="form-Administrator_Guide-Cyrus_IMAP-Services">
- <title>Services:</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <application>imapd</application>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <application>pop3d TODO: remove?</application>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <application>/usr/lib/cyrus-impad/cyrus-master</application>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <application>idled</application>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </formalpara>
-
- </section>
-
- <section id="sect-Administrator_Guide-EMail_Directory_Service-OpenLDAP">
- <title>OpenLDAP</title>
- <para>
- LDAP is the directory services used to store information about users as well as parts of the Kolab configuration. The service consists of the <application>slapd</application> deamon, which provides access to the directory. <application>slurpd</application> is a replication deamon for the LDAP database, allowing the system to be distributed over several machines which increases relaiability as well as availability. <application>slurpd</application> is replaced by <application>syncrepl</application> as of version 3.0.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- URL: <ulink url="http://www.openldap.org/">www.openldap.org/</ulink>
- </para>
-
- </listitem>
- <listitem>
- <para>
- Documentation: <ulink url="http://www.openldap.org/doc/admin24/">OpenLDAP admin guide</ulink>
- </para>
-
- </listitem>
-
- </itemizedlist>
- <formalpara id="form-Administrator_Guide-OpenLDAP-Services">
- <title>Services:</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <application>slapd</application>
- </para>
-
- </listitem>
- <listitem>
- <para>
- <application>slurpd</application>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </formalpara>
-
- </section>
-
- <section id="sect-Administrator_Guide-EMail_Directory_Service-Cyrus_SASL_authentication">
- <title>Cyrus-SASL authentication</title>
- <para>
- SASL (Simple Authentication and Security Layer) is a method to add authentication support for connection based protocols. The authentication via SASL is used by Postfix and the IMAP-Server. <application>saslauthd</application> is the deamon providing the authentication, using the credentials stored in the LDAP database.
- </para>
- <formalpara id="form-Administrator_Guide-Cyrus_SASL_authentication-Services">
- <title>Services:</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <application>/usr/sbin/saslauthd</application>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </formalpara>
-
- </section>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-Spam_Virus_Scanner">
- <title>Spam-/Virus-Scanner</title>
- <section id="sect-Administrator_Guide-Spam_Virus_Scanner-Amavisd">
- <title>Amavisd</title>
- <para>
- <application>Amavisd</application> is an emailscanner, which unpacks all messages (including attachments) and forwards them to virus scanners and spam filters.
- </para>
- <formalpara id="form-Administrator_Guide-Amavisd-Services">
- <title>Services:</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <application>amavisd</application>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </formalpara>
-
- </section>
-
- <section id="sect-Administrator_Guide-Spam_Virus_Scanner-ClamAV">
- <title>ClamAV</title>
- <para>
- <application>ClamAV</application> is a virus scanner, suitable for Mailservers.
- </para>
- <para>
- <application>clamd.amavisd</application>
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Spam_Virus_Scanner-SpamAssassin">
- <title>SpamAssassin</title>
- <para>
- <application>SpamAssassin</application> is a spam filter.
- </para>
-
- </section>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-Kolab_Webclient">
- <title>Kolab-Webclient</title>
- <section id="sect-Administrator_Guide-Kolab_Webclient-Horde">
- <title>Horde</title>
- <para>
- <application>Horde</application> is the old webclient for Kolab.
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Kolab_Webclient-Roundcube">
- <title>Roundcube</title>
- <para>
- <application>Roundcube</application> is the new webclient for Kolab.
- </para>
-
- </section>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-General">
- <title>General</title>
- <section id="sect-Administrator_Guide-General-Apache">
- <title>Apache</title>
- <para>
- The infamous http server.
- </para>
- <formalpara id="form-Administrator_Guide-Apache-Services">
- <title>Services:</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <application>/usr/sbin/httpd</application>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </formalpara>
-
- </section>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-Kolab_specific_Components">
- <title>Kolab specific Components</title>
- <para>
- Apart from the main components, consisting of proven 3rd-party OpenSource software, there are also some Kolab specific software components.
- </para>
- <section id="sect-Administrator_Guide-Kolab_specific_Components-kolabd">
- <title>kolabd</title>
- <para>
- The Kolab-Daemon is the central control unit between the various components. It is responsible for synchronizing the user accounts in the LDAP directory with the available IMAP folders. TODO: further responsabilites of kolabd
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Kolab_specific_Components-kolab_webadmin">
- <title>kolab-webadmin</title>
- <para>
- The Kolab-Webadin is an administrator webinterface.
- </para>
-
- </section>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-Component_Interaction">
- <title>Component Interaction</title>
- <para>
- The following diagram illustrates the interaction between the various components.
- </para>
- <para>
- <application>kolabd</application> is the central control instance of the kolab server, responsible to configure all components,
- </para>
-
- </section>
-
+ <title>Detailed Kolab Server Overview</title>
+ <para>
+ The Kolab Server consists of various 3rd-party OpenSource components as well as some kolab specific components which provide the glue between those. Most of the 3rd-party components can be exchanged, such as the IMAP-Server.
+ </para>
+ <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-EMail_Directory_Service">
+ <title>EMail-/Directory-Service</title>
+ <section id="sect-Administrator_Guide-EMail_Directory_Service-Postfix">
+ <title>Postfix</title>
+ <para>
+ Postfix is an <emphasis>MTA</emphasis> (Mail Transfer Agent), responsible for the transport and distribution of emails.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ URL: <ulink url="http://www.postfix.org">www.postfix.org</ulink>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Documentation: <ulink url="http://www.postfix.org/documentation.html">Postfix Documentation</ulink>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+ <formalpara id="form-Administrator_Guide-Postfix-Services">
+ <title>Services:</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <application>postfix</application>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Administrator_Guide-Postfix-Configuration_files">
+ <title>Configuration files:</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/main.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/master.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/alias_maps.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/local_recipient_maps.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/mydestination.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/virtual_alias_maps.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/virtual_alias_maps_mailenabled_distgroups.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/virtual_alias_maps_mailenabled_dynamic_distgroups.cf</filename>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Administrator_Guide-Postfix-Logfiles">
+ <title>Logfiles</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>/var/log/logfile</filename>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Administrator_Guide-Postfix-Commands">
+ <title>Commands</title>
+ <para>
+ /etc/init.d/postfix restart
+ </para>
+
+ </formalpara>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-EMail_Directory_Service-Cyrus_IMAP">
+ <title>Cyrus-IMAP</title>
+ <para>
+ The <application>Cyrus-IMAP</application> server is a scalable, fast IMAP server.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ URL: <ulink url="http://www.cyrusimap.org/">www.cyrusimap.org/</ulink>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Documentation: <ulink url="http://www.cyrusimap.org/docs/cyrus-imapd/">Cyrus Documentation</ulink>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+ <formalpara id="form-Administrator_Guide-Cyrus_IMAP-Services">
+ <title>Services:</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <application>imapd</application>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <application>pop3d TODO: remove?</application>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <application>/usr/lib/cyrus-impad/cyrus-master</application>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <application>idled</application>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </formalpara>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-EMail_Directory_Service-OpenLDAP">
+ <title>OpenLDAP</title>
+ <para>
+ LDAP is the directory services used to store information about users as well as parts of the Kolab configuration. The service consists of the <application>slapd</application> deamon, which provides access to the directory. <application>slurpd</application> is a replication deamon for the LDAP database, allowing the system to be distributed over several machines which increases relaiability as well as availability. <application>slurpd</application> is replaced by <application>syncrepl</application> as of version 3.0.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ URL: <ulink url="http://www.openldap.org/">www.openldap.org/</ulink>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Documentation: <ulink url="http://www.openldap.org/doc/admin24/">OpenLDAP admin guide</ulink>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+ <formalpara id="form-Administrator_Guide-OpenLDAP-Services">
+ <title>Services:</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <application>slapd</application>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <application>slurpd</application>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </formalpara>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-EMail_Directory_Service-Cyrus_SASL_authentication">
+ <title>Cyrus-SASL authentication</title>
+ <para>
+ SASL (Simple Authentication and Security Layer) is a method to add authentication support for connection based protocols. The authentication via SASL is used by Postfix and the IMAP-Server. <application>saslauthd</application> is the deamon providing the authentication, using the credentials stored in the LDAP database.
+ </para>
+ <formalpara id="form-Administrator_Guide-Cyrus_SASL_authentication-Services">
+ <title>Services:</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <application>/usr/sbin/saslauthd</application>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </formalpara>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-Spam_Virus_Scanner">
+ <title>Spam-/Virus-Scanner</title>
+ <section id="sect-Administrator_Guide-Spam_Virus_Scanner-Amavisd">
+ <title>Amavisd</title>
+ <para>
+ <application>Amavisd</application> is an emailscanner, which unpacks all messages (including attachments) and forwards them to virus scanners and spam filters.
+ </para>
+ <formalpara id="form-Administrator_Guide-Amavisd-Services">
+ <title>Services:</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <application>amavisd</application>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </formalpara>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Spam_Virus_Scanner-ClamAV">
+ <title>ClamAV</title>
+ <para>
+ <application>ClamAV</application> is a virus scanner, suitable for Mailservers.
+ </para>
+ <para>
+ <application>clamd.amavisd</application>
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Spam_Virus_Scanner-SpamAssassin">
+ <title>SpamAssassin</title>
+ <para>
+ <application>SpamAssassin</application> is a spam filter.
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-Kolab_Webclient">
+ <title>Kolab-Webclient</title>
+ <section id="sect-Administrator_Guide-Kolab_Webclient-Horde">
+ <title>Horde</title>
+ <para>
+ <application>Horde</application> is the old webclient for Kolab.
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Kolab_Webclient-Roundcube">
+ <title>Roundcube</title>
+ <para>
+ <application>Roundcube</application> is the new webclient for Kolab.
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-General">
+ <title>General</title>
+ <section id="sect-Administrator_Guide-General-Apache">
+ <title>Apache</title>
+ <para>
+ The infamous http server.
+ </para>
+ <formalpara id="form-Administrator_Guide-Apache-Services">
+ <title>Services:</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <application>/usr/sbin/httpd</application>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </formalpara>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-Kolab_specific_Components">
+ <title>Kolab specific Components</title>
+ <para>
+ Apart from the main components, consisting of proven 3rd-party OpenSource software, there are also some Kolab specific software components.
+ </para>
+ <section id="sect-Administrator_Guide-Kolab_specific_Components-kolabd">
+ <title>kolabd</title>
+ <para>
+ The Kolab-Daemon is the central control unit between the various components. It is responsible for synchronizing the user accounts in the LDAP directory with the available IMAP folders. TODO: further responsabilites of kolabd
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Kolab_specific_Components-kolab_webadmin">
+ <title>kolab-webadmin</title>
+ <para>
+ The Kolab-Webadin is an administrator webinterface.
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Detailed_Kolab_Server_Overview-Component_Interaction">
+ <title>Component Interaction</title>
+ <para>
+ The following diagram illustrates the interaction between the various components.
+ </para>
+ <para>
+ <application>kolabd</application> is the central control instance of the kolab server, responsible to configure all components,
+ </para>
+
+ </section>
+
</chapter>
diff --git a/Administrator_Guide/en-US/Hosted_Kolab_Groupware_Setup.xml b/Administrator_Guide/en-US/Hosted_Kolab_Groupware_Setup.xml
new file mode 100644
index 0000000..b9cbf5b
--- /dev/null
+++ b/Administrator_Guide/en-US/Hosted_Kolab_Groupware_Setup.xml
@@ -0,0 +1,603 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Administrator_Guide.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Administrator_Guide-Hosted_Kolab_Groupware_Setup">
+ <title>Hosted Kolab Groupware Setup</title>
+ <para>
+ A hosted Kolab Groupware setup offers users or customers the opportunity to get one or more Kolab Groupware accounts by registering for an account, perhaps including payment.
+ </para>
+ <para>
+ The nature of a hosted Kolab Groupware setup is such that;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Two or more isolated domains exist. One domain is the <emphasis>management domain</emphasis>, and the Kolab Groupware <emphasis>primary domain</emphasis>. The other domain is added later, after the setup of the management domain, and is considered the <emphasis>primary hosted domain</emphasis>.
+ </para>
+ <para>
+ The management domain contains the system and service users, and is intended for only the users of the organization providing the hosted Kolab Groupware deployment.
+ </para>
+ <para>
+ The primary hosted domain can have one or more domain aliases allowing users that register to choose between the options (for example "@example.org" or "@example.eu").
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Users register (perhaps including payment) for a <emphasis>hosted plan</emphasis>, and are added to a <emphasis>hosted domain</emphasis>. Each hosted plan offers the user certain features, or lifts restrictions, and as such is a different type of account.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <procedure id="proc-Administrator_Guide-Hosted_Kolab_Groupware_Setup-Setting_up_Hosted_Kolab_Groupware">
+ <title>Setting up Hosted Kolab Groupware</title>
+ <para>
+ This procedure assumes an existing, default Kolab Groupware deployment is available.
+ </para>
+ <step>
+ <para>
+ Add a hosted Kolab service account. This procedure uses a username of <literal>hosted-kolab-service</literal>, which is added to the management domain
+ </para>
+ <para>
+
+<screen># <userinput>ldapadd -x -h localhost -D "cn=Directory Manager" -w $password</userinput>
+dn: uid=hosted-kolab-service,ou=Special Users,<replaceable>$management_domain_root_dn</replaceable>
+objectclass: top
+objectclass: inetorgperson
+objectclass: person
+uid: hosted-kolab-service
+cn: Hosted Kolab Service Account
+sn: Service Account
+givenname: Hosted Kolab
+userpassword: <replaceable>$password</replaceable>
+
+</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Make the list of domain name spaces accessible for the hosted Kolab service account:
+ </para>
+ <para>
+
+<screen># <userinput>ldapmodify -x -h localhost -D "cn=Directory Manager" -w $password \</userinput>
+> <userinput>-f -</userinput>
+dn: cn=kolab,cn=config
+changetype: modify
+add: aci
+aci: (targetattr = "*") (version 3.0;acl "Hosted Kolab Services";allow
+ (read,compare,search)(userdn = "ldap:///uid=hosted-kolab-service,ou=
+ Special Users,<replaceable>$management_domain_root_dn</replaceable>");)
+
+</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Prevent the hosted Kolab service account from reading the management domain, effectively hiding the management domain from the selection of available domains to register in;
+ </para>
+ <para>
+
+<screen># <userinput>ldapmodify -x -h localhost -D "cn=Directory Manager" -w $password</userinput>
+dn: associateddomain=<replaceable>$management_domain</replaceable>,cn=kolab,cn=config
+changetype: modify
+add: aci
+aci: (targetattr = "*") (version 3.0;acl "Hosted Kolab Services";deny
+ (read,search)(userdn = "ldap:///uid=hosted-kolab-service,ou=Special
+ Users,<replaceable>$management_domain_root_dn</replaceable>");)
+
+</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Using the Kolab Web Administration Panel, create a new domain.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Create a new section for the hosted settings in <filename>/etc/kolab/kolab.conf</filename> as follows:
+ </para>
+ <para>
+
+<screen language="INI Files">[kolab_hosting]
+primary_domain = <replaceable>$hosted_domain</replaceable>
+bind_dn = uid=hosted-kolab-service,ou=Special Users,<replaceable>$management_domain_root_dn</replaceable>
+bind_pw = <replaceable>$hosted_service_account_password</replaceable></screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Create a new section for the primary hosted domain in <filename>/etc/kolab/kolab.conf</filename>.
+ </para>
+ <para>
+ A section for the management domain already exists, which you could copy/paste and rename to the new domain name space.
+ </para>
+ <para>
+ Alternatively, all settings included in the <literal>[ldap]</literal> and <literal>[example.org]</literal> sections in the <ulink url="http://git.kolab.org/pykolab/tree/conf/kolab.conf">default configuration file</ulink> are available for the new domain name space.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Create an Administrator user in the new domain, which you can use to create new users, and test the configuration / deployment.
+ </para>
+ <para>
+
+<screen># <userinput>ldapmodify -x -h localhost -D "cn=Directory Manager" -w $password</userinput>
+dn: uid=doe,ou=People,<replaceable>$hosted_domain_root_dn</replaceable>
+objectclass: top
+objectclass: inetorgperson
+objectclass: person
+uid: doe
+cn: John Doe
+sn: Doe
+givenname: John
+displayName: Doe, John
+mail: doe@<replaceable>$hosted_domain</replaceable>
+nsroledn: cn=kolab-admin,<replaceable>$hosted_domain_root_dn</replaceable>
+userpassword: <replaceable>$password</replaceable>
+
+</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Allow the hosted Kolab service account to create new entries in the hosted domain root dn:
+ </para>
+ <para>
+
+<screen># <userinput>ldapmodify -x -h localhost -D "cn=Directory Manager" -w $password</userinput>
+dn: ou=People,<replaceable>$hosted_domain_root_dn</replaceable>
+changetype: modify
+add: aci
+aci: (targetattr = "*") (version 3.0;acl "Hosted Kolab Services";allow
+ (all)(userdn = "ldap:///uid=hosted-kolab-service,ou=Special Users,
+ <replaceable>$management_domain_root_dn</replaceable>");)
+
+</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ TODO: A list of illegitimate user ID that are not available for registration (i.e. root@, etc.).
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Add new user_types specifically designed for a hosted registration interface.
+ </para>
+ <para>
+
+<screen># <userinput>mysql --user=kolab --password=<replaceable>$password</replaceable> \</userinput>
+> <userinput> kolab < /usr/share/doc/kolab-webadmin-*/kolab_hosted-*.sql</userinput></screen>
+
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <procedure id="proc-Administrator_Guide-Hosted_Kolab_Groupware_Setup-Removing_Canonification_from_Cyrus_IMAP">
+ <title>Removing Canonification from Cyrus IMAP</title>
+ <para>
+ This procedure removes canonification from Cyrus IMAP
+ </para>
+ <step>
+ <para>
+ Edit <filename>/etc/imapd.conf</filename> removing auth_mech, pts_module and ldap_* settings.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Restart Cyrus IMAP.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Test with
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <!--
+ <procedure id="proc-Administrator_Guide-Hosted_Kolab_Groupware_Setup-Multiple_Domain_Canonification_through_Referrals">
+ <title>Multiple Domain Canonification through Referrals</title>
+ <para>
+ This procedure sets up Cyrus IMAP to chase referrals from the management domain onto the hosted domains.
+ </para>
+ <step>
+ <para>
+ Edit <filename>/etc/imapd.conf</filename>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Test with
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <procedure id="proc-Administrator_Guide-Hosted_Kolab_Groupware_Setup-Setting_up_Multiple_Isolated_Cyrus_IMAP_Server_Instances">
+ <title>Setting up Multiple Isolated Cyrus IMAP Server Instances</title>
+ <para>
+ This procedure sets up a separate group of Cyrus IMAP services for each hosted domain.
+ </para>
+ <step>
+ <para>
+ Test with
+ </para>
+
+ </step>
+
+ </procedure>
+// --> <procedure id="proc-Administrator_Guide-Hosted_Kolab_Groupware_Setup-Update_Postfix_LDAP_Lookup_Tables">
+ <title>Update Postfix LDAP Lookup Tables</title>
+ <para>
+ This procedure sets up Postfix to be able to lookup parent domain name spaces with one dot (.) character. It will work for <emphasis>example.org</emphasis>, but not for <emphasis>demo.example.org</emphasis> recipient email addresses.
+ </para>
+ <remark>Fact check needed for the aforementioned (relates to matching parent domains in Postfix)</remark>
+ <step>
+ <para>
+ Edit the following files, replacing the <literal>base_dn</literal> setting with a value of <literal>dc=%2,dc=%1</literal>.
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/local_recipient_maps.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/mailenabled_distgroups.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/mailenabled_dynamic_distgroups.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/transport_maps.cf</filename>
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/postfix/ldap/virtual_alias_maps.cf</filename>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Restart the <literal>postfix</literal> service:
+ </para>
+ <para>
+
+<screen># <userinput>service postfix restart</userinput></screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Test looking up the primary domain name space:
+ </para>
+ <para>
+
+<screen># <userinput>postmap -q <replaceable>$management_domain</replaceable> ldap:/etc/postfix/ldap/mydestination.cf</userinput></screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Should any email recipient exist in the primary domain name space, test the primary recipient email address for this user:
+ </para>
+ <para>
+
+<screen># <userinput>postmap -q <replaceable>$email_address</replaceable> ldap:/etc/postfix/ldap/local_recipient_maps.cf</userinput></screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Test a secondary recipient email address for this user:
+ </para>
+ <para>
+
+<screen># <userinput>postmap -q <replaceable>$email_address</replaceable> ldap:/etc/postfix/ldap/local_recipient_maps.cf</userinput></screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Test the primary recipient email address for the administrator user created in the primary hosted domain:
+ </para>
+ <para>
+
+<screen># <userinput>postmap -q <replaceable>$email_address</replaceable> ldap:/etc/postfix/ldap/local_recipient_maps.cf</userinput></screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Test a secondary recipient email address for this user:
+ </para>
+ <para>
+
+<screen># <userinput>postmap -q <replaceable>$email_address</replaceable> ldap:/etc/postfix/ldap/local_recipient_maps.cf</userinput></screen>
+
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <procedure id="proc-Administrator_Guide-Hosted_Kolab_Groupware_Setup-Configuring_Roundcube">
+ <title>Configuring Roundcube</title>
+ <para>
+ This procedure configures the Roundcube webmail client to use different settings for different webserver virtual hosts.
+ </para>
+ <step>
+ <para>
+ Create a directory specific to the vhost:
+ </para>
+ <para>
+
+<screen># <userinput>mkdir /etc/roundcubemail/<replaceable>$http_host</replaceable>/</userinput></screen>
+
+ </para>
+ <para>
+ where <literal>$http_host</literal> is the server address name your users will use to connect to the webmail interface. For example, if your users visit <ulink url="https://webmail.example.org/">http://webmail.example.org/</ulink> to get to the webmail interface, then the <literal>$http_host</literal> is <literal>webmail.example.org</literal> and the directory to create is <filename>/etc/roundcubemail/webmail.example.org/</filename>.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Copy <filename>/etc/roundcubemail/main.inc.php</filename> and <filename>/etc/roundcubemail/kolab_auth.inc.php</filename> to the new <filename>/etc/roundcubemail/<replaceable>$http_host</replaceable>/</filename> directory.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Edit <filename>/etc/roundcubemail/main.inc.php</filename> as follows:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Remove the <literal>$rcmail_config['ldap_public']</literal> configuration in its entirety.
+ </para>
+ <para>
+ The configuration for any sort of global address book is supposed to be a business hosted plan feature only.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Edit the <literal>$rcmail_config['plugins']</literal> setting to only list the plugins that are to be enabled for the personal hosted plan.
+ </para>
+ <para>
+ For example, this list of plugins could be as minimal as:
+ </para>
+ <para>
+
+<screen>$rcmail_config['plugins'] = array(
+ 'calendar',
+ 'kolab_addressbook',
+ 'password'
+ );</screen>
+
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Replace the contents of <filename>/etc/roundcubemail/kolab_auth.inc.php</filename> with the following:
+ </para>
+ <para>
+
+<screen language="PHP/PHP"><?php
+if (file_exists(
+ RCMAIL_CONFIG_DIR . '/' .
+ $_SERVER["HTTP_HOST"] . '/' .
+ basename(__FILE__))
+ ) {
+
+ include_once(
+ RCMAIL_CONFIG_DIR . '/' .
+ $_SERVER["HTTP_HOST"] . '/' .
+ basename(__FILE__));
+}</screen>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Edit <filename>/etc/roundcubemail/<replaceable>$http_host</replaceable>/main.inc.php</filename> and change the settings related to the <literal>$rcmail_config['ldap_public']['kolab_addressbook']</literal> configuration.
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Depending on the division of features in your hosted plans, you may want to remove the entire LDAP address book configuration. Hosted plans with an increased number of features (such as this LDAP address book) are configured later, elsewhere.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Make sure that the configuration file includes a statement similar to the following (lines terminated prematurely for legibility purposes):
+ </para>
+ <para>
+
+<screen>if (file_exists(
+ RCMAIL_CONFIG_DIR . '/' .
+ $_SERVER["HTTP_HOST"] . '/' .
+ basename(__FILE__))
+ ) {
+
+ include_once(
+ RCMAIL_CONFIG_DIR . '/' .
+ $_SERVER["HTTP_HOST"] . '/' .
+ basename(__FILE__));
+ }</screen>
+
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Edit <filename>/etc/roundcubemail/<replaceable>$http_host</replaceable>/kolab_auth.inc.php</filename> and make sure the settings in the <literal>$rcmail_config['kolab_auth_addressbook']</literal> reflect the settings required for the corresponding hosted domain.
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The <literal>$rcmail_config['kolab_auth_addressbook']['base_dn']</literal> and <literal>$rcmail_config['kolab_auth_addressbook']['groups']['base_dn']</literal> settings need to be updated to the hosted domain root dn.
+ </para>
+ <para>
+ The <literal>$rcmail_config['kolab_auth_addressbook']['bind_dn']</literal> setting does not need to be updated as the <literal>uid=kolab-service</literal> user in the management domain is supposed to be allowed to read all of the contents of all of the domain name spaces hosted, including other root dns.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Make sure that the configuration file includes a statement similar to the following (lines terminated prematurely for legibility purposes):
+ </para>
+ <para>
+
+<screen>if (file_exists(
+ RCMAIL_CONFIG_DIR . '/' .
+ $_SERVER["HTTP_HOST"] . '/' .
+ basename(__FILE__))
+ ) {
+
+ include_once(
+ RCMAIL_CONFIG_DIR . '/' .
+ $_SERVER["HTTP_HOST"] . '/' .
+ basename(__FILE__));
+ }</screen>
+
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <section id="sect-Administrator_Guide-Hosted_Kolab_Groupware_Setup-Role_based_Enabling_of_Plugins_and_Pinning_of_Settings_for_Roundcube">
+ <title>Role-based Enabling of Plugins and Pinning of Settings for Roundcube</title>
+ <para>
+ This section outlines how to set up Roundcube to match the various specifications of the hosted plans outlined on <ulink url="http://wiki.kolab.org/Hosted_Kolab_for_Kolab_3.0">this wiki page</ulink>.
+ </para>
+ <para>
+ The <literal>kolab_auth</literal> plugin allows two separate settings to be configured, that on a role-by-role basis enable certain plugins, or configure (the default for) certain settings (and optionally pin them down so that the user is not allowed to change them).
+ </para>
+ <para>
+ Having removed the <literal>acl</literal> plugin from the list of plugins in the <literal>$rcmail_config['plugins']</literal> setting in <filename>/etc/roundcubemail/main.inc.php</filename> allows the plugin to be selectively re-enabled, for example only for users with the <literal>professional-user</literal> role:
+ </para>
+ <para>
+
+<screen>$rcmail_config['kolab_auth_role_plugins'] = array(
+ "cn=professional-user,dc=example,dc=org" => array(
+ 'acl',
+ ),
+ );</screen>
+
+ </para>
+ <para>
+ Similarly, a personal hosted plan user may be restricted from using the HTML editor, while a professional hosted plan user may be allowed to choose:
+ </para>
+ <para>
+
+<screen>$rcmail_config['kolab_auth_role_settings'] = array(
+ "cn=professional-user,dc=example,dc=org" => array(
+ 'htmleditor' => array(
+ 'mode' => 'override',
+ 'value' => 1,
+ 'allow_override' => true,
+ ),
+ ),
+ "cn=personal-user,dc=example,dc=org" => array(
+ 'htmleditor' => array(
+ 'mode' => 'override',
+ 'value' => 0,
+ 'allow_override' => false,
+ ),
+
+ ),
+ );</screen>
+
+ </para>
+ <note>
+ <para>
+ Please note that setting a default for a particular role and setting is necessary only if the default needs to change from the default configured in <filename>/etc/roundcubemail/main.inc.php</filename> (global) and <filename>/etc/roundcubemail/<replaceable>$http_host</replaceable>/main.inc.php</filename> (domain specific).
+ </para>
+
+ </note>
+
+ </section>
+
+
+</chapter>
+
diff --git a/Administrator_Guide/en-US/Kolab_Web_Administration_Panel.xml b/Administrator_Guide/en-US/Kolab_Web_Administration_Panel.xml
index de3bce3..ce52972 100644
--- a/Administrator_Guide/en-US/Kolab_Web_Administration_Panel.xml
+++ b/Administrator_Guide/en-US/Kolab_Web_Administration_Panel.xml
@@ -4,182 +4,182 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Kolab_Web_Administration_Panel">
- <title>Kolab Web Administration Panel</title>
- <section id="sect-Administrator_Guide-Kolab_Web_Administration_Panel-Editing_user_types">
- <title>Editing <literal>user_types</literal></title>
- <para>
- The <literal>user_types</literal> table in the MySQL <literal>kolab</literal> database contains the following columns:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <formalpara id="form-Administrator_Guide-Editing_user_types-id">
- <title>id</title>
- <para>
- A unique ID.
- </para>
-
- </formalpara>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Editing_user_types-key">
- <title>key</title>
- <para>
- A machine-readable key identifying the user type.
- </para>
-
- </formalpara>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Editing_user_types-name">
- <title>name</title>
- <para>
- A human-readable name.
- </para>
-
- </formalpara>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Editing_user_types-description">
- <title>description</title>
- <para>
- A description of the user type.
- </para>
-
- </formalpara>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Editing_user_types-attributes">
- <title>attributes</title>
- <para>
- The actual settings. Please see <xref linkend="sect-Administrator_Guide-Editing_user_types-Attributes_Reference" /> for a full reference, and <xref linkend="proc-Administrator_Guide-Editing_user_types-Manually_Changing_the_user_types_Available" /> for the procedure to edit these settings manually.
- </para>
-
- </formalpara>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
- <procedure id="proc-Administrator_Guide-Editing_user_types-Manually_Changing_the_user_types_Available">
- <title>Manually Changing the <literal>user_types</literal> Available</title>
- <step>
- <para>
- Sample scripts are provided as part of the <application>kolab-webadmin</application> package. Use the following command to locate these scripts, called <emphasis>sample-insert-user_types.php</emphasis>;
- </para>
- <para>
-
+ <title>Kolab Web Administration Panel</title>
+ <section id="sect-Administrator_Guide-Kolab_Web_Administration_Panel-Editing_user_types">
+ <title>Editing <literal>user_types</literal></title>
+ <para>
+ The <literal>user_types</literal> table in the MySQL <literal>kolab</literal> database contains the following columns:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Editing_user_types-id">
+ <title>id</title>
+ <para>
+ A unique ID.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Editing_user_types-key">
+ <title>key</title>
+ <para>
+ A machine-readable key identifying the user type.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Editing_user_types-name">
+ <title>name</title>
+ <para>
+ A human-readable name.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Editing_user_types-description">
+ <title>description</title>
+ <para>
+ A description of the user type.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Editing_user_types-attributes">
+ <title>attributes</title>
+ <para>
+ The actual settings. Please see <xref linkend="sect-Administrator_Guide-Editing_user_types-Attributes_Reference" /> for a full reference, and <xref linkend="proc-Administrator_Guide-Editing_user_types-Manually_Changing_the_user_types_Available" /> for the procedure to edit these settings manually.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <procedure id="proc-Administrator_Guide-Editing_user_types-Manually_Changing_the_user_types_Available">
+ <title>Manually Changing the <literal>user_types</literal> Available</title>
+ <step>
+ <para>
+ Sample scripts are provided as part of the <application>kolab-webadmin</application> package. Use the following command to locate these scripts, called <emphasis>sample-insert-user_types.php</emphasis>;
+ </para>
+ <para>
+
<screen># <userinput>rpm -qld kolab-webadmin</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Copy the relevant example file to one directory above the <filename>public_html/</filename> directory, like so:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Copy the relevant example file to one directory above the <filename>public_html/</filename> directory, like so:
- </para>
- <para>
-
<screen># <userinput>cp -a /path/to/sample-insert-user_types.php \</userinput>
<userinput>/usr/share/kolab-webadmin/insert-user_types.php</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Edit the file to reflect your needs. For example, to avoid the <literal>mail</literal> attribute from being automatically generated, remove <literal>$attributes['auto_form_fields']['mail']</literal>.
- </para>
-
- </step>
- <step>
- <para>
- You may want to insert <literal>$attributes["form_fields"]["mail"]</literal> to insert back a form field that allows supplying a mail attribute value for the user type.
- </para>
-
- </step>
- <step>
- <para>
- Once done editing, check the syntax;
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Edit the file to reflect your needs. For example, to avoid the <literal>mail</literal> attribute from being automatically generated, remove <literal>$attributes['auto_form_fields']['mail']</literal>.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ You may want to insert <literal>$attributes["form_fields"]["mail"]</literal> to insert back a form field that allows supplying a mail attribute value for the user type.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Once done editing, check the syntax;
+ </para>
+ <para>
+
<screen># <userinput>php -l insert-user_types.php</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Execute the file to replace the user types currently in the database;
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Execute the file to replace the user types currently in the database;
- </para>
- <para>
-
<screen># <userinput>php insert-user_types.php</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Log out and log back in to the web admin.
- </para>
-
- </step>
-
- </procedure>
-
- <section id="sect-Administrator_Guide-Editing_user_types-Attributes_Reference">
- <title>Attributes Reference</title>
- <para>
- The attributes column for user types describes which form fields are to be offered to the <emphasis>add user</emphasis> dialog for each type of user available.
- </para>
- <para>
- It is an object consisting of three types of form fields, namely;
- </para>
- <para>
- <orderedlist>
- <listitem>
- <para>
- <literal>auto_form_fields</literal>, or form fields for which the value is generated automatically (from values that are entered in other form fields).
- </para>
- <para>
- Example form fields for which the value can be generated automatically include <literal>displayname</literal> and <literal>cn</literal>.
- </para>
-
- </listitem>
- <listitem>
- <para>
- <literal>form_fields</literal>, for form fields to which the user or administrator is to provide input.
- </para>
- <para>
- Example form fields that users or administrators would provide input to include <literal>givenname</literal> and <literal>surname</literal>.
- </para>
-
- </listitem>
- <listitem>
- <para>
- <literal>fields</literal>, for form fields that are hidden from plain sight, and cannot be edited by the user or administrator.
- </para>
- <para>
- Example fields that would be configured as immutable, or static, and therefore be hidden from the client interface include <literal>objectclass</literal>.
- </para>
-
- </listitem>
-
- </orderedlist>
-
- </para>
- <para>
- The structure of the <literal>attributes</literal> attribute value is:
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Log out and log back in to the web admin.
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <section id="sect-Administrator_Guide-Editing_user_types-Attributes_Reference">
+ <title>Attributes Reference</title>
+ <para>
+ The attributes column for user types describes which form fields are to be offered to the <emphasis>add user</emphasis> dialog for each type of user available.
+ </para>
+ <para>
+ It is an object consisting of three types of form fields, namely;
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ <literal>auto_form_fields</literal>, or form fields for which the value is generated automatically (from values that are entered in other form fields).
+ </para>
+ <para>
+ Example form fields for which the value can be generated automatically include <literal>displayname</literal> and <literal>cn</literal>.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <literal>form_fields</literal>, for form fields to which the user or administrator is to provide input.
+ </para>
+ <para>
+ Example form fields that users or administrators would provide input to include <literal>givenname</literal> and <literal>surname</literal>.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <literal>fields</literal>, for form fields that are hidden from plain sight, and cannot be edited by the user or administrator.
+ </para>
+ <para>
+ Example fields that would be configured as immutable, or static, and therefore be hidden from the client interface include <literal>objectclass</literal>.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <para>
+ The structure of the <literal>attributes</literal> attribute value is:
+ </para>
+ <para>
+
<screen language="PHP/PHP">Array(
"<form_field_type>" => Array(
"<form_field_name>" => Array(
@@ -198,39 +198,39 @@
)
)</screen>
- </para>
- <para>
- The <literal>attributes</literal> attribute to a <literal>user_type</literal> entry holds an array with any or all of the following <emphasis><form_field_type></emphasis> keys:
- </para>
- <important>
- <para>
- The reference implementation and general rule of thumb is to use the LDAP attribute name as the form field name.
- </para>
-
- </important>
- <para>
- <itemizedlist>
- <listitem>
- <formalpara id="form-Administrator_Guide-Attributes_Reference-auto_form_fields">
- <title><literal>auto_form_fields</literal></title>
- <para>
- The <literal>auto_form_fields</literal> key holds an array of form fields that correspond with attributes for which the value is to be generated automatically, using an API call.
- </para>
-
- </formalpara>
- <para>
- The key name for each key => value pair indicates the form field name for which the value is to be generated automatically.
- </para>
- <para>
- Each array key corresponds with a user attribute name, and it's value is an array containing the name of the form fields for which the value to submit as part of the API call.
- </para>
- <example id="exam-Administrator_Guide-Attributes_Reference-A_Users_displayname">
- <title>A User's <literal>displayname</literal></title>
- <para>
- Provided the user type's <literal>auto_form_fields</literal> contains an array key of <literal>displayname</literal>, the array value for this key could look as follows:
- </para>
- <para>
-
+ </para>
+ <para>
+ The <literal>attributes</literal> attribute to a <literal>user_type</literal> entry holds an array with any or all of the following <emphasis><form_field_type></emphasis> keys:
+ </para>
+ <important>
+ <para>
+ The reference implementation and general rule of thumb is to use the LDAP attribute name as the form field name.
+ </para>
+
+ </important>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Attributes_Reference-auto_form_fields">
+ <title><literal>auto_form_fields</literal></title>
+ <para>
+ The <literal>auto_form_fields</literal> key holds an array of form fields that correspond with attributes for which the value is to be generated automatically, using an API call.
+ </para>
+
+ </formalpara>
+ <para>
+ The key name for each key => value pair indicates the form field name for which the value is to be generated automatically.
+ </para>
+ <para>
+ Each array key corresponds with a user attribute name, and it's value is an array containing the name of the form fields for which the value to submit as part of the API call.
+ </para>
+ <example id="exam-Administrator_Guide-Attributes_Reference-A_Users_displayname">
+ <title>A User's <literal>displayname</literal></title>
+ <para>
+ Provided the user type's <literal>auto_form_fields</literal> contains an array key of <literal>displayname</literal>, the array value for this key could look as follows:
+ </para>
+ <para>
+
<screen language="PHP/PHP">Array(
'auto_form_fields' => Array(
'displayname' => Array(
@@ -244,119 +244,119 @@
(...)
);</screen>
- </para>
- <para>
- This indicates to the client that a form field named 'displayname' is to be populated with the information contained within the form fields named 'givenname' and 'sn'.
- </para>
- <para>
- If the client is capable of doing so, it should also update the form field named 'displayname' after the values for any of the form fields named 'givenname' or 'sn' have been changed.
- </para>
-
- </example>
- <para>
- With a JSON object payload containing the values of the form fields for which the names are contained within the 'data' key, if any, the client should submit a POST request on change of these form fields, and will be returned the new value for the automatically generated form field.
- </para>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Attributes_Reference-form_fields">
- <title><literal>form_fields</literal></title>
- <para>
- The <literal>form_fields</literal> key holds an array of form fields that require user input.
- </para>
-
- </formalpara>
- <para>
- The key name for each key => value pair indicates the form field name for which the value is to be supplied by the user.
- </para>
- <para>
- Because some attributes can be multi-valued, or have a limited list of options, each defined form field in <literal>form_fields</literal> can hold an array with additional key => value pairs illustrating the type of form field that should be used, and what format to expect the result value in.
- </para>
- <para>
- <itemizedlist id="item-Administrator_Guide-Attributes_Reference-Additional_Information_in_form_fields">
- <title>Additional Information in <literal>form_fields</literal></title>
- <listitem>
- <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-maxlength">
- <title><literal>maxlength</literal></title>
- <para>
- For a form field of type <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-text" /> or type <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-list" />, this value holds the maximum length for a given item.
- </para>
-
- </formalpara>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-type">
- <title><literal>type</literal></title>
- <para>
- The <literal>type</literal> is to indicate the type of form field. Options include;
- </para>
-
- </formalpara>
- <para>
- <itemizedlist>
- <listitem>
- <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-text">
- <title><literal>text</literal></title>
- <para>
- This is a regular input field of type text.
- </para>
-
- </formalpara>
- <para>
- This is the default.
- </para>
- <para>
- Additional parameters for a text form field include <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-maxlength" />.
- </para>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-list">
- <title><literal>list</literal></title>
- <para>
- A form field of type <literal>list</literal> is expecting a list of text input values.
- </para>
-
- </formalpara>
- <para>
- A client web interface could choose to display a textarea with the instructions to supply one item per line, or more advanced (better) equivalents, such as an add/delete widget.
- </para>
- <para>
- A client command-line interface could choose to prompt for input values until an empty value is supplied.
- </para>
- <para>
- Additional parameters for a list form field include <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-maxlength" />, which holds the maximum length of each text value in the list.
- </para>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-multiselect">
- <title><literal>multiselect</literal></title>
- <para>
- This form field is a select list, where multiple options may be selected (as opposed to a <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-select" /> list, where only one option may be selected).
- </para>
-
- </formalpara>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-select">
- <title><literal>select</literal></title>
- <para>
- This form field is a selection list, of which one option may be selected.
- </para>
-
- </formalpara>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </listitem>
- <!--
+ </para>
+ <para>
+ This indicates to the client that a form field named 'displayname' is to be populated with the information contained within the form fields named 'givenname' and 'sn'.
+ </para>
+ <para>
+ If the client is capable of doing so, it should also update the form field named 'displayname' after the values for any of the form fields named 'givenname' or 'sn' have been changed.
+ </para>
+
+ </example>
+ <para>
+ With a JSON object payload containing the values of the form fields for which the names are contained within the 'data' key, if any, the client should submit a POST request on change of these form fields, and will be returned the new value for the automatically generated form field.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Attributes_Reference-form_fields">
+ <title><literal>form_fields</literal></title>
+ <para>
+ The <literal>form_fields</literal> key holds an array of form fields that require user input.
+ </para>
+
+ </formalpara>
+ <para>
+ The key name for each key => value pair indicates the form field name for which the value is to be supplied by the user.
+ </para>
+ <para>
+ Because some attributes can be multi-valued, or have a limited list of options, each defined form field in <literal>form_fields</literal> can hold an array with additional key => value pairs illustrating the type of form field that should be used, and what format to expect the result value in.
+ </para>
+ <para>
+ <itemizedlist id="item-Administrator_Guide-Attributes_Reference-Additional_Information_in_form_fields">
+ <title>Additional Information in <literal>form_fields</literal></title>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-maxlength">
+ <title><literal>maxlength</literal></title>
+ <para>
+ For a form field of type <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-text" /> or type <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-list" />, this value holds the maximum length for a given item.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-type">
+ <title><literal>type</literal></title>
+ <para>
+ The <literal>type</literal> is to indicate the type of form field. Options include;
+ </para>
+
+ </formalpara>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-text">
+ <title><literal>text</literal></title>
+ <para>
+ This is a regular input field of type text.
+ </para>
+
+ </formalpara>
+ <para>
+ This is the default.
+ </para>
+ <para>
+ Additional parameters for a text form field include <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-maxlength" />.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-list">
+ <title><literal>list</literal></title>
+ <para>
+ A form field of type <literal>list</literal> is expecting a list of text input values.
+ </para>
+
+ </formalpara>
+ <para>
+ A client web interface could choose to display a textarea with the instructions to supply one item per line, or more advanced (better) equivalents, such as an add/delete widget.
+ </para>
+ <para>
+ A client command-line interface could choose to prompt for input values until an empty value is supplied.
+ </para>
+ <para>
+ Additional parameters for a list form field include <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-maxlength" />, which holds the maximum length of each text value in the list.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-multiselect">
+ <title><literal>multiselect</literal></title>
+ <para>
+ This form field is a select list, where multiple options may be selected (as opposed to a <xref linkend="form-Administrator_Guide-Additional_Information_in_form_fields-select" /> list, where only one option may be selected).
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-select">
+ <title><literal>select</literal></title>
+ <para>
+ This form field is a selection list, of which one option may be selected.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <!--
<listitem>
<formalpara id="form-Administrator_Guide-Additional_Information_in_form_fields-value_source">
<title><literal>value_source</literal></title>
@@ -377,32 +377,32 @@
</formalpara>
</listitem>
- // -->
- </itemizedlist>
+ // -->
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Attributes_Reference-fields">
+ <title><literal>fields</literal></title>
+ <para>
+ The <literal>fields</literal> key holds an array of form fields and values for said form fields, that are static. One example of such form fields is <literal>objectclass</literal>.
+ </para>
- </para>
+ </formalpara>
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Attributes_Reference-fields">
- <title><literal>fields</literal></title>
- <para>
- The <literal>fields</literal> key holds an array of form fields and values for said form fields, that are static. One example of such form fields is <literal>objectclass</literal>.
- </para>
+ </listitem>
- </formalpara>
+ </itemizedlist>
- </listitem>
+ </para>
- </itemizedlist>
+ </section>
- </para>
- </section>
-
+ </section>
- </section>
-
</chapter>
diff --git a/Administrator_Guide/en-US/Preface.xml b/Administrator_Guide/en-US/Preface.xml
index 0b1e251..c9e647e 100644
--- a/Administrator_Guide/en-US/Preface.xml
+++ b/Administrator_Guide/en-US/Preface.xml
@@ -4,9 +4,9 @@
%BOOK_ENTITIES;
]>
<preface id="pref-Administrator_Guide-Preface">
- <title>Preface</title>
- <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="sect-Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="sect-About_Kolab_Groupware.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <title>Preface</title>
+ <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="sect-Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="sect-About_Kolab_Groupware.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</preface>
diff --git a/Administrator_Guide/en-US/Revision_History.xml b/Administrator_Guide/en-US/Revision_History.xml
index 5d8b7ea..a75c98d 100644
--- a/Administrator_Guide/en-US/Revision_History.xml
+++ b/Administrator_Guide/en-US/Revision_History.xml
@@ -4,30 +4,30 @@
%BOOK_ENTITIES;
]>
<appendix id="appe-Administrator_Guide-Revision_History">
- <title>Revision History</title>
- <simpara>
- <revhistory>
- <revision>
- <revnumber>0-0</revnumber>
- <date>Mon Dec 13 2010</date>
- <author>
- <firstname>Dude</firstname>
- <surname>McPants</surname>
- <email>Dude.McPants at example.com</email>
+ <title>Revision History</title>
+ <simpara>
+ <revhistory>
+ <revision>
+ <revnumber>0-0</revnumber>
+ <date>Mon Dec 13 2010</date>
+ <author>
+ <firstname>Dude</firstname>
+ <surname>McPants</surname>
+ <email>Dude.McPants at example.com</email>
- </author>
- <revdescription>
- <simplelist>
- <member>Initial creation of book by publican</member>
+ </author>
+ <revdescription>
+ <simplelist>
+ <member>Initial creation of book by publican</member>
- </simplelist>
+ </simplelist>
- </revdescription>
+ </revdescription>
- </revision>
+ </revision>
- </revhistory>
+ </revhistory>
- </simpara>
+ </simpara>
</appendix>
diff --git a/Administrator_Guide/en-US/Tweaking_Tips_for_389_Directory_Server.xml b/Administrator_Guide/en-US/Tweaking_Tips_for_389_Directory_Server.xml
index 48c1ff5..e5eae63 100644
--- a/Administrator_Guide/en-US/Tweaking_Tips_for_389_Directory_Server.xml
+++ b/Administrator_Guide/en-US/Tweaking_Tips_for_389_Directory_Server.xml
@@ -4,66 +4,66 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server">
- <title>Tweaking Tips for 389 Directory Server</title>
- <para>
- para
- </para>
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Adjusting_Cache_Sizes">
- <title>Adjusting Cache Sizes</title>
- <para>
- para
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees">
- <title>Using Virtual List View Control for Larger Directory Information Trees</title>
- <para>
- A default deployment of Kolab Groupware includes a largely unmodified 389 Directory Server with not all too many tweaked settings. When deployments grow the size of their Directory Information Tree, such as would be the case with more than 2000 user, group and/or contact entries, regular bind credentials run out of bounds when querying the tree.
- </para>
- <para>
- Regular bind credentials include look-through, size and time limitations, usually causing a result set to be limited to 2000 entries (usually the first symptom), or causing the query to time out (larger trees, usually a later symptom).
- </para>
- <para>
- Because a variety of User Interfaces depend on listing users, groups and contacts, it may be necessary to seek aid in Virtual List View (VLV) capabilities. VLV consists of additional indexes that can be queried by enabling two server-side controls:
- </para>
- <para>
- <orderedlist>
- <listitem>
- <para>
- Virtual List View control, with corresponding Base DN, Filter and Scope
- </para>
-
- </listitem>
- <listitem>
- <para>
- Server-Side Sorting control (SSS), with a corresponding list of attributes to use when sorting result entries.
- </para>
-
- </listitem>
-
- </orderedlist>
-
- </para>
- <para>
- VLV along with SSS enables the pagination of search results, and circumvents the search limits for regular bind credentials.
- </para>
- <procedure id="proc-Administrator_Guide-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees-Configuring_VLV_and_SSS_on_389_Directory_Server">
- <title>Configuring VLV and SSS on 389 Directory Server</title>
- <step>
- <para>
- A version of these scripts can be downloaded from <ulink url="http://hosted.kolabsys.com/~vanmeeuwen/kolab-scripts.tar.gz" />.
- </para>
- <para>
- Inclusion into the <application>kolab</application> command-line utility is planned, so make sure to check <command>kolab help</command> to see if the commands have been included already.
- </para>
-
- </step>
- <step>
- <para>
- In the following few steps, the scripts refer to the variables outlined below (which are contained in <filename>./settings.sh</filename>).
- </para>
-
+ <title>Tweaking Tips for 389 Directory Server</title>
+ <para>
+ para
+ </para>
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Adjusting_Cache_Sizes">
+ <title>Adjusting Cache Sizes</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees">
+ <title>Using Virtual List View Control for Larger Directory Information Trees</title>
+ <para>
+ A default deployment of Kolab Groupware includes a largely unmodified 389 Directory Server with not all too many tweaked settings. When deployments grow the size of their Directory Information Tree, such as would be the case with more than 2000 user, group and/or contact entries, regular bind credentials run out of bounds when querying the tree.
+ </para>
+ <para>
+ Regular bind credentials include look-through, size and time limitations, usually causing a result set to be limited to 2000 entries (usually the first symptom), or causing the query to time out (larger trees, usually a later symptom).
+ </para>
+ <para>
+ Because a variety of User Interfaces depend on listing users, groups and contacts, it may be necessary to seek aid in Virtual List View (VLV) capabilities. VLV consists of additional indexes that can be queried by enabling two server-side controls:
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Virtual List View control, with corresponding Base DN, Filter and Scope
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Server-Side Sorting control (SSS), with a corresponding list of attributes to use when sorting result entries.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <para>
+ VLV along with SSS enables the pagination of search results, and circumvents the search limits for regular bind credentials.
+ </para>
+ <procedure id="proc-Administrator_Guide-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees-Configuring_VLV_and_SSS_on_389_Directory_Server">
+ <title>Configuring VLV and SSS on 389 Directory Server</title>
+ <step>
+ <para>
+ A version of these scripts can be downloaded from <ulink url="http://hosted.kolabsys.com/~vanmeeuwen/kolab-scripts.tar.gz" />.
+ </para>
+ <para>
+ Inclusion into the <application>kolab</application> command-line utility is planned, so make sure to check <command>kolab help</command> to see if the commands have been included already.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ In the following few steps, the scripts refer to the variables outlined below (which are contained in <filename>./settings.sh</filename>).
+ </para>
+
<programlisting language="Bash">#!/bin/bash
export rootdn="dc=example,dc=org"
@@ -73,12 +73,12 @@ export ldap_host="localhost"
export ldap_binddn="cn=Directory Manager"
export ldap_bindpw="VerySecret"</programlisting>
- </step>
- <step>
- <para>
- Add the VLV Search definitions:
- </para>
-
+ </step>
+ <step>
+ <para>
+ Add the VLV Search definitions:
+ </para>
+
<programlisting language="Bash">#!/bin/bash
. ./settings.sh
@@ -119,12 +119,12 @@ export ldap_bindpw="VerySecret"</programlisting>
echo ""
) | ldapadd -x -h ${ldap_host} -D "${ldap_binddn}" -w "${ldap_bindpw}" -c</programlisting>
- </step>
- <step>
- <para>
- Add the VLV Indexes:
- </para>
-
+ </step>
+ <step>
+ <para>
+ Add the VLV Indexes:
+ </para>
+
<programlisting language="Bash">#!/bin/bash
. ./settings.sh
@@ -159,12 +159,12 @@ export ldap_bindpw="VerySecret"</programlisting>
echo ""
) | ldapadd -x -h ${ldap_host} -D "${ldap_binddn}" -w "${ldap_bindpw}" -c</programlisting>
- </step>
- <step>
- <para>
- Execute the indexing tasks:
- </para>
-
+ </step>
+ <step>
+ <para>
+ Execute the indexing tasks:
+ </para>
+
<programlisting language="Bash">#!/bin/bash
. ./settings.sh
@@ -241,12 +241,12 @@ while [ ${ldap_complete} -ne 1 ]; do
fi
done</programlisting>
- </step>
- <step>
- <para>
- Test the VLV functioning with this detection and execution script:
- </para>
-
+ </step>
+ <step>
+ <para>
+ Test the VLV functioning with this detection and execution script:
+ </para>
+
<programlisting language="Bash">#!/bin/bash
. ./settings.sh
@@ -379,37 +379,37 @@ done</programlisting>
fi
done</programlisting>
- </step>
-
- </procedure>
-
- <section id="sect-Administrator_Guide-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees-Making_Use_of_VLV_and_SSS">
- <title>Making Use of VLV and SSS</title>
- <para>
- See <xref linkend="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Configuring_the_LDAP_Address_Book_for_Use_of_VLV_and_SSS" /> for instructions on configuring Roundcube to make use of VLV and SSS for its Global Address Book.
- </para>
-
- </section>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Enforcing_Global_Attribute_Uniqueness">
- <title>Enforcing (Global) Attribute Uniqueness</title>
- <para>
- para
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Enforcing_a_Password_Policy">
- <title>Enforcing a Password Policy</title>
- <para>
- para
- </para>
-
- </section>
-
+ </step>
+
+ </procedure>
+
+ <section id="sect-Administrator_Guide-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees-Making_Use_of_VLV_and_SSS">
+ <title>Making Use of VLV and SSS</title>
+ <para>
+ See <xref linkend="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Configuring_the_LDAP_Address_Book_for_Use_of_VLV_and_SSS" /> for instructions on configuring Roundcube to make use of VLV and SSS for its Global Address Book.
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Enforcing_Global_Attribute_Uniqueness">
+ <title>Enforcing (Global) Attribute Uniqueness</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Enforcing_a_Password_Policy">
+ <title>Enforcing a Password Policy</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
</chapter>
diff --git a/Administrator_Guide/en-US/Tweaking_Tips_for_Cyrus_IMAP.xml b/Administrator_Guide/en-US/Tweaking_Tips_for_Cyrus_IMAP.xml
index 95ed08d..46bee2e 100644
--- a/Administrator_Guide/en-US/Tweaking_Tips_for_Cyrus_IMAP.xml
+++ b/Administrator_Guide/en-US/Tweaking_Tips_for_Cyrus_IMAP.xml
@@ -4,126 +4,126 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP">
- <title>Tweaking Tips for Cyrus IMAP</title>
- <para>
- A default Kolab Groupware environment includes most if not all features that Cyrus IMAP offers, which is not necessarily optimal for all deployments. The sections in this chapter address some of the various opportunities to tweak settings for your deployment.
- </para>
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-Flushing_Seen_State">
- <title>Flushing Seen State</title>
- <para>
- When users connect multiple clients to Cyrus IMAP, or when multiple users use the same mail folder that has shared seen state enabled, one client may be marking a message as \Seen, and another client may seem to take a while before it picks up on the message having been marked as read.
- </para>
- <para>
- In a default deployment scenario, Cyrus IMAP keeps the flagging of messages from being flushed to disk immediately, which saves on disk I/O, making Cyrus IMAP more efficient in most deployment scenarios. If, however, you have the aforementioned situation occurring in your deployment, you may need to flush the seen state of messages to disk at the first opportunity.
- </para>
- <para>
- In order to do so, execute
- </para>
- <procedure id="proc-Administrator_Guide-Flushing_Seen_State-Configuring_Cyrus_IMAP_to_Flush_the_Seen_State_to_Disk_Immediately">
- <title>Configuring Cyrus IMAP to Flush the Seen State to Disk Immediately</title>
- <step>
- <para>
- Open up /etc/imapd.conf in your favorite editor
- </para>
-
- </step>
- <step>
- <para>
- Set (add the setting if not available already) <literal>flushseenstate</literal> to <literal>1</literal>.
- </para>
-
- </step>
- <step>
- <para>
- Restart the Cyrus IMAP service
- </para>
-
- </step>
-
- </procedure>
-
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-Disabling_the_Shared_Folders_Namespace">
- <title>Disabling the "Shared Folders" Namespace</title>
- <para>
- para
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-Speeding_Up_Authentication">
- <title>Speeding Up Authentication</title>
- <para>
- para
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-Full_text_Indexing_of_Mail_Folders">
- <title>Full-text Indexing of Mail Folders</title>
- <para>
- para
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-IMAP_Single_Instance_Store">
- <title>IMAP Single Instance Store</title>
- <para>
- Cyrus IMAP allows for <emphasis>single instance store</emphasis> that de-duplicates messages being delivered to its mailboxes, but with a certain set of restrictions. This section addresses some of those restrictions and advises on parameters to tweak in Kolab to make optimal use of the feature.
- </para>
- <para>
- Single instance store requires delivery of the message (through LMTP) in one single shot (a single LMTP session). For deployments that expect to have significant numbers of emails be sent to significant numbers of users through Kolab Distribution Groups, tweaking the Postfix settings <literal>lmtp_destination_concurrency_limit</literal> and <literal>lmtp_destination_concurrency_limit</literal> may be necessary.
- </para>
- <procedure id="proc-Administrator_Guide-IMAP_Single_Instance_Store-Example_of_Single_Instance_Store">
- <title>Example of Single Instance Store</title>
- <para>
- The following example depicts a scenario in which single instance store can be shown in full force.
- </para>
- <step>
- <para>
- Set the destination concurrency and recipient limits for LMTP to 1 (from a default 20):
- </para>
- <para>
-
+ <title>Tweaking Tips for Cyrus IMAP</title>
+ <para>
+ A default Kolab Groupware environment includes most if not all features that Cyrus IMAP offers, which is not necessarily optimal for all deployments. The sections in this chapter address some of the various opportunities to tweak settings for your deployment.
+ </para>
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-Flushing_Seen_State">
+ <title>Flushing Seen State</title>
+ <para>
+ When users connect multiple clients to Cyrus IMAP, or when multiple users use the same mail folder that has shared seen state enabled, one client may be marking a message as \Seen, and another client may seem to take a while before it picks up on the message having been marked as read.
+ </para>
+ <para>
+ In a default deployment scenario, Cyrus IMAP keeps the flagging of messages from being flushed to disk immediately, which saves on disk I/O, making Cyrus IMAP more efficient in most deployment scenarios. If, however, you have the aforementioned situation occurring in your deployment, you may need to flush the seen state of messages to disk at the first opportunity.
+ </para>
+ <para>
+ In order to do so, execute
+ </para>
+ <procedure id="proc-Administrator_Guide-Flushing_Seen_State-Configuring_Cyrus_IMAP_to_Flush_the_Seen_State_to_Disk_Immediately">
+ <title>Configuring Cyrus IMAP to Flush the Seen State to Disk Immediately</title>
+ <step>
+ <para>
+ Open up /etc/imapd.conf in your favorite editor
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Set (add the setting if not available already) <literal>flushseenstate</literal> to <literal>1</literal>.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Restart the Cyrus IMAP service
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-Disabling_the_Shared_Folders_Namespace">
+ <title>Disabling the "Shared Folders" Namespace</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-Speeding_Up_Authentication">
+ <title>Speeding Up Authentication</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-Full_text_Indexing_of_Mail_Folders">
+ <title>Full-text Indexing of Mail Folders</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Cyrus_IMAP-IMAP_Single_Instance_Store">
+ <title>IMAP Single Instance Store</title>
+ <para>
+ Cyrus IMAP allows for <emphasis>single instance store</emphasis> that de-duplicates messages being delivered to its mailboxes, but with a certain set of restrictions. This section addresses some of those restrictions and advises on parameters to tweak in Kolab to make optimal use of the feature.
+ </para>
+ <para>
+ Single instance store requires delivery of the message (through LMTP) in one single shot (a single LMTP session). For deployments that expect to have significant numbers of emails be sent to significant numbers of users through Kolab Distribution Groups, tweaking the Postfix settings <literal>lmtp_destination_concurrency_limit</literal> and <literal>lmtp_destination_concurrency_limit</literal> may be necessary.
+ </para>
+ <procedure id="proc-Administrator_Guide-IMAP_Single_Instance_Store-Example_of_Single_Instance_Store">
+ <title>Example of Single Instance Store</title>
+ <para>
+ The following example depicts a scenario in which single instance store can be shown in full force.
+ </para>
+ <step>
+ <para>
+ Set the destination concurrency and recipient limits for LMTP to 1 (from a default 20):
+ </para>
+ <para>
+
<screen># <userinput>postconf -e lmtp_destination_concurrency_limit=1</userinput>
# <userinput>postconf -e lmtp_destination_recipient_limit=1</userinput>
<userinput># service postfix reload</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Create a Kolab Distribution Group with 20 users.
- </para>
-
- </step>
- <step>
- <para>
- Send an email to the distribution group, such as:
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Create a Kolab Distribution Group with 20 users.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Send an email to the distribution group, such as:
+ </para>
+ <para>
+
<screen># <userinput>date | mail -s "single instance store test #1" kolab-users at example.org</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Await delivery of the mail message to all users.
- </para>
-
- </step>
- <step>
- <para>
- Examine the inode numbers (links) and the cumulative size on disk for the files.
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Await delivery of the mail message to all users.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Examine the inode numbers (links) and the cumulative size on disk for the files.
+ </para>
+ <para>
+
<screen># <userinput>cd /var/spool/imap/domain/e/example.org/</userinput>
# <userinput>files=$(grep -lr "^Subject: single instance store test #1" \</userinput>
> <userinput>$(find . -type f -name "*.") | sort -u)</userinput>
@@ -181,45 +181,45 @@ Modify: 2012-08-06 11:04:06.000000000 +0200
Change: 2012-08-06 11:04:06.757235163 +0200
</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Set the destination concurrency and recipient limits for LMTP back to the default 20:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Set the destination concurrency and recipient limits for LMTP back to the default 20:
- </para>
- <para>
-
<screen># <userinput>postconf -e lmtp_destination_concurrency_limit=20</userinput>
# <userinput>postconf -e lmtp_destination_recipient_limit=20</userinput>
<userinput># service postfix reload</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Send an email to the distribution group, such as:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Send an email to the distribution group, such as:
- </para>
- <para>
-
<screen># <userinput>date | mail -s "single instance store test #2" kolab-users at example.org</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Await delivery of the mail message to all users.
- </para>
-
- </step>
- <step>
- <para>
- Examine the inode numbers (links) and the cumulative size on disk for the files.
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Await delivery of the mail message to all users.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Examine the inode numbers (links) and the cumulative size on disk for the files.
+ </para>
+ <para>
+
<screen># <userinput>cd /var/spool/imap/domain/e/example.org/</userinput>
# <userinput>files=$(grep -lr "^Subject: single instance store test #2" \</userinput>
> <userinput>$(find . -type f -name "*.") | sort -u)</userinput>
@@ -257,15 +257,15 @@ Access: 2012-08-06 11:08:56.742891364 +0200
Modify: 2012-08-06 11:08:28.000000000 +0200
Change: 2012-08-06 11:08:28.760261876 +0200</screen>
- </para>
+ </para>
+
+ </step>
+
+ </procedure>
- </step>
- </procedure>
-
+ </section>
- </section>
-
</chapter>
diff --git a/Administrator_Guide/en-US/Tweaking_Tips_for_Postfix.xml b/Administrator_Guide/en-US/Tweaking_Tips_for_Postfix.xml
index 1ce978b..7c33a06 100644
--- a/Administrator_Guide/en-US/Tweaking_Tips_for_Postfix.xml
+++ b/Administrator_Guide/en-US/Tweaking_Tips_for_Postfix.xml
@@ -4,52 +4,52 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Tweaking_Tips_for_Postfix">
- <title>Tweaking Tips for Postfix</title>
- <para>
- para
- </para>
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Postfix-Large_Kolab_Distribution_Groups">
- <title>Large Kolab Distribution Groups</title>
- <para>
- If you have Kolab distribution groups with many members, you may see the following message occur in log file <filename>/var/log/maillog</filename>:
- </para>
- <para>
-
+ <title>Tweaking Tips for Postfix</title>
+ <para>
+ para
+ </para>
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Postfix-Large_Kolab_Distribution_Groups">
+ <title>Large Kolab Distribution Groups</title>
+ <para>
+ If you have Kolab distribution groups with many members, you may see the following message occur in log file <filename>/var/log/maillog</filename>:
+ </para>
+ <para>
+
<screen>Aug 17 10:21:59 kolab postfix/cleanup[5916]: warning: 398194A151: unreasonable virtual_alias_maps map expansion size for kolab-users at example.org</screen>
- </para>
- <para>
- The setting <literal>virtual_alias_expansion_limit</literal> controls the maximum number of recipient address that are produced from a single original recipient address. The default depends on your installation.
- </para>
- <para>
- To get the default value, execute:
- </para>
- <para>
-
+ </para>
+ <para>
+ The setting <literal>virtual_alias_expansion_limit</literal> controls the maximum number of recipient address that are produced from a single original recipient address. The default depends on your installation.
+ </para>
+ <para>
+ To get the default value, execute:
+ </para>
+ <para>
+
<screen># <userinput>postconf -d virtual_alias_expansion_limit</userinput>
1000</screen>
- </para>
- <para>
- To get the current value, execute:
- </para>
- <para>
-
+ </para>
+ <para>
+ To get the current value, execute:
+ </para>
+ <para>
+
<screen># <userinput>postconf virtual_alias_expansion_limit</userinput>
1000</screen>
- </para>
- <para>
- To set a new value, execute:
- </para>
- <para>
-
+ </para>
+ <para>
+ To set a new value, execute:
+ </para>
+ <para>
+
<screen># <userinput>postconf -e virtual_alias_expansion_limit=10000</userinput></screen>
- </para>
+ </para>
+
+ </section>
- </section>
-
</chapter>
diff --git a/Administrator_Guide/en-US/Tweaking_Tips_for_Roundcube.xml b/Administrator_Guide/en-US/Tweaking_Tips_for_Roundcube.xml
index 6595358..89a1f97 100644
--- a/Administrator_Guide/en-US/Tweaking_Tips_for_Roundcube.xml
+++ b/Administrator_Guide/en-US/Tweaking_Tips_for_Roundcube.xml
@@ -4,180 +4,180 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Tweaking_Tips_for_Roundcube">
- <title>Tweaking Tips for Roundcube</title>
- <para>
- para
- </para>
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Setting_the_Maximum_Upload_Size">
- <title>Setting the Maximum Upload Size</title>
- <para>
- para
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Using_Memcached_for_Session_Storage">
- <title>Using Memcached for Session Storage</title>
- <para>
- para
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Using_APC_to_Accelerate_PHP">
- <title>Using APC to Accelerate PHP</title>
- <para>
- para
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Configuring_the_LDAP_Address_Book_for_Use_of_VLV_and_SSS">
- <title>Configuring the LDAP Address Book for Use of VLV and SSS</title>
- <para>
- With a large directory information tree (as described in <xref linkend="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees" />), having set up VLV and SSS (see <xref linkend="proc-Administrator_Guide-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees-Configuring_VLV_and_SSS_on_389_Directory_Server" />), Roundcube must still be configured to make use of the new settings.
- </para>
- <procedure id="proc-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_Use_of_VLV_and_SSS-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS">
- <title>Configuring the LDAP Address Book for VLV and SSS</title>
- <step>
- <para>
- Relevant settings are contained within the <literal>$rcmail_config['ldap_public']['kolab_addressbook']</literal> setting in <filename>/etc/roundcubemail/main.inc.php</filename>. Working from a default Kolab Groupware installation, we are going to verify and/or change the relevant settings one by one.
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-base_dn">
- <title><literal>base_dn</literal></title>
- <para>
- The <literal>base_dn</literal> configured in the address book should match the Base DN configured for the People VLV Search.
- </para>
-
- </formalpara>
- <para>
- Should you not have modified the configuration deployed by default too much, then the likely appropriate value for this setting is <literal>ou=People,${rootdn}</literal>
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-filter">
- <title><literal>filter</literal></title>
- <para>
- The <literal>filter</literal> configured in the address book should match the search filter configured for the People VLV Search.
- </para>
-
- </formalpara>
- <para>
- By default, all LDAP entries with object class <literal>inetOrgPerson</literal> are included.
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-scope">
- <title><literal>scope</literal></title>
- <para>
- The <literal>scope</literal> configured in the address book should match the search scope configured for the People VLV Search.
- </para>
-
- </formalpara>
- <para>
- para
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-sort">
- <title><literal>sort</literal></title>
- <para>
- The <literal>sort</literal> setting is an array, that must contain the exact list of elements configured in the vlv sort configured for the People VLV Index.
- </para>
-
- </formalpara>
- <para>
- para
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-vlv">
- <title><literal>vlv</literal></title>
- <para>
- This setting controls whether VLV is to be used at all. Set it to <literal>true</literal>.
- </para>
-
- </formalpara>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-vlv_search">
- <title><literal>vlv_search</literal></title>
- <para>
- This setting controls whether searches are to use VLV and SSS as well. More specifically, this influences auto-completion such as during the composition of new messages, adding participants to events, and adding ACL entries in folder management.
- </para>
-
- </formalpara>
- <para>
- para
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-groups_Array_base_dn">
- <title><literal>groups</literal> Array <literal>base_dn</literal></title>
- <para>
- para
- </para>
-
- </formalpara>
- <para>
- para
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-groups_Array_filter">
- <title><literal>groups</literal> Array <literal>filter</literal></title>
- <para>
- para
- </para>
-
- </formalpara>
- <para>
- para
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-groups_Array_scope">
- <title><literal>groups</literal> Array <literal>scope</literal></title>
- <para>
- para
- </para>
-
- </formalpara>
- <para>
- para
- </para>
-
- </step>
- <step>
- <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-groups_Array_sort">
- <title><literal>groups</literal> Array <literal>sort</literal></title>
- <para>
- para
- </para>
-
- </formalpara>
- <para>
- para
- </para>
-
- </step>
-
- </procedure>
-
-
- </section>
-
+ <title>Tweaking Tips for Roundcube</title>
+ <para>
+ para
+ </para>
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Setting_the_Maximum_Upload_Size">
+ <title>Setting the Maximum Upload Size</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Using_Memcached_for_Session_Storage">
+ <title>Using Memcached for Session Storage</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Using_APC_to_Accelerate_PHP">
+ <title>Using APC to Accelerate PHP</title>
+ <para>
+ para
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Tweaking_Tips_for_Roundcube-Configuring_the_LDAP_Address_Book_for_Use_of_VLV_and_SSS">
+ <title>Configuring the LDAP Address Book for Use of VLV and SSS</title>
+ <para>
+ With a large directory information tree (as described in <xref linkend="sect-Administrator_Guide-Tweaking_Tips_for_389_Directory_Server-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees" />), having set up VLV and SSS (see <xref linkend="proc-Administrator_Guide-Using_Virtual_List_View_Control_for_Larger_Directory_Information_Trees-Configuring_VLV_and_SSS_on_389_Directory_Server" />), Roundcube must still be configured to make use of the new settings.
+ </para>
+ <procedure id="proc-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_Use_of_VLV_and_SSS-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS">
+ <title>Configuring the LDAP Address Book for VLV and SSS</title>
+ <step>
+ <para>
+ Relevant settings are contained within the <literal>$rcmail_config['ldap_public']['kolab_addressbook']</literal> setting in <filename>/etc/roundcubemail/main.inc.php</filename>. Working from a default Kolab Groupware installation, we are going to verify and/or change the relevant settings one by one.
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-base_dn">
+ <title><literal>base_dn</literal></title>
+ <para>
+ The <literal>base_dn</literal> configured in the address book should match the Base DN configured for the People VLV Search.
+ </para>
+
+ </formalpara>
+ <para>
+ Should you not have modified the configuration deployed by default too much, then the likely appropriate value for this setting is <literal>ou=People,${rootdn}</literal>
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-filter">
+ <title><literal>filter</literal></title>
+ <para>
+ The <literal>filter</literal> configured in the address book should match the search filter configured for the People VLV Search.
+ </para>
+
+ </formalpara>
+ <para>
+ By default, all LDAP entries with object class <literal>inetOrgPerson</literal> are included.
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-scope">
+ <title><literal>scope</literal></title>
+ <para>
+ The <literal>scope</literal> configured in the address book should match the search scope configured for the People VLV Search.
+ </para>
+
+ </formalpara>
+ <para>
+ para
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-sort">
+ <title><literal>sort</literal></title>
+ <para>
+ The <literal>sort</literal> setting is an array, that must contain the exact list of elements configured in the vlv sort configured for the People VLV Index.
+ </para>
+
+ </formalpara>
+ <para>
+ para
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-vlv">
+ <title><literal>vlv</literal></title>
+ <para>
+ This setting controls whether VLV is to be used at all. Set it to <literal>true</literal>.
+ </para>
+
+ </formalpara>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-vlv_search">
+ <title><literal>vlv_search</literal></title>
+ <para>
+ This setting controls whether searches are to use VLV and SSS as well. More specifically, this influences auto-completion such as during the composition of new messages, adding participants to events, and adding ACL entries in folder management.
+ </para>
+
+ </formalpara>
+ <para>
+ para
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-groups_Array_base_dn">
+ <title><literal>groups</literal> Array <literal>base_dn</literal></title>
+ <para>
+ para
+ </para>
+
+ </formalpara>
+ <para>
+ para
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-groups_Array_filter">
+ <title><literal>groups</literal> Array <literal>filter</literal></title>
+ <para>
+ para
+ </para>
+
+ </formalpara>
+ <para>
+ para
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-groups_Array_scope">
+ <title><literal>groups</literal> Array <literal>scope</literal></title>
+ <para>
+ para
+ </para>
+
+ </formalpara>
+ <para>
+ para
+ </para>
+
+ </step>
+ <step>
+ <formalpara id="form-Administrator_Guide-Configuring_the_LDAP_Address_Book_for_VLV_and_SSS-groups_Array_sort">
+ <title><literal>groups</literal> Array <literal>sort</literal></title>
+ <para>
+ para
+ </para>
+
+ </formalpara>
+ <para>
+ para
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </section>
+
</chapter>
diff --git a/Administrator_Guide/en-US/Upgrading_Accounts_from_Kolab_Format_version_2.xml b/Administrator_Guide/en-US/Upgrading_Accounts_from_Kolab_Format_version_2.xml
index a7b7fb1..c22bdc0 100644
--- a/Administrator_Guide/en-US/Upgrading_Accounts_from_Kolab_Format_version_2.xml
+++ b/Administrator_Guide/en-US/Upgrading_Accounts_from_Kolab_Format_version_2.xml
@@ -4,17 +4,17 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Upgrading_Accounts_from_Kolab_Format_version_2">
- <title>Upgrading Accounts from Kolab Format version 2</title>
- <para>
- Upgrading the existing accounts from a Kolab 2 server to a Kolab 3 server is a question of upgrading the server itself, but also upgrading the format from Kolab XML format version 2, to Kolab XML Format version 3.
- </para>
- <para>
- Upgrading the server itself is documented in a different chapter (TODO, link to that chapter). This chapter concerns the upgrading of IMAP Accounts from the Kolab v2 format to the Kolab v3 format.
- </para>
- <para>
- imapsync --host1 kolab2.example.org --tls1 --authuser1 john.doe at example.org --user1 cyrus-admin --proxyauth1 --password1 Welcome2KolabSystems --host2 kolab3.example.org --tls2 --authuser2 john.doe at example.org --user2 cyrus-admin --proxyauth2 --password2 Welcome2KolabSystems --include="INBOX"
- </para>
-
+ <title>Upgrading Accounts from Kolab Format version 2</title>
+ <para>
+ Upgrading the existing accounts from a Kolab 2 server to a Kolab 3 server is a question of upgrading the server itself, but also upgrading the format from Kolab XML format version 2, to Kolab XML Format version 3.
+ </para>
+ <para>
+ Upgrading the server itself is documented in a different chapter (TODO, link to that chapter). This chapter concerns the upgrading of IMAP Accounts from the Kolab v2 format to the Kolab v3 format.
+ </para>
+ <para>
+ imapsync --host1 kolab2.example.org --tls1 --authuser1 john.doe at example.org --user1 cyrus-admin --proxyauth1 --password1 Welcome2KolabSystems --host2 kolab3.example.org --tls2 --authuser2 john.doe at example.org --user2 cyrus-admin --proxyauth2 --password2 Welcome2KolabSystems --include="INBOX"
+ </para>
+
<programlisting language="Bash">#!/bin/bash
kolab -c /etc/kolab/kolab2.conf list-mailbox-acls user/*@example.org | \
@@ -33,36 +33,36 @@ kolab -c /etc/kolab/kolab2.conf list-mailbox-acls user/*@example.org | \
"${aci_permissions}"
fi
done</programlisting>
- <para>
- warning about --useuid
- </para>
- <para>
- rsync -aHvz --progress --partial --exclude="Archive/" --exclude="Administrativia/" --exclude="Bugzilla/" --exclude="Ham/" --exclude="Spam/" root at kolab.kolabsys.com:/kolab/var/imapd/spool/domain/k/kolabsys.com/v/user/vanmeeuwen/ /var/spool/imap/domain/k/kolabsys.com/v/user/vanmeeuwen/
- </para>
- <para>
- /kolab/var/imapd/domain/k/kolabsys.com/user/v/vanmeeuwen.seen
- </para>
- <para>
- /kolab/var/imapd/domain/k/kolabsys.com/user/v/vanmeeuwen.sub
- </para>
- <procedure id="proc-Administrator_Guide-Upgrading_Accounts_from_Kolab_Format_version_2-Synchronizing_IMAP_Accounts_using_Offlineimap">
- <title>Synchronizing IMAP Accounts using Offlineimap</title>
- <step>
- <para>
- Obtain the SSL certificate fingerprints needed with the following command:
- </para>
- <para>
-
+ <para>
+ warning about --useuid
+ </para>
+ <para>
+ rsync -aHvz --progress --partial --exclude="Archive/" --exclude="Administrativia/" --exclude="Bugzilla/" --exclude="Ham/" --exclude="Spam/" root at kolab.kolabsys.com:/kolab/var/imapd/spool/domain/k/kolabsys.com/v/user/vanmeeuwen/ /var/spool/imap/domain/k/kolabsys.com/v/user/vanmeeuwen/
+ </para>
+ <para>
+ /kolab/var/imapd/domain/k/kolabsys.com/user/v/vanmeeuwen.seen
+ </para>
+ <para>
+ /kolab/var/imapd/domain/k/kolabsys.com/user/v/vanmeeuwen.sub
+ </para>
+ <procedure id="proc-Administrator_Guide-Upgrading_Accounts_from_Kolab_Format_version_2-Synchronizing_IMAP_Accounts_using_Offlineimap">
+ <title>Synchronizing IMAP Accounts using Offlineimap</title>
+ <step>
+ <para>
+ Obtain the SSL certificate fingerprints needed with the following command:
+ </para>
+ <para>
+
<screen># <userinput>openssl x509 -fingerprint \</userinput>
> <userinput>-in /etc/pki/cyrus-imapd/cyrus-imapd.pem | head -n 1</userinput></screen>
- </para>
+ </para>
+
+ </step>
+
+ </procedure>
- </step>
- </procedure>
-
-
<programlisting language="INI Files">[general]
metadata = ~/.offlineimap
accounts = kolab2to3
diff --git a/Administrator_Guide/en-US/Upgrading_Cyrus_IMAP_from_2.3_to_2.4.xml b/Administrator_Guide/en-US/Upgrading_Cyrus_IMAP_from_2.3_to_2.4.xml
index 0bd1aa7..3151c27 100644
--- a/Administrator_Guide/en-US/Upgrading_Cyrus_IMAP_from_2.3_to_2.4.xml
+++ b/Administrator_Guide/en-US/Upgrading_Cyrus_IMAP_from_2.3_to_2.4.xml
@@ -4,118 +4,118 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Upgrading_Cyrus_IMAP_from_2.3_to_2.4">
- <title>Upgrading Cyrus IMAP from 2.3 to 2.4</title>
- <para>
- As a seperate set of procedures, we have documented for you, the process of upgrading Cyrus IMAP 2.3 to Cyrus IMAP 2.4 on the same server system. This process involves getting some information out of Cyrus IMAP 2.3 before shutting it down and upgrading Cyrus IMAP 2.3 to 2.4.
- </para>
- <procedure id="proc-Administrator_Guide-Upgrading_Cyrus_IMAP_from_2.3_to_2.4-Preparations">
- <title>Preparations</title>
- <step>
- <para>
- During the migration, the Kolab 2 server cannot be allowed to;
- </para>
- <para>
- <orderedlist>
- <listitem>
- <para>
- Receive new email.
- </para>
-
- </listitem>
- <listitem>
- <para>
- Let users post/submit new data.
- </para>
-
- </listitem>
-
- </orderedlist>
-
- </para>
- <para>
- The easiest way to prevent any of this happening is to shut down the MTA and restrict access to the IMAP and POP services through firewalling.
- </para>
-
- </step>
- <step>
- <para>
- Remember to create a backup of the data.
- </para>
-
- </step>
-
- </procedure>
-
- <procedure id="proc-Administrator_Guide-Upgrading_Cyrus_IMAP_from_2.3_to_2.4-Upgrading_to_Cyrus_IMAP_2.4">
- <title>Upgrading to Cyrus IMAP 2.4</title>
- <step>
- <para>
- List the existing folder annotations, and save them to a file:
- </para>
- <para>
-
+ <title>Upgrading Cyrus IMAP from 2.3 to 2.4</title>
+ <para>
+ As a seperate set of procedures, we have documented for you, the process of upgrading Cyrus IMAP 2.3 to Cyrus IMAP 2.4 on the same server system. This process involves getting some information out of Cyrus IMAP 2.3 before shutting it down and upgrading Cyrus IMAP 2.3 to 2.4.
+ </para>
+ <procedure id="proc-Administrator_Guide-Upgrading_Cyrus_IMAP_from_2.3_to_2.4-Preparations">
+ <title>Preparations</title>
+ <step>
+ <para>
+ During the migration, the Kolab 2 server cannot be allowed to;
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Receive new email.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Let users post/submit new data.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <para>
+ The easiest way to prevent any of this happening is to shut down the MTA and restrict access to the IMAP and POP services through firewalling.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Remember to create a backup of the data.
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <procedure id="proc-Administrator_Guide-Upgrading_Cyrus_IMAP_from_2.3_to_2.4-Upgrading_to_Cyrus_IMAP_2.4">
+ <title>Upgrading to Cyrus IMAP 2.4</title>
+ <step>
+ <para>
+ List the existing folder annotations, and save them to a file:
+ </para>
+ <para>
+
<screen># <userinput>kolab list-mailbox-metadata \</userinput>
> <userinput>"user/*@example.org" > metadata.txt</userinput>
# <userinput>kolab list-mailbox-metadata \</userinput>
> <userinput>"shared/*@example.org" >> metadata.txt</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Stop the Cyrus IMAP 2.3 service.
- </para>
-
- </step>
- <step>
- <para>
- Convert the annotations database to flat. This example converts the database from skiplist:
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Stop the Cyrus IMAP 2.3 service.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Convert the annotations database to flat. This example converts the database from skiplist:
+ </para>
+ <para>
+
<screen># <userinput>/path/to/cvt_cyrusdb /path/to/annotations.db skiplist /path/to/annotations.txt flat</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Copy both annotations.db and annotations.txt to a safe location.
- </para>
-
- </step>
- <step>
- <para>
- Upgrade to Cyrus IMAP 2.4.
- </para>
-
- </step>
- <xi:include href="step-convert-seen-databases.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <step>
- <para>
- Start the Cyrus IMAP 2.4 service:
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Copy both annotations.db and annotations.txt to a safe location.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Upgrade to Cyrus IMAP 2.4.
+ </para>
+
+ </step>
+ <xi:include href="step-convert-seen-databases.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <step>
+ <para>
+ Start the Cyrus IMAP 2.4 service:
+ </para>
+ <para>
+
<screen># <userinput>service cyrus-imapd start</userinput></screen>
- </para>
- <important>
- <para>
- Users should not yet be allowed to interact with the system at this point. We suggest closing access to the system through the firewall.
- </para>
-
- </important>
-
- </step>
- <xi:include href="step-select-all-mailboxes.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <step>
- <para>
- Verify annotations have been preserved:
- </para>
- <para>
-
+ </para>
+ <important>
+ <para>
+ Users should not yet be allowed to interact with the system at this point. We suggest closing access to the system through the firewall.
+ </para>
+
+ </important>
+
+ </step>
+ <xi:include href="step-select-all-mailboxes.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <step>
+ <para>
+ Verify annotations have been preserved:
+ </para>
+ <para>
+
<screen># <userinput>kolab -c conf/kolab-kolab2.example.org.conf \</userinput>
> <userinput>list-mailbox-metadata "user/john.doe/Calendar*@example.org"</userinput>
Folder user/john.doe/Calendar at example.org
@@ -159,11 +159,11 @@ Folder user/john.doe/Calendar/Private at example.org
/shared/vendor/cmu/cyrus-imapd/size 305426
/shared/vendor/cmu/cyrus-imapd/sharedseen false</screen>
- </para>
- <para>
- If not, like in the example, use the previously saved <filename>metadata.txt</filename> to restore the annotations:
- </para>
-
+ </para>
+ <para>
+ If not, like in the example, use the previously saved <filename>metadata.txt</filename> to restore the annotations:
+ </para>
+
<programlisting language="Bash">#!/bin/bash
# Interesting Annotations
@@ -203,10 +203,10 @@ cat metadata.txt | \
fi
done</programlisting>
- </step>
+ </step>
+
+ </procedure>
- </procedure>
-
</chapter>
diff --git a/Administrator_Guide/en-US/Upgrading_from_Kolab_2_on_OpenPKG.xml b/Administrator_Guide/en-US/Upgrading_from_Kolab_2_on_OpenPKG.xml
index f1097c4..d518b19 100644
--- a/Administrator_Guide/en-US/Upgrading_from_Kolab_2_on_OpenPKG.xml
+++ b/Administrator_Guide/en-US/Upgrading_from_Kolab_2_on_OpenPKG.xml
@@ -4,169 +4,169 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG">
- <title>Upgrading from Kolab 2 on OpenPKG</title>
- <para>
- As Kolab Groupware used to be distributed as an OpenPKG stack, with different locations for files, the upgrade of a Kolab 2 server to a Kolab 3 server is a largely manual process.
- </para>
- <note>
- <para>
- The Kolab 3 server used here has been set up for the same domain name space as the Kolab 2 server. No users have been created on the Kolab 3 server.
- </para>
-
- </note>
- <para>
- <literal>kolab2.example.org</literal> refers to the Kolab 2 server, <literal>kolab3.example.org</literal> refers to the Kolab 3 server.
- </para>
- <procedure id="proc-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Preparations">
- <title>Preparations</title>
- <step>
- <para>
- During the migration, the Kolab 2 server cannot be allowed to;
- </para>
- <para>
- <orderedlist>
- <listitem>
- <para>
- Receive new email.
- </para>
-
- </listitem>
- <listitem>
- <para>
- Let users post/submit new data.
- </para>
-
- </listitem>
-
- </orderedlist>
-
- </para>
- <para>
- The easiest way to prevent any of this happening is to shut down all Kolab Groupware related services on <literal>kolab2.example.org</literal>:
- </para>
- <para>
-
+ <title>Upgrading from Kolab 2 on OpenPKG</title>
+ <para>
+ As Kolab Groupware used to be distributed as an OpenPKG stack, with different locations for files, the upgrade of a Kolab 2 server to a Kolab 3 server is a largely manual process.
+ </para>
+ <note>
+ <para>
+ The Kolab 3 server used here has been set up for the same domain name space as the Kolab 2 server. No users have been created on the Kolab 3 server.
+ </para>
+
+ </note>
+ <para>
+ <literal>kolab2.example.org</literal> refers to the Kolab 2 server, <literal>kolab3.example.org</literal> refers to the Kolab 3 server.
+ </para>
+ <procedure id="proc-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Preparations">
+ <title>Preparations</title>
+ <step>
+ <para>
+ During the migration, the Kolab 2 server cannot be allowed to;
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Receive new email.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Let users post/submit new data.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <para>
+ The easiest way to prevent any of this happening is to shut down all Kolab Groupware related services on <literal>kolab2.example.org</literal>:
+ </para>
+ <para>
+
<screen># <userinput>/kolab/bin/openpkg rc stop all</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Create a backup of the data from <literal>kolab2.example.org</literal>.
- </para>
-
- </step>
- <step>
- <para>
- Shut down the Cyrus IMAP service on <literal>kolab3.example.org</literal>:
- </para>
- <para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Create a backup of the data from <literal>kolab2.example.org</literal>.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Shut down the Cyrus IMAP service on <literal>kolab3.example.org</literal>:
+ </para>
+ <para>
+
<screen># <userinput>service cyrus-imapd stop</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Shut down the Kolab daemon on <literal>kolab3.example.org</literal>:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Shut down the Kolab daemon on <literal>kolab3.example.org</literal>:
- </para>
- <para>
-
<screen># <userinput>service kolabd stop</userinput></screen>
- </para>
-
- </step>
- <step>
- <para>
- Update the settings related to the recipient policy in <filename>/etc/kolab/kolab.conf</filename>. The following settings are important:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- The <literal>primary_mail</literal> setting in the <literal>[<replaceable>$domain</replaceable>]</literal> section.
- </para>
- <para>
- The policy MUST<footnote> <para>
- the policy enforces consistency in the <literal>mail</literal> attribute values for all users - and therefore mailbox names, and ACL entry subject validity
- </para>
- </footnote> either match the former convention used, if any, or not be enabled at all. See <xref linkend="exam-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Example_Migration_of_example.org" /> for an example and some more gotchas.
- </para>
- <important>
- <para>
- In case the recipient policy is not to be applied, consider updating the <literal>user_types</literal> as per the instructions in <xref linkend="sect-Administrator_Guide-Kolab_Web_Administration_Panel-Editing_user_types" />.
- </para>
-
- </important>
-
- </listitem>
- <listitem>
- <para>
- The <literal>secondary_mail</literal> setting in the <literal>[<replaceable>$domain</replaceable>]</literal> section.
- </para>
- <para>
- This part of the policy does not apply should the <literal>primary_mail</literal> setting already have been disabled.
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </step>
-
- </procedure>
-
- <example id="exam-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Example_Migration_of_example.org">
- <title>Example Migration of example.org</title>
- <para>
- Our first example has had a running Kolab 2.3 on OpenPKG server, with a general email address convention of "surname"@example.org.
- </para>
- <para>
- By default, a Kolab &PRODUCT_VERSION; Groupware server will apply a recipient policy for the <literal>mail</literal> attribute value of "givenname"."surname"@example.org. The recipient policy must therefore be adjusted.
- </para>
- <para>
- In the <literal>[example.org]</literal> section in <filename>/etc/kolab/kolab.conf</filename>, the <literal>primary_mail</literal> setting must be adjusted to match the "surname"@example.org convention:
- </para>
-
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Update the settings related to the recipient policy in <filename>/etc/kolab/kolab.conf</filename>. The following settings are important:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The <literal>primary_mail</literal> setting in the <literal>[<replaceable>$domain</replaceable>]</literal> section.
+ </para>
+ <para>
+ The policy MUST<footnote> <para>
+ the policy enforces consistency in the <literal>mail</literal> attribute values for all users - and therefore mailbox names, and ACL entry subject validity
+ </para>
+ </footnote> either match the former convention used, if any, or not be enabled at all. See <xref linkend="exam-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Example_Migration_of_example.org" /> for an example and some more gotchas.
+ </para>
+ <important>
+ <para>
+ In case the recipient policy is not to be applied, consider updating the <literal>user_types</literal> as per the instructions in <xref linkend="sect-Administrator_Guide-Kolab_Web_Administration_Panel-Editing_user_types" />.
+ </para>
+
+ </important>
+
+ </listitem>
+ <listitem>
+ <para>
+ The <literal>secondary_mail</literal> setting in the <literal>[<replaceable>$domain</replaceable>]</literal> section.
+ </para>
+ <para>
+ This part of the policy does not apply should the <literal>primary_mail</literal> setting already have been disabled.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <example id="exam-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Example_Migration_of_example.org">
+ <title>Example Migration of example.org</title>
+ <para>
+ Our first example has had a running Kolab 2.3 on OpenPKG server, with a general email address convention of "surname"@example.org.
+ </para>
+ <para>
+ By default, a Kolab &PRODUCT_VERSION; Groupware server will apply a recipient policy for the <literal>mail</literal> attribute value of "givenname"."surname"@example.org. The recipient policy must therefore be adjusted.
+ </para>
+ <para>
+ In the <literal>[example.org]</literal> section in <filename>/etc/kolab/kolab.conf</filename>, the <literal>primary_mail</literal> setting must be adjusted to match the "surname"@example.org convention:
+ </para>
+
<programlisting language="INI Files">(...snip...)
[example.org]
primary_mail = %(surname)s@%(domain)s
(...snip...)</programlisting>
- <para>
- Now, users that are created will get a <literal>mail</literal> attribute value of "surname"@example.org assigned.
- </para>
- <para>
- First adding user John Doe will give him a <literal>mail</literal> attribute value of <emphasis>doe at example.org</emphasis>, but should you have a Jane Doe as well, she would get <emphasis>doe2 at example.org</emphasis>. It is therefore important to add users in order.
- </para>
-
- </example>
- <section id="sect-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Migration_of_LDAP">
- <title>Migration of LDAP</title>
- <para>
- This section has not been authored yet.
- </para>
-
- </section>
-
- <section id="sect-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Migration_and_Upgrade_of_Data">
- <title>Migration and Upgrade of Data</title>
- <para>
- The following procedure
- </para>
- <procedure id="proc-Administrator_Guide-Migration_and_Upgrade_of_Data-Migrate_the_Data_Through_Copying">
- <title>Migrate the Data Through Copying</title>
- <step>
- <para>
- Login to <literal>kolab3.example.org</literal> to execute the steps in this procedure.
- </para>
-
- </step>
- <!--
+ <para>
+ Now, users that are created will get a <literal>mail</literal> attribute value of "surname"@example.org assigned.
+ </para>
+ <para>
+ First adding user John Doe will give him a <literal>mail</literal> attribute value of <emphasis>doe at example.org</emphasis>, but should you have a Jane Doe as well, she would get <emphasis>doe2 at example.org</emphasis>. It is therefore important to add users in order.
+ </para>
+
+ </example>
+ <section id="sect-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Migration_of_LDAP">
+ <title>Migration of LDAP</title>
+ <para>
+ This section has not been authored yet.
+ </para>
+
+ </section>
+
+ <section id="sect-Administrator_Guide-Upgrading_from_Kolab_2_on_OpenPKG-Migration_and_Upgrade_of_Data">
+ <title>Migration and Upgrade of Data</title>
+ <para>
+ The following procedure
+ </para>
+ <procedure id="proc-Administrator_Guide-Migration_and_Upgrade_of_Data-Migrate_the_Data_Through_Copying">
+ <title>Migrate the Data Through Copying</title>
+ <step>
+ <para>
+ Login to <literal>kolab3.example.org</literal> to execute the steps in this procedure.
+ </para>
+
+ </step>
+ <!--
It doesn't seem this step causes the annotations.{db,txt} to transfer 1:1
<step>
@@ -181,12 +181,12 @@ primary_mail = %(surname)s@%(domain)s
</para>
</step>
- // --> <step>
- <para>
- Copy mailboxes.db and annotations.db. These files are located in <filename>/kolab/var/imapd/</filename> on your Kolab 2 server.
- </para>
- <para>
-
+ // --> <step>
+ <para>
+ Copy mailboxes.db and annotations.db. These files are located in <filename>/kolab/var/imapd/</filename> on your Kolab 2 server.
+ </para>
+ <para>
+
<screen># <userinput>scp root at kolab2.example.org:/kolab/var/imapd/annotations.db \</userinput>
> <userinput>/var/lib/imap/annotations.db</userinput>
(...)
@@ -194,29 +194,29 @@ primary_mail = %(surname)s@%(domain)s
> <userinput>/var/lib/imap/mailboxes.db</userinput>
(...)</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Migrate the mail spool:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Migrate the mail spool:
- </para>
- <para>
-
<screen># <userinput>rsync -rltpHvz --progress --partial \</userinput>
> <userinput>kolab2.example.org:/var/imapd/spool/ \</userinput>
> <userinput>/var/spool/imap/</userinput>
(...)</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Migrate the seen and subscription databases:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Migrate the seen and subscription databases:
- </para>
- <para>
-
<screen># <userinput>rsync -rltpHvz --progress --partial \</userinput>
> <userinput>kolab2.example.org:/var/imapd/domain/ \</userinput>
> <userinput>/var/lib/imap/domain/</userinput>
@@ -226,70 +226,70 @@ primary_mail = %(surname)s@%(domain)s
> <userinput>/var/lib/imap/user/</userinput>
(...)</screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Ensure the filesystem permissions are correct:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Ensure the filesystem permissions are correct:
- </para>
- <para>
-
<screen># <userinput>chown -R cyrus:mail /var/lib/imap/ /var/spool/imap/</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Ensure only the cyrus user can read and write, and the mail group can read the contents of either directory tree:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Ensure only the cyrus user can read and write, and the mail group can read the contents of either directory tree:
- </para>
- <para>
-
<screen># <userinput>find /var/lib/imap -type f -exec chmod 640 {} \;</userinput>
# <userinput>find /var/lib/imap -type d -exec chmod 750 {} \;</userinput>
# <userinput>find /var/spool/imap -type f -exec chmod 640 {} \;</userinput>
# <userinput>find /var/spool/imap -type d -exec chmod 750 {} \;</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <xi:include href="step-convert-seen-databases.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <step>
+ <para>
+ Stop the Kolab daemon:
+ </para>
+ <para>
- </step>
- <xi:include href="step-convert-seen-databases.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <step>
- <para>
- Stop the Kolab daemon:
- </para>
- <para>
-
<screen># <userinput>service kolabd stop</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Start the Cyrus IMAP service on <literal>kolab3.example.org</literal>:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Start the Cyrus IMAP service on <literal>kolab3.example.org</literal>:
- </para>
- <para>
-
<screen># <userinput>service cyrus-imapd start</userinput></screen>
- </para>
- <important>
- <para>
- Users should not yet be allowed to interact with the system at this point. We suggest closing access to the system through the firewall.
- </para>
-
- </important>
-
- </step>
- <xi:include href="step-select-all-mailboxes.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <step>
- <para>
- The annotations database may not have been upgraded correctly, causing some annotations to miss the first 4 characters of their value. The easiest way to fix the issue, that is known to work, is to get the annotation values as they were on the old (Kolab 2) IMAP server, and set them on the new (Kolab 3) IMAP server.
- </para>
- <para>
-
+ </para>
+ <important>
+ <para>
+ Users should not yet be allowed to interact with the system at this point. We suggest closing access to the system through the firewall.
+ </para>
+
+ </important>
+
+ </step>
+ <xi:include href="step-select-all-mailboxes.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <step>
+ <para>
+ The annotations database may not have been upgraded correctly, causing some annotations to miss the first 4 characters of their value. The easiest way to fix the issue, that is known to work, is to get the annotation values as they were on the old (Kolab 2) IMAP server, and set them on the new (Kolab 3) IMAP server.
+ </para>
+ <para>
+
<screen># <userinput>kolab -c conf/kolab-kolab2.example.org.conf \</userinput>
> <userinput>list-mailbox-metadata "user/john.doe/Calendar*@example.org"</userinput>
Folder user/john.doe/Calendar at example.org
@@ -333,11 +333,11 @@ Folder user/john.doe/Calendar/Private at example.org
/shared/vendor/cmu/cyrus-imapd/size 305426
/shared/vendor/cmu/cyrus-imapd/sharedseen false</screen>
- </para>
- <para>
- Fix'em:
- </para>
-
+ </para>
+ <para>
+ Fix'em:
+ </para>
+
<programlisting language="Bash">#!/bin/bash
# Interesting Annotations
@@ -383,13 +383,13 @@ for folder_search in user/*@example.org shared/*@example.org; do
done</programlisting>
- </step>
- <step>
- <para>
- Upgrade all messages from Kolab Format version 2 to Kolab Format version 3 using <command>kolab-formatupgrade</command>. This command is run in two parts. The first will upgrade all mailbox contents in the personal namespace:
- </para>
- <para>
-
+ </step>
+ <step>
+ <para>
+ Upgrade all messages from Kolab Format version 2 to Kolab Format version 3 using <command>kolab-formatupgrade</command>. This command is run in two parts. The first will upgrade all mailbox contents in the personal namespace:
+ </para>
+ <para>
+
<screen># <userinput>kolab lm "user/%@example.org" | \</userinput>
> <userinput>sed -e 's/user\///g' | \</userinput>
> <userinput>while read user; do</userinput>
@@ -402,15 +402,15 @@ done</programlisting>
> <userinput><replaceable>localhost</replaceable></userinput>
> <userinput>done</userinput></screen>
- </para>
- <para>
- The second part upgrades the contents of shared folders. Shared folders have no designated owners, and we can therefore not login as a designated user to upgrade the format.
- </para>
- <para>
- As the user <literal>cyrus-admin</literal> normally does not have the necessary privileges to insert new messages into mail folders, so we're going to have to give out the rights first. We'll delete them again afterwards.
- </para>
- <para>
-
+ </para>
+ <para>
+ The second part upgrades the contents of shared folders. Shared folders have no designated owners, and we can therefore not login as a designated user to upgrade the format.
+ </para>
+ <para>
+ As the user <literal>cyrus-admin</literal> normally does not have the necessary privileges to insert new messages into mail folders, so we're going to have to give out the rights first. We'll delete them again afterwards.
+ </para>
+ <para>
+
<screen># <userinput>kolab sam shared/*@example.org cyrus-admin lrswiptexa</userinput>
# <userinput>kolab lm shared/*@example.org | \</userinput>
> <userinput>while read folder; do</userinput>
@@ -424,15 +424,15 @@ done</programlisting>
> <userinput>done</userinput>
# <userinput>kolab dam shared/*@example.org cyrus-admin</userinput></screen>
- </para>
+ </para>
+
+ </step>
+
+ </procedure>
- </step>
- </procedure>
-
+ </section>
- </section>
-
</chapter>
diff --git a/Administrator_Guide/en-US/Verifying_the_Installation.xml b/Administrator_Guide/en-US/Verifying_the_Installation.xml
index c254cc3..c53e3fd 100644
--- a/Administrator_Guide/en-US/Verifying_the_Installation.xml
+++ b/Administrator_Guide/en-US/Verifying_the_Installation.xml
@@ -4,353 +4,353 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-Verifying_the_Installation">
- <title>Verifying the Installation</title>
- <para>
- This chapter concerns verifying the Kolab Groupware installation works as expected, to the limited realm this documentation can serve. If you have modified the Kolab Groupware deployment to match your needs, some of the following verification steps may not function as expected.
- </para>
- <section id="sect-Administrator_Guide-Verifying_the_Installation-Running_Services">
- <title>Running Services</title>
- <para>
- Verify the following services are running:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <formalpara id="form-Administrator_Guide-Running_Services-a389_Directory_Server">
- <title>389 Directory Server</title>
- <para>
- The LDAP server is crucial to authentication, authorization, user and group information and mail routing, and must be running.
- </para>
-
- </formalpara>
- <procedure>
- <step>
- <para>
- Verify the service is running:
- </para>
- <para>
-
+ <title>Verifying the Installation</title>
+ <para>
+ This chapter concerns verifying the Kolab Groupware installation works as expected, to the limited realm this documentation can serve. If you have modified the Kolab Groupware deployment to match your needs, some of the following verification steps may not function as expected.
+ </para>
+ <section id="sect-Administrator_Guide-Verifying_the_Installation-Running_Services">
+ <title>Running Services</title>
+ <para>
+ Verify the following services are running:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Running_Services-a389_Directory_Server">
+ <title>389 Directory Server</title>
+ <para>
+ The LDAP server is crucial to authentication, authorization, user and group information and mail routing, and must be running.
+ </para>
+
+ </formalpara>
+ <procedure>
+ <step>
+ <para>
+ Verify the service is running:
+ </para>
+ <para>
+
<screen># <userinput>service dirsrv status</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Verify the service is listening on the expected port(s):
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Verify the service is listening on the expected port(s):
- </para>
- <para>
-
<screen># <userinput>netstat -ltnp | grep -E ":(389|636)"</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Verify the firewall allows access to those ports, if the <literal>iptables</literal> service is running:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Verify the firewall allows access to those ports, if the <literal>iptables</literal> service is running:
- </para>
- <para>
-
<screen># <userinput>service iptables status</userinput>
# <userinput>iptables -L INPUT -n -v | grep -E "dpt:(389|636)" | grep ACCEPT</userinput></screen>
- </para>
- <note>
- <para>
- Kolab Groupware does not configure your firewall for you. You may have decided to work your firewall yourself, in which case the former commands may not include any ouput.
- </para>
-
- </note>
-
- </step>
- <step>
- <para>
- Perform a search:
- </para>
- <para>
-
+ </para>
+ <note>
+ <para>
+ Kolab Groupware does not configure your firewall for you. You may have decided to work your firewall yourself, in which case the former commands may not include any ouput.
+ </para>
+
+ </note>
+
+ </step>
+ <step>
+ <para>
+ Perform a search:
+ </para>
+ <para>
+
<screen># <userinput>ldapsearch -x -h localhost -D "${binddn}" -w "${bindpw}" -b "${basedn}"</userinput></screen>
- </para>
-
- </step>
-
- </procedure>
-
- <para>
- Log files for 389 Directory Server are located in <filename>/var/log/dirsrv/slapd-*/</filename>.
- </para>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Running_Services-Kolab_SASL_Authentication_Daemon">
- <title>Kolab SASL Authentication Daemon</title>
- <para>
- The Kolab SASL authentication daemon is used by Postfix and Cyrus IMAP, to authenticate users.
- </para>
-
- </formalpara>
- <procedure>
- <step>
- <para>
- Verify the service is running:
- </para>
- <para>
-
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <para>
+ Log files for 389 Directory Server are located in <filename>/var/log/dirsrv/slapd-*/</filename>.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Running_Services-Kolab_SASL_Authentication_Daemon">
+ <title>Kolab SASL Authentication Daemon</title>
+ <para>
+ The Kolab SASL authentication daemon is used by Postfix and Cyrus IMAP, to authenticate users.
+ </para>
+
+ </formalpara>
+ <procedure>
+ <step>
+ <para>
+ Verify the service is running:
+ </para>
+ <para>
+
<screen># <userinput>service kolab-saslauthd status</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Make some attempts to authenticate:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Make some attempts to authenticate:
- </para>
- <para>
-
<screen># <userinput>testsaslauthd -u <replaceable>cyrus-admin</replaceable> -p <replaceable>$password</replaceable></userinput>
# <userinput>testsaslauthd -u <replaceable>john.doe at example.org</replaceable> -p <replaceable>$password</replaceable></userinput>
# <userinput>testsaslauthd -u <replaceable>doe</replaceable> -p <replaceable>$password</replaceable></userinput>
# <userinput>testsaslauthd -u <replaceable>doe</replaceable> -r <replaceable>example.org</replaceable> -p <replaceable>$password</replaceable></userinput></screen>
- </para>
-
- </step>
-
- </procedure>
-
- <para>
- The log file for the Kolab SASL authentication daemon is <filename>/var/log/kolab/pykolab.log</filename>.
- </para>
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Running_Services-Cyrus_IMAP">
- <title>Cyrus IMAP</title>
- <para>
- Essential for access to all email and other groupware data.
- </para>
-
- </formalpara>
- <procedure>
- <step>
- <para>
- Verify the service is running:
- </para>
- <para>
-
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <para>
+ The log file for the Kolab SASL authentication daemon is <filename>/var/log/kolab/pykolab.log</filename>.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Running_Services-Cyrus_IMAP">
+ <title>Cyrus IMAP</title>
+ <para>
+ Essential for access to all email and other groupware data.
+ </para>
+
+ </formalpara>
+ <procedure>
+ <step>
+ <para>
+ Verify the service is running:
+ </para>
+ <para>
+
<screen># <userinput>service cyrus-imapd status</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Verify the service is listening on the expected port(s):
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Verify the service is listening on the expected port(s):
- </para>
- <para>
-
<screen># <userinput>netstat -tlnp | grep -E ":(143|993)"</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Verify the firewall allows access to those ports, if the <literal>iptables</literal> service is running:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Verify the firewall allows access to those ports, if the <literal>iptables</literal> service is running:
- </para>
- <para>
-
<screen># <userinput>service iptables status</userinput>
# <userinput>iptables -L INPUT -n -v | grep -E "dpt:(143|993)" | grep ACCEPT</userinput></screen>
- </para>
- <note>
- <para>
- Kolab Groupware does not configure your firewall for you. You may have decided to work your firewall yourself, in which case the former commands may not include any ouput.
- </para>
-
- </note>
-
- </step>
- <step>
- <para>
- Attempt to connect and authenticate:
- </para>
- <para>
-
+ </para>
+ <note>
+ <para>
+ Kolab Groupware does not configure your firewall for you. You may have decided to work your firewall yourself, in which case the former commands may not include any ouput.
+ </para>
+
+ </note>
+
+ </step>
+ <step>
+ <para>
+ Attempt to connect and authenticate:
+ </para>
+ <para>
+
<screen># <userinput>imtest -t "" -u <replaceable>john.doe at example.org</replaceable> -w <replaceable>$password</replaceable> localhost</userinput>
# <userinput>imtest -t "" -u <replaceable>doe</replaceable> -w <replaceable>$password</replaceable> localhost</userinput></screen>
- </para>
-
- </step>
-
- </procedure>
-
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Running_Services-Apache_Webserver">
- <title>Apache Webserver</title>
- <para>
- The Apache webserver is needed for the Kolab Web Client, Administration Panel and the exchange of Free/Busy information.
- </para>
-
- </formalpara>
- <procedure id="proc-Administrator_Guide-Running_Services-Verifying_the_Apache_Webserver_Service_is_Running">
- <title>Verifying the Apache Webserver Service is Running</title>
- <step>
- <para>
- Verify the service is running:
- </para>
- <para>
-
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Running_Services-Apache_Webserver">
+ <title>Apache Webserver</title>
+ <para>
+ The Apache webserver is needed for the Kolab Web Client, Administration Panel and the exchange of Free/Busy information.
+ </para>
+
+ </formalpara>
+ <procedure id="proc-Administrator_Guide-Running_Services-Verifying_the_Apache_Webserver_Service_is_Running">
+ <title>Verifying the Apache Webserver Service is Running</title>
+ <step>
+ <para>
+ Verify the service is running:
+ </para>
+ <para>
+
<screen># <userinput>service httpd status</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Verify the service is listening on the correct ports:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Verify the service is listening on the correct ports:
- </para>
- <para>
-
<screen># <userinput>netstat -ltnp | grep -E ":(80|443)"</userinput></screen>
- </para>
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Verify the firewall allows access to those ports, if the <literal>iptables</literal> service is running:
+ </para>
+ <para>
- </step>
- <step>
- <para>
- Verify the firewall allows access to those ports, if the <literal>iptables</literal> service is running:
- </para>
- <para>
-
<screen># <userinput>service iptables status</userinput>
# <userinput>iptables -L INPUT -n -v | grep -E "dpt:(80|443)" | grep ACCEPT</userinput></screen>
- </para>
- <note>
- <para>
- Kolab Groupware does not configure your firewall for you. You may have decided to work your firewall yourself, in which case the former commands may not include any ouput.
- </para>
-
- </note>
-
- </step>
- <step>
- <para>
- Attempt to get a few pages:
- </para>
- <para>
-
+ </para>
+ <note>
+ <para>
+ Kolab Groupware does not configure your firewall for you. You may have decided to work your firewall yourself, in which case the former commands may not include any ouput.
+ </para>
+
+ </note>
+
+ </step>
+ <step>
+ <para>
+ Attempt to get a few pages:
+ </para>
+ <para>
+
<screen># <userinput>wget -O- http://localhost</userinput>
# <userinput>wget -O- https://localhost</userinput></screen>
- </para>
- <note>
- <para>
- Kolab Groupware does not, by default, configure the webserver to also listen on HTTPS port 443.
- </para>
-
- </note>
-
- </step>
-
- </procedure>
-
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Running_Services-MySQL">
- <title>MySQL</title>
- <para>
- para
- </para>
-
- </formalpara>
- <procedure>
- <step>
- <para>
- para
- </para>
-
- </step>
-
- </procedure>
-
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Running_Services-Kolab_Web_Administration_Panel">
- <title>Kolab Web Administration Panel</title>
- <para>
- para
- </para>
-
- </formalpara>
- <procedure>
- <step>
- <para>
- para
- </para>
-
- </step>
-
- </procedure>
-
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Running_Services-Roundcube_Webmail">
- <title>Roundcube Webmail</title>
- <para>
- para
- </para>
-
- </formalpara>
- <procedure>
- <step>
- <para>
- para
- </para>
-
- </step>
-
- </procedure>
-
-
- </listitem>
- <listitem>
- <formalpara id="form-Administrator_Guide-Running_Services-The_Kolab_Daemon">
- <title>The Kolab Daemon</title>
- <para>
- para
- </para>
-
- </formalpara>
- <procedure>
- <step>
- <para>
- para
- </para>
-
- </step>
-
- </procedure>
-
-
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </section>
-
+ </para>
+ <note>
+ <para>
+ Kolab Groupware does not, by default, configure the webserver to also listen on HTTPS port 443.
+ </para>
+
+ </note>
+
+ </step>
+
+ </procedure>
+
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Running_Services-MySQL">
+ <title>MySQL</title>
+ <para>
+ para
+ </para>
+
+ </formalpara>
+ <procedure>
+ <step>
+ <para>
+ para
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Running_Services-Kolab_Web_Administration_Panel">
+ <title>Kolab Web Administration Panel</title>
+ <para>
+ para
+ </para>
+
+ </formalpara>
+ <procedure>
+ <step>
+ <para>
+ para
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Running_Services-Roundcube_Webmail">
+ <title>Roundcube Webmail</title>
+ <para>
+ para
+ </para>
+
+ </formalpara>
+ <procedure>
+ <step>
+ <para>
+ para
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Administrator_Guide-Running_Services-The_Kolab_Daemon">
+ <title>The Kolab Daemon</title>
+ <para>
+ para
+ </para>
+
+ </formalpara>
+ <procedure>
+ <step>
+ <para>
+ para
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
</chapter>
diff --git a/Administrator_Guide/en-US/chap-About_Kolab_Groupware.xml b/Administrator_Guide/en-US/chap-About_Kolab_Groupware.xml
index eb8a22f..39c850a 100644
--- a/Administrator_Guide/en-US/chap-About_Kolab_Groupware.xml
+++ b/Administrator_Guide/en-US/chap-About_Kolab_Groupware.xml
@@ -4,27 +4,27 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Administrator_Guide-About_Kolab_Groupware">
- <title>About Kolab Groupware</title>
- <para>
- Kolab is a Groupware Solution for Emails, Appointments, Contacts and more. It supports mixed client environments (Outlook/KDE) because of an open storage format. Any email client speaking standard protocols can be served.
- </para>
- <section id="sect-Administrator_Guide-About_Kolab_Groupware-Free_Software_Components">
- <title>Free Software Components</title>
- <para>
- TODO: Come on, be a little more verbose...
- </para>
- <section id="sect-Administrator_Guide-Free_Software_Components-This_documentation">
- <title>This documentation</title>
- <para>
- Describe how this documentation can be modified to custom, internal documentation
- </para>
+ <title>About Kolab Groupware</title>
+ <para>
+ Kolab is a Groupware Solution for Emails, Appointments, Contacts and more. It supports mixed client environments (Outlook/KDE) because of an open storage format. Any email client speaking standard protocols can be served.
+ </para>
+ <section id="sect-Administrator_Guide-About_Kolab_Groupware-Free_Software_Components">
+ <title>Free Software Components</title>
+ <para>
+ TODO: Come on, be a little more verbose...
+ </para>
+ <section id="sect-Administrator_Guide-Free_Software_Components-This_documentation">
+ <title>This documentation</title>
+ <para>
+ Describe how this documentation can be modified to custom, internal documentation
+ </para>
- </section>
-
+ </section>
- </section>
-
- <xi:include href="sect-Supported_Platforms_and_System_Requirements.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+
+ </section>
+
+ <xi:include href="sect-Supported_Platforms_and_System_Requirements.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</chapter>
diff --git a/Administrator_Guide/en-US/part-Clients.xml b/Administrator_Guide/en-US/part-Clients.xml
index 5d391cb..cabfdf5 100644
--- a/Administrator_Guide/en-US/part-Clients.xml
+++ b/Administrator_Guide/en-US/part-Clients.xml
@@ -4,9 +4,9 @@
%BOOK_ENTITIES;
]>
<part id="part-Administrator_Guide-Kolab_Groupware_Clients">
- <title>Kolab Groupware Clients</title>
- <xi:include href="Kontact.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Thunderbird.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Outlook.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <title>Kolab Groupware Clients</title>
+ <xi:include href="Kontact.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Thunderbird.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Outlook.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</part>
diff --git a/Administrator_Guide/en-US/part-Kolab_Server.xml b/Administrator_Guide/en-US/part-Kolab_Server.xml
index ff348ca..4435f64 100755
--- a/Administrator_Guide/en-US/part-Kolab_Server.xml
+++ b/Administrator_Guide/en-US/part-Kolab_Server.xml
@@ -4,19 +4,20 @@
%BOOK_ENTITIES;
]>
<part id="part-Administrator_Guide-Kolab_Groupware_Server">
- <title>Kolab Groupware Server</title>
- <xi:include href="Upgrading_from_Kolab_2_on_OpenPKG.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <!--
+ <title>Kolab Groupware Server</title>
+ <xi:include href="Upgrading_from_Kolab_2_on_OpenPKG.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <!--
<xi:include href="Upgrading_Accounts_from_Kolab_Format_version_2.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Upgrading_Cyrus_IMAP_from_2.3_to_2.4.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- // --> <xi:include href="Verifying_the_Installation.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Configuring_the_Kolab_Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Detailed_Kolab_Server_Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Kolab_Web_Administration_Panel.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Combating_Spam.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Tweaking_Tips_for_389_Directory_Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Tweaking_Tips_for_Cyrus_IMAP.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Tweaking_Tips_for_Postfix.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Tweaking_Tips_for_Roundcube.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ // --> <xi:include href="Verifying_the_Installation.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Configuring_the_Kolab_Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Detailed_Kolab_Server_Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Kolab_Web_Administration_Panel.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Combating_Spam.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Tweaking_Tips_for_389_Directory_Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Tweaking_Tips_for_Cyrus_IMAP.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Tweaking_Tips_for_Postfix.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Tweaking_Tips_for_Roundcube.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Hosted_Kolab_Groupware_Setup.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</part>
diff --git a/Administrator_Guide/en-US/sect-Kolab_Recipient_Policy_and_Web_Administration_Panel.xml b/Administrator_Guide/en-US/sect-Kolab_Recipient_Policy_and_Web_Administration_Panel.xml
index d63d034..ff19e9d 100644
--- a/Administrator_Guide/en-US/sect-Kolab_Recipient_Policy_and_Web_Administration_Panel.xml
+++ b/Administrator_Guide/en-US/sect-Kolab_Recipient_Policy_and_Web_Administration_Panel.xml
@@ -292,7 +292,7 @@ print secondary_mail</screen>
<section id="sect-Administrator_Guide-Kolab_Recipient_Policy_and_Web_Administration_Panel-Controlling_the_Primary_and_Secondary_Recipient_Email_Address_Attributes">
<title>Controlling the Primary and Secondary Recipient Email Address Attributes</title>
<para>
- The attribute names that contain the primary and secondary recipient email addresses are controlled by the <literal>mail_attrs</literal> setting in the <literal>[<replaceable>$domain</replaceable>]</literal> section of <filename>/etc/kolab/kolab.conf</filename>. Should no such section or setting exist, the fallback in the <literal>[<replaceable>$auth_mechanism</replaceable>]</literal> section is used, where <literal>$auth_mechanism</title> is the authentication mechanism configured using the <literal>auth_mechanism</literal> setting in the <literal>[kolab]</literal> section – note that only 'ldap' is currently supported as an authentication mechanism.
+ The attribute names that contain the primary and secondary recipient email addresses are controlled by the <literal>mail_attrs</literal> setting in the <literal>[<replaceable>$domain</replaceable>]</literal> section of <filename>/etc/kolab/kolab.conf</filename>. Should no such section or setting exist, the fallback in the <literal>[<replaceable>$auth_mechanism</replaceable>]</literal> section is used, where <literal>$auth_mechanism</literal> is the authentication mechanism configured using the <literal>auth_mechanism</literal> setting in the <literal>[kolab]</literal> section – note that only 'ldap' is currently supported as an authentication mechanism.
</para>
<para>
This setting is a comma- and/or comma-space separated list of attribute names. By default, <literal>mail_attrs</literal> is set to <literal>mail, alias</literal>.
More information about the commits
mailing list