1. Allgemeine Betriebsdokumentation
für
Kolab Server 2.2
Version: 1.0
Osnabrück, am 3. Januar 2008

2. Änderungsverzeichnis
Geänderte
Änderung Beschreibung der Änderung Autor
Kapitel
Nr Datum Version
1 2008-01-03 1.0 Emanuel Schütze
Aktueller Status: Fertig gestellt
Impressum
© 2007 Intevation GmbH
Version: 1.0
Autor: Emanuel Schütze
Fachliche Leitung: Bernhard Reiter, Thomas Arendsen Hein
Kontakt: emanuel.schuetze@intevation.de | http://intevation.org
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation
License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front­
Cover Texts, and no Back­Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation
License".
Diese Kolab Server Betriebsdokumentation ist unter http://kolab.org erhältlich.
2

3. Inhaltsverzeichnis
Kapitel 1: Einführung 5
1.1 Was ist Kolab?.................................................................................6
1.2 Entwicklungshistorie von Kolab................................................................7
1.3 Was ist neu in Kolab Server 2.2?...............................................................8
Kapitel 2: Die Komponenten des Kolab Servers 9
2.1 Übersicht.......................................................................................9
2.2 Interaktion der Komponenten.................................................................11
2.3 OpenPKG.....................................................................................12
2.4 Kolabspezifische Komponenten...............................................................13
Kapitel 3: Kolab Server – Bedarfsplanung 17
3.1 Festplattenspeicher............................................................................17
3.2 Rechenleistung / Hauptspeicher...............................................................18
3.3 Verfügbarkeit.................................................................................18
3.4 Wer arbeitet mit wem?........................................................................19
Kapitel 4: Kolab Server – Vorbereitung und Installation 20
4.1 Installationsvorbereitung......................................................................20
4.2 Installation....................................................................................22
4.3 Aktualisierung................................................................................25
4.4 Deinstallation.................................................................................27
Kapitel 5: Kolab Server – Konfiguration und Betrieb 28
5.1 Kolab Web-Admin............................................................................28
5.2 Rollen.........................................................................................29
5.2.1 Administrator..........................................................................30
5.2.2 Verwalter..............................................................................30
5.2.3 Domänenverwalter.....................................................................30
5.2.4 Benutzer...............................................................................31
5.3 Kontotypen...................................................................................33
5.4 Nutzerlebenszyklus...........................................................................34
5.5 E-Mail........................................................................................36
5.5.1 Die IMAP Spool Struktur..............................................................36
5.5.2 Der Weg einer E-Mail..................................................................36
5.5.3 Weiterleitung...........................................................................39
5.5.4 Abwesenheitsbenachrichtigung........................................................39
5.5.5 Serverseitige Filterung mit Sieve.......................................................40
5.5.6 E-Mail-Vertreter.......................................................................41
5.5.7 Verteilerlisten..........................................................................42
3

4. 5.5.8 Virenfilter-Konfiguration..............................................................43
5.5.9 Spamfilter-Konfiguration..............................................................45
5.5.10 E-Mail-Domänen.....................................................................47
5.5.11 Administrative E-Mail-Adressen......................................................47
5.5.12 Sicherheitseinstellungen..............................................................48
5.6 Adressbuch...................................................................................51
5.7 Kalender......................................................................................52
5.7.1 Einladungen...........................................................................52
5.7.2 Frei/Belegt-Listen......................................................................53
5.8 Notizen.......................................................................................54
5.9 Aufgaben.....................................................................................54
5.10 Gemeinsames Nutzen von IMAP-Ordnern....................................................55
5.10.1 Freigegebene Benutzerordner.........................................................55
5.10.2 Gemeinsam genutzte IMAP-Ordner ohne Konto......................................56
5.11 Quotas........................................................................................57
5.12 Master- und Slaveserver / Homeserver........................................................58
5.13 Datensicherung und -wiederherstellung.......................................................59
5.14 Dienste........................................................................................63
Kapitel 6: Kolab­Klienten 64
6.1 KDE Kontact..................................................................................64
6.2 Microsoft Outlook............................................................................64
6.2.1 Toltec Connector.......................................................................64
6.2.2 Konsec Konnektor.....................................................................65
6.3 Horde Webklient..............................................................................65
Anhang 66
Anhang A: Weiterführende Informationen 67
A.1 Die Kolab-Gemeinschaft......................................................................69
A.2 Das Kolab-Konsortium.......................................................................70
Anhang B: Glossar 71
Anhang C: GNU Free Documentation License 74
4

5. 1 Einführung
Kolab ist eine Freie Lösung, die Groupware-Funktionalitäten bietet. Kolab spe-
zifiziert ein Verhalten von Server und Klienten, welches als Freie Software in
dem Kolab Server, dem Kolab KDE Klienten Kontact und dem Horde Webklien-
ten implementiert ist. Das Konzept von Kolab, basierend auf offenen Standards,
gestattet die Entwicklung von Kolab-Servern und -Klienten durch Drittanbieter.
Als Groupware bezeichnet man eine Software, die für die Zusammenarbeit
innerhalb einer Arbeitsgruppe konzipiert ist und die Arbeitsabläufe rationalisie-
ren und automatisieren soll. In der Regel besteht Groupware aus Anwendungen,
die typische Organizer-Funktionen (wie Kalender, Kontakte, Aufgaben, Notizen)
sowie Funktionen für den Austausch von E-Mails und die gemeinsame Bearbei-
tung von Dateien bereitstellen.
Die vorliegende Betriebsdokumentation konzentriert sich auf den Kolab Server und unterstützt beim
Aufsetzen und Betreiben eines solchen Groupware-Servers.
Diese Dokumentation richtet sich an Systemadministratoren, die Server-Anwendungen betreuen. Kennt-
nisse über den Kolab Server werden nicht vorausgesetzt. Grundlegende Erfahrungen mit Server-Anwen-
dungen sind jedoch erforderlich; wünschenswert auf GNU/Linux. Zu diesen Themen gibt es bereits zahl-
reiche Literatur.
Ziel dieser Arbeit ist es, einen Überblick über den Kolab Server zu geben und die Fähigkeiten für War-
tung und Betrieb zu vermitteln. Es existieren sehr vielfältige Möglichkeiten und Einsatzszenarien den
Kolab Server zu nutzen, die anhand einiger konkreter Beispiele dargestellt werden. Auf die dabei getrof-
fenen Annahmen wird jeweils hingewiesen.
5

6. 1 Einführung
Diese Betriebsdokumentation bezieht sich auf die OpenPKG-Variante von Kolab Server 2.2 (vgl.
Abschnitt 2.3). Da Version 2.2.0 zum Recherchezeitpunkt noch nicht erschienen ist, wurde Kolab Server
2.2-beta2 genutzt.
Gliederung
➔ Kapitel 1 und 2 geben einen allgemeinen Überblick über den Kolab Server und dessen Kompo-
nenten.
➔ Im 3. Kapitel wird anhand von grundsätzlichen Leitfragen die Bedarfsplanung für den Einsatz
eines Kolab-Servers erarbeitet.
➔ Hinweise zur Installation sowie praktische Anleitungen zur Installation, zum Update und zur
Deinstallation des Kolab Servers werden im Kapitel 4 gegeben.
➔ Das Kapitel 5 Kolab Server – Konfiguration und Betrieb beschreibt ausführlich die wichtigsten
Einstellmöglichkeiten am Kolab Server und gibt praktische Hinweise für die eigene Konfigura-
tion.
➔ Einen allgemeiner Überblick über die verfügbaren Kolab-Klienten stellt Kapitel 6 dar.
➔ Weiterführende Quellen mit Kontaktmöglichkeiten zur Kolab-Gemeinschaft und dem Kolab-
Konsortium sowie ein Glossar sind im Anhang A und B zu finden.
Konventionen
Der leichten Lesbarkeit wegen wird oft nur eine Form verwendet – meist die männliche – gemeint sind
bei Personen jedoch immer Männer und Frauen, wie bei „Nutzern“ und „Nutzerinnen“.
Das Produkt „Kolab Server“ wird in dieser Dokumentation stets ohne Bindestrich geschrieben.
Handelt es sich um eine beliebige Implementation oder eine spezielle Installation des Produkts „Kolab
Server“, so wird „Kolab-Server“ mit Bindestrich verwendet.
1.1 Was ist Kolab?
Kolab ist in erster Linie ein Konzept, wie mit Freier Software eine skalierbare, stabile und sichere
Groupware-Lösung umgesetzt werden kann. In dieser Idee unterscheidet sich Kolab bereits von vielen
anderen Produkten, welche Kommunikation und Arbeitsgruppen unterstützen möchten. Ein Nutzen von
Kolab entsteht aus der Kombination mehrerer Softwarekomponenten. Für Anwender ist allein der Nut-
zen entscheidend. Als Administrator ist es jedoch nützlich die Zusammenhänge zu kennen; sie sind für
einen täglichen Betrieb zwar nicht direkt erforderlich, erlauben aber oft, den Nutzen der Lösung für alle
Beteiligten zu erhöhen.
Bei Kolab entsteht der Nutzen im Zusammenspiel von Klient und Kolab-Server. Es werden Groupware-
Funktionen zum Austauschen von E-Mails, Freigeben und Bearbeiten von Dateien sowie Verwalten von
Kontakten, Terminen, Aufgaben und Notizen auf Basis offener Standards geboten. Nachfolgend einige
wesentliche Eigenschaften des Kolab Servers:
6

7. 1 Einführung
➔ Nutzerdaten werden in Ordnern auf dem Server gespeichert.
➔ Ein Ordner enthält Objekte eines Typs: Kontakte, Termine, Aufgaben, Notizen oder E-Mails.
➔ Jeder Nutzer verwaltet seine Ordner und kann diese anderen Nutzern freigeben.
➔ Nutzung von Abwesenheitsbenachrichtigung, E-Mail-Weiterleitung und -Vertretern.
➔ Frei-/Belegt-Listen unterstützen die Terminfindung.
➔ Einladungen können automatisch bearbeitet werden.
➔ Verschiedene Verzeichnisdienste können genutzt werden.
➔ Unterstützt IMAP, POP3, SMTP (optional verschlüsselt); damit für jeden Mail-Klient geeignet.
➔ Vollwertige Kolab-Klienten können offline arbeiten und dann synchronisieren.
➔ Inkrementelle Datensicherung ist leicht zu realisieren.
➔ Nur der Verzeichnisdienst ist zentral, alles andere ist verteil- und skalierbar.
Mit Kolab lassen sich u. a. E-Mails, Kontakte und Kalendereinträge von Arbeitsplatz und Laptop eines
Nutzers synchronisieren und mit anderen Benutzern austauschen. Alles was dazu nötig ist, ist ein Kolab-
kompatibler Klient. Für die gängigsten Konfigurationsmöglichkeiten des Kolab Servers wird ein Webin-
terface zur Verfügung gestellt. Zur Speicherung der Daten dient der Verzeichnisdienst.
Neben dem offiziellen Kolab Server sowie den Kolab-Klienten Kontact und Horde gibt es bereits wei-
tere Entwicklungen von Drittanbietern1: Der Univention Groupware Server (UGS) als ein weiterer
Kolab-Server sowie die Outlook-Konnektoren von Toltec und Konsec (vgl. Kapitel 6), die Microsoft
Outlook Groupware-Funktionalitäten eines Kolab Klienten ermöglichen. Weiter befinden sich in der Ent-
wicklung: das Thunderbird Plugin Sync Kolab2 und der Bynary Insight Connector3 für MS Outlook.
1.2 Entwicklungshistorie von Kolab
Die Entwicklung von Kolab, geht auf eine Ausschreibung des deutschen Bundesamtes für Sicherheit in
der Informationstechnik (BSI) zurück. Ziel der Ausschreibung war die Bereitstellung einer Groupware-
Lösung, welche eine heterogene Klientenlandschaft bedienen kann, für den eigenen Bedarf. Im Oktober
2002 wurde die Ausschreibung von drei Unternehmen gewonnen, die das Projekt im Juli 2003 erfolg-
reich zum Abschluss brachten. Die Intevation GmbH (Osnabrück) hatte die Projektleitung, die Erfrakon
PartG (Stuttgart) war für die Entwicklung des Kolab Servers sowie das technischen Konzept verant-
wortlich und Klarälvdalens Datakonsult AB (Schweden) realisierte den KDE-basierten Kolab-Klienten
Kontact. Der Auftrag trug den Kodenamen Kroupware. Das Konzept und die Software, welche u. a. aus
diesem Auftrag entstand, heißt Kolab. Entsprechend heißen die Softwarekomponenten Kolab Server
sowie KDE Kolab Client. Am 17. Juli 2003 erschien die erste stabile Version von Kolab1: Kolab Server
1.0 und KDE Kolab Client 1.0.
Im Jahre 2004 wurde Kolab einer Generalüberholung unterzogen. Um Groupware-Daten plattformüber-
greifend zugreifbar zu machen, wird in Kolab2 das Kolab XML Format eingeführt. Im Juni 2005 wurde
Kolab Server 2.0 veröffentlicht, einige Monate nachdem Kolab Server 2 bereits im produktiven Einsatz
1 Stand: Dezember 2007
2 http://www.gargan.org/extensions/synckolab.html [Abruf: 07.12.2007]
3 http://www.bynari.net/ [Abruf: 07.12.2007]
7

8. 1 Einführung
war. Es folgte das Kolab Server 2.1 Release im Mai 2007. Kolab Server 2.2 ist aktuell in der Entwick-
lung. Das stabile Release ist für Anfang 2008 geplant.
1.3 Was ist neu in Kolab Server 2.2?
Nachfolgend eine Auflistung der wesentlichen Neuerungen in Kolab Server 2.2 gegenüber Version 2.1:
➔ Aufnahme des webbasierten Kolab-Klienten Horde (vgl. Abschnitt 6.3)
➔ Upgrade des Apache-Servers von Generation 1 auf Version 2.2
➔ Upgrade von PHP4 auf PHP5
➔ Upgrade von Postfix auf Version 2.4. Damit sind keine kolabspezifischen Änderungen an Postfix
mehr nötig.
➔ Upgrade des Cyrus IMAP Server auf Version 2.3. Damit sind ebenfalls einige (nicht alle) kolabspe-
zifischen Änderungen überflüssig geworden.
➔ Strukturelle Verbesserungen von verschiedenen Serverkomponenten
➔ Verbesserungen, Fehlerbeseitigung und aktualisierte Softwarekomponenten. Dazu gehört eine aktua-
lisierte OpenPKG-Umgebung mit einer verbesserten Unterstützung für aktuelle Betriebssysteme und
Hardware.
8

9. 2 Die Komponenten des
Kolab Servers
Dieses Kapitel gibt eine Übersicht über die im Kolab Server verwendeten Komponenten, erklärt deren
Zusammenspiel und beschreibt im Detail die Komponente OpenPKG sowie die kolabspezifischen Kern-
komponenten kolabd und kolabconf.
2.1 Übersicht
Der Kolab Server 2.2 benutzt zahlreiche Freie-Software-Produkte. Nachfolgend eine Auswahl der wich-
tigsten Serverkomponenten:
E­Mail / Verzeichnisdienst
➔ Postfix
Postfix ist ein freier Mail Transfer Agent (MTA), der den Transport und die Verteilung von
Nachrichten übernimmt.
URL: www.postfix.org
Dokumentation: http://www.postfix.org/documentation.html
➔ Cyrus IMAP Daemon
Der Cyrus-IMAP-Server ist ein skalierbarer Mail-Server und bietet Zugriff auf E-Mails über das
IMAP-Protokoll (Internet Message Access Protocol). Zusätzlich verarbeitet der Server auch
Anfragen über das POP3-Protokoll.
URL/Dokumentation: http://cyrusimap.web.cmu.edu/imapd/
Manual Pages: http://cyrusimap.web.cmu.edu/imapd/man.html
9

10. 2 Die Komponenten des Kolab Servers
➔ OpenLDAP
OpenLDAP ist ein Verzeichnisdienst, der sich über das Protokoll LDAP (Lightweight Directory
Access Protocol) abfragen lässt.
URL: http://www.openldap.org
Dokumentation: http://www.openldap.org/doc/index.html
Manual Pages: http://www.openldap.org/software/man.cgi
Spam­ und Virenscanner
➔ amavisd-new
Amavisd-new ist ein in Perl implementierter E-Mailscanner, der Nachrichten vom Mailserver
entgegennimmt, diese (inkl. Anhang) auspackt und an definierte Viren- und/oder Spamfilter zur
Überprüfung übergibt.
URL: http://www.ijs.si/software/amavisd
Dokumentation: http://www.ijs.si/software/amavisd/amavisd-new-docs.html
➔ ClamAV
ClamAV (ClamAntiVirus) ist ein Virenscanner, der insbesondere auf Mailservern zum Einsatz
kommt.
URL: http://www.clamav.net
Dokumentation: http://www.clamav.org/doc/latest/
➔ SpamAssassin
SpamAssassin ist ein in Perl implementierter E-Mail-Filter, der zur Überprüfung und Identifizie-
rung von unerwünschten Nachrichten eingesetzt wird.
URL: http://spamassassin.apache.org
Dokumentation: http://spamassassin.apache.org/doc.html
Kolab Webklient
➔ Horde
Horde ist ein webbasierter Klient für Kolab.
URL: http://horde.org
Dokumentation: http://www.horde.org/documentation.php
Allgemein
➔ Apache (HTTP-Server)
Der HTTP-Server von Apache ist der meist verbreitete (freie) Webserver im Internet.
URL: http://www.apache.org/
Dokumentation: http://httpd.apache.org/docs/
➔ Perl
Perl ist eine serverseitige, plattformunabhängige und interpretierte Skriptsprache.
URL: http://www.perl.org
Dokumentation: http://www.perl.org/docs.html
➔ PHP
PHP ist eine serverseitige und in HTML-Quelltext integrierbare Skriptsprache.
URL: http://www.php.net
Dokumentation: http://www.php.net/docs.php
10

11. 2 Die Komponenten des Kolab Servers
Die Kolab Server/OpenPKG-Version nutzt zusätzlich die freie Komponente OpenPKG:
➔ OpenPKG
OpenPKG ist ein Paketmanagementsystem für Unix (basierend auf dem RPM-System) und
erleichtert die Paketinstallation auf bekannten Unix-Plattformen (Linux, Solaris, FreeBSD).
Weitere Informationen zu OpenPKG folgen im Abschnitt 2.3.
URL: http://www.openpkg.org
Dokumentation: http://www.openpkg.org/documentation/
Der Kolab Server besteht aus weiteren spezifischen Elementen und Werkzeugen, welche die einzelnen
Komponenten um Groupware-Funktionalitäten und ein gemeinsames Konfigurationssystem ergänzen.
Alle kolabspezifischen Komponenten, insbesondere kolabd und kolabconf, werden im Abschnitt 2.4
beschrieben.
2.2 Interaktion der Komponenten
Der Kolab-Dämon (kolabd) dient als zentrale Steuerungsinstanz des Kolab Servers. Er verwaltet die
Konfigurationen der einzelnen Serverkomponenten. Abbildung 2.1 veranschaulicht die Interaktion dieser
Komponenten:
Die Komponenten Cyrus IMAP und Postfix authentifizieren Benutzer über die von SASLauthd gestellten
Methoden per LDAP (slapd). Der Verzeichnisdienst sorgt über das LDAP-Protokoll außerdem für die
direkte Authentifizierung von Benutzern des Apache Webfrontends – dem Kolab Web-Admin. Der Ver-
zeichnisdienst-Slave-Server slurpd dient der Replikation und redundanten Vorhaltung der Verzeichnisda-
ten.
Abbildung 2.1: Die Interaktion der Kolab Serverkomponenten
11

12. 2 Die Komponenten des Kolab Servers
2.3 OpenPKG
Die Kolab Server/OpenPKG-Variante nutzt eine Schicht zwischen Anwendung und Betriebssystem,
names OpenPKG1. Im Ergebnis wird für den Anwendungsentwickler die Plattform vereinheitlicht. Was
für die Entwickler und Tester des Kolab Servers eine Erleichterung bedeutet. Betrieben werden kann der
Kolab Server daher auf allen Betriebssystemen, auf denen auch OpenPKG läuft (vgl. dazu die Angaben
von OpenPKG). Am meisten getestet ist der Kolab Server/OpenPKG mit den verbreiten GNU/Linux-
Distribution, also z. B. Debian und RedHat Enterprise.
Abbildung 2.2 zeigt schematisch den Aufbau eines Kolab Servers mit OpenPKG.
Abbildung 2.2: Die Schichten beim Kolab Server/OpenPKG
OpenPKG bringt viele Komponenten selbst mit und verwaltet diese mit einer eigenen RPM-Datenbank
zur Paketverwaltung. OpenPKG ist demnach von Bibliotheken auf dem eigentlichen Betriebssystem
und dessen Paketverwaltung weitestgehend unabhängig. Das bringt viele Vorteile, aber auch einige
Nachteile.
Aus der Unabhängigkeit der Paketverwaltungssysteme voneinander folgt,
1. dass für OpenPKG andere Kommandos bzw. Pfade existieren.
2. dass auch die Paketverwaltung über OpenPKG-Kommandos erfolgt
(z.B. /kolab/bin/openpkg rpm) und dafür OpenPKG Pakete gebraucht werden.
3. dass Konflikte um gemeinsame Ressourcen (wie Portnummern) im Blick behalten werden müs-
sen. Welche das sind ist Abschnitt 4.1 zu entnehmen.
4. die Steuerung von Kolab Server/OpenPKG ist auf vielen Betriebssystemen gleich.
OpenPKG hängt sich an einigen Punkten in das Betriebssystem ein, so werden für Kolab Server bei-
spielsweise die Nutzer kolab-r, kolab-n und kolab sowie ein Startskript in /etc/init.d/kolab ange-
legt.
Um an die Anwendungen in der OpenPKG-Welt zu kommen, gibt es zwei grundsätzliche Vorgehenswei-
sen:
a) direktes Aufrufen von /kolab/bin/openpkg <Kommando>, z.B. lässt sich der Apache mit
/kolab/bin/openpkg rc apache stop anhalten. Andere Kommandos lassen sich mit
absoluten Pfaden aufrufen, wie /kolab/bin/cyrreconstruct.
1 http://www.openpkg.org/ [Abruf: 07.12.2007]
12

13. 2 Die Komponenten des Kolab Servers
b) setzen der Pfade in Umgebungsvariablen MANPATH, PATH, LIBRARY_PATH usw. Die Nut-
zer kolab, kolab-r und kolab-n haben diese Pfade bereits gesetzt.
Die Hilfeseiten (Manpages) von OpenPKG-Komponenten können z.B. mit:
➔ /kolab/bin/openpkg man ... oder
➔ man ... (als Benutzer kolab)
aufgerufen werden.
Hinweise für Techniker
Die Paketverwaltung von OpenPKG ist das bekannte RPM-System in Version 4. Um selbst Pakete bauen
zu können, sollte beachten, dass die meisten Bibliotheken statisch gelinkt werden. Wird beispielsweise
db ausgetauscht, dann müssen auch die Anwendungen neu gebaut werden, welche diese Bibliothek hin-
eingelinkt haben.
OpenPKG verteilt Pakete im Quelltext, um durch die Übersetzung erst auf der genauen Zielplattform ein
optimales Ergebnis zu erreichen. Die Binärpakete lassen sich aber auf Systemen mit ähnlicher Hardware
und Betriebssystem austauschen.
2.4 Kolabspezifische Komponenten
Zu den kolabspezifischen Kernkomponenten gehören:
➔ kolabd
➔ kolabconf
➔ kolab-webadmin
➔ kolab-filter
➔ kolab-freebusy
➔ kolab-horde-framework
➔ kolab-horde-fbview
➔ kolab-ressource-handlers
Der folgende Abschnitt konzentriert sich auf die Komponenten kolabd und kolabconf.
Der Kolab-Dämon (kolabd) sowie kolabconf dienen als zentrale Steuerungsinstanzen des Kolab Servers.
Kolabd führt die notwendigen Arbeiten aus, wenn ein Nutzer angelegt, geändert oder gelöscht worden
ist. Kolabconf verwaltet die Konfigurationen der einzelnen Serverkomponenten und erzeugt die eigentli-
chen Konfigurationsdateien aus Vorlagen, so genannten Templates.
Ändert sich etwas an den Kolab-Nutzern oder Verteilerlisten ist nur kolabd (und nicht kolabconf) für die
Bearbeitung zuständig; beispielsweise kann kolabd ein Konto auf dem Cyrus IMAPd anlegen, ändern
oder löschen. Für die Arbeit am Cyrus-Server hält sich kolabd einen Zwischenspeicher von allen existie-
renden Nutzer auf der Festplatte, um den IMAPd nicht mit weiteren Anfragen zu belegen.
Abbildung 2.3 veranschaulicht die Arbeitsweise von kolabd und kolabconf.
13

14. 2 Die Komponenten des Kolab Servers
Abbildung 2.3: Arbeitsweise des Kolab­Server­Konfigurationssystems – vereinfacht für einen Dienst.
Der Verzeichnisdienst OpenLDAP gibt die kolabspezifischen Einstellungen per LDAP heraus. Ändern
sich Einstellungen, zum Beispiel durch eine Konfiguration über den Kolab Web-Admin, so werden auto-
matisch neue Konfigurationsdateien erzeugt und betroffene Dienste benachrichtigt.
1. Wie in Abbildung 2.3 veranschaulicht, schreibt der Kolab Web-Admin Änderungen in den Ver-
zeichnisdienst (Schritt 1).
2. Der kolabd muss nun mitbekommen, dass sich im Verzeichnisdienst etwas geändert hat.
○ Dies wird entweder automatisch gemacht: Dazu hängt kolabd bei OpenLDAP als Replika-
tionsziel und lauscht auf Port 9999. Sobald sich etwas im Verzeichnisdienst ändert, teilt
OpenLDAP dies kolabd mit.
○ Der andere Weg, um kolabd mitzuteilen, dass sich etwas geändert hat, ist manuell den
Befehl /kolab/sbin/kolabconf ausführen (Schritt 2 in der Abbildung – gestrichelter
Pfeil).
3. Anschließend ruft kolabd die benötigten Angaben der Änderungen per LDAP vom Verzeichnis-
dienst ab.
4. Nun muss kolabconf benachrichtigt werden: Dazu ruft kolabd im Schritt 4
/kolab/sbin/kolabconf auf.
5. Kolabconf liest alle relevanten Einstellungen aus dem Verzeichnisdienst, ..
6. ... liest anschließend das entsprechende Template ein, ...
7. ... generiert daraus die passende Konfigurationsdatei und ...
8. ... informiert abschließend den zugehörigen Dienst, der dann ggf. neu gestartet wird.
14

15. 2 Die Komponenten des Kolab Servers
Konfiguration durch Templates
Die Kolab-Komponenten werden durch Konfigurationsdateien konfiguriert, die von kolabconf aus
Templates generiert werden. Am Beispiel des Postfix-Dienstes wird nun die Funktionsweise von
Templates erläutert:
Alle Template-Dateien liegen im Verzeichnis /kolab/etc/kolab/templates und sind an der
Dateiendung .template zu erkennen. Aus dem Dateiname lässt sich erschließen, um welche
Konfiguration es sich handelt; so wird z. B. aus dem Template /kolab/etc/kolab/templates/
main.cf.template die Konfigurationsdatei /kolab/etc/postfix/main.cf für Postfix generiert
(vgl. Schritt 7 in der obigen Abbildung).
In jeder Template-Datei steht zu Beginn ein Block mit Metainformationen; exemplarisch der Meta-Block
von Postfix:
KOLAB_META_START
TARGET=/kolab/etc/postfix/main.cf
PERMISSIONS=0644
OWNERSHIP=kolab-n:kolab-r
KOLAB_META_END
In diesem Abschnitt wird festgelegt wo (TARGET) und mit welchen Zugriffsrechten (PERMISSIONS und
OWNERSHIP) die generierte Konfigurationsdatei im Dateisystem abgelegt wird.
Nachdem die Konfigurationsdateien neu generiert wurden, informiert kolabconf die zugehörigen
Dienste. Einige Dienste müssen nach Änderungen an ihren Konfigurationsdateien neu gestartet werden.
Welche das sind, ist in Kolab Server 2.2 beta2 noch „hart“ im Kolab-Konfigurationssystem kodiert. Bei
künftigen Kolab-Versionen soll auch diese Information in dem o. g. Metainformations-Block im Tem-
plate festgelegt werden.
Auffällig sind auch die von @@@ eingerahmten Schlüsselworte im Template. Im einfachsten Fall werden
diese beim Schreiben der Konfigurationsdateien eins zu eins durch entsprechende Werte aus dem Ver-
zeichnisdienst ersetzt. Kolabconf liest dafür Werte aus dem vertrauenswürdigen Objekt:
dn: k=kolab, dc=example, dc=com
Anstatt eines Schlüsselwortes können auch konkrete Angaben direkt in das Template eintragen werden.
Dazu wird das Schlüsselwort (inkl. dessen einrahmende @@@ Zeichen) einfach überschrieben.
15

16. 2 Die Komponenten des Kolab Servers
Problemsuche in kolabd / kolabconf
Der kolabd ist das Bindeglied zwischen dem Verzeichnisdienst und dem Cyrus-IMAP-Server. Kolabd
kommt erst dann zum Einsatz, wenn Änderungen an der Konfiguration oder den Nutzereinstellungen
vorgenommen werden. Probleme am kolabd werden also erst dann sichtbar, wenn Änderungen nicht
abgearbeitet werden können.
Typische Symptome für einen gestörten kolabd sind:
a) Der im Verzeichnisdienst angelegte Nutzer kann sich nicht im Cyrus anmelden (der kolabd hat
das Konto noch nicht angelegt).
b) Die Löschung eines Nutzers dauert sehr lang.
Ein Neustart des kolabd ist harmlos, da er selbst keinen Zustand hält und nicht zeitnah auf Anfragen ant-
worten muss. Es schadet also nicht, den kolabd in den beiden oben beschriebenen Situation neu zu star-
ten.
Der kolabd protokolliert seine Arbeit in der normalen Log-Datei für Systemmeldungen, bei Debian ist
das meist /var/log/syslog (Achtung: Dies ist nicht innerhalb der OpenPKG-Hierarchie). Um dort
mehr Ausgaben zu erhalten, sollte in der Konfigurationsdatei /kolab/etc/kolab/kolab.conf der
Wert für log_level erhöht und kolabd neu gestartet werden. log_level steht nach der Installation von
Kolab Server noch nicht in der kolab.conf; er muss also manuell eingetragen werden. Dessen voreinge-
stellter Wert ist in der Regel 2 und steht in /kolab/etc/kolab/kolab.globals. Für die Ausgaben
in syslog ist nur log_level (0 – 4) interessant. Analog kann für ein interaktives Debugging der Flag
debug (0/1) gesetzt werden.
Voreinstellungen in /kolab/etc/kolab/kolab.globals:
log_level : 2
debug : 0
Änderung der Werte in /kolab/etc/kolab/kolab.conf, z.B.:
log_level : 4
debug : 1
Bedeutung der Werte:
log_level: debug:
0: SILENT 0: send to syslog if log level >= message priority
1: ERROR 1: additionally print all messages to stdout
2: WARN
3: INFO
4: DEBUG
Sind mehrere Slave-Server im Betrieb, muss erst die Replikation des Verzeichnisdienstes funktionieren,
bevor der kolabd auf den verschiedenen Servern tätig werden kann. Die obigen Symptome können also
auch auf eine gestörte Replikation hinweisen.
16

17. 3 Kolab Server –
Bedarfsplanung
Es empfiehlt sich den eigenen Bedarf für den Server abzuschätzen. Anhand von einigen Rahmenbedin-
gungen werden in diesem Kapitel Hinweise für eine Grob-Planung gegeben.
Dabei ist zu beachten, dass das Nutzungsmuster einen starken Einfluss auf die Bedarfsplanung hat. In
manchen Organisation reichen beispielsweise 50 Megabyte E-Mail-Speicherplatz und es werden pro
Nutzer weniger als dreistellige Termine gespeichert. Bei Anderen wird E-Mail zur „Ablage“ großer Mul-
timedia-Dateien verwendet und die 3000 Termine der ganzen Arbeitsgruppe der letzten drei Jahre archi-
viert; hier wird ein Quota von 2 Gigabyte sicherlich schnell eng.
3.1 Festplattenspeicher
Die wichtigste Tätigkeit eines Kolab-Servers ist es, für die Klienten E-Mail-Daten zu liefern. Jedes
Groupware-Objekt ist ebenfalls eine E-Mail. In der Regel haben die meisten Nutzer deutlich mehr nor-
male E-Mails als andere Groupware-Objekte, eine Bedarfsschätzung sollte also bei der E-Mail anfangen.
Der durchschnittliche E-Mail-Speicherplatz in den nächsten Jahren, multipliziert mit der Anzahl der Nut-
zer und etwas Puffer ergibt den zu erwartenden Plattenplatz der Nutzerdaten. Aus der erwarteten Ände-
rungsrate lässt sich auch der Platz für die Datensicherung abschätzen. Gegenüber den normalen E-Mails
fallen die Termine und Kontakte meist nicht ins Gewicht.
Wird als Klient Microsoft Outlook mit einem der verfügbaren Konnektoren verwendet (vgl. Abschnitt
6.2), ist es möglich, dass sich die Größe mancher E-Mails in der Speicherung verdoppeln. Nur so können
manche Objekt-Attribute gespeichert werden, welche nur für Outlook wichtig sind. Wer ganz sicher
gehen möchte, migriert auf ein Testsystem die alten Daten einiger repräsentativer Nutzer.
17

18. 3 Kolab Server – Bedarfsplanung
Entscheidend wird der Umgang mit Alt-Daten im System sein. Was werden die Nutzer tun, wenn sie an
ihr Limit stoßen? Es empfiehlt sich, den Nutzern hier früh eine Möglichkeit anzubieten, z.B. zum selb-
ständigen Archivieren. Die Klienten bieten meist Funktionen zum automatischen Löschen alter E-Mails
oder Termine an.
3.2 Rechenleistung / Hauptspeicher
Beim Verfügbarmachen von E-Mails sind vor allem das Übermitteln von Daten, Platten- und Netzwerk-
durchsatz, sowie die Netzlatenz limitierender als die Rechenleistung. Pro aktivem Klienten läuft etwa ein
Cyrus-IMAPd, der grob um die 2 Megabyte Hauptspeicher benötigt.
Ein „aktiver Klient“ steht in diesem Zusammenhang für einen Klienten, der einen Zwischenspeicher
besitzt und daher hauptsächlich nur zum Synchronisieren eine Netzwerkverbindung benötigt. Der ein-
zelne Nutzer kommt also problemlos minutenlang ohne Verbindung aus. Es ist zu erwarten das durch
geschicktere Synchronisations-Algorithmen von Seiten der Klienten der Bedarf an Netzverbindungen in
Zukunft sogar sinken kann.
Deutlich mehr Rechenleistung im Kolab-Server benötigen zwei andere Prozesse:
1. Das Scannen von E-Mails auf Schadsoftware und unerwünschte Werbung,
2. sowie das Erstellen von Frei/Belegt-Listen.
Die Erstellungszeiten von Frei/Belegt-Listen sind von Kolab Server 2.0 auf 2.1 entscheidend verbessert
worden. Langzeiterfahrungen fehlen, aber es wird eine deutliche Besserung erwartet, so dass dieses für
den Betrieb von 2.2 nicht mehr gesondert geplant werden muss. Im Gegensatz dazu hat der Ansturm an
unerwünschten E-Mails zugenommen, was mehr Scan-Leistung erforderlich macht. Für das Scannen von
E-Mails ist deshalb bei größeren Installation ein eigener Rechner sinnvoll.
Bei durchschnittlicher Nutzung ist zu erwarten, dass eine übliche Server-Hardware mit 2 Prozessoren
und 4 Gigabyte Hauptspeicher mehrere tausend Nutzer bedienen kann. Das gilt pro Kolab-Server; durch
den Einsatz von Slave-Servern ist hier eine gute Skalierung möglich.
3.3 Verfügbarkeit
Die Bedürfnisse an die Verfügbarkeit der Kolab-Server sind recht unterschiedlich. Wie im letzten Absatz
beschrieben, sind die Klienten auch ohne Netzverbindung grundsätzlich arbeitsfähig. Dennoch sollte
eine hohe Verfügbarkeit von jedem Kolab-Servers angestrebt werden.
Der Kolab-Server kann mit üblichen GNU/Linux Mechanismen abgesichert werden. Zum Beispiel durch
ein aktiv-passiv System, welches per Linux-HA1 den aktiven Rechner überwacht und bei Schwierigkei-
ten den passiven einschaltet. Dazu muss der passive Rechner auf die Daten zugreifen können: z. B.
durch ein gemeinsames SCSI Plattensystem / SAN, ggf. auch standortübergreifend.
1 http://www.linux-ha.org/ [Abruf: 07.12.2007]
18

19. 3 Kolab Server – Bedarfsplanung
3.4 Wer arbeitet mit wem?
Es kann sinnvoll sein, aus Gründen der Leistung oder verschiedener Standorte, mehrere Kolab-Server
zu planen. Dabei ist zu beachten, wie die Arbeitsbeziehungen der Nutzer sind. Es ist empfehlenswert,
eng zusammenarbeitende Nutzer auf einen Kolab Server zu legen – also beispielsweise lieber eine Abtei-
lung X, als die Mitarbeiter von A bis H.
Interessant sind dabei auch Fragen der Modellierung von gemeinsamen Ordner (z.B. für Termine):
Ein Ordner steht zunächst nur Nutzern auf einem Server zur Verfügung. Kolab-Nutzer haben einen
bestimmten Heimatserver, dürfen sich aber auf allen anderen anmelden. Das ist weniger nötig, wenn sich
die Nutzer einer Arbeitsgruppe schon auf einem gemeinsamen Heimatserver befinden.
19

20. 4 Kolab Server – Vorbereitung
und Installation
In diesem Kapitel werden zunächst die nötigen Grundvoraussetzungen und Vorbereitungen für die
danach beschriebene Installationsanleitung des Kolab Servers erläutert. Anschließend wird das Vorgehen
für eine Aktualisierung und für die Deinstallation dargestellt.
4.1 Installationsvorbereitung
Speicherplatz/ ­ort Die Installation des Kolab Servers (inkl. Horde) belegt unter /kolab etwa
1 GB Speicherplatz. Falls das Verzeichnis nicht existiert, wird es angelegt.
Ein Symlink kann genutzt werden. Die Nutzung eines NFS gemounteten
Laufwerks ist nicht möglich, da es sonst zu Problemen mit dem Cyrus
IMAP Server kommt1.
Partitionierung Für einen produktiven Einsatz eines Kolab Servers wird empfohlen,
getrennte Partitionen für Programme, Bewegungsdaten und Nutzerdaten zu
verwenden. Nachfolgend eine Empfehlung für eine typische Installation,
bei der Verzeichnisse von Kolab auf drei Partitionen verteilt werden:
/kolab 2 - 4 GB (Programme)
/kolab/var 2 - 4 GB (Bewegungsdaten)
/kolab/var/imapd/spool nach geplanten Bedarf (Nutzerdaten)
Dateisystem Es wird ein geeignetes Dateisystem benötigt. Die meisten Kolab-Server-
Installationen werden mit ext3 betrieben, aber es existieren auch nennens-
werte Erfahrung mit XFS. Bei der Nutzung von ext3 wird empfohlen, einen
Linux Kernel ab 2.6.19.2 oder einen entsprechend gepatchten Kernel zu
1 http://cyrusimap.web.cmu.edu/imapd/faq.html [Abruf: 07.12.2007] Der Cyrus IMAPd braucht ein lokales Dateisystem, mit
Unix-Eigenschaften und funktionierender mmap()/write() Kombination.
20

21. 4 Kolab Server – Vorbereitung und Installation
verwenden. Frühere Versionen haben einen Defekt im mmap(). Für ext3
spricht, dass es sich um ein vergleichsweise einfaches und damit sehr
robustes Journaling-Dateisystem handelt. Sollte ein Dateisystem-Check
trotzdem einmal nötig werden, dann dieser jedoch im Ernstfall längere Zeit
benötigen. XFS ist ein komplizierteres Journaling-Dateisystem.
Reservierte Benutzer Die folgenden Benutzer sollten noch nicht existieren, da OpenPKG diese
anlegt: kolab, kolab-r, kolab-n.
Pakete Es sollten nur Pakete verwendet werden, von deren Echtheit man sich über-
zeugt hat. Unter http://kolab.org/mirrors.html gibt es eine Liste von Ser-
vern, welche die Kolab-Server-Pakete zum kostenfreien Herunterladen
anbieten. Nach dem Download sollten die Signaturen überprüft werden.
Aus dem Verzeichnis server sollte die aktuelle Kolab-Server-Version herun-
tergeladen werden – entweder die komplette Quellcodeversion im Verzeich-
nis sources oder die binäre, vorkompilierte Version für Debian 4.0 (Etch)
im Ordner ix86-debian4.0. Binär-Versionen für andere Distributionen kön-
nen selbst gebaut oder über Kolab-Dienstleister bezogen werden (Kontakte
im Anhang A.2).
Ports Die folgenden Ports möchte der Kolab Server öffnen. Alle Anwendungen
des Betriebssystems, die diese Ports ansonsten bräuchten, sollten gestoppt
oder deinstalliert werden.
80/tcp http offen nach außen (bei Bedarf)
443/tcp https offen nach außen
25/tcp smtp offen nach außen
465/tcp smtps offen nach außen
110/tcp pop3 offen nach außen (bei Bedarf)
995/tcp pop3s offen nach außen (bei Bedarf)
143/tcp imap offen nach außen
993/tcp imaps offen nach außen
389/tcp ldap offen nach außen
636/tcp ldap offen nach außen
2000/tcp sieve offen nach außen (bei Bedarf)
2003/tcp lmtp nur intern offen
9999/tcp kolabd nur intern offen
10024/tcp amavis nur intern offen
21

22. 4 Kolab Server – Vorbereitung und Installation
4.2 Installation
Im folgenden Abschnitt werden die Schritte zur Installation des Kolab Servers mit den unter Abschnitt
4.1 heruntergeladenen Paketen beschrieben. Es sollte zusätzlich die bei den Paketen beiliegende
1st.README-Datei beachtet werden.
1. Die Installation
Die Pakete in den Verzeichnissen sources und ix86-debian4.0 lassen sich mit dem enthaltenen
install-kolab.sh-Skript (als root) installieren. Es steht eine Installation von den Quellcodepaketen
(sources) oder von den für Debian 4.0 vorkompilierten ix86-Binärpaketen (ix86-debian4.0) zur
Wahl. Dafür muss in das entsprechende Verzeichnis gewechselt werden. Anschließend wird die
Installation gestartet mit:
./install-kolab.sh -H -F 2>&1 | tee kolab-install.log
Um den Kolab Webklienten Horde und/oder den Frei/Belegt-Viewer nicht mitzuinstallieren, muss
der Parameter -H und/oder -F in o. g. Befehlszeile weggelassen werden. Die Konsolenausgabe
wird in der kolab-install.log protokolliert.
Installationsdauer: Die Installation aus den Quellpaketen kann, je nach Rechenleistung, leicht einige
Stunden dauern (z. B. bei einem P4 mit 3 GHz sind es ca. 3 Stunden). Bei der Binärpaket-Installa-
tion kann mit ca. 3 bis 10 Minuten gerechnet werden.
Bei Schwierigkeiten mit der Binärpaket-Installation sollte stets die Installation von den Quellen pro-
biert werden.
2. Das Bootstrapping
Nach der Installation sollte die initiale Konfiguration (das Bootstrapping) des Kolab-Servers mit
folgendem Befehl durchgeführt werden:
/kolab/etc/kolab/kolab_bootstrap -b
Dabei werden zunächst die benötigten Ports nach Verfügbarkeit getestet. Anschließend werden
unterschiedliche Informationen zum Kolab-Server abgefragt.
Nachfolgender Ausdruck zeigt exemplarisch das Konfigurieren eines Master-Servers mit einer eige-
nen Zertifizierungsstelle für Testzwecke. Alle nötigen Eingaben sind fett gedruckt ([Enter] meint
das Drücken der Enter/Return-Taste ohne weitere Eingabe) und dienen nur zur Demonstration des
Bootstrapping-Prozesses. Für das Aufsetzen eines eigenen Systems sollten diese Eingaben unbe-
dingt an die spezifischen Anforderungen angepasst werden.
Wird ein Produktivsystem aufgesetzt, sollten Zertifikate einer „richtigen“ Zertifizierungsstelle (Cer-
tification Authorities, kurz CA) zum Einsatz kommen. Unter http://www.pki-page.org gibt es eine
ausführliche Liste weltweiter, aktueller Zertifizierungsstellen. Wichtig ist dabei, dass die Zertifikate
in den Klienten als vertrauenswürdig anerkannt werden.
22

23. 4 Kolab Server – Vorbereitung und Installation
Ein exemplarischer(!) Bootstrapping-Prozess
Eingabe des Hostnamens
> Please enter Hostname including Domain Name (e.g. thishost.domain.tld)
[example]: kolab.example.com
Proceeding with Hostname kolab.example.com
Auswahl „Master Server“
> Do you want to set up (1) a master Kolab server or (2) a slave [1]
(1/2): 1
Proceeding with master server setup
Eingabe der Maildomain (Bestätigung der Defaultangabe mit Enter)
> Please enter your Maildomain - if you do not know your mail domain
use the fqdn from above [example.com]: [Enter]
proceeding with Maildomain example.com
Kolab primary email addresses will be of the type user@example.com
Generating default configuration:
Top level DN for Kolab [dc=example,dc=com]:
base_dn : dc=example,dc=com
bind_dn : cn=manager,cn=internal,dc=example,dc=com
Eingabe eines sicheren Managerpasswortes (Bestätigung der Defaultangabe mit Enter)
> Please choose a manager password [VG1rXCIxi22/c4DT]: [Enter]
bind_pw : <managerpasswort>
done modifying /kolab/etc/kolab/kolab.conf
IMPORTANT NOTE:
use login=manager and passwd=VG1rXCIxi22/c4DT when you log into the
webinterface!
Eingabe des Hostnames eines Slaveservers (ohne Slaveserver fortfahren durch Drücken von Enter)
> Enter fully qualified hostname of slave kolab server e.g.
thishost.domain.tld [empty when done]: [Enter]
prepare LDAP database...
temporarily starting slapd
Waiting for OpenLDAP to start
no dc=example,dc=com object found, creating one
mynetworkinterfaces: 127.0.0.0/8
LDAP setup finished
Create initial config files for postfix, apache, cyrus imap, saslauthd
running /kolab/sbin/kolabconf -n
kill temporary slapd
OpenPKG: stop: openldap.
Creating RSA keypair for resource password encryption
/kolab/bin/openssl genrsa -out /kolab/etc/kolab/res_priv.pem 1024
Generating RSA private key, 1024 bit long modulus
....................++++++
...............++++++
e is 65537 (0x10001)
/kolab/bin/openssl rsa -in /kolab/etc/kolab/res_priv.pem -pubout -out
/kolab/etc/kolab/res_pub.pem
writing RSA key
chown kolab:kolab-n /kolab/etc/kolab/res_pub.pem /kolab/etc/kolab/res_priv.pem
Kolab can create and manage a certificate authority that can be used
to create SSL certificates for use within the Kolab environment. You
can choose to skip this section if you already have certificates for
the Kolab server.
23

24. 4 Kolab Server – Vorbereitung und Installation
Erstellen einer eigenen Test-Zertifizierungsstelle und eines Zertifikats
> Do you want to create CA and certificates [y] (y/n): y
Now we need to create a cerificate authority (CA) for Kolab and a server
certificate. You will be prompted for a passphrase for the CA.
######################################################################
/kolab/etc/kolab/kolab_ca.sh -newca kolab.example.com
> Enter organization name [Kolab]: [Enter]
> Enter organizational unit [Test-CA]: [Enter]
Using subject O=Kolab,OU=Test-CA,CN=kolab.example.com
Using dn
> CA certificate filename (or enter to create) [Enter]
Making CA certificate ...
Generating a 1024 bit RSA private key
....++++++
writing new private key to '/kolab/etc/kolab/ca/private/cakey.pem'
> Enter PEM pass phrase: <passphrase>
> Verifying - Enter PEM pass phrase: <passphrase>
-----
/root
/kolab/etc/kolab/kolab_ca.sh -newkey kolab.example.com /kolab/etc/kolab/key.pem
Using dn
Generating RSA private key, 1024 bit long modulus
......++++++
e is 65537 (0x10001)
writing RSA key
/root
/kolab/etc/kolab/kolab_ca.sh -newreq kolab.example.com /kolab/etc/kolab/key.pem
/kolab/etc/kolab/newreq.pem
Using dn
Request is in /kolab/etc/kolab/newreq.pem and private key is in /kolab/etc/kolab/key.pem
/root
/kolab/etc/kolab/kolab_ca.sh -sign /kolab/etc/kolab/newreq.pem /kolab/etc/kolab/cert.pem
Using dn
Using configuration from /kolab/etc/kolab/kolab-ssl.cnf
> Enter pass phrase for /kolab/etc/kolab/ca/private/cakey.pem: <passphrase>
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Oct 19 07:24:15 2007 GMT
Not After : Oct 16 07:24:15 2017 GMT
Subject:
commonName = kolab.example.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
65:CD:3E:49:47:34:B6:05:52:25:3B:C7:C5:4D:7D:09:92:13:6D:1B
X509v3 Authority Key Identifier:
DirName:/O=Kolab/OU=Test-CA/CN=kolab.example.com
serial:85:3B:73:2D:BA:56:FC:67
> Certificate is to be certified until Oct 16 07:24:15 2017 GMT (3650 days)
Sign the certificate? [y/n]: y
> 1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in /kolab/etc/kolab/cert.pem
/root
chgrp kolab-r /kolab/etc/kolab/key.pem;
chmod 0640 /kolab/etc/kolab/key.pem;
chgrp kolab-r /kolab/etc/kolab/cert.pem;
chmod 0640 /kolab/etc/kolab/cert.pem;
######################################################################
CA and certificate creation complete.
You can install /kolab/etc/kolab/ca/cacert.pem on your clients to allow them to verify
the validity of your server certificates.
<<Ende des exemplarischen Bootstrappings-Prozesses>>
24

25. 4 Kolab Server – Vorbereitung und Installation
Am Ende des Bootstrappings sollte die Ausgabe der folgenden ähnlich sein:
kolab is now ready to run!
please run '/kolab/bin/openpkg rc all start'
Use login=manager and passwd=VG1rXCIxi22/c4DT when you log into the
webinterface https://kolab.example.com/admin !
Anmerkung: Es sollte zunächst der Master-Server konfiguriert werden. Das (optionale) Hinzufügen
von weiteren Kolab-Slave-Servern ist im Abschnitt 5.12 beschrieben.
3. Server starten
Der Kolab Server ist erfolgreich installiert und kann nun mit folgendem Befehl gestartet werden:
/kolab/bin/openpkg rc all start
Das Verzeichnis /kolab/RPM/PKG/ wird nur zur Installation gebraucht und kann anschließend
gelöscht oder für spätere Installationen archiviert werden (Größe: ca. 500 MB).
4.3 Aktualisierung
Achtung: Die Migration von Kolab Server 2.1 auf 2.2 wird zur Zeit noch getestet!
Für Hinweise kann die Kolab-Mailinglisten, das Kolab-Wiki bzw. der Kolab-Issue-Tracker genutzt
werden (vgl. Anhang A).
Vor jeder Aktualisierung sollte in jedem Fall ein Backup von /kolab durchgeführt werden (vgl.
Punkt 2 dieser Anleitung und Abschnitt 5.13).
Hier folgt eine allgemeine Anleitung zum Aktualisieren des Kolab Servers.
Die Installation von neuen Paketen läuft analog zur initialen Kolab-Server-Installation (vgl. Abschnitt
4.2). Die Hinweise in der Datei 1st.README sind zusätzlich zu beachten.
1. Beenden aller Kolab Server Dienste:
/kolab/bin/openpkg rc all stop
und sicherstellen, dass kein LDAP-Prozess mehr läuft:
/kolab/bin/openpkg rc openldap status und ps -AF | grep slapd
2. Sichern der vollständigen, alten Kolab-Installation!
Zum Reduzieren der Server-Stillstandszeit (downtime) wird empfohlen, das Verzeichnis
/kolab mit rsync zunächst von dem noch laufenden Server zu kopieren. Anschließend, bei
gestoppten Server, müssen mit rsync nur noch die geänderten Dateien nachgesichert werden.
Sofern ein ähnliches Vorstufen-System zur Verfügung steht („staging“) empfiehlt es sich, die
Binärdateien dort zu bauen und diese dann zu kopieren. Dadurch wird entscheidende Zeit
gespart.
25

26. 4 Kolab Server – Vorbereitung und Installation
3. Nach dem Aktualisieren der Kolab Server Pakete in dem Verzeichnis, in dem bereits die anderen
Pakete liegen kann das Kolab Server Update (als root) gestartet werden:
./install-kolab.sh -H -F 2>&1 | tee kolab-update.log
install-kolab.sh bestimmt in der Regel automatisch welche Pakete benötigt werden und instal-
liert oder baut diese.
Die Parameter -H und -F geben an, ob der Kolab Webklient Horde und der Frei/Belegt-Viewer
nachinstalliert / aktualisiert werden.
Die Konsolenausgabe wird in der kolab-update.log protokolliert.
Der Server wird aktualisiert, ohne dass die bereits vorhandenen Konfigurationen und Daten
überschrieben werden. Manuell geänderte Konfigurationsdateien werden mit der Dateinamener-
weiterung *.rpmsave gespeichert. Bei Konfigurationsdateien, die von Templates generiert wer-
den, müssen die *.conf.rpmsave Dateien zunächst gelöscht werden, um den entsprechenden
Dienst starten zu können; z. B. für ClamAV:
rm /kolab/etc/clamav/*.conf.rpmsave
Die Änderungen aus den *.template.rpmsave Dateien (die angelegt werden, wenn Templates
geändert wurden) können nun in die neuen Template-Dateien übertragen werden.
Nun muss der OpenLDAP gestartet, die Konfigurationsdateien neu generiert und schließlich der
komplette Kolab Server neu gestartet werden:
/kolab/bin/openpkg rc openldap start
/kolab/sbin/kolabconf
/kolab/bin/openpkg rc all start
Detailliertere Upgrade-Informationen – insbesondere zu Besonderheiten beim Upgrade von früheren
Kolab-Versionen – sind in den Readme-Dateien im CVS-Server-Verzeichnis 2 bzw. in der 1st.README
im Installationsordner zu finden.
Sicherheitsupdates
Zunächst ist der Benachrichtigungsweg relevant: Wie bekommt der Administrator Kenntnis von einem
Sicherheitsupdate? Entweder wird er von seinem Dienstleister benachrichtigt und mit einer genauen
Anleitung versorgt, oder er muss sich selbst darum kümmern.
Ist kein Dienstleister damit beauftragt, wird geraten, mindestens folgende Quellen zu verfolgen:
➔ die Kolab-Announce-Mailingliste (vgl. Anhang A) zu abonnieren
➔ die Sicherheitsrelevanten Informationen der genutzten Distribution (z.B. Debian security) zu
beobachten
Anschließend sollte eine Bewertung der in Frage kommenden Updates durchgeführt werden.
2 http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/ [Abruf: 07.12.2007]
26

27. 4 Kolab Server – Vorbereitung und Installation
Treten Unsicherheiten/Schwierigkeiten beim Durchführen von Sicherheitsupdates auf, sollte ein Dienst-
leister zu Rate gezogen werden. Ein funktionierender Prozess, um zu Aktualisierungen zu kommen ist
wichtig, da ansonsten das eingesetzte System Gefahr läuft längere Zeit bekannte Angriffspunkte zu bie-
ten.
4.4 Deinstallation
Der Kolab Server/OpenPKG kann in drei Schritten deinstalliert werden:
1. Kolab Server beenden:
/kolab/bin/openpkg rc all stop
2. Alle Kolab-Pakete löschen:
/kolab/bin/openpkg rpm -e `/kolab/bin/openpkg rpm -qa`
rpm -qa listet alle Pakete innerhalb der OpenPKG Umgebung und rpm -e löscht diese.
3. Kolab-Verzeichnis löschen:
rm -rf /kolab/
Anschließend sollten ...
➔ ... alle kolabspezifischen cronjobs in /etc/crontab und die Datei
/var/spool/cron/crontabs/kolab,
➔ ... alle kolabspezifischen Benutzer in /etc/passwd und in /etc/shadow,
➔ ... alle kolabspezifischen Gruppen in /etc/group,
➔ ... alle kolabspezifischen Einträge in /etc/shells,
➔ ... das Kolab/OpenPKG Initskript /etc/init.d/kolab mit den Symlinks in
/etc/rc?.d/???kolab und
➔ ... das /kolab Verzeichnis
durch OpenPKG entfernt worden sein.
27

28. 5 Kolab Server – Konfiguration
und Betrieb
Dieses Kapitel beschreibt die Konfigurationsmöglichkeiten des Kolab Servers und gibt darüber hinaus
für den Betrieb nützliche Methoden und Einstellungen mit.
Es gibt zwei grundsätzliche Strategien den Kolab Server zu konfigurieren:
➔ Über ein LDAP-Verzeichnisdienst-Werkzeug – beispielsweise mit dem Kolab Web-Admin (vgl.
folgender Abschnitt) oder
➔ über die kolabspezifische Konfigurationskomponente kolabconf. Dabei können die Konfigurati-
onstemplates und -dateien der einzelnen Kolab-Komponenten angepasst werden. Mithilfe des
Befehls /kolab/sbin/kolabconf werden die Änderungen aus den Templates wirksam.
Beide Strategien sollte ein Systemadministrator eines Kolab Servers anwenden können. Dieses Kapitel
vermittelt die dafür nötigen Kenntnisse.
5.1 Kolab Web­Admin
Der Kolab Server stellt ein Webinterface – den Kolab Web-Admin – zur Verfügung, worüber die gän-
gigsten Servereinstellungen konfiguriert werden können. Der Web-Admin ist unter dem Kolab-Rechner-
namen https://kolab.example.com/admin im Web-Browser zu erreichen. Für den ersten Login kann der
voreingestellte Administratorname manager genutzt werden; das Passwort wurde während der Installa-
tion vergeben. Für die regelmäßige, administrative Arbeit sollte jedoch ein Administrator-Account ange-
legt werden. Nach dem Einloggen erhält der Nutzer eine Navigationsleiste (vgl. Abb. 5.1) mit Links zu
Einstellmöglichkeiten des Kolab Servers.
28

29. 5 Kolab Server – Konfiguration und Betrieb
Abbildung 5.1: Navigationsleiste vom Kolab Web­Admin (manager­Ansicht)
Der Web-Admin ist in PHP geschrieben und nutzt den Apache Webserver (mit mod_php). Das Webinter-
face unterstützt SSL-Verschlüsselung und Authentifikation gegen den Verzeichnisdienst. Der Web-
Admin ist ein LDAP-Verzeichnisdienst-Werkzeug und kommuniziert ausschließlich mit dem LDAP-Ser-
ver (eine Ausnahme sind Sieve-Skripte). In dieser Betriebsdokumentation wird exemplarisch für einige
Konfigurationsmöglichkeiten auf den Web-Admin verwiesen. Weitere Informationen zur Konfiguration
des Kolab Servers mit dem Web-Admin sind in der Kolab-Dokumentation Doc2 zu finden (vgl. Anhang
A).
5.2 Rollen
Der Kolab Server stellt vier Rollen zur Verfügung, die nachfolgend beschrieben werden:
1. Administrator
2. Verwalter
3. Domänenverwalter
4. Benutzer
Darüber hinaus nimmt der Rechner-Administrator (root) eine „Sonderrolle“ ein. Aus Sicherheitsgründen
haben die Kolab-Nutzer in der Regel keine Rechnerkonten und somit keinen direkten Zugriff (z.B. per
ssh) auf den Server.
Abbildung 5.2 veranschaulicht den Zusammenhang der vier Rollen und deren Berechtigungen: Die
Rechte von Benutzer sind eine Untermenge von den Domänenverwalter-Rechten, diese wiederum
Untermenge von Verwalter sind. Die Administratoren-Rechte umfasst alle genannten Berechtigungs-
mengen. Eine detaillierte Auflistung der rollenspezifischen Rechte folgt in den nächsten Abschnitten.
29

30. 5 Kolab Server – Konfiguration und Betrieb
Abbildung 5.2: Die vier Benutzerrollen des Kolab Servers mit ihren Zugriffsberechtigungen auf den
Verzeichnisdienst
5.2.1 Administrator
Die Benutzergruppe Administrator besitzt Lese- und Schreibberechtigung für den LDAP-Verzeichnis-
baum. Ein Administrator hat Zugang zu allen Einstellmöglichkeiten innerhalb des Kolab Web-Admins.
Das Passwort des voreingestellten Administrators manager wurde bei der Installation des Kolab Servers
vergeben und ist bei Verlust in der folgender Datei wiederzufinden (Dies gilt ausschließlich nur für den
manager. Andere Administratoren werden hier nicht gespeichert!):
/kolab/etc/kolab/kolab.conf (Zeile bind_pw).
Zum Ändern des manager Passworts kann der Befehl
/kolab/bin/kolabpasswd
genutzt werden.
Ein Administrator ist berechtigt folgende Aufgaben durchzuführen:
➔ Hinzufügen, Ändern und Löschen von Administratoren
➔ Hinzufügen, Ändern und Löschen von Verwaltern
➔ Hinzufügen, Ändern und Löschen von Domänenverwaltern
➔ Hinzufügen, Ändern und Löschen von Benutzern
➔ Hinzufügen, Ändern und Löschen von externen Adressen
➔ Hinzufügen, Ändern und Löschen von gemeinsam genutzten Ordnern
➔ Hinzufügen, Ändern und Löschen von Verteilerlisten
➔ Konfiguration der Dienste
➔ eigenes Passwort ändern (außer manager)
30

31. 5 Kolab Server – Konfiguration und Betrieb
5.2.2 Verwalter
Die Rolle Verwalter ist die eines Administrators ähnlich – mit dem Unterschied, dass ein Verwalter nicht
berechtigt ist, folgende Aufgaben durchzuführen:
➔ Hinzufügen, Ändern und Löschen von Administratoren
➔ Hinzufügen, Ändern und Löschen von Verwaltern
➔ Konfiguration der Dienste
5.2.3 Domänenverwalter
Im Vergleich zum Verwalter darf ein Domänenverwalter folgende Aufgaben nicht durchführen:
➔ Hinzufügen, Ändern und Löschen von Domänenverwaltern
➔ Hinzufügen, Ändern und Löschen von externen Adressen
➔ Hinzufügen, Ändern und Löschen von Benutzern für fremde (nicht berechtigte) Domänen
5.2.4 Benutzer
Benutzer werden von Administratoren, Verwaltern oder Domänenverwaltern angelegt. Abbildung 5.3
zeigt das Eingabeformular zum Hinzufügen eines Benutzers im Kolab Web-Admin.
Benutzer können sich selbständig über den Web-Admin anmelden und ihre persönlichen Daten ändern.
In der Voreinstellung dürfen folgende Attribute jedoch nur vom Administrator, Verwalter oder Domänen-
verwalter geändert werden:
● Vorname
● Nachname
● Eindeutige Identität (UID = Unique identity)
● Kontotyp
● E-Mail-Aliasnamen
● Plattenplatz des Benutzers in Megabytes
Als Benutzername für den Login beim Kolab Web-Admin kann sowohl die UID also auch die primäre
E-Mail-Adresse (PEM) eines Kontos genutzt werden. Die UID ist in der Voreinstellung gleichzeitig auch
die primäre E-Mail-Adresse. Diese kann aber jederzeit vom Administrator/(Domänen-)Verwalter geän-
dert werden.
Die primäre E-Mail-Adresse und der zugeordnete Kolab-Homeserver kann nach dem Anlegen eines
Kontos nicht mehr geändert werden. Was bei einer Namensänderung oder einer geplanten Migrierung
eines Kontos auf einen anderen Homeserver zu tun ist, zeigt die zweite graue Box auf der übernächsten
Seite. Weitere Informationen zu Kolab-Homeservern sind im Abschnitt 5.12 zu finden.
31

32. 5 Kolab Server – Konfiguration und Betrieb
Abbildung 5.3: Anlegen eines neuen Benutzers im Kolab Web­Admin
LDAP­Attribute ändern
Die Sichtbarkeit und Zugriffsberechtigung der LDAP-Attribute im Web-Admin kann im Template
/kolab/etc/kolab/templates/session_vars.php.template definiert werden. Wichtig:
Diese LDAP-Attributseinstellungen gelten nur für den Kolab Web-Admin!
Um ein Attribut zu ändern, muss dem Array $params['attribute_access'] ein Element hinzuge-
fügt werden. Deren möglichen Rechte sind:
➔ ro (readonly)
➔ rw (read/write)
➔ hidden (atribute removed from display)
➔ mandatory (read/write and must not be empty)
Alle nicht im o. g. Array angegeben Attribute sind auf den voreingestellten Wert rw definiert. Ein Bei-
spiel, wie nur die Attribute „firstname“ und „lastname“ auf „nur lesbar“ gesetzt werden:
$params['attribute_access'] = array('firstname'=>'ro','lastname'=>'ro');
Um die Änderung in dem Template wirksam werden zu lassen, muss anschließend der Befehl
/kolab/sbin/kolabconf aufgerufen werden (vgl. Abschnitt 2.4).
32

33. 5 Kolab Server – Konfiguration und Betrieb
Wie findet man den Kolab­Homeserver zu einem bestimmten E­Mail­Konto?
...mit den Befehlen listusers und showuser:
kolab listusers|grep user
-> user1@example.com
user2@example.com
user3@example.com
kolab showuser user1@example.com|grep -i kolabhome
-> kolabHomeServer: kolab2.example.com
Das Postfach des Benutzers user1@example.com befindet sich also auf kolab2.example.com.
Lösungsalternative: Mit dem Befehl /kolab/sbin/slapcat lässt sich der vollständige Inhalt des
Verzeichnisdienstes ausgeben und kann anschließend nach dem bestimmten E-Mail-Konto durch-
sucht werden.
Was muss man tun, wenn der Name (und damit die primäre E­Mail­Adresse) eines Benutzers sich
ändert (z. B. durch Heirat oder Scheidung)?
Wie lässt sich ein Benutzer auf einen anderen Kolab­Server migrieren?
Der Name kann problemlos von einem Administrator/Verwalter geändert werden. Die primäre E-
Mail-Adresse kann nach dem Anlegen eines Kontos allerdings nicht mehr bearbeitet werden. Die
einfachste Lösung wäre, eine neue Alias-E-Mail-Adresse einzutragen und die UID auf einen neuen
Benutzernamen (z. B. ebenfalls die neue Alias-Adresse) zu ändern.
Alternativ müsste ein neues Benutzerkonto (mit neuem Nachnamen und primärer E-Mail-Adresse)
auf dem (neuen) Kolab Server anlegt und alle alten Daten des Benutzers in das neue Konto kopiert
werden. Diese Variante ist auch für das vollständige migrieren eines Benutzers auf einen anderen
Kolab-Homeserver geeignet. Eine aktuelle Anleitung ist in folgender Datei (im Kolab CVS) enthal-
ten: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/raw-howtos/move-rename-user.txt
5.3 Kontotypen
Zu jedem neu angelegten Benutzer muss einer der vier Kontotypen ausgewählt werden:
1. Benutzerkonto (voreingestellt)
Dies ist der meist gebräuchliche Kontotyp. Die E-Mail-Adresse ist von außen erreichbar und der
Benutzer ist im LDAP-Adressbuch sichtbar.
Speicherort: Base-DN (z. B.: dc=example, dc=com)
2. Internes Benutzerkonto
Dieser Kontotyp ist ähnlich zu (1), mit dem Unterschied, dass die E-Mail-Adresse des Benutzers
nur intern gültig ist. Das bedeutet: der Benutzer kann keine E-Mails nach außen senden oder von
33

34. 5 Kolab Server – Konfiguration und Betrieb
außen empfangen. Er ist damit auch nicht im öffentlichen Kolab-Adressbuch geführt.
Speicherort: unter cn=internal, Base-DN
3. Gruppenkonto
Ein Gruppenkonto ist für das Arbeiten von mehreren Nutzern in einer Gruppen konzipiert. Der
Name des Kontos sollte (zur besseren Übersicht) für den Titel der Arbeitsgruppe stehen. Mit-
hilfe von Sieve lassen sich eingehende E-Mails an eine Kolab-Verteilerliste weiterleiten, deren
Abonnenten gewissermaßen die Mitglieder der Gruppe darstellen (vgl. Abschnitt 5.5.3 und
5.5.7). Um bestimmten Benutzern zu erlauben, E-Mails mit dem Gruppenkonto zu versenden,
müssen deren E-Mail-Adressen als Vertreter eingetragen werden (vgl. Abschnitt 5.5.6.). Das
gemeinsame Nutzen von IMAP-Ordnern innerhalb des Gruppenkontos ist (wie beim Benutzer-
konto) durch das Setzen von Zugriffsrechten für bestimmte Nutzer möglich (vgl. Abschnitt
5.10).
Gruppenkonten haben bereits voreingestellt für den Benutzer calendar Schreibzugriff auf den
eigenen Kalender-Ordner, um automatisch Einladungen annehmen zu können (vgl. Abschnitt
5.7.1).
Speicherort: unter cn=groups, Base-DN
4. Ressourcenkonto
Mit dem Kolab Server können Ressourcen (wie z. B. ein Besprechungsraum, Dienstwagen oder
Beamer) verwaltet werden. Ressourcenkonten haben bereits voreingestellt für den Benutzer
calendar Schreibzugriff auf den eigenen Kalender-Ordner, um automatisch Einladungen anneh-
men zu können (vgl. Abschnitt 5.7.1).
Speicherort: unter cn=resources, Base-DN
Jedes Konto braucht einen Inhaber. Insbesondere bei Gruppen- und Ressourcenkonten ist es wichtig,
dass es eine zuständige Person gibt, die das Konto pflegt und z. B. von unerwünschten Nachrichten
bereinigt. Diese Person muss nicht der Systemadministrator sein; im Gegenteil: es sollte eher eine der
Gruppe oder der Ressource inhaltlich nahe stehende Person damit beauftragt werden.
5.4 Nutzerlebenszyklus
Anlegen im Webinterface
➔ Der Webinterface-Code überprüft, ob die E-Mail-Adresse, die UID oder eines der Alias-Einträge
mit bestehenden Nutzern, Verteilerlisten oder Adressbucheinträgen kollidiert und verweigert in
diesem Fall das Anlegen.
➔ Das LDAP-Objekt im Kolab-Master wird angelegt.
➔ Replikation auf Kolab-Slaves
➔ Replikation zu allen kolabd-Prozessen
➔ kolabd auf allen Servern legen IMAP-Mailboxen an.
Die INBOX wird nicht nur auf dem Kolab-Homeserver angelegt, damit IMAP-Klienten zum
Lesen von freigegebenen Ordnern auch die anderen Server kontaktieren können.
Auf dem Kolab-Homeserver bleiben die IMAP-ACLs auf den Standardwerten, bei Ressourcen-
34

35. 5 Kolab Server – Konfiguration und Betrieb
und Gruppenkonten wird zusätzlich noch dem calendar-Benutzer Zugriff gewährt.
Auf den anderen Servern wird die Lookup-Berechtigung entfernt, so dass die Mailbox unsicht-
bar ist.
Umbenennen im Webinterface
➔ Der Webinterface-Code überprüft, ob der umzubenennende Benutzer ein Mitglied einer Vertei-
lerliste ist und passt diese ggf. an.
➔ Das LDAP-Objekt im Kolab-Master wird umbenannt.
➔ Replikation auf Kolab-Slaves
➔ Da die primäre E-Mail-Adresse nicht geändert werden kann, müssen keine weiteren Änderungen
durchgeführt werden.
Löschen im Webinterface
➔ Der Webinterface-Code überprüft, ob der zu löschende Benutzer ein Mitglied einer Verteilerliste
ist. Ist er das einzige Mitglied wird die Löschung verweigert, ansonsten wird der Benutzer aus
der Verteilerliste entfernt.
➔ Das LDAP-Objekt kolabInetOrgPerson im Kolab-Master erhält kolabDeleteflag-Einträge für
den Master-Server und alle Slave-Server, z.B.:
kolabDeleteflag: kolab-master.example.com
kolabDeleteflag: kolab-slave1.example.com
kolabDeleteflag: kolab-slave2.example.com
➔ Replikation auf Kolab-Slaves
➔ Replikation zu allen kolabd-Prozessen
➔ kolabd auf allen Slaves löschen die lokalen IMAP-Mailboxen und entfernen danach ihren kolab-
Deleteflag-Eintrag im LDAP des Kolab-Masters.
➔ Replikation zum kolabd-Prozess auf dem Master
➔ Wenn der kolabd auf dem Master feststellt, dass nur noch der eigene kolabDeleteflag-Eintrag
vorhanden ist, löscht er die lokalen IMAP-Mailboxen, die Einträge im Kolab-uid-Cache und
Mailbox-Quota-Cache und das Benutzerobjekt.
Wenn die Kolab-Server in einem existierenden Verzeichnisdienst eingebunden werden, ist es oft
sinnvoll, wenn der kolabd nicht das vollständige Objekt löscht, sondern nur die kolabspezifi-
schen Teile. Hierzu muss in der kolab.conf ein Eintrag kolab_remove_objectclass : 1
ergänzt werden. Falls noch weitere Attribute entfernt werden sollen, können diese zusätzlich mit
der Konfigurationsoption kolab_remove_attributes angegeben werden, z.B.:
kolab_remove_objectclass : 1
kolab_remove_attributes : mail ou
35

36. 5 Kolab Server – Konfiguration und Betrieb
5.5 E­Mail
Der nachfolgende Abschnitt beschreibt, wie der E-Mail-Betrieb auf dem Kolab Server funktioniert und
an welchen Stellen der Administrator diesen Betrieb konfigurieren kann.
5.5.1 Die IMAP Spool Struktur
Der Cyrus IMAP-Server speichert alle E-Mails als einzelne Dateien in seinem Spool-Verzeichnis, das
bei einer typischen Kolab-Installation unter /kolab/var/imapd/spool liegt. Zur übersichtlicheren
Verwaltung bei sehr vielen Nutzern, verwendet der Kolab Server (seit Version 2.1) die Option
hashimapspool: yes. Danach folgt die Struktur des Spool-Verzeichnisses dem Muster:
.../spool/domain/e/example.com/m/user/meier/[Ordner/...]
Die Domänen und Benutzer liegen in Verzeichnissen, die ihren jeweiligen Anfangsbuchstaben entspre-
chen: in dem o. g. Beispiel liegt also das Verzeichnis für example.com in dem Verzeichnis e. Im Unter-
schied dazu werden Gruppenkonten unter ../user/<Gruppenname> und Ressourcenkonten unter
../user/<Ressourcenname> gespeichert.
Das eigentliche Benutzer-Verzeichnis entspricht der jeweiligen IMAP-Inbox, alle Unterverzeichnisse
entsprechen den IMAP-Unterordnern. Die Ordner enthalten jeweils Dateien, deren Name eine Zahl
gefolgt von einem Punkt ist. Diese Dateien enthalten die eigentlichen E-Mails. Im gleichen Ordner
befinden sich die drei Dateien cyrus.cache, cyrus.header und cyrus.index, die bestimmte Metainforma-
tionen der Nachrichten speichern.
Mit diesen Kenntnissen kann der Administrator leicht E-Mails eines bestimmten Anwenders im Backup
finden. Die unter /kolab/var/imapd/log liegenden Logdateien bieten zusätzliche Informationen,
wann aus welchen Postfächern E-Mails gelöscht wurden.
5.5.2 Der Weg einer E­Mail
Trifft eine E-Mail am Kolab-Server ein, durchläuft sie verschiedenen Komponenten des Servers. Dieser
Weg einer E-Mail – vom SMTP-Eingangsserver bis in das IMAP-Ordner des Kolab-Nutzers – wird in
Abbildung 5.4 veranschaulicht und in den folgenden Schritten erläutert:
1. Die E-Mail wird von Postfix auf dem SMTP-Port 25 entgegengenommen.
2. Postfix konsultiert den kolab_policy (/kolab/etc/kolab/kolab_smtpdpolicy). Dieser
überprüft z. B., ob der Sender berechtigt ist an die adressierte Kolab Verteilerliste zu schreiben.
3. Postfix übergibt anschließend die Nachricht an den kolabfilter (/kolab/var/kolab-filter
/scripts/kolabfilter.php). Handelt es sich bei der Empfänger-Adresse um eine Vertei-
lerliste oder eine Kolab Alias-Adresse, so wird vorher die Adresse in die primäre E-Mail-
Adresse aufgelöst. Bei einer Verteilerliste existiert anschließend weiterhin noch eine E-Mail,
jedoch mit allen einzelnen Empfänger-Adressen der Listenmitglieder.
4. Nachdem kolabfilter seine Aufgabe beendet hat, übergibt er die Mail per SMTP an Postfix (Port
10025).
36

37. 5 Kolab Server – Konfiguration und Betrieb
5. Sofern E-Mail-Scanning mit amavisd-new aktiviert ist, wird die Nachricht von Postfix über
SMTP an amavisd-new (Port 10025) zugestellt (Ist amavisd-new deaktiviert, wird mit Schritt 9
fortgesetzt.) Amavisd-new filtert die Mail zunächst nach unerwünschten Absendern und nicht
zugelassenen Anhängen, ...
6. ... bevor amavisd-new die Nachricht von ClamAV auf Viren...
7. ... und anschließend von SpamAssassin auf Spam überprüfen lässt.
8. Nachdem die E-Mail als harmlos befunden wurde, wird sie per SMTP an Postfix an den Port
10026 übergeben.
9. Postfix stellt die gefilterte Nachricht an den kolabmailboxfilter (/kolab/var/kolab-
filter /scripts/kolabmailboxfilter.php) zu. Bei einer Nachrichten an mehrere
Empfänger werden daraus vorher mehrere Nachrichten mit jeweils nur einem Empfänger
(aufgrund der Postfix-Voreinstellung: local_destination_recipient_limit=1). Der
kolabmailboxfilter übergibt die E-Mail an den LMTP-Port 2003, vgl.
/kolab/lib/php/Kolab/Filter/ kolabmailtransport.php.
10. Auf Port 2003 lauscht der Cyrus LMTPD, der die Nachricht entgegen nimmt, ...
11. ... sofern vorhanden, ein aktiviertes Sieve-Skript ausführt (andernfalls wird dieser Schritt igno-
riert) ...
12. ... und die Nachricht in den entsprechenden IMAP-Benutzerordner ausliefert.
37

38. 5 Kolab Server – Konfiguration und Betrieb
Abbildung 5.4: Der Weg einer E­Mail im Kolab Server
38

39. 5 Kolab Server – Konfiguration und Betrieb
5.5.3 Weiterleitung
Ein Benutzer ist berechtigt eine E-Mail-Weiterleitung an jede beliebige E-Mail-Adresse einzurichten.
Die Aktivierung kann vom Benutzer selbständig im Kolab Web-Admin (innerhalb seiner eigenen Benut-
zereinstellungen) erfolgen. Es besteht die Möglichkeit Kopien der weitergeleiteten E-Mails auf dem
Kolab-Server zu belassen.
5.5.4 Abwesenheitsbenachrichtigung
Ein Benutzer kann in seiner Abwesenheit das automatische Versenden von Antworten auf eingehende E-
Mails aktivieren. Die nötigen Einstellungen können innerhalb der Web-Admin-Benutzereinstellungen
vorgenommen werden (vgl. Abbildung 5.5).
Abbildung 5.5: Einstellungen für Abwesenheitsbenachrichtigungen im Kolab Web­Admin
Anmerkung zum erneuten Benachrichtigungsversand: Die Einstellung in obiger Abbildung (7 Tage)
bedeutet, dass das Senden einer Abwesenheitsbenachrichtigung aktiviert wurde und falls innerhalb von 7
Tagen weitere Mails desselben Absenders eingehen, nur die erste Nachricht automatisch beantwortet
wird. Nach Ablauf dieser Frist wird erneut eine Abwesenheitsnachricht versandt. Dies soll unnötigen E-
Mail-Verkehr vermeiden helfen.
Anmerkung zu Spam-Mails: Bei Aktivierung der Option Keine Abwesenheitsbenachrichtigungen auf
Spamnachrichten senden wird keine Nachricht an den Absender geschickt, wenn die E-Mail als Spam
deklariert wurde.
Anmerkung zur Domain-Angabe: Sofern eine Mail-Domäne angegeben wird, bekommen nur Absender
dieser Domäne Abwesenheitsbenachrichtigungen zugesandt. Dadurch kann diese Funktion z. B. auf
Nachrichten einer Organisation beschränkt werden.
39

40. 5 Kolab Server – Konfiguration und Betrieb
5.5.5 Serverseitige Filterung mit Sieve
Sieve ist eine Skriptsprache, die speziell für das serverseitige Filtern von E-Mails konzipiert wurde. Die
genaue Spezifikation kann im RFC 3028 nachgelesen werden. Der Kolab Server nutzt Sieve u. a. für
Weiterleitungen und Abwesenheitsbenachrichtigungen (vgl. Abschnitt 5.5.3 und 5.5.4). Ein Benutzer
kann immer nur ein Sieve-Skript zur gleichen Zeit aktiviert haben. Im Web-Admin kann aus drei vorde-
finierten Sieve-Skripten – zum Verteilen, Weiterleiten und Verschicken von Abwesenheitsbenachrichti-
gungen (vgl. vorhergehende Abschnitte) – ausgewählt werden.
Manchmal kann es nützlich sein, ein selbst erstelltes Sieve-Skript mit mehreren unterschiedlichen Filter-
regeln zu definieren. Ein Weg das fertige Skript hochzuladen und zu aktivieren ist sieveshell. Es ist zu
beachten, dass sieveshell eine unverschlüsselte Verbindung nutzt. Es wird daher dringendst empfohlen
sieveshell nur direkt auf dem Kolab- Server oder über eine verschlüsselte Netzwerkverbindung auszu-
führen.
Starten von sieveshell (das manager-Passwort wird dafür benötigt):
/kolab/bin/sieveshell --user=user@example.com --authname=manager localhost
Der Befehl muss als root ausgeführt werden, sofern das Sieve-Skript für eine andere Person gesetzt wer-
den soll.
Mit nachfolgenden sieveshell-Befehlen lassen sich alle Sieve-Skripte des Nutzers auf dem Server anzei-
gen (list), das Skrip hochladen (put) und aktivieren (activate) und schließlich sieveshell wieder
beenden (quit):
> list
> put example.siv
> activate example.siv
> quit
Mit help lassen sich alle sieveshell-Befehle mit einer kurzen Erklärung auflisten.
Um eintreffende E-Mails nicht alle im zentralen Posteingang des Benutzers zu haben, ist es mit Sieve
möglich diese Nachrichten bereits serverseitig in bestimmte IMAP-Ordner einzusortieren (nützlich z. B.
um E-Mails aus verschiedenen Mailinglisten automatisch in bestimmte Unterordner verschieben zu las-
sen). Das nachfolgende Sieve-Skript-Beispiel demonstriert diesen Fall, wobei Sieve zusätzlich Abwesen-
heitsbenachrichtigungen nur an Absender einer Mail-Domain sendet:
require "vacation";
require "fileinto";
if allof (not header :contains "X-Spam-Flag" "YES",
address :domain :contains "From" "example.com" ) {
vacation :addresses [ "usera@example.com", "mr.a@example.org" ] :days 7 text:
Ich bin bis 01.12.2007 abwesend.
In dringenden Fällen nehmen Sie bitte mit <Urlaubsvertretung> Kontakt auf.
E-Mail: <E-Mail-Adresse der Urlaubsvertretung>
Telefon: +49 711 1111 11
Fax: +49 711 1111 12
40

41. 5 Kolab Server – Konfiguration und Betrieb
Mit freundlichen Grüßen,
Max Mustermann
;
}
if header :contains ["X-Kolab-Scheduling-Message"] ["FALSE"] {
fileinto "INBOX/incoming";
}
if header :contains ["List-Id"] ["list.example.com"] {
fileinto "INBOX/list";
stop;
}
Sieve-Skripte eignen sich auch gut zum Ausfiltern von Spam-Nachrichten (vgl. Abschnitt 5.5.9).
Eine ausführliche Beschreibung von Sieve, dessen Befehle und Syntax sowie weiterführenden Beispie-
len ist in diesem deutschsprachigen Artikel1 zu finden.
5.5.6 E­Mail­Vertreter
Wenn ein Benutzer einen Vertreter bestimmt, kann dieser Vertreter mit der E-Mail-Adresse des Benut-
zers Nachrichten versenden. Dies ist dann hilfreich, wenn der Vertreter beispielsweise den Kalender des
Benutzers verwalten darf und z. B. der Sekretär im Namen seines Chefs Einladungen verschicken kann.
Vertreter dürfen sowohl für Benutzerkonten als auch für Gruppen- oder Ressourcenkonten definiert wer-
den.
Es können nur Kolab-Nutzer als Vertreter bestimmt werden (aufgrund der Nachrichtenfilterregelung –
vgl. Abschnitt 5.5.12). Ein externer Nutzer kann kein Vertreter sein. Das Bestimmen mehrerer Vertreter
ist möglich.
Ein Benutzer kann seine Vertretung mit dem Eintragen der Vertreter-E-Mail-Adresse(n) innerhalb seiner
Web-Admin-Benutzereinstellungen aktivieren.
Anmerkung: Wenn ein Vertreter im Namen des Benutzers Einladungen aussprechen können soll, müssen
dem Vertreter auch Schreibrechte für den Kalenderordner des Benutzers erteilt werden. In KDE Kontact
z. B. kann der Benutzer dies unter Kontexmenü Kalender → Einstellungen → Zugriffskontrolle einstel-
len. Falls der Kalenderordner ausgeblendet ist, vorher unter Einstellungen → Kontact einrichten... →
E-Mail → Diverses → Arbeitsgruppen → Arbeitsgruppenordner ausblenden das Häkchen deaktivieren.
Alternativ kann der Rechneradministrator mit dem cyradm-Kommando setaclmailbox die nötigen
Rechte setzen2.
Im Kolab-Klient des Vertreters muss entsprechend eine neue Identität eingerichtet werden. Die bisheri-
gen SMTP-Einstellungen des Vertreters müssen für diese neue Identität nicht verändert werden.
1 http://www.holtmann.org/email/sieve/ [Abruf: 07.12.2007]
2 http://www.oreilly.com/catalog/mimap/chapter/ch09.html#98759 [Abruf: 07.12.2007]
41

42. 5 Kolab Server – Konfiguration und Betrieb
5.5.7 Verteilerlisten
Eine Verteilerliste wird zum Verteilen von E-Mails an alle eingetragene Mitglieder dieser Liste verwen-
det und kann zum Setzen von Rechten verwendet werden. Jede Verteilerliste besitzt eine E-Mail-Adresse
von der eintreffende E-Mails an alle Mitglieder der Liste weitergeleitet werden. Im Unterschied zu Grup-
penkonten (siehe Abschnitt 5.3) können in Verteilerlisten auch externe Adressen aus dem Kolab-Adress-
buch aufgenommen werden.
Verteilerlisten können nur von Administratoren, Verwalter oder Domänenverwalter erstellt und verwaltet
werden. Nach dem Anlegen einer Verteilerliste ist diese sofort nutzbar. Abbildung 5.6 zeigt das Eingabe-
formular im Kolab Web-Admin zum Anlegen einer neuen Verteilerliste. Bei Aktivierung der Option Ver-
borgen steht eine Verteilerliste nur für authentifizierte Nutzer zur Verfügung; d. h. nur authentifizierte
Nutzer sind berechtigt, an diese Liste E-Mails zu senden. Die Verteilerliste wird im Status Verborgen bei
einer LDAP Suche mit einer nicht-authentifizierten Verbindung im Kolab-Klient nicht angezeigt.
Anmerkung: Ein authentifizierter Anwender ist ein Anwender, der sich mit seinem Benutzernamen und
Passwort am Kolab-Server anmelden kann. Wenn ein nicht authentifizierten Nutzer (Nicht-Kolab-Nut-
zer) in eine Verteilerliste aufgenommen werden soll, muss dieser zuvor im externen Adressbuch angelegt
werden. Der Nutzer kann dadurch E-Mails, die an diese Liste gerichtet sind, empfangen. Falls die Ver-
borgen-Option aktiviert ist, kann er aber keine E-Mails an diese Liste senden.
Abbildung 5.6: Anlegen einer neuen Verteilerliste im Web­Admin
42

43. 5 Kolab Server – Konfiguration und Betrieb
5.5.8 Virenfilter­Konfiguration
Der Kolab Server nutzt nach der Installation standardmäßig den Virenscanner amavisd-new3 in Verbin-
dung mit Clam AntiVirus4. Im folgenden Abschnitt werden diese beiden Werkzeuge erläutert.
Amavisd­new
Amavisd-new bildet im Kolab Server die Schnittstelle zwischen Postfix auf der einen Seite sowie
SpamAssassin und ClamAV auf der anderen. Amavisd-new ist der Nachfolger von AMaViS (= A Mail
Virus Scanner).
Amavisd­new im Kolab Server 2.2
➔ Template: /kolab/etc/kolab/templates/amavisd.conf.template
➔ Konfigurationsdatei: /kolab/etc/amavisd/amavisd.conf
➔ Logdatei: /kolab/var/amavisd/amavisd.log
➔ Quarantäne-Verzeichnis: /kolab/var/amavisd/virusmails
➔ Start-Kommandos: /kolab/bin/openpkg rc amavisd {start|stop|status|
restart}
Abbildung 5.5.2 auf Seite 38 veranschaulicht die Arbeitsweise von amavisd-new:
Eine bei Postfix eintreffende E-Mail wird in Schritt 5 der Abbildung an amavisd-new (an Port 10024)
übergeben. Amavisd-new filtert die Nachricht zunächst nach unerwünschten Absendern und nicht zuge-
lassenen Anhängen und ruft zur Virenprüfung ClamAV [6] und anschließend (wenn die Nachricht viren-
frei ist) SpamAssassin [7] auf. Wenn die E-Mail als harmlos befunden wurde, übergibt amavisd-new sie
zurück zu Postfix an Port 10026 [8]. Andernfalls landet die Nachricht im Quarantäne-Verzeichnis (siehe
Kasten oben).
Eine gebannte Nachricht aus dem Quarantäne-Verzeichnis kann z. B. (als Nuter kolab-r) durch
/kolab/bin/cyrdeliver user@example.com < /kolab/var/amavisd/virusmails/banned-kXuJ2d3uGVCT
in das Postfach eines Kolab Nutzers manuell ausgeliefert werden.
Einstellungen zu den Viren-, Mail- und Spam-Filter (wie z. B. ClamAV und SpamAssassin) können über
das zentrale amavisd-Template /kolab/etc/kolab/templates/amavisd.conf.template defi-
niert werden. Um Änderungen im Template wirksam werden zu lassen, muss /kolab/sbin/kolab-
conf zum Generieren der Konfigurationsdatei ausgeführt (vgl. Abschnitt 2.4) und amavisd-new neu
gestartet (Kommando: siehe oben im Kasten) werden.
3 http://www.ijs.si/software/amavisd/ [Abruf: 07.12.2007]
4 http://www.clamav.net/ [Abruf: 07.12.2007]
43

44. 5 Kolab Server – Konfiguration und Betrieb
ClamAV
ClamAV ist ein Freier-Software-Virenscanner und Phishing-Filter, der nach jeder Kolab Server Installa-
tion standardmäßig als primärer Scanner aktiv ist. Clamscan ist der kommandozeilenbasierte Virenscan-
ner und kann z. B. auf das aktuelle Verzeichnis mit dem Befehl /kolab/bin/clamscan ausgeführt
werden. Clamscan wird automatisch dann zum Überprüfen von Viren in E-Mails eingesetzt, wenn alle
anderen Virenscanner ausgefallen sind.
Es ist problemlos möglich andere, auch proprietäre, Virenscanner zu installieren und diese an Stelle von
oder zusätzlich mit ClamAV auf dem Kolab Server zu nutzen. Dafür muss die ClamAV-Einstellung im
amavisd-new Konfigurationstemplate editiert werden (vgl. externe Anleitung5).
ClamAV im Kolab Server 2.2
➔ Template: /kolab/etc/kolab/templates/clamd.conf.template
und /kolab/etc/kolab/templates/freshclam.conf.template
➔ Konfigurationsdatei: /kolab/etc/clamav/clamd.conf
und /kolab/etc/clamav/freshclam.conf
➔ Logdatei: /kolab/var/clamav/clamd.log
➔ Start-Kommandos: /kolab/bin/openpkg rc clamav {start|stop|status|
restart}
➔ Update-Kommando (als kolab-r): /kolab/bin/freshclam
Die Virusinformations-Datenbank wird automatisch in regelmäßigen Abständen durch einen voreinge-
stellten Cronjob auf /kolab/bin/freshclam aktualisiert. Das voreingestellte Updateintervall von
einer Stunde kann im Template /kolab/etc/kolab/templates/rc.conf.template (in der Zeile
clamav_update = "hourly") geändert werden. In der /etc/crontab werden die Parameter
hourly und weitere definiert.
ClamAV überprüft auch alle Dateien innerhalb von Archiven (z. B. *.tar.gz oder *.zip).
5 http://www.activmedia.ch/groupware5.php#viren [Abruf: 07.12.2007]
44

45. 5 Kolab Server – Konfiguration und Betrieb
5.5.9 Spamfilter­Konfiguration
Unerwünschte Nachrichten lassen sich auf mehrere verschiedene Arten ausfiltern. Dieser Abschnitt kon-
zentriert sich auf die Spamfilter-Möglichkeiten von SpamAssassin und erläutert dessen Konfiguration.
SpamAssassin
SpamAssassin im Kolab Server 2.2
➔ Template: –
➔ Konfigurationsdatei: /kolab/etc/spamassassin/local.cf
➔ Logdatei: /kolab/var/spamassassin/spamassassin.log
➔ Bayes-Datenbank: /kolab/var/amavisd/.spamassassin
➔ Start-Kommandos: /kolab/bin/openpkg rc spamassassin {start|stop|status|
restart}
Die Kommandos gelten nur für spamd, welcher von amavisd-new nicht verwendet wird und des-
halb in rc.conf.template standardmäßig abgeschaltet ist. Wird SpamAssassin über amavisd-new
genutzt, gelten nur die amavisd-new-Kommandos.
Nach der Installation von Kolab Server ist der Mailscanner amavisd-new so konfiguriert, dass der mit
Kolab ausgelieferte Spamfilter SpamAssassin aktiv ist.
Die Konfiguration erfolgt in der Datei /kolab/etc/spamassassin/local.cf. Einige Funktionen
von SpamAssassin sollten hier nicht mehr benutzt werden, da sie in amavisd-new integriert sind, wie
z.B. Whitelist/Blacklist, Spam-Grenzwert und Header-/Body-Änderungen. Eingestellt werden hier also
nur noch der statistische Bayes-Filter, eigene Regeln und Wertigkeiten für bestehende Regeln. Da
SpamAssassin in amavisd-new integriert ist, muss nach Änderungen
/kolab/etc/rc amavisd restart
ausgeführt werden.
SpamAssassin arbeitet mit verschiedenen Tests, die je nach Ergebnis sogenannte X-Spam-Scores verge-
ben. Diese Scores können positive oder negative Werte sein, je höher eine Nachricht am Ende bewertet
ist, desto wahrscheinlicher ist sie Spam. Ab dem voreingestellten Schwellwert für X-Spam-Score von
$sa_tag_level_deflt = 3.0 (vgl. amavisd-Template) wird die Nachricht als Spam markiert.
Zusätzlich zu dieser Markierung wird eine unerwünschte Nachricht in das Quarantäne-Verzeichnis
kopiert (aufgrund der Voreinstellung im amavisd-Template: $final_spam_destiny = D_PASS;).
Sollen Spam-Mails ausschließlich in der Quarantäne (und nicht beim Empfänger) ankommen, dann ist
der Wert von D_PASS auf D_DISCARD umzustellen.
Im Gegensatz dazu werden Spam-Nachrichten nie in das Quarantäne-Verzeichnis kopiert, wenn der o. g.
X-Spam-Score auf $sa_tag_level_deflt = 999.0; gesetzt wird. In diesem Fall sollte
$final_spam_destiny = D_PASS; gesetzt sein, damit die Nachrichten an die Empfänger ausgelie-
fert werden.
Jede als Spam bewertete E-Mail, wird ein X-Spam-Level-Feld im Header hinzugefügt.
45

46. 5 Kolab Server – Konfiguration und Betrieb
SpamAssassin in der Grundkonfiguration ist noch nicht sehr mächtig. Um eine höhere Trefferquote zu
erreichen, muss dieser lernen was Spam ist und was nicht. Dazu muss der verwendete Bayes-Filter trai-
niert werden. Nachfolgend werden drei Methoden beschrieben, wie SpamAssassin zum Spam melden
(und lernen) genutzt werden kann:
1. Eine Möglichkeit besteht darin einen neuen Benutzer anzulegen; z. B. spam@example.com. In sei-
nem IMAP-Postfach werden zwei Unterordner erstellt – spam und nospam – mit entsprechenden
Lese-/Schreibzugriffen für die gewünschten Benutzer, welche diese Ordner pflegen sollen. Diese
Benutzer können nun eintreffende Spam-Mails, welche als solche nicht erkannt wurden, in den Ord-
ner /user/spam/spam verschieben. Abschließend werden zwei cronjob-Einträge vorgenommen,
um mit Hilfe der manuell einsortierten Spam-Nachrichten die SpamAssassin-Datenbank stündlich
(hier zu jeder vollen Stunde) auf den neusten Stand zu bringen. Dazu muss in die Datei
/etc/crontab folgende zwei Zeilen hinzugefügt werden (als root):
0 * * * * kolab-r /kolab/bin/sa-learn
--dbpath /kolab/var/amavisd/.spamassassin
--spam /kolab/var/imapd/spool/domain/e/example.com/s/user/spam/spam
--ham /kolab/var/imapd/spool/domain/e/example.com/s/user/spam/nospam
Anmerkung: Eine effektive Methode, um SpamAssassin neuen Spam beizubringen, ist eine „Spam-
Falle“. Dazu kann die oben angelegte spam@example.com Adresse in diversen spamverdächtigen
Internetseiten veröffentlicht/eingetragen werden. Nach kurzer Zeit werden so kontinuierlich neue
Spam-Mails eintreffen, die sich gut zum Spam-Erlernen eignen.
2. Methode (1) lässt sich auch ohne der Freigabe von IMAP-Ordner realisieren:
Um Spam-E-Mails zu melden, leiten Benutzer unerwünschte Nachrichten einfach an die Adresse
spam@example.com weiter. Der Posteingang dieses Kontos kann so vollständig zum Spam-Lernen
genutzt werden.
3. Eine weitere Variante von Methode (1), um auf einen gemeinsamen Spam-Ordner zu verzichten, ist
ein lokaler IMAP-Order des Benutzers. Das sa-lern-Kommando wird dann mit cronjobs auf den
lokalen Spam-Ordnern aller Benutzer ausgeführt.
4. Eine andere Möglichkeit Spam zu melden besteht darin, zwei (gemeinsam genutzte) kontolose Ord-
ner für den Spam-Lern-Prozess einzusetzen. Die angelegten Spam-/Nicht-Spam-Ordner liegen auf
gleicher Ebene wie die Benutzerpostfächer (im Spool-Verzeichnis).
Diese Möglichkeit wird jedoch aus Gründen der Instabilität von kontolosen Ordnern nicht empfoh-
len (vgl. Abschnitt 5.10.2).
46