Allgemeine BetriebsdokumentationfürKolab Server 2.2Version: 1.0Osnabrück, am 3. Januar 2008
Änderungsverzeichnis                                          Geänderte                Änderung                           ...
InhaltsverzeichnisKapitel 1:  Einführung                                                                                  ...
5.5.8 Virenfilter-Konfiguration..............................................................43         5.5.9 Spamfilter-K...
1 Einführung               Kolab ist eine Freie Lösung, die Groupware-Funktionalitäten bietet. Kolab spe-               zi...
1 EinführungDiese Betriebsdokumentation bezieht sich auf die OpenPKG-Variante von Kolab Server 2.2 (vgl.Abschnitt 2.3). Da...
1 Einführung     ➔   Nutzerdaten werden in Ordnern auf dem Server gespeichert.     ➔   Ein Ordner enthält Objekte eines Ty...
1 Einführungwar. Es folgte das Kolab Server 2.1 Release im Mai 2007. Kolab Server 2.2 ist aktuell in der Entwick-lung. Das...
2 Die Komponenten des                                                                     Kolab ServersDieses Kapitel gibt...
2 Die Komponenten des Kolab Servers    ➔   OpenLDAP        OpenLDAP ist ein Verzeichnisdienst, der sich über das Protokoll...
2 Die Komponenten des Kolab ServersDie Kolab Server/OpenPKG-Version nutzt zusätzlich die freie Komponente OpenPKG:    ➔ Op...
2 Die Komponenten des Kolab Servers2.3  OpenPKGDie Kolab Server/OpenPKG-Variante nutzt eine Schicht zwischen Anwendung und...
2 Die Komponenten des Kolab Servers    b) setzen der Pfade in Umgebungsvariablen MANPATH, PATH, LIBRARY_PATH usw. Die Nut-...
2 Die Komponenten des Kolab Servers     Abbildung 2.3: Arbeitsweise des Kolab­Server­Konfigurationssystems – vereinfacht f...
2 Die Komponenten des Kolab ServersKonfiguration durch TemplatesDie Kolab-Komponenten werden durch Konfigurationsdateien k...
2 Die Komponenten des Kolab ServersProblemsuche in kolabd / kolabconfDer kolabd ist das Bindeglied zwischen dem Verzeichni...
3 Kolab Server –                                                           BedarfsplanungEs empfiehlt sich den eigenen Bed...
3 Kolab Server – BedarfsplanungEntscheidend wird der Umgang mit Alt-Daten im System sein. Was werden die Nutzer tun, wenn ...
3 Kolab Server – Bedarfsplanung3.4  Wer arbeitet mit wem?Es kann sinnvoll sein, aus Gründen der Leistung oder verschiedene...
4 Kolab Server – Vorbereitung                                                                     und InstallationIn diese...
4 Kolab Server – Vorbereitung und Installation                            verwenden. Frühere Versionen haben einen Defekt ...
4 Kolab Server – Vorbereitung und Installation4.2  InstallationIm folgenden Abschnitt werden die Schritte zur Installation...
4 Kolab Server – Vorbereitung und Installation    Ein exemplarischer(!) Bootstrapping-Prozess    Eingabe des Hostnamens   ...
4 Kolab Server – Vorbereitung und Installation    Erstellen einer eigenen Test-Zertifizierungsstelle und eines Zertifikats...
4 Kolab Server – Vorbereitung und Installation    Am Ende des Bootstrappings sollte die Ausgabe der folgenden ähnlich sein...
4 Kolab Server – Vorbereitung und Installation     3. Nach dem Aktualisieren der Kolab Server Pakete in dem Verzeichnis, i...
4 Kolab Server – Vorbereitung und InstallationTreten Unsicherheiten/Schwierigkeiten beim Durchführen von Sicherheitsupdate...
5 Kolab Server – Konfiguration                                                                      und BetriebDieses Kapi...
5 Kolab Server – Konfiguration und Betrieb                  Abbildung 5.1: Navigationsleiste vom Kolab Web­Admin (manager­...
5 Kolab Server – Konfiguration und Betrieb      Abbildung 5.2: Die vier Benutzerrollen des Kolab Servers mit ihren Zugriff...
5 Kolab Server – Konfiguration und Betrieb5.2.2  VerwalterDie Rolle Verwalter ist die eines Administrators ähnlich – mit d...
5 Kolab Server – Konfiguration und Betrieb                     Abbildung 5.3:  Anlegen eines neuen Benutzers im Kolab Web­...
5 Kolab Server – Konfiguration und Betrieb Wie findet man den Kolab­Homeserver zu einem bestimmten E­Mail­Konto? ...mit de...
5 Kolab Server – Konfiguration und Betrieb        außen empfangen. Er ist damit auch nicht im öffentlichen Kolab-Adressbuc...
5 Kolab Server – Konfiguration und Betrieb        und Gruppenkonten wird zusätzlich noch dem calendar-Benutzer Zugriff gew...
5 Kolab Server – Konfiguration und Betrieb5.5  E­MailDer nachfolgende Abschnitt beschreibt, wie der E-Mail-Betrieb auf dem...
5 Kolab Server – Konfiguration und Betrieb    5. Sofern E-Mail-Scanning mit amavisd-new aktiviert ist, wird die Nachricht ...
5 Kolab Server – Konfiguration und Betrieb                             Abbildung 5.4: Der Weg einer E­Mail im Kolab Server...
5 Kolab Server – Konfiguration und Betrieb5.5.3  WeiterleitungEin Benutzer ist berechtigt eine E-Mail-Weiterleitung an jed...
5 Kolab Server – Konfiguration und Betrieb5.5.5  Serverseitige Filterung mit SieveSieve ist eine Skriptsprache, die spezie...
5 Kolab Server – Konfiguration und Betrieb    Mit freundlichen Grüßen,    Max Mustermann    ;    }    if header :contains ...
5 Kolab Server – Konfiguration und Betrieb5.5.7  VerteilerlistenEine Verteilerliste wird zum Verteilen von E-Mails an alle...
5 Kolab Server – Konfiguration und Betrieb5.5.8  Virenfilter­KonfigurationDer Kolab Server nutzt nach der Installation sta...
5 Kolab Server – Konfiguration und BetriebClamAV ClamAV ist ein Freier-Software-Virenscanner und Phishing-Filter, der nach...
5 Kolab Server – Konfiguration und Betrieb5.5.9  Spamfilter­KonfigurationUnerwünschte Nachrichten lassen sich auf mehrere ...
5 Kolab Server – Konfiguration und BetriebSpamAssassin in der Grundkonfiguration ist noch nicht sehr mächtig. Um eine höhe...
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Upcoming SlideShare
Loading in...5
×

Allgemeine betriebsdokumentation-kolab server22-20080103_1.0

7,805

Published on

Published in: Automotive
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,805
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Allgemeine betriebsdokumentation-kolab server22-20080103_1.0

  1. 1. Allgemeine BetriebsdokumentationfürKolab Server 2.2Version: 1.0Osnabrück, am 3. Januar 2008
  2. 2. Änderungsverzeichnis Geänderte Änderung Beschreibung der Änderung Autor Kapitel Nr Datum Version 1 2008-01-03 1.0 Emanuel SchützeAktueller Status: Fertig gestelltImpressum© 2007 Intevation GmbHVersion: 1.0Autor: Emanuel SchützeFachliche Leitung: Bernhard Reiter, Thomas Arendsen HeinKontakt: 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. 3. InhaltsverzeichnisKapitel 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?...............................................................8Kapitel 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...............................................................13Kapitel 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?........................................................................19Kapitel 4:  Kolab Server – Vorbereitung und Installation 20 4.1 Installationsvorbereitung......................................................................20 4.2 Installation....................................................................................22 4.3 Aktualisierung................................................................................25 4.4 Deinstallation.................................................................................27Kapitel 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. 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........................................................................................63Kapitel 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..............................................................................65Anhang 66Anhang A:  Weiterführende Informationen 67 A.1 Die Kolab-Gemeinschaft......................................................................69 A.2 Das Kolab-Konsortium.......................................................................70Anhang B:  Glossar 71Anhang C:  GNU Free Documentation License 74 4
  5. 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 beimAufsetzen 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 denKolab Server zu nutzen, die anhand einiger konkreter Beispiele dargestellt werden. Auf die dabei getrof-fenen Annahmen wird jeweils hingewiesen. 5
  6. 6. 1 EinführungDiese 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 Server2.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.KonventionenDer leichten Lesbarkeit wegen wird oft nur eine Form verwendet – meist die männliche – gemeint sindbei 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 „KolabServer“, 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 sichereGroupware-Lösung umgesetzt werden kann. In dieser Idee unterscheidet sich Kolab bereits von vielenanderen Produkten, welche Kommunikation und Arbeitsgruppen unterstützen möchten. Ein Nutzen vonKolab 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üreinen täglichen Betrieb zwar nicht direkt erforderlich, erlauben aber oft, den Nutzen der Lösung für alleBeteiligten 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 vonKontakten, Terminen, Aufgaben und Notizen auf Basis offener Standards geboten. Nachfolgend einigewesentliche Eigenschaften des Kolab Servers: 6
  7. 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 einesNutzers 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 weitererKolab-Server sowie die Outlook-Konnektoren von Toltec und Konsec (vgl. Kapitel 6), die MicrosoftOutlook 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 KolabDie Entwicklung von Kolab, geht auf eine Ausschreibung des deutschen Bundesamtes für Sicherheit inder 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 Oktober2002 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 ErfrakonPartG (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-KlientenKontact. Der Auftrag trug den Kodenamen Kroupware. Das Konzept und die Software, welche u. a. ausdiesem Auftrag entstand, heißt Kolab. Entsprechend heißen die Softwarekomponenten Kolab Serversowie KDE Kolab Client. Am 17. Juli 2003 erschien die erste stabile Version von Kolab1: Kolab Server1.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 wurdeKolab Server 2.0 veröffentlicht, einige Monate nachdem Kolab Server 2 bereits im produktiven Einsatz1 Stand: Dezember 20072 http://www.gargan.org/extensions/synckolab.html [Abruf: 07.12.2007]3 http://www.bynari.net/ [Abruf: 07.12.2007] 7
  8. 8. 1 Einführungwar. 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. 9. 2 Die Komponenten des  Kolab ServersDieses Kapitel gibt eine Übersicht über die im Kolab Server verwendeten Komponenten, erklärt derenZusammenspiel und beschreibt im Detail die Komponente OpenPKG sowie die kolabspezifischen Kern-komponenten kolabd und kolabconf.2.1  ÜbersichtDer 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. 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.cgiSpam­ 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.htmlKolab Webklient ➔ Horde Horde ist ein webbasierter Klient für Kolab. URL: http://horde.org Dokumentation: http://www.horde.org/documentation.phpAllgemein ➔ 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. 11. 2 Die Komponenten des Kolab ServersDie 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 einzelnenKomponenten um Groupware-Funktionalitäten und ein gemeinsames Konfigurationssystem ergänzen.Alle kolabspezifischen Komponenten, insbesondere kolabd und kolabconf, werden im Abschnitt 2.4beschrieben.2.2  Interaktion der KomponentenDer Kolab-Dämon (kolabd) dient als zentrale Steuerungsinstanz des Kolab Servers. Er verwaltet dieKonfigurationen der einzelnen Serverkomponenten. Abbildung 2.1 veranschaulicht die Interaktion dieserKomponenten:Die Komponenten Cyrus IMAP und Postfix authentifizieren Benutzer über die von SASLauthd gestelltenMethoden per LDAP (slapd). Der Verzeichnisdienst sorgt über das LDAP-Protokoll außerdem für diedirekte 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. 12. 2 Die Komponenten des Kolab Servers2.3  OpenPKGDie Kolab Server/OpenPKG-Variante nutzt eine Schicht zwischen Anwendung und Betriebssystem,names OpenPKG1. Im Ergebnis wird für den Anwendungsentwickler die Plattform vereinheitlicht. Wasfür die Entwickler und Tester des Kolab Servers eine Erleichterung bedeutet. Betrieben werden kann derKolab Server daher auf allen Betriebssystemen, auf denen auch OpenPKG läuft (vgl. dazu die Angabenvon 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/OpenPKGOpenPKG bringt viele Komponenten selbst mit und verwaltet diese mit einer eigenen RPM-Datenbankzur Paketverwaltung. OpenPKG ist demnach von Bibliotheken auf dem eigentlichen Betriebssystemund dessen Paketverwaltung weitestgehend unabhängig. Das bringt viele Vorteile, aber auch einigeNachteile.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. 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 TechnikerDie Paketverwaltung von OpenPKG ist das bekannte RPM-System in Version 4. Um selbst Pakete bauenzu können, sollte beachten, dass die meisten Bibliotheken statisch gelinkt werden. Wird beispielsweisedb 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 einoptimales Ergebnis zu erreichen. Die Binärpakete lassen sich aber auf Systemen mit ähnlicher Hardwareund Betriebssystem austauschen.2.4  Kolabspezifische KomponentenZu den kolabspezifischen Kernkomponenten gehören: ➔ kolabd ➔ kolabconf ➔ kolab-webadmin ➔ kolab-filter ➔ kolab-freebusy ➔ kolab-horde-framework ➔ kolab-horde-fbview ➔ kolab-ressource-handlersDer 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 wordenist. 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 dieBearbeitung zuständig; beispielsweise kann kolabd ein Konto auf dem Cyrus IMAPd anlegen, ändernoder 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. 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. Ändernsich 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. 15. 2 Die Komponenten des Kolab ServersKonfiguration durch TemplatesDie Kolab-Komponenten werden durch Konfigurationsdateien konfiguriert, die von kolabconf ausTemplates generiert werden. Am Beispiel des Postfix-Dienstes wird nun die Funktionsweise vonTemplates erläutert:Alle Template-Dateien liegen im Verzeichnis /kolab/etc/kolab/templates und sind an derDateiendung .template zu erkennen. Aus dem Dateiname lässt sich erschließen, um welcheKonfiguration 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-Blockvon Postfix: KOLAB_META_START TARGET=/kolab/etc/postfix/main.cf PERMISSIONS=0644 OWNERSHIP=kolab-n:kolab-r KOLAB_META_ENDIn diesem Abschnitt wird festgelegt wo (TARGET) und mit welchen Zugriffsrechten (PERMISSIONS undOWNERSHIP) die generierte Konfigurationsdatei im Dateisystem abgelegt wird.Nachdem die Konfigurationsdateien neu generiert wurden, informiert kolabconf die zugehörigenDienste. 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. Beikü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 werdendiese 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=comAnstatt 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. 16. 2 Die Komponenten des Kolab ServersProblemsuche in kolabd / kolabconfDer kolabd ist das Bindeglied zwischen dem Verzeichnisdienst und dem Cyrus-IMAP-Server. Kolabdkommt erst dann zum Einsatz, wenn Änderungen an der Konfiguration oder den Nutzereinstellungenvorgenommen werden. Probleme am kolabd werden also erst dann sichtbar, wenn Änderungen nichtabgearbeitet 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 istdas meist /var/log/syslog (Achtung: Dies ist nicht innerhalb der OpenPKG-Hierarchie). Um dortmehr Ausgaben zu erhalten, sollte in der Konfigurationsdatei /kolab/etc/kolab/kolab.conf derWert für log_level erhöht und kolabd neu gestartet werden. log_level steht nach der Installation vonKolab 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 Ausgabenin syslog ist nur log_level (0 – 4) interessant. Analog kann für ein interaktives Debugging der Flagdebug (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 : 1Bedeutung 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: DEBUGSind 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 alsoauch auf eine gestörte Replikation hinweisen. 16
  17. 17. 3 Kolab Server –  BedarfsplanungEs 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. Inmanchen Organisation reichen beispielsweise 50 Megabyte E-Mail-Speicherplatz und es werden proNutzer 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  FestplattenspeicherDie wichtigste Tätigkeit eines Kolab-Servers ist es, für die Klienten E-Mail-Daten zu liefern. JedesGroupware-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-Mailsfallen die Termine und Kontakte meist nicht ins Gewicht.Wird als Klient Microsoft Outlook mit einem der verfügbaren Konnektoren verwendet (vgl. Abschnitt6.2), ist es möglich, dass sich die Größe mancher E-Mails in der Speicherung verdoppeln. Nur so könnenmanche Objekt-Attribute gespeichert werden, welche nur für Outlook wichtig sind. Wer ganz sichergehen möchte, migriert auf ein Testsystem die alten Daten einiger repräsentativer Nutzer. 17
  18. 18. 3 Kolab Server – BedarfsplanungEntscheidend wird der Umgang mit Alt-Daten im System sein. Was werden die Nutzer tun, wenn sie anihr 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-Mailsoder Termine an.3.2  Rechenleistung / HauptspeicherBeim 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 einCyrus-IMAPd, der grob um die 2 Megabyte Hauptspeicher benötigt.Ein „aktiver Klient“ steht in diesem Zusammenhang für einen Klienten, der einen Zwischenspeicherbesitzt 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 durchgeschicktere Synchronisations-Algorithmen von Seiten der Klienten der Bedarf an Netzverbindungen inZukunft 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 verbessertworden. Langzeiterfahrungen fehlen, aber es wird eine deutliche Besserung erwartet, so dass dieses fürden Betrieb von 2.2 nicht mehr gesondert geplant werden muss. Im Gegensatz dazu hat der Ansturm anunerwünschten E-Mails zugenommen, was mehr Scan-Leistung erforderlich macht. Für das Scannen vonE-Mails ist deshalb bei größeren Installation ein eigener Rechner sinnvoll.Bei durchschnittlicher Nutzung ist zu erwarten, dass eine übliche Server-Hardware mit 2 Prozessorenund 4 Gigabyte Hauptspeicher mehrere tausend Nutzer bedienen kann. Das gilt pro Kolab-Server; durchden Einsatz von Slave-Servern ist hier eine gute Skalierung möglich.3.3  VerfügbarkeitDie Bedürfnisse an die Verfügbarkeit der Kolab-Server sind recht unterschiedlich. Wie im letzten Absatzbeschrieben, sind die Klienten auch ohne Netzverbindung grundsätzlich arbeitsfähig. Dennoch sollteeine hohe Verfügbarkeit von jedem Kolab-Servers angestrebt werden.Der Kolab-Server kann mit üblichen GNU/Linux Mechanismen abgesichert werden. Zum Beispiel durchein 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. 19. 3 Kolab Server – Bedarfsplanung3.4  Wer arbeitet mit wem?Es kann sinnvoll sein, aus Gründen der Leistung oder verschiedener Standorte, mehrere Kolab-Serverzu 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 einenbestimmten Heimatserver, dürfen sich aber auf allen anderen anmelden. Das ist weniger nötig, wenn sichdie Nutzer einer Arbeitsgruppe schon auf einem gemeinsamen Heimatserver befinden. 19
  20. 20. 4 Kolab Server – Vorbereitung  und InstallationIn diesem Kapitel werden zunächst die nötigen Grundvoraussetzungen und Vorbereitungen für diedanach beschriebene Installationsanleitung des Kolab Servers erläutert. Anschließend wird das Vorgehenfü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 zu1 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. 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. 22. 4 Kolab Server – Vorbereitung und Installation4.2  InstallationIm folgenden Abschnitt werden die Schritte zur Installation des Kolab Servers mit den unter Abschnitt4.1 heruntergeladenen Paketen beschrieben. Es sollte zusätzlich die bei den Paketen beiliegende1st.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. 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. 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. 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 startDas Verzeichnis /kolab/RPM/PKG/ wird nur zur Installation gebraucht und kann anschließendgelö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. Abschnitt4.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. 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 startDetailliertere Upgrade-Informationen – insbesondere zu Besonderheiten beim Upgrade von früherenKolab-Versionen – sind in den Readme-Dateien im CVS-Server-Verzeichnis 2 bzw. in der 1st.READMEim Installationsordner zu finden.SicherheitsupdatesZunächst ist der Benachrichtigungsweg relevant: Wie bekommt der Administrator Kenntnis von einemSicherheitsupdate? Entweder wird er von seinem Dienstleister benachrichtigt und mit einer genauenAnleitung 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 beobachtenAnschließ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. 27. 4 Kolab Server – Vorbereitung und InstallationTreten Unsicherheiten/Schwierigkeiten beim Durchführen von Sicherheitsupdates auf, sollte ein Dienst-leister zu Rate gezogen werden. Ein funktionierender Prozess, um zu Aktualisierungen zu kommen istwichtig, da ansonsten das eingesetzte System Gefahr läuft längere Zeit bekannte Angriffspunkte zu bie-ten.4.4  DeinstallationDer 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 Verzeichnisdurch OpenPKG entfernt worden sein. 27
  28. 28. 5 Kolab Server – Konfiguration  und BetriebDieses Kapitel beschreibt die Konfigurationsmöglichkeiten des Kolab Servers und gibt darüber hinausfü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 Kapitelvermittelt die dafür nötigen Kenntnisse.5.1  Kolab Web­AdminDer 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 dervoreingestellte 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 zuEinstellmöglichkeiten des Kolab Servers. 28
  29. 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 einigeKonfigurationsmöglichkeiten auf den Web-Admin verwiesen. Weitere Informationen zur Konfigurationdes Kolab Servers mit dem Web-Admin sind in der Kolab-Dokumentation Doc2 zu finden (vgl. AnhangA).5.2  RollenDer Kolab Server stellt vier Rollen zur Verfügung, die nachfolgend beschrieben werden: 1. Administrator 2. Verwalter 3. Domänenverwalter 4. BenutzerDarüber hinaus nimmt der Rechner-Administrator (root) eine „Sonderrolle“ ein. Aus Sicherheitsgründenhaben die Kolab-Nutzer in der Regel keine Rechnerkonten und somit keinen direkten Zugriff (z.B. perssh) auf den Server.Abbildung 5.2 veranschaulicht den Zusammenhang der vier Rollen und deren Berechtigungen: DieRechte von Benutzer sind eine Untermenge von den Domänenverwalter-Rechten, diese wiederumUntermenge 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. 30. 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.2: Die vier Benutzerrollen des Kolab Servers mit ihren Zugriffsberechtigungen auf den  Verzeichnisdienst5.2.1  AdministratorDie 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 Serversvergeben und ist bei Verlust in der folgender Datei wiederzufinden (Dies gilt ausschließlich nur für denmanager. Andere Administratoren werden hier nicht gespeichert!): /kolab/etc/kolab/kolab.conf (Zeile bind_pw).Zum Ändern des manager Passworts kann der Befehl /kolab/bin/kolabpasswdgenutzt 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. 31. 5 Kolab Server – Konfiguration und Betrieb5.2.2  VerwalterDie Rolle Verwalter ist die eines Administrators ähnlich – mit dem Unterschied, dass ein Verwalter nichtberechtigt ist, folgende Aufgaben durchzuführen: ➔ Hinzufügen, Ändern und Löschen von Administratoren ➔ Hinzufügen, Ändern und Löschen von Verwaltern ➔ Konfiguration der Dienste5.2.3  DomänenverwalterIm 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änen5.2.4  BenutzerBenutzer werden von Administratoren, Verwaltern oder Domänenverwaltern angelegt. Abbildung 5.3zeigt 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 MegabytesAls Benutzername für den Login beim Kolab Web-Admin kann sowohl die UID also auch die primäreE-Mail-Adresse (PEM) eines Kontos genutzt werden. Die UID ist in der Voreinstellung gleichzeitig auchdie 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 einesKontos nicht mehr geändert werden. Was bei einer Namensänderung oder einer geplanten Migrierungeines Kontos auf einen anderen Homeserver zu tun ist, zeigt die zweite graue Box auf der übernächstenSeite. Weitere Informationen zu Kolab-Homeservern sind im Abschnitt 5.12 zu finden. 31
  32. 32. 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.3:  Anlegen eines neuen Benutzers im Kolab Web­AdminLDAP­Attribute ändernDie 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. 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.txt5.3  KontotypenZu 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. 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-DNJedes 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 Nachrichtenbereinigt. Diese Person muss nicht der Systemadministrator sein; im Gegenteil: es sollte eher eine derGruppe oder der Ressource inhaltlich nahe stehende Person damit beauftragt werden.5.4  NutzerlebenszyklusAnlegen 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. 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. 36. 5 Kolab Server – Konfiguration und Betrieb5.5  E­MailDer nachfolgende Abschnitt beschreibt, wie der E-Mail-Betrieb auf dem Kolab Server funktioniert undan welchen Stellen der Administrator diesen Betrieb konfigurieren kann.5.5.1  Die IMAP Spool StrukturDer Cyrus IMAP-Server speichert alle E-Mails als einzelne Dateien in seinem Spool-Verzeichnis, dasbei einer typischen Kolab-Installation unter /kolab/var/imapd/spool liegt. Zur übersichtlicherenVerwaltung bei sehr vielen Nutzern, verwendet der Kolab Server (seit Version 2.1) die Optionhashimapspool: 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 Unterverzeichnisseentsprechen den IMAP-Unterordnern. Die Ordner enthalten jeweils Dateien, deren Name eine Zahlgefolgt von einem Punkt ist. Diese Dateien enthalten die eigentlichen E-Mails. Im gleichen Ordnerbefinden 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 Backupfinden. 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­MailTrifft eine E-Mail am Kolab-Server ein, durchläuft sie verschiedenen Komponenten des Servers. DieserWeg einer E-Mail – vom SMTP-Eingangsserver bis in das IMAP-Ordner des Kolab-Nutzers – wird inAbbildung 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. 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. 38. 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.4: Der Weg einer E­Mail im Kolab Server 38
  39. 39. 5 Kolab Server – Konfiguration und Betrieb5.5.3  WeiterleitungEin 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 demKolab-Server zu belassen.5.5.4  AbwesenheitsbenachrichtigungEin 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-Benutzereinstellungenvorgenommen werden (vgl. Abbildung 5.5). Abbildung 5.5: Einstellungen für Abwesenheitsbenachrichtigungen im Kolab Web­AdminAnmerkung zum erneuten Benachrichtigungsversand: Die Einstellung in obiger Abbildung (7 Tage)bedeutet, dass das Senden einer Abwesenheitsbenachrichtigung aktiviert wurde und falls innerhalb von 7Tagen weitere Mails desselben Absenders eingehen, nur die erste Nachricht automatisch beantwortetwird. 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 aufSpamnachrichten senden wird keine Nachricht an den Absender geschickt, wenn die E-Mail als Spamdeklariert wurde.Anmerkung zur Domain-Angabe: Sofern eine Mail-Domäne angegeben wird, bekommen nur Absenderdieser Domäne Abwesenheitsbenachrichtigungen zugesandt. Dadurch kann diese Funktion z. B. aufNachrichten einer Organisation beschränkt werden. 39
  40. 40. 5 Kolab Server – Konfiguration und Betrieb5.5.5  Serverseitige Filterung mit SieveSieve ist eine Skriptsprache, die speziell für das serverseitige Filtern von E-Mails konzipiert wurde. Diegenaue Spezifikation kann im RFC 3028 nachgelesen werden. Der Kolab Server nutzt Sieve u. a. fürWeiterleitungen und Abwesenheitsbenachrichtigungen (vgl. Abschnitt 5.5.3 und 5.5.4). Ein Benutzerkann 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 zubeachten, dass sieveshell eine unverschlüsselte Verbindung nutzt. Es wird daher dringendst empfohlensieveshell 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 localhostDer 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 wiederbeenden (quit): > list > put example.siv > activate example.siv > quitMit 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 Sievemö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. 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­VertreterWenn 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 desBenutzers 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 Vertreterist möglich.Ein Benutzer kann seine Vertretung mit dem Eintragen der Vertreter-E-Mail-Adresse(n) innerhalb seinerWeb-Admin-Benutzereinstellungen aktivieren.Anmerkung: Wenn ein Vertreter im Namen des Benutzers Einladungen aussprechen können soll, müssendem Vertreter auch Schreibrechte für den Kalenderordner des Benutzers erteilt werden. In KDE Kontactz. 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ötigenRechte 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. 42. 5 Kolab Server – Konfiguration und Betrieb5.5.7  VerteilerlistenEine 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-Adressevon 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 verwaltetwerden. 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 authentifizierteNutzer sind berechtigt, an diese Liste E-Mails zu senden. Die Verteilerliste wird im Status Verborgen beieiner LDAP Suche mit einer nicht-authentifizierten Verbindung im Kolab-Klient nicht angezeigt.Anmerkung: Ein authentifizierter Anwender ist ein Anwender, der sich mit seinem Benutzernamen undPasswort 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 angelegtwerden. 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. 43. 5 Kolab Server – Konfiguration und Betrieb5.5.8  Virenfilter­KonfigurationDer 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 sowieSpamAssassin und ClamAV auf der anderen. Amavisd-new ist der Nachfolger von AMaViS (= A MailVirus 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 siezurück zu Postfix an Port 10026 [8]. Andernfalls landet die Nachricht im Quarantäne-Verzeichnis (sieheKasten 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-kXuJ2d3uGVCTin das Postfach eines Kolab Nutzers manuell ausgeliefert werden.Einstellungen zu den Viren-, Mail- und Spam-Filter (wie z. B. ClamAV und SpamAssassin) können überdas 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 neugestartet (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. 44. 5 Kolab Server – Konfiguration und BetriebClamAV 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ührtwerden. Clamscan wird automatisch dann zum Überprüfen von Viren in E-Mails eingesetzt, wenn alleanderen Virenscanner ausgefallen sind.Es ist problemlos möglich andere, auch proprietäre, Virenscanner zu installieren und diese an Stelle vonoder zusätzlich mit ClamAV auf dem Kolab Server zu nutzen. Dafür muss die ClamAV-Einstellung imamavisd-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/freshclamDie Virusinformations-Datenbank wird automatisch in regelmäßigen Abständen durch einen voreinge-stellten Cronjob auf /kolab/bin/freshclam aktualisiert. Das voreingestellte Updateintervall voneiner Stunde kann im Template /kolab/etc/kolab/templates/rc.conf.template (in der Zeileclamav_update = "hourly") geändert werden. In der /etc/crontab werden die Parameterhourly 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. 45. 5 Kolab Server – Konfiguration und Betrieb5.5.9  Spamfilter­KonfigurationUnerwü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 mitKolab ausgelieferte Spamfilter SpamAssassin aktiv ist.Die Konfiguration erfolgt in der Datei /kolab/etc/spamassassin/local.cf. Einige Funktionenvon SpamAssassin sollten hier nicht mehr benutzt werden, da sie in amavisd-new integriert sind, wiez.B. Whitelist/Blacklist, Spam-Grenzwert und Header-/Body-Änderungen. Eingestellt werden hier alsonur noch der statistische Bayes-Filter, eigene Regeln und Wertigkeiten für bestehende Regeln. DaSpamAssassin in amavisd-new integriert ist, muss nach Änderungen /kolab/etc/rc amavisd restartausgefü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 bewertetist, 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-Verzeichniskopiert (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 istder 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. 46. 5 Kolab Server – Konfiguration und BetriebSpamAssassin in der Grundkonfiguration ist noch nicht sehr mächtig. Um eine höhere Trefferquote zuerreichen, 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

×