2 commits - Administrator_Guide/en-US Administrator_Guide/Makefile Installation_Guide/en-US
Jeroen van Meeuwen
vanmeeuwen at kolabsys.com
Fri Dec 16 13:59:40 CET 2011
Administrator_Guide/Makefile | 3
Administrator_Guide/en-US/Administrator_Guide.xml | 2
Administrator_Guide/en-US/Combating_Spam.xml | 528 +++++++++++++++++
Administrator_Guide/en-US/Combatting_Spam.xml | 54 -
Administrator_Guide/en-US/part-Kolab_Server.xml | 2
Installation_Guide/en-US/Kolab_Server_Installation.xml | 7
6 files changed, 539 insertions(+), 57 deletions(-)
New commits:
commit 258b4f46c235676d2237630c02304f04d3d1d867
Author: Jeroen van Meeuwen (Kolab Systems) <vanmeeuwen at kolabsys.com>
Date: Fri Dec 16 12:58:45 2011 +0000
Update administrator guide
diff --git a/Administrator_Guide/Makefile b/Administrator_Guide/Makefile
index a86b675..6143644 100644
--- a/Administrator_Guide/Makefile
+++ b/Administrator_Guide/Makefile
@@ -20,3 +20,6 @@ clean_ids:
-e 's/((\s{4})+)\s*/\1/g' \
-e 's/\s*$$//g' \
`find en-US/ -type f -name "*.xml"`
+
+pdf: clean clean_ids
+ @publican build --embedtoc --publish --langs=all --formats=pdf
diff --git a/Administrator_Guide/en-US/Administrator_Guide.xml b/Administrator_Guide/en-US/Administrator_Guide.xml
index cec1fe3..6fe4f69 100644
--- a/Administrator_Guide/en-US/Administrator_Guide.xml
+++ b/Administrator_Guide/en-US/Administrator_Guide.xml
@@ -7,7 +7,7 @@
<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" />
+ <!-- <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/Combating_Spam.xml b/Administrator_Guide/en-US/Combating_Spam.xml
new file mode 100644
index 0000000..f984a54
--- /dev/null
+++ b/Administrator_Guide/en-US/Combating_Spam.xml
@@ -0,0 +1,528 @@
+<?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-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 for 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 they 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>
+
+ </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>
+
+<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>
+
+ </step>
+ <step>
+ <para>
+ Extract the archives:
+ </para>
+ <para>
+
+<screen># for archive in `ls -1 *.tar.bz2`; do tar jxf $archive; done</screen>
+
+ </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>
+
+<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>
+
+<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-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>
+
+<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>
+
+<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>
+
+<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;"
+# 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>
+
+<screen># mysql -e 'FLUSH PRIVILEGES;'</screen>
+
+ </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>
+
+ </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>
+
+<screen># sa-learn --backup > <filename>/path/to/sa_backup.txt</filename></screen>
+
+ </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>
+
+ </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>
+bayes_sql_username <emphasis>kolab_bayes</emphasis><footnote> <para>
+ Replace with the username for database access
+ </para>
+ </footnote>
+bayes_sql_password <emphasis>Welcome2KolabSystems</emphasis><footnote> <para>
+ Replace with the user password
+ </para>
+ </footnote>
+bayes_sql_override_username root</screen>
+
+ </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>
+
+<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>
+ 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>
+
+ </section>
+
+
+</chapter>
+
diff --git a/Administrator_Guide/en-US/Combatting_Spam.xml b/Administrator_Guide/en-US/Combatting_Spam.xml
deleted file mode 100644
index 74c1c10..0000000
--- a/Administrator_Guide/en-US/Combatting_Spam.xml
+++ /dev/null
@@ -1,54 +0,0 @@
-<?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-Combatting_Spam">
- <title>Combatting Spam</title>
- <para>
- Kolab Groupware comes with SpamAssassin by default.
- </para>
- <para>
- Learning spam
- </para>
- <para>
- Optionally, find all folders named "Spam" or "Junk":
- </para>
- <para>
-
-<screen>$ <userinput>find /path/to/spool -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>
-
- </note>
- <remark> We would like to do the very same through IMAP, with annotations / SPECIAL-USE. </remark>
- <para>
-
-<screen>$ <userinput>sa-learn --dbpath /var/lib/amavisd/.spamassassin --spam /path/to/folder/[0-9]*.</userinput></screen>
-
- </para>
- <section id="sect-Administrator_Guide-Combatting_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.
- </para>
- <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>
-
-
-</chapter>
-
diff --git a/Administrator_Guide/en-US/part-Kolab_Server.xml b/Administrator_Guide/en-US/part-Kolab_Server.xml
index c4b7925..a92ed4f 100755
--- a/Administrator_Guide/en-US/part-Kolab_Server.xml
+++ b/Administrator_Guide/en-US/part-Kolab_Server.xml
@@ -8,6 +8,6 @@
<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="Combatting_Spam.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Combating_Spam.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</part>
commit 2c72c3600e0f14abe239f3e91b629ddd94bc2356
Author: Jeroen van Meeuwen (Kolab Systems) <vanmeeuwen at kolabsys.com>
Date: Fri Dec 16 12:57:52 2011 +0000
Update Kolab Server Installation instructions letting readers know yum-priorities is only required for Enterprise Linux releases prior to Enterprise Linux 6
diff --git a/Installation_Guide/en-US/Kolab_Server_Installation.xml b/Installation_Guide/en-US/Kolab_Server_Installation.xml
index 1a46920..9fd0236 100755
--- a/Installation_Guide/en-US/Kolab_Server_Installation.xml
+++ b/Installation_Guide/en-US/Kolab_Server_Installation.xml
@@ -562,7 +562,7 @@ kolab-&PRODUCT_VERSION;-updates-testing-source
</procedure>
<para>
- Please consider using <application>yum-priorities</application> as described in <xref linkend="sect-Community_Installation_Guide-Prerequisites-Using_yum_priorities_to_Avoid_Package_Conflicts" />.
+ Please consider using <application>yum-priorities</application> as described in <xref linkend="sect-Community_Installation_Guide-Prerequisites-Using_yum_priorities_to_Avoid_Package_Conflicts" />. This is necessary for Enterprise Linux releases prior to Enterprise Linux 6 only.
</para>
</section>
@@ -572,6 +572,11 @@ kolab-&PRODUCT_VERSION;-updates-testing-source
<para>
Since any given package may, at any time, be or become available to the system through both the Kolab repositories as well as through the regular distribution repositories, to avoid the risk of switching back and forth between the two different versions continuously, by mistake or by accident, we recommend you use the following procedure including employing YUM repository priorities to eliminate the risk of running in such problems in the future.
</para>
+ <note>
+ <para>
+ This is necessary only for Enterprise Linux 5.
+ </para>
+ </note>
<procedure id="proc-Community_Installation_Guide-Using_yum_priorities_to_Avoid_Package_Conflicts-Installing_and_Configuring_YUM_priorities">
<title>Installing and Configuring YUM priorities</title>
<step>
More information about the commits
mailing list