allgemeine betriebsdokumentation-kolab server22-20080103_1.0

Allgemeine Betriebsdokumentationfür

Kolab Server 2.2

Version: 1.0

Osnabrück, am 3. Januar 2008

Änderungsverzeichnis

ÄnderungGeänderte

KapitelBeschreibung der Änderung Autor

Nr Datum Version

1 2008-01-03 1.0 Emanuel Schütze

Aktueller Status: Fertig gestellt

Impressum© 2007 Intevation GmbHVersion: 1.0Autor: Emanuel SchützeFachliche Leitung: Bernhard Reiter, Thomas Arendsen HeinKontakt: [email protected] | 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 FrontCover Texts, and no BackCover 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

mailto:[email protected]

http://kolab.org/

http://intevation.org/

Inhaltsverzeichnis

Kapitel 1: Einführung 51.1 Was ist Kolab?.................................................................................61.2 Entwicklungshistorie von Kolab................................................................71.3 Was ist neu in Kolab Server 2.2?...............................................................8

Kapitel 2: Die Komponenten des Kolab Servers 92.1 Übersicht.......................................................................................92.2 Interaktion der Komponenten.................................................................112.3 OpenPKG.....................................................................................122.4 Kolabspezifische Komponenten...............................................................13

Kapitel 3: Kolab Server – Bedarfsplanung 173.1 Festplattenspeicher............................................................................173.2 Rechenleistung / Hauptspeicher...............................................................183.3 Verfügbarkeit.................................................................................183.4 Wer arbeitet mit wem?........................................................................19

Kapitel 4: Kolab Server – Vorbereitung und Installation 204.1 Installationsvorbereitung......................................................................204.2 Installation....................................................................................224.3 Aktualisierung................................................................................254.4 Deinstallation.................................................................................27

Kapitel 5: Kolab Server – Konfiguration und Betrieb 285.1 Kolab Web-Admin............................................................................285.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...................................................................................335.4 Nutzerlebenszyklus...........................................................................345.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

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...................................................................................515.7 Kalender......................................................................................52

5.7.1 Einladungen...........................................................................52 5.7.2 Frei/Belegt-Listen......................................................................53

5.8 Notizen.......................................................................................545.9 Aufgaben.....................................................................................545.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........................................................................................575.12 Master- und Slaveserver / Homeserver........................................................585.13 Datensicherung und -wiederherstellung.......................................................595.14 Dienste........................................................................................63

Kapitel 6: KolabKlienten 646.1 KDE Kontact..................................................................................646.2 Microsoft Outlook............................................................................64

6.2.1 Toltec Connector.......................................................................64 6.2.2 Konsec Konnektor.....................................................................65

6.3 Horde Webklient..............................................................................65

Anhang 66

Anhang A: Weiterführende Informationen 67A.1 Die Kolab-Gemeinschaft......................................................................69A.2 Das Kolab-Konsortium.......................................................................70

Anhang B: Glossar 71

Anhang C: GNU Free Documentation License 74

4

1 Einführung

Kolab ist eine Freie Lösung, die Groupware-Funktionalitäten bietet. Kolab spe-zifiziert ein Verhalten von Server und Klienten, welches als Freie Software in dem Kolab Server, dem Kolab KDE Klienten Kontact und dem Horde Webklien-ten implementiert ist. Das Konzept von Kolab, basierend auf offenen Standards, gestattet die Entwicklung von Kolab-Servern und -Klienten durch Drittanbieter.

Als Groupware bezeichnet man eine Software, die für die Zusammenarbeit innerhalb einer Arbeitsgruppe konzipiert ist und die Arbeitsabläufe rationalisie-ren und automatisieren soll. In der Regel besteht Groupware aus Anwendungen, die typische Organizer-Funktionen (wie Kalender, Kontakte, Aufgaben, Notizen) sowie Funktionen für den Austausch von E-Mails und die gemeinsame Bearbei-tung von Dateien bereitstellen.

Die vorliegende Betriebsdokumentation konzentriert sich auf den Kolab Server und unterstützt beim Aufsetzen und Betreiben eines solchen Groupware-Servers.

Diese Dokumentation richtet sich an Systemadministratoren, die Server-Anwendungen betreuen. Kennt-nisse über den Kolab Server werden nicht vorausgesetzt. Grundlegende Erfahrungen mit Server-Anwen-dungen sind jedoch erforderlich; wünschenswert auf GNU/Linux. Zu diesen Themen gibt es bereits zahl-reiche Literatur.

Ziel dieser Arbeit ist es, einen Überblick über den Kolab Server zu geben und die Fähigkeiten für War-tung und Betrieb zu vermitteln. Es existieren sehr vielfältige Möglichkeiten und Einsatzszenarien den Kolab Server zu nutzen, die anhand einiger konkreter Beispiele dargestellt werden. Auf die dabei getrof-fenen Annahmen wird jeweils hingewiesen.

5

1 Einführung

Diese Betriebsdokumentation bezieht sich auf die OpenPKG-Variante von Kolab Server 2.2 (vgl. Abschnitt 2.3). Da Version 2.2.0 zum Recherchezeitpunkt noch nicht erschienen ist, wurde Kolab Server 2.2-beta2 genutzt.

Gliederung

➔ Kapitel 1 und 2 geben einen allgemeinen Überblick über den Kolab Server und dessen Kompo-nenten.

➔ Im 3. Kapitel wird anhand von grundsätzlichen Leitfragen die Bedarfsplanung für den Einsatz eines Kolab-Servers erarbeitet.

➔ Hinweise zur Installation sowie praktische Anleitungen zur Installation, zum Update und zur Deinstallation des Kolab Servers werden im Kapitel 4 gegeben.

➔ Das Kapitel 5 Kolab Server – Konfiguration und Betrieb beschreibt ausführlich die wichtigsten Einstellmöglichkeiten am Kolab Server und gibt praktische Hinweise für die eigene Konfigura-tion.

➔ Einen allgemeiner Überblick über die verfügbaren Kolab-Klienten stellt Kapitel 6 dar.➔ Weiterführende Quellen mit Kontaktmöglichkeiten zur Kolab-Gemeinschaft und dem Kolab-

Konsortium sowie ein Glossar sind im Anhang A und B zu finden.

Konventionen

Der leichten Lesbarkeit wegen wird oft nur eine Form verwendet – meist die männliche – gemeint sind bei Personen jedoch immer Männer und Frauen, wie bei „Nutzern“ und „Nutzerinnen“.

Das Produkt „Kolab Server“ wird in dieser Dokumentation stets ohne Bindestrich geschrieben.Handelt es sich um eine beliebige Implementation oder eine spezielle Installation des Produkts „Kolab Server“, so wird „Kolab-Server“ mit Bindestrich verwendet.

1.1 Was ist Kolab?

Kolab ist in erster Linie ein Konzept, wie mit Freier Software eine skalierbare, stabile und sichere Groupware-Lösung umgesetzt werden kann. In dieser Idee unterscheidet sich Kolab bereits von vielen anderen Produkten, welche Kommunikation und Arbeitsgruppen unterstützen möchten. Ein Nutzen von Kolab entsteht aus der Kombination mehrerer Softwarekomponenten. Für Anwender ist allein der Nut-zen entscheidend. Als Administrator ist es jedoch nützlich die Zusammenhänge zu kennen; sie sind für einen täglichen Betrieb zwar nicht direkt erforderlich, erlauben aber oft, den Nutzen der Lösung für alle Beteiligten zu erhöhen.

Bei Kolab entsteht der Nutzen im Zusammenspiel von Klient und Kolab-Server. Es werden Groupware-Funktionen zum Austauschen von E-Mails, Freigeben und Bearbeiten von Dateien sowie Verwalten von Kontakten, Terminen, Aufgaben und Notizen auf Basis offener Standards geboten. Nachfolgend einige wesentliche Eigenschaften des Kolab Servers:

6

1 Einführung

➔ Nutzerdaten werden in Ordnern auf dem Server gespeichert.➔ Ein Ordner enthält Objekte eines Typs: Kontakte, Termine, Aufgaben, Notizen oder E-Mails.➔ Jeder Nutzer verwaltet seine Ordner und kann diese anderen Nutzern freigeben.➔ Nutzung von Abwesenheitsbenachrichtigung, E-Mail-Weiterleitung und -Vertretern.➔ Frei-/Belegt-Listen unterstützen die Terminfindung.➔ Einladungen können automatisch bearbeitet werden.➔ Verschiedene Verzeichnisdienste können genutzt werden.➔ Unterstützt IMAP, POP3, SMTP (optional verschlüsselt); damit für jeden Mail-Klient geeignet.➔ Vollwertige Kolab-Klienten können offline arbeiten und dann synchronisieren.➔ Inkrementelle Datensicherung ist leicht zu realisieren.➔ Nur der Verzeichnisdienst ist zentral, alles andere ist verteil- und skalierbar.

Mit Kolab lassen sich u. a. E-Mails, Kontakte und Kalendereinträge von Arbeitsplatz und Laptop eines Nutzers synchronisieren und mit anderen Benutzern austauschen. Alles was dazu nötig ist, ist ein Kolab-kompatibler Klient. Für die gängigsten Konfigurationsmöglichkeiten des Kolab Servers wird ein Webin-terface zur Verfügung gestellt. Zur Speicherung der Daten dient der Verzeichnisdienst.

Neben dem offiziellen Kolab Server sowie den Kolab-Klienten Kontact und Horde gibt es bereits wei-tere Entwicklungen von Drittanbietern1: Der Univention Groupware Server (UGS) als ein weiterer Kolab-Server sowie die Outlook-Konnektoren von Toltec und Konsec (vgl. Kapitel 6), die Microsoft Outlook Groupware-Funktionalitäten eines Kolab Klienten ermöglichen. Weiter befinden sich in der Ent-wicklung: das Thunderbird Plugin Sync Kolab2 und der Bynary Insight Connector3 für MS Outlook.

1.2 Entwicklungshistorie von Kolab

Die Entwicklung von Kolab, geht auf eine Ausschreibung des deutschen Bundesamtes für Sicherheit in der Informationstechnik (BSI) zurück. Ziel der Ausschreibung war die Bereitstellung einer Groupware-Lösung, welche eine heterogene Klientenlandschaft bedienen kann, für den eigenen Bedarf. Im Oktober 2002 wurde die Ausschreibung von drei Unternehmen gewonnen, die das Projekt im Juli 2003 erfolg-reich zum Abschluss brachten. Die Intevation GmbH (Osnabrück) hatte die Projektleitung, die Erfrakon PartG (Stuttgart) war für die Entwicklung des Kolab Servers sowie das technischen Konzept verant-wortlich und Klarälvdalens Datakonsult AB (Schweden) realisierte den KDE-basierten Kolab-Klienten Kontact. Der Auftrag trug den Kodenamen Kroupware. Das Konzept und die Software, welche u. a. aus diesem Auftrag entstand, heißt Kolab. Entsprechend heißen die Softwarekomponenten Kolab Server sowie KDE Kolab Client. Am 17. Juli 2003 erschien die erste stabile Version von Kolab1: Kolab Server 1.0 und KDE Kolab Client 1.0.

Im Jahre 2004 wurde Kolab einer Generalüberholung unterzogen. Um Groupware-Daten plattformüber-greifend zugreifbar zu machen, wird in Kolab2 das Kolab XML Format eingeführt. Im Juni 2005 wurde Kolab Server 2.0 veröffentlicht, einige Monate nachdem Kolab Server 2 bereits im produktiven Einsatz

1 Stand: Dezember 20072 http://www.gargan.org/extensions/synckolab.html [Abruf: 07.12.2007]3 http://www.bynari.net/ [Abruf: 07.12.2007]

7

http://www.bynari.net/

http://www.gargan.org/extensions/synckolab.html

1 Einführung

war. Es folgte das Kolab Server 2.1 Release im Mai 2007. Kolab Server 2.2 ist aktuell in der Entwick-lung. Das stabile Release ist für Anfang 2008 geplant.

1.3 Was ist neu in Kolab Server 2.2?

Nachfolgend eine Auflistung der wesentlichen Neuerungen in Kolab Server 2.2 gegenüber Version 2.1:

➔ Aufnahme des webbasierten Kolab-Klienten Horde (vgl. Abschnitt 6.3)➔ Upgrade des Apache-Servers von Generation 1 auf Version 2.2➔ Upgrade von PHP4 auf PHP5➔ Upgrade von Postfix auf Version 2.4. Damit sind keine kolabspezifischen Änderungen an Postfix

mehr nötig.➔ Upgrade des Cyrus IMAP Server auf Version 2.3. Damit sind ebenfalls einige (nicht alle) kolabspe-

zifischen Änderungen überflüssig geworden.➔ Strukturelle Verbesserungen von verschiedenen Serverkomponenten➔ Verbesserungen, Fehlerbeseitigung und aktualisierte Softwarekomponenten. Dazu gehört eine aktua-

lisierte OpenPKG-Umgebung mit einer verbesserten Unterstützung für aktuelle Betriebssysteme und Hardware.

8

2 Die Komponenten des

Kolab Servers

Dieses Kapitel gibt eine Übersicht über die im Kolab Server verwendeten Komponenten, erklärt deren Zusammenspiel und beschreibt im Detail die Komponente OpenPKG sowie die kolabspezifischen Kern-komponenten kolabd und kolabconf.

2.1 Übersicht

Der Kolab Server 2.2 benutzt zahlreiche Freie-Software-Produkte. Nachfolgend eine Auswahl der wich-tigsten Serverkomponenten:

EMail / 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

http://cyrusimap.web.cmu.edu/imapd/man.html

http://cyrusimap.web.cmu.edu/imapd/

http://www.postfix.org/documentation.html

http://www.postfix.org/

2 Die Komponenten des Kolab Servers

➔ OpenLDAPOpenLDAP ist ein Verzeichnisdienst, der sich über das Protokoll LDAP (Lightweight Directory Access Protocol) abfragen lässt.URL: http://www.openldap.org

Dokumentation: http://www.openldap.org/doc/index.html

Manual Pages: http://www.openldap.org/software/man.cgi

Spam und Virenscanner

➔ amavisd-new Amavisd-new ist ein in Perl implementierter E-Mailscanner, der Nachrichten vom Mailserver entgegennimmt, diese (inkl. Anhang) auspackt und an definierte Viren- und/oder Spamfilter zur Überprüfung übergibt.URL: http://www.ijs.si/software/amavisd

Dokumentation: http://www.ijs.si/software/amavisd/amavisd-new-docs.html

➔ ClamAVClamAV (ClamAntiVirus) ist ein Virenscanner, der insbesondere auf Mailservern zum Einsatz kommt. URL: http://www.clamav.net

Dokumentation: http://www.clamav.org/doc/latest/

➔ SpamAssassinSpamAssassin ist ein in Perl implementierter E-Mail-Filter, der zur Überprüfung und Identifizie-rung von unerwünschten Nachrichten eingesetzt wird.URL: http://spamassassin.apache.org

Dokumentation: http://spamassassin.apache.org/doc.html

Kolab Webklient

➔ HordeHorde ist ein webbasierter Klient für Kolab.URL: http://horde.org

Dokumentation: http://www.horde.org/documentation.php

Allgemein

➔ Apache (HTTP-Server)Der HTTP-Server von Apache ist der meist verbreitete (freie) Webserver im Internet.URL: http://www.apache.org/

Dokumentation: http://httpd.apache.org/docs/

➔ PerlPerl ist eine serverseitige, plattformunabhängige und interpretierte Skriptsprache.URL: http://www.perl.org

Dokumentation: http://www.perl.org/docs.html

➔ PHPPHP ist eine serverseitige und in HTML-Quelltext integrierbare Skriptsprache.URL: http://www.php.net

Dokumentation: http://www.php.net/docs.php

10

http://www.php.net/docs.php

http://www.php.net/

http://www.perl.org/docs.html

http://www.perl.org/

http://httpd.apache.org/docs/

http://www.apache.org/

http://www.horde.org/documentation.php

http://horde.org/

http://spamassassin.apache.org/doc.html

http://spamassassin.apache.org/

http://www.clamav.org/doc/latest/

http://www.clamav.net/

http://www.ijs.si/software/amavisd/amavisd-new-docs.html

http://www.ijs.si/software/amavisd/

http://www.openldap.org/software/man.cgi

http://www.openldap.org/doc/index.html

http://www.openldap.org/


Die Kolab Server/OpenPKG-Version nutzt zusätzlich die freie Komponente OpenPKG:➔ OpenPKG

OpenPKG ist ein Paketmanagementsystem für Unix (basierend auf dem RPM-System) und erleichtert die Paketinstallation auf bekannten Unix-Plattformen (Linux, Solaris, FreeBSD).Weitere Informationen zu OpenPKG folgen im Abschnitt 2.3.URL: http://www.openpkg.org

Dokumentation: http://www.openpkg.org/documentation/

Der Kolab Server besteht aus weiteren spezifischen Elementen und Werkzeugen, welche die einzelnen Komponenten um Groupware-Funktionalitäten und ein gemeinsames Konfigurationssystem ergänzen. Alle kolabspezifischen Komponenten, insbesondere kolabd und kolabconf, werden im Abschnitt 2.4 beschrieben.

2.2 Interaktion der Komponenten

Der Kolab-Dämon (kolabd) dient als zentrale Steuerungsinstanz des Kolab Servers. Er verwaltet die Konfigurationen der einzelnen Serverkomponenten. Abbildung 2.1 veranschaulicht die Interaktion dieser Komponenten:Die Komponenten Cyrus IMAP und Postfix authentifizieren Benutzer über die von SASLauthd gestellten Methoden per LDAP (slapd). Der Verzeichnisdienst sorgt über das LDAP-Protokoll außerdem für die direkte Authentifizierung von Benutzern des Apache Webfrontends – dem Kolab Web-Admin. Der Ver-zeichnisdienst-Slave-Server slurpd dient der Replikation und redundanten Vorhaltung der Verzeichnisda-ten.

11

Abbildung 2.1: Die Interaktion der Kolab Serverkomponenten

http://www.openpkg.org/documentation/

http://www.openpkg.org/


2.3 OpenPKG

Die Kolab Server/OpenPKG-Variante nutzt eine Schicht zwischen Anwendung und Betriebssystem, names OpenPKG1. Im Ergebnis wird für den Anwendungsentwickler die Plattform vereinheitlicht. Was für die Entwickler und Tester des Kolab Servers eine Erleichterung bedeutet. Betrieben werden kann der Kolab Server daher auf allen Betriebssystemen, auf denen auch OpenPKG läuft (vgl. dazu die Angaben von OpenPKG). Am meisten getestet ist der Kolab Server/OpenPKG mit den verbreiten GNU/Linux-Distribution, also z. B. Debian und RedHat Enterprise.Abbildung 2.2 zeigt schematisch den Aufbau eines Kolab Servers mit OpenPKG.

OpenPKG bringt viele Komponenten selbst mit und verwaltet diese mit einer eigenen RPM-Datenbank zur Paketverwaltung. OpenPKG ist demnach von Bibliotheken auf dem eigentlichen Betriebssystem und dessen Paketverwaltung weitestgehend unabhängig. Das bringt viele Vorteile, aber auch einige Nachteile.Aus der Unabhängigkeit der Paketverwaltungssysteme voneinander folgt,

1. dass für OpenPKG andere Kommandos bzw. Pfade existieren.2. dass auch die Paketverwaltung über OpenPKG-Kommandos erfolgt

(z.B. /kolab/bin/openpkg rpm) und dafür OpenPKG Pakete gebraucht werden.

3. dass Konflikte um gemeinsame Ressourcen (wie Portnummern) im Blick behalten werden müs-sen. Welche das sind ist Abschnitt 4.1 zu entnehmen.

4. die Steuerung von Kolab Server/OpenPKG ist auf vielen Betriebssystemen gleich.

OpenPKG hängt sich an einigen Punkten in das Betriebssystem ein, so werden für Kolab Server bei-

spielsweise die Nutzer kolab-r, kolab-n und kolab sowie ein Startskript in /etc/init.d/kolab ange-

legt.

Um an die Anwendungen in der OpenPKG-Welt zu kommen, gibt es zwei grundsätzliche Vorgehenswei-sen:

a) direktes Aufrufen von /kolab/bin/openpkg <Kommando>, z.B. lässt sich der Apache mit

/kolab/bin/openpkg rc apache stop anhalten. Andere Kommandos lassen sich mit

absoluten Pfaden aufrufen, wie /kolab/bin/cyrreconstruct.

1 http://www.openpkg.org/ [Abruf: 07.12.2007]

12

Abbildung 2.2: Die Schichten beim Kolab Server/OpenPKG

http://www.openpkg.org/


b) setzen der Pfade in Umgebungsvariablen MANPATH, PATH, LIBRARY_PATH usw. Die Nut-

zer kolab, kolab-r und kolab-n haben diese Pfade bereits gesetzt.

Die Hilfeseiten (Manpages) von OpenPKG-Komponenten können z.B. mit:➔ /kolab/bin/openpkg man ... oder

➔ man ... (als Benutzer kolab)

aufgerufen werden.

Hinweise für Techniker

Die Paketverwaltung von OpenPKG ist das bekannte RPM-System in Version 4. Um selbst Pakete bauen zu können, sollte beachten, dass die meisten Bibliotheken statisch gelinkt werden. Wird beispielsweise db ausgetauscht, dann müssen auch die Anwendungen neu gebaut werden, welche diese Bibliothek hin-eingelinkt haben.

OpenPKG verteilt Pakete im Quelltext, um durch die Übersetzung erst auf der genauen Zielplattform ein optimales Ergebnis zu erreichen. Die Binärpakete lassen sich aber auf Systemen mit ähnlicher Hardware und Betriebssystem austauschen.

2.4 Kolabspezifische Komponenten

Zu den kolabspezifischen Kernkomponenten gehören:➔ kolabd➔ kolabconf➔ kolab-webadmin➔ kolab-filter➔ kolab-freebusy➔ kolab-horde-framework➔ kolab-horde-fbview➔ kolab-ressource-handlers

Der folgende Abschnitt konzentriert sich auf die Komponenten kolabd und kolabconf.

Der Kolab-Dämon (kolabd) sowie kolabconf dienen als zentrale Steuerungsinstanzen des Kolab Servers. Kolabd führt die notwendigen Arbeiten aus, wenn ein Nutzer angelegt, geändert oder gelöscht worden ist. Kolabconf verwaltet die Konfigurationen der einzelnen Serverkomponenten und erzeugt die eigentli-chen Konfigurationsdateien aus Vorlagen, so genannten Templates.

Ändert sich etwas an den Kolab-Nutzern oder Verteilerlisten ist nur kolabd (und nicht kolabconf) für die Bearbeitung zuständig; beispielsweise kann kolabd ein Konto auf dem Cyrus IMAPd anlegen, ändern oder löschen. Für die Arbeit am Cyrus-Server hält sich kolabd einen Zwischenspeicher von allen existie-renden Nutzer auf der Festplatte, um den IMAPd nicht mit weiteren Anfragen zu belegen.

Abbildung 2.3 veranschaulicht die Arbeitsweise von kolabd und kolabconf.

13


Der Verzeichnisdienst OpenLDAP gibt die kolabspezifischen Einstellungen per LDAP heraus. Ändern sich Einstellungen, zum Beispiel durch eine Konfiguration über den Kolab Web-Admin, so werden auto-matisch neue Konfigurationsdateien erzeugt und betroffene Dienste benachrichtigt.

1. Wie in Abbildung 2.3 veranschaulicht, schreibt der Kolab Web-Admin Änderungen in den Ver-zeichnisdienst (Schritt 1).

2. Der kolabd muss nun mitbekommen, dass sich im Verzeichnisdienst etwas geändert hat.○ Dies wird entweder automatisch gemacht: Dazu hängt kolabd bei OpenLDAP als Replika-

tionsziel und lauscht auf Port 9999. Sobald sich etwas im Verzeichnisdienst ändert, teilt OpenLDAP dies kolabd mit.

○ Der andere Weg, um kolabd mitzuteilen, dass sich etwas geändert hat, ist manuell den

Befehl /kolab/sbin/kolabconf ausführen (Schritt 2 in der Abbildung – gestrichelter

Pfeil).3. Anschließend ruft kolabd die benötigten Angaben der Änderungen per LDAP vom Verzeichnis-

dienst ab. 4. Nun muss kolabconf benachrichtigt werden: Dazu ruft kolabd im Schritt 4

/kolab/sbin/kolabconf auf.

5. Kolabconf liest alle relevanten Einstellungen aus dem Verzeichnisdienst, ..6. ... liest anschließend das entsprechende Template ein, ...7. ... generiert daraus die passende Konfigurationsdatei und ...8. ... informiert abschließend den zugehörigen Dienst, der dann ggf. neu gestartet wird.

14

Abbildung 2.3: Arbeitsweise des KolabServerKonfigurationssystems – vereinfacht für einen Dienst.


Konfiguration durch Templates

Die Kolab-Komponenten werden durch Konfigurationsdateien konfiguriert, die von kolabconf aus Templates generiert werden. Am Beispiel des Postfix-Dienstes wird nun die Funktionsweise von Templates erläutert:

Alle Template-Dateien liegen im Verzeichnis /kolab/etc/kolab/templates und sind an der

Dateiendung .template zu erkennen. Aus dem Dateiname lässt sich erschließen, um welche

Konfiguration es sich handelt; so wird z. B. aus dem Template /kolab/etc/kolab/templates/

main.cf.template die Konfigurationsdatei /kolab/etc/postfix/main.cf für Postfix generiert

(vgl. Schritt 7 in der obigen Abbildung).

In jeder Template-Datei steht zu Beginn ein Block mit Metainformationen; exemplarisch der Meta-Block von Postfix:

KOLAB_META_START

TARGET=/kolab/etc/postfix/main.cf

PERMISSIONS=0644

OWNERSHIP=kolab-n:kolab-r

KOLAB_META_END

In diesem Abschnitt wird festgelegt wo (TARGET) und mit welchen Zugriffsrechten (PERMISSIONS und

OWNERSHIP) die generierte Konfigurationsdatei im Dateisystem abgelegt wird.

Nachdem die Konfigurationsdateien neu generiert wurden, informiert kolabconf die zugehörigen Dienste. Einige Dienste müssen nach Änderungen an ihren Konfigurationsdateien neu gestartet werden. Welche das sind, ist in Kolab Server 2.2 beta2 noch „hart“ im Kolab-Konfigurationssystem kodiert. Bei künftigen Kolab-Versionen soll auch diese Information in dem o. g. Metainformations-Block im Tem-plate festgelegt werden.

Auffällig sind auch die von @@@ eingerahmten Schlüsselworte im Template. Im einfachsten Fall werden

diese beim Schreiben der Konfigurationsdateien eins zu eins durch entsprechende Werte aus dem Ver-zeichnisdienst ersetzt. Kolabconf liest dafür Werte aus dem vertrauenswürdigen Objekt:

dn: k=kolab, dc=example, dc=com

Anstatt eines Schlüsselwortes können auch konkrete Angaben direkt in das Template eintragen werden.

Dazu wird das Schlüsselwort (inkl. dessen einrahmende @@@ Zeichen) einfach überschrieben.

15


Problemsuche in kolabd / kolabconf

Der kolabd ist das Bindeglied zwischen dem Verzeichnisdienst und dem Cyrus-IMAP-Server. Kolabd kommt erst dann zum Einsatz, wenn Änderungen an der Konfiguration oder den Nutzereinstellungen vorgenommen werden. Probleme am kolabd werden also erst dann sichtbar, wenn Änderungen nicht abgearbeitet werden können.

Typische Symptome für einen gestörten kolabd sind:a) Der im Verzeichnisdienst angelegte Nutzer kann sich nicht im Cyrus anmelden (der kolabd hat

das Konto noch nicht angelegt).b) Die Löschung eines Nutzers dauert sehr lang.

Ein Neustart des kolabd ist harmlos, da er selbst keinen Zustand hält und nicht zeitnah auf Anfragen ant-worten muss. Es schadet also nicht, den kolabd in den beiden oben beschriebenen Situation neu zu star-ten.

Der kolabd protokolliert seine Arbeit in der normalen Log-Datei für Systemmeldungen, bei Debian ist

das meist /var/log/syslog (Achtung: Dies ist nicht innerhalb der OpenPKG-Hierarchie). Um dort

mehr Ausgaben zu erhalten, sollte in der Konfigurationsdatei /kolab/etc/kolab/kolab.conf der

Wert für log_level erhöht und kolabd neu gestartet werden. log_level steht nach der Installation von Kolab Server noch nicht in der kolab.conf; er muss also manuell eingetragen werden. Dessen voreinge-

stellter Wert ist in der Regel 2 und steht in /kolab/etc/kolab/kolab.globals. Für die Ausgaben

in syslog ist nur log_level (0 – 4) interessant. Analog kann für ein interaktives Debugging der Flag debug (0/1) gesetzt werden. Voreinstellungen in /kolab/etc/kolab/kolab.globals:

log_level : 2

debug : 0

Änderung der Werte in /kolab/etc/kolab/kolab.conf, z.B.:

log_level : 4

debug : 1

Bedeutung der Werte:log_level:

0: SILENT

1: ERROR

2: WARN

3: INFO

4: DEBUG

debug:

0: send to syslog if log level >= message priority

1: additionally print all messages to stdout

Sind mehrere Slave-Server im Betrieb, muss erst die Replikation des Verzeichnisdienstes funktionieren, bevor der kolabd auf den verschiedenen Servern tätig werden kann. Die obigen Symptome können also auch auf eine gestörte Replikation hinweisen.

16

3 Kolab Server –

Bedarfsplanung

Es empfiehlt sich den eigenen Bedarf für den Server abzuschätzen. Anhand von einigen Rahmenbedin-gungen werden in diesem Kapitel Hinweise für eine Grob-Planung gegeben.

Dabei ist zu beachten, dass das Nutzungsmuster einen starken Einfluss auf die Bedarfsplanung hat. In manchen Organisation reichen beispielsweise 50 Megabyte E-Mail-Speicherplatz und es werden pro Nutzer weniger als dreistellige Termine gespeichert. Bei Anderen wird E-Mail zur „Ablage“ großer Mul-timedia-Dateien verwendet und die 3000 Termine der ganzen Arbeitsgruppe der letzten drei Jahre archi-viert; hier wird ein Quota von 2 Gigabyte sicherlich schnell eng.

3.1 Festplattenspeicher

Die wichtigste Tätigkeit eines Kolab-Servers ist es, für die Klienten E-Mail-Daten zu liefern. Jedes Groupware-Objekt ist ebenfalls eine E-Mail. In der Regel haben die meisten Nutzer deutlich mehr nor-male E-Mails als andere Groupware-Objekte, eine Bedarfsschätzung sollte also bei der E-Mail anfangen. Der durchschnittliche E-Mail-Speicherplatz in den nächsten Jahren, multipliziert mit der Anzahl der Nut-zer und etwas Puffer ergibt den zu erwartenden Plattenplatz der Nutzerdaten. Aus der erwarteten Ände-rungsrate lässt sich auch der Platz für die Datensicherung abschätzen. Gegenüber den normalen E-Mails fallen die Termine und Kontakte meist nicht ins Gewicht.

Wird als Klient Microsoft Outlook mit einem der verfügbaren Konnektoren verwendet (vgl. Abschnitt 6.2), ist es möglich, dass sich die Größe mancher E-Mails in der Speicherung verdoppeln. Nur so können manche Objekt-Attribute gespeichert werden, welche nur für Outlook wichtig sind. Wer ganz sicher gehen möchte, migriert auf ein Testsystem die alten Daten einiger repräsentativer Nutzer.

17

3 Kolab Server – Bedarfsplanung

Entscheidend wird der Umgang mit Alt-Daten im System sein. Was werden die Nutzer tun, wenn sie an ihr Limit stoßen? Es empfiehlt sich, den Nutzern hier früh eine Möglichkeit anzubieten, z.B. zum selb-ständigen Archivieren. Die Klienten bieten meist Funktionen zum automatischen Löschen alter E-Mails oder Termine an.

3.2 Rechenleistung / Hauptspeicher

Beim Verfügbarmachen von E-Mails sind vor allem das Übermitteln von Daten, Platten- und Netzwerk-durchsatz, sowie die Netzlatenz limitierender als die Rechenleistung. Pro aktivem Klienten läuft etwa ein Cyrus-IMAPd, der grob um die 2 Megabyte Hauptspeicher benötigt.

Ein „aktiver Klient“ steht in diesem Zusammenhang für einen Klienten, der einen Zwischenspeicher besitzt und daher hauptsächlich nur zum Synchronisieren eine Netzwerkverbindung benötigt. Der ein-zelne Nutzer kommt also problemlos minutenlang ohne Verbindung aus. Es ist zu erwarten das durch geschicktere Synchronisations-Algorithmen von Seiten der Klienten der Bedarf an Netzverbindungen in Zukunft sogar sinken kann.

Deutlich mehr Rechenleistung im Kolab-Server benötigen zwei andere Prozesse:1. Das Scannen von E-Mails auf Schadsoftware und unerwünschte Werbung, 2. sowie das Erstellen von Frei/Belegt-Listen.

Die Erstellungszeiten von Frei/Belegt-Listen sind von Kolab Server 2.0 auf 2.1 entscheidend verbessert worden. Langzeiterfahrungen fehlen, aber es wird eine deutliche Besserung erwartet, so dass dieses für den Betrieb von 2.2 nicht mehr gesondert geplant werden muss. Im Gegensatz dazu hat der Ansturm an unerwünschten E-Mails zugenommen, was mehr Scan-Leistung erforderlich macht. Für das Scannen von E-Mails ist deshalb bei größeren Installation ein eigener Rechner sinnvoll.

Bei durchschnittlicher Nutzung ist zu erwarten, dass eine übliche Server-Hardware mit 2 Prozessoren und 4 Gigabyte Hauptspeicher mehrere tausend Nutzer bedienen kann. Das gilt pro Kolab-Server; durch den Einsatz von Slave-Servern ist hier eine gute Skalierung möglich.

3.3 Verfügbarkeit

Die Bedürfnisse an die Verfügbarkeit der Kolab-Server sind recht unterschiedlich. Wie im letzten Absatz beschrieben, sind die Klienten auch ohne Netzverbindung grundsätzlich arbeitsfähig. Dennoch sollte eine hohe Verfügbarkeit von jedem Kolab-Servers angestrebt werden.

Der Kolab-Server kann mit üblichen GNU/Linux Mechanismen abgesichert werden. Zum Beispiel durch ein aktiv-passiv System, welches per Linux-HA1 den aktiven Rechner überwacht und bei Schwierigkei-ten den passiven einschaltet. Dazu muss der passive Rechner auf die Daten zugreifen können: z. B. durch ein gemeinsames SCSI Plattensystem / SAN, ggf. auch standortübergreifend.

1 http://www.linux-ha.org/ [Abruf: 07.12.2007]

18

http://www.linux-ha.org/

3 Kolab Server – Bedarfsplanung

3.4 Wer arbeitet mit wem?

Es kann sinnvoll sein, aus Gründen der Leistung oder verschiedener Standorte, mehrere Kolab-Server zu planen. Dabei ist zu beachten, wie die Arbeitsbeziehungen der Nutzer sind. Es ist empfehlenswert, eng zusammenarbeitende Nutzer auf einen Kolab Server zu legen – also beispielsweise lieber eine Abtei-lung X, als die Mitarbeiter von A bis H.

Interessant sind dabei auch Fragen der Modellierung von gemeinsamen Ordner (z.B. für Termine):Ein Ordner steht zunächst nur Nutzern auf einem Server zur Verfügung. Kolab-Nutzer haben einen bestimmten Heimatserver, dürfen sich aber auf allen anderen anmelden. Das ist weniger nötig, wenn sich die Nutzer einer Arbeitsgruppe schon auf einem gemeinsamen Heimatserver befinden.

19

4 Kolab Server – Vorbereitung

und Installation

In diesem Kapitel werden zunächst die nötigen Grundvoraussetzungen und Vorbereitungen für die danach beschriebene Installationsanleitung des Kolab Servers erläutert. Anschließend wird das Vorgehen für eine Aktualisierung und für die Deinstallation dargestellt.

4.1 Installationsvorbereitung

Speicherplatz/ ort Die Installation des Kolab Servers (inkl. Horde) belegt unter /kolab etwa

1 GB Speicherplatz. Falls das Verzeichnis nicht existiert, wird es angelegt. Ein Symlink kann genutzt werden. Die Nutzung eines NFS gemounteten Laufwerks ist nicht möglich, da es sonst zu Problemen mit dem Cyrus IMAP Server kommt1.

Partitionierung Für einen produktiven Einsatz eines Kolab Servers wird empfohlen, getrennte Partitionen für Programme, Bewegungsdaten und Nutzerdaten zu verwenden. Nachfolgend eine Empfehlung für eine typische Installation, bei der Verzeichnisse von Kolab auf drei Partitionen verteilt werden:

/kolab 2 - 4 GB (Programme)

/kolab/var 2 - 4 GB (Bewegungsdaten)

/kolab/var/imapd/spool nach geplanten Bedarf (Nutzerdaten)

Dateisystem Es wird ein geeignetes Dateisystem benötigt. Die meisten Kolab-Server- Installationen werden mit ext3 betrieben, aber es existieren auch nennens-werte Erfahrung mit XFS. Bei der Nutzung von ext3 wird empfohlen, einen Linux Kernel ab 2.6.19.2 oder einen entsprechend gepatchten Kernel zu

1 http://cyrusimap.web.cmu.edu/imapd/faq.html [Abruf: 07.12.2007] Der Cyrus IMAPd braucht ein lokales Dateisystem, mit Unix-Eigenschaften und funktionierender mmap()/write() Kombination.

20

http://cyrusimap.web.cmu.edu/imapd/faq.html

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ßen25/tcp smtp offen nach außen465/tcp smtps offen nach außen110/tcp pop3 offen nach außen (bei Bedarf)995/tcp pop3s offen nach außen (bei Bedarf)143/tcp imap offen nach außen993/tcp imaps offen nach außen389/tcp ldap offen nach außen636/tcp ldap offen nach außen2000/tcp sieve offen nach außen (bei Bedarf)2003/tcp lmtp nur intern offen9999/tcp kolabd nur intern offen10024/tcp amavis nur intern offen

21

http://kolab.org/mirrors.html


4.2 InstallationIm folgenden Abschnitt werden die Schritte zur Installation des Kolab Servers mit den unter Abschnitt 4.1 heruntergeladenen Paketen beschrieben. Es sollte zusätzlich die bei den Paketen beiliegende 1st.README-Datei beachtet werden.

1. Die Installation

Die Pakete in den Verzeichnissen sources und ix86-debian4.0 lassen sich mit dem enthaltenen install-kolab.sh-Skript (als root) installieren. Es steht eine Installation von den Quellcodepaketen (sources) oder von den für Debian 4.0 vorkompilierten ix86-Binärpaketen (ix86-debian4.0) zur Wahl. Dafür muss in das entsprechende Verzeichnis gewechselt werden. Anschließend wird die Installation gestartet mit:

./install-kolab.sh -H -F 2>&1 | tee kolab-install.log

Um den Kolab Webklienten Horde und/oder den Frei/Belegt-Viewer nicht mitzuinstallieren, muss

der Parameter -H und/oder -F in o. g. Befehlszeile weggelassen werden. Die Konsolenausgabe

wird in der kolab-install.log protokolliert.

Installationsdauer: Die Installation aus den Quellpaketen kann, je nach Rechenleistung, leicht einige Stunden dauern (z. B. bei einem P4 mit 3 GHz sind es ca. 3 Stunden). Bei der Binärpaket-Installa-tion kann mit ca. 3 bis 10 Minuten gerechnet werden.

Bei Schwierigkeiten mit der Binärpaket-Installation sollte stets die Installation von den Quellen pro-biert werden.

2. Das Bootstrapping

Nach der Installation sollte die initiale Konfiguration (das Bootstrapping) des Kolab-Servers mit folgendem Befehl durchgeführt werden:

/kolab/etc/kolab/kolab_bootstrap -b

Dabei werden zunächst die benötigten Ports nach Verfügbarkeit getestet. Anschließend werden unterschiedliche Informationen zum Kolab-Server abgefragt.

Nachfolgender Ausdruck zeigt exemplarisch das Konfigurieren eines Master-Servers mit einer eige-nen Zertifizierungsstelle für Testzwecke. Alle nötigen Eingaben sind fett gedruckt ([Enter] meint das Drücken der Enter/Return-Taste ohne weitere Eingabe) und dienen nur zur Demonstration des Bootstrapping-Prozesses. Für das Aufsetzen eines eigenen Systems sollten diese Eingaben unbe-dingt an die spezifischen Anforderungen angepasst werden. Wird ein Produktivsystem aufgesetzt, sollten Zertifikate einer „richtigen“ Zertifizierungsstelle (Cer-tification Authorities, kurz CA) zum Einsatz kommen. Unter http://www.pki-page.org gibt es eine ausführliche Liste weltweiter, aktueller Zertifizierungsstellen. Wichtig ist dabei, dass die Zertifikate in den Klienten als vertrauenswürdig anerkannt werden.

22

http://www.pki-page.org/


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 [email protected] 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


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


Am Ende des Bootstrappings sollte die Ausgabe der folgenden ähnlich sein: kolab is now ready to run! please run '/kolab/bin/openpkg rc all start'

Use login=manager and passwd=VG1rXCIxi22/c4DT when you log into the webinterface https://kolab.example.com/admin !

Anmerkung: Es sollte zunächst der Master-Server konfiguriert werden. Das (optionale) Hinzufügen von weiteren Kolab-Slave-Servern ist im Abschnitt 5.12 beschrieben.

3. Server starten

Der Kolab Server ist erfolgreich installiert und kann nun mit folgendem Befehl gestartet werden:

/kolab/bin/openpkg rc all start

Das Verzeichnis /kolab/RPM/PKG/ wird nur zur Installation gebraucht und kann anschließend

gelöscht oder für spätere Installationen archiviert werden (Größe: ca. 500 MB).

4.3 Aktualisierung

Achtung: Die Migration von Kolab Server 2.1 auf 2.2 wird zur Zeit noch getestet! Für Hinweise kann die Kolab-Mailinglisten, das Kolab-Wiki bzw. der Kolab-Issue-Tracker genutzt werden (vgl. Anhang A).

Vor jeder Aktualisierung sollte in jedem Fall ein Backup von /kolab durchgeführt werden (vgl.

Punkt 2 dieser Anleitung und Abschnitt 5.13).

Hier folgt eine allgemeine Anleitung zum Aktualisieren des Kolab Servers. Die Installation von neuen Paketen läuft analog zur initialen Kolab-Server-Installation (vgl. Abschnitt 4.2). Die Hinweise in der Datei 1st.README sind zusätzlich zu beachten.

1. Beenden aller Kolab Server Dienste: /kolab/bin/openpkg rc all stop

und sicherstellen, dass kein LDAP-Prozess mehr läuft: /kolab/bin/openpkg rc openldap status und ps -AF | grep slapd

2. Sichern der vollständigen, alten Kolab-Installation!Zum Reduzieren der Server-Stillstandszeit (downtime) wird empfohlen, das Verzeichnis

/kolab mit rsync zunächst von dem noch laufenden Server zu kopieren. Anschließend, bei

gestoppten Server, müssen mit rsync nur noch die geänderten Dateien nachgesichert werden. Sofern ein ähnliches Vorstufen-System zur Verfügung steht („staging“) empfiehlt es sich, die Binärdateien dort zu bauen und diese dann zu kopieren. Dadurch wird entscheidende Zeit gespart.

25


3. Nach dem Aktualisieren der Kolab Server Pakete in dem Verzeichnis, in dem bereits die anderen Pakete liegen kann das Kolab Server Update (als root) gestartet werden:

./install-kolab.sh -H -F 2>&1 | tee kolab-update.log

install-kolab.sh bestimmt in der Regel automatisch welche Pakete benötigt werden und instal-liert oder baut diese.

Die Parameter -H und -F geben an, ob der Kolab Webklient Horde und der Frei/Belegt-Viewer

nachinstalliert / aktualisiert werden.

Die Konsolenausgabe wird in der kolab-update.log protokolliert. Der Server wird aktualisiert, ohne dass die bereits vorhandenen Konfigurationen und Daten überschrieben werden. Manuell geänderte Konfigurationsdateien werden mit der Dateinamener-weiterung *.rpmsave gespeichert. Bei Konfigurationsdateien, die von Templates generiert wer-den, müssen die *.conf.rpmsave Dateien zunächst gelöscht werden, um den entsprechenden Dienst starten zu können; z. B. für ClamAV:

rm /kolab/etc/clamav/*.conf.rpmsave

Die Änderungen aus den *.template.rpmsave Dateien (die angelegt werden, wenn Templates geändert wurden) können nun in die neuen Template-Dateien übertragen werden. Nun muss der OpenLDAP gestartet, die Konfigurationsdateien neu generiert und schließlich der komplette Kolab Server neu gestartet werden:

/kolab/bin/openpkg rc openldap start

/kolab/sbin/kolabconf

/kolab/bin/openpkg rc all start

Detailliertere Upgrade-Informationen – insbesondere zu Besonderheiten beim Upgrade von früheren Kolab-Versionen – sind in den Readme-Dateien im CVS-Server-Verzeichnis2 bzw. in der 1st.README im Installationsordner zu finden.

Sicherheitsupdates

Zunächst ist der Benachrichtigungsweg relevant: Wie bekommt der Administrator Kenntnis von einem Sicherheitsupdate? Entweder wird er von seinem Dienstleister benachrichtigt und mit einer genauen Anleitung versorgt, oder er muss sich selbst darum kümmern.

Ist kein Dienstleister damit beauftragt, wird geraten, mindestens folgende Quellen zu verfolgen: ➔ die Kolab-Announce-Mailingliste (vgl. Anhang A) zu abonnieren ➔ die Sicherheitsrelevanten Informationen der genutzten Distribution (z.B. Debian security) zu

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

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/


Treten Unsicherheiten/Schwierigkeiten beim Durchführen von Sicherheitsupdates auf, sollte ein Dienst-leister zu Rate gezogen werden. Ein funktionierender Prozess, um zu Aktualisierungen zu kommen ist wichtig, da ansonsten das eingesetzte System Gefahr läuft längere Zeit bekannte Angriffspunkte zu bie-ten.

4.4 Deinstallation

Der Kolab Server/OpenPKG kann in drei Schritten deinstalliert werden:

1. Kolab Server beenden:/kolab/bin/openpkg rc all stop

2. Alle Kolab-Pakete löschen:/kolab/bin/openpkg rpm -e `/kolab/bin/openpkg rpm -qa`

rpm -qa listet alle Pakete innerhalb der OpenPKG Umgebung und rpm -e löscht diese.

3. Kolab-Verzeichnis löschen:rm -rf /kolab/

Anschließend sollten ...➔ ... alle kolabspezifischen cronjobs in /etc/crontab und die Datei

/var/spool/cron/crontabs/kolab,

➔ ... alle kolabspezifischen Benutzer in /etc/passwd und in /etc/shadow,

➔ ... alle kolabspezifischen Gruppen in /etc/group,

➔ ... alle kolabspezifischen Einträge in /etc/shells,

➔ ... das Kolab/OpenPKG Initskript /etc/init.d/kolab mit den Symlinks in

/etc/rc?.d/???kolab und

➔ ... das /kolab Verzeichnis

durch OpenPKG entfernt worden sein.

27

5 Kolab Server – Konfiguration

und Betrieb

Dieses Kapitel beschreibt die Konfigurationsmöglichkeiten des Kolab Servers und gibt darüber hinaus für den Betrieb nützliche Methoden und Einstellungen mit.

Es gibt zwei grundsätzliche Strategien den Kolab Server zu konfigurieren: ➔ Über ein LDAP-Verzeichnisdienst-Werkzeug – beispielsweise mit dem Kolab Web-Admin (vgl.

folgender Abschnitt) oder➔ über die kolabspezifische Konfigurationskomponente kolabconf. Dabei können die Konfigurati-

onstemplates und -dateien der einzelnen Kolab-Komponenten angepasst werden. Mithilfe des

Befehls /kolab/sbin/kolabconf werden die Änderungen aus den Templates wirksam.

Beide Strategien sollte ein Systemadministrator eines Kolab Servers anwenden können. Dieses Kapitel vermittelt die dafür nötigen Kenntnisse.

5.1 Kolab WebAdmin

Der Kolab Server stellt ein Webinterface – den Kolab Web-Admin – zur Verfügung, worüber die gän-gigsten Servereinstellungen konfiguriert werden können. Der Web-Admin ist unter dem Kolab-Rechner-namen https://kolab.example.com/admin im Web-Browser zu erreichen. Für den ersten Login kann der voreingestellte Administratorname manager genutzt werden; das Passwort wurde während der Installa-tion vergeben. Für die regelmäßige, administrative Arbeit sollte jedoch ein Administrator-Account ange-legt werden. Nach dem Einloggen erhält der Nutzer eine Navigationsleiste (vgl. Abb. 5.1) mit Links zu Einstellmöglichkeiten des Kolab Servers.

28

5 Kolab Server – Konfiguration und Betrieb

Der Web-Admin ist in PHP geschrieben und nutzt den Apache Webserver (mit mod_php). Das Webinter-face unterstützt SSL-Verschlüsselung und Authentifikation gegen den Verzeichnisdienst. Der Web-Admin ist ein LDAP-Verzeichnisdienst-Werkzeug und kommuniziert ausschließlich mit dem LDAP-Ser-ver (eine Ausnahme sind Sieve-Skripte). In dieser Betriebsdokumentation wird exemplarisch für einige Konfigurationsmöglichkeiten auf den Web-Admin verwiesen. Weitere Informationen zur Konfiguration des Kolab Servers mit dem Web-Admin sind in der Kolab-Dokumentation Doc2 zu finden (vgl. Anhang A).

5.2 Rollen

Der Kolab Server stellt vier Rollen zur Verfügung, die nachfolgend beschrieben werden:1. Administrator2. Verwalter3. Domänenverwalter4. Benutzer

Darüber hinaus nimmt der Rechner-Administrator (root) eine „Sonderrolle“ ein. Aus Sicherheitsgründen haben die Kolab-Nutzer in der Regel keine Rechnerkonten und somit keinen direkten Zugriff (z.B. per ssh) auf den Server.

Abbildung 5.2 veranschaulicht den Zusammenhang der vier Rollen und deren Berechtigungen: Die Rechte von Benutzer sind eine Untermenge von den Domänenverwalter-Rechten, diese wiederum Untermenge von Verwalter sind. Die Administratoren-Rechte umfasst alle genannten Berechtigungs-mengen. Eine detaillierte Auflistung der rollenspezifischen Rechte folgt in den nächsten Abschnitten.

29

Abbildung 5.1: Navigationsleiste vom Kolab WebAdmin (managerAnsicht)


5.2.1 Administrator

Die Benutzergruppe Administrator besitzt Lese- und Schreibberechtigung für den LDAP-Verzeichnis-baum. Ein Administrator hat Zugang zu allen Einstellmöglichkeiten innerhalb des Kolab Web-Admins.

Das Passwort des voreingestellten Administrators manager wurde bei der Installation des Kolab Servers vergeben und ist bei Verlust in der folgender Datei wiederzufinden (Dies gilt ausschließlich nur für den manager. Andere Administratoren werden hier nicht gespeichert!):

/kolab/etc/kolab/kolab.conf (Zeile bind_pw).

Zum Ändern des manager Passworts kann der Befehl /kolab/bin/kolabpasswd

genutzt werden.

Ein Administrator ist berechtigt folgende Aufgaben durchzuführen:➔ Hinzufügen, Ändern und Löschen von Administratoren➔ Hinzufügen, Ändern und Löschen von Verwaltern➔ Hinzufügen, Ändern und Löschen von Domänenverwaltern➔ Hinzufügen, Ändern und Löschen von Benutzern➔ Hinzufügen, Ändern und Löschen von externen Adressen➔ Hinzufügen, Ändern und Löschen von gemeinsam genutzten Ordnern➔ Hinzufügen, Ändern und Löschen von Verteilerlisten➔ Konfiguration der Dienste➔ eigenes Passwort ändern (außer manager)

30

Abbildung 5.2: Die vier Benutzerrollen des Kolab Servers mit ihren Zugriffsberechtigungen auf den Verzeichnisdienst


5.2.2 Verwalter

Die Rolle Verwalter ist die eines Administrators ähnlich – mit dem Unterschied, dass ein Verwalter nicht berechtigt ist, folgende Aufgaben durchzuführen:

➔ Hinzufügen, Ändern und Löschen von Administratoren➔ Hinzufügen, Ändern und Löschen von Verwaltern➔ Konfiguration der Dienste

5.2.3 Domänenverwalter

Im Vergleich zum Verwalter darf ein Domänenverwalter folgende Aufgaben nicht durchführen:➔ Hinzufügen, Ändern und Löschen von Domänenverwaltern➔ Hinzufügen, Ändern und Löschen von externen Adressen➔ Hinzufügen, Ändern und Löschen von Benutzern für fremde (nicht berechtigte) Domänen

5.2.4 Benutzer

Benutzer werden von Administratoren, Verwaltern oder Domänenverwaltern angelegt. Abbildung 5.3 zeigt das Eingabeformular zum Hinzufügen eines Benutzers im Kolab Web-Admin.

Benutzer können sich selbständig über den Web-Admin anmelden und ihre persönlichen Daten ändern. In der Voreinstellung dürfen folgende Attribute jedoch nur vom Administrator, Verwalter oder Domänen-verwalter geändert werden:

● Vorname● Nachname● Eindeutige Identität (UID = Unique identity)● Kontotyp● E-Mail-Aliasnamen● Plattenplatz des Benutzers in Megabytes

Als Benutzername für den Login beim Kolab Web-Admin kann sowohl die UID also auch die primäre E-Mail-Adresse (PEM) eines Kontos genutzt werden. Die UID ist in der Voreinstellung gleichzeitig auch die primäre E-Mail-Adresse. Diese kann aber jederzeit vom Administrator/(Domänen-)Verwalter geän-dert werden.

Die primäre E-Mail-Adresse und der zugeordnete Kolab-Homeserver kann nach dem Anlegen eines Kontos nicht mehr geändert werden. Was bei einer Namensänderung oder einer geplanten Migrierung eines Kontos auf einen anderen Homeserver zu tun ist, zeigt die zweite graue Box auf der übernächsten Seite. Weitere Informationen zu Kolab-Homeservern sind im Abschnitt 5.12 zu finden.

31


LDAPAttribute ändern

Die Sichtbarkeit und Zugriffsberechtigung der LDAP-Attribute im Web-Admin kann im Template

/kolab/etc/kolab/templates/session_vars.php.template definiert werden. Wichtig:

Diese LDAP-Attributseinstellungen gelten nur für den Kolab Web-Admin!

Um ein Attribut zu ändern, muss dem Array $params['attribute_access'] ein Element hinzuge-

fügt werden. Deren möglichen Rechte sind:➔ ro (readonly)

➔ rw (read/write)

➔ hidden (atribute removed from display)

➔ mandatory (read/write and must not be empty)

Alle nicht im o. g. Array angegeben Attribute sind auf den voreingestellten Wert rw definiert. Ein Bei-

spiel, wie nur die Attribute „firstname“ und „lastname“ auf „nur lesbar“ gesetzt werden:$params['attribute_access'] = array('firstname'=>'ro','lastname'=>'ro');

Um die Änderung in dem Template wirksam werden zu lassen, muss anschließend der Befehl

/kolab/sbin/kolabconf aufgerufen werden (vgl. Abschnitt 2.4).

32

Abbildung 5.3: Anlegen eines neuen Benutzers im Kolab WebAdmin


Wie findet man den KolabHomeserver zu einem bestimmten EMailKonto?

...mit den Befehlen listusers und showuser:kolab listusers|grep user

-> [email protected]

[email protected]

[email protected]

kolab showuser [email protected]|grep -i kolabhome

-> kolabHomeServer: kolab2.example.com

Das Postfach des Benutzers [email protected] 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 EMailAdresse) eines Benutzers sich ändert (z. B. durch Heirat oder Scheidung)? Wie lässt sich ein Benutzer auf einen anderen KolabServer migrieren?

Der Name kann problemlos von einem Administrator/Verwalter geändert werden. Die primäre E-Mail-Adresse kann nach dem Anlegen eines Kontos allerdings nicht mehr bearbeitet werden. Die einfachste Lösung wäre, eine neue Alias-E-Mail-Adresse einzutragen und die UID auf einen neuen Benutzernamen (z. B. ebenfalls die neue Alias-Adresse) zu ändern.

Alternativ müsste ein neues Benutzerkonto (mit neuem Nachnamen und primärer E-Mail-Adresse) auf dem (neuen) Kolab Server anlegt und alle alten Daten des Benutzers in das neue Konto kopiert werden. Diese Variante ist auch für das vollständige migrieren eines Benutzers auf einen anderen Kolab-Homeserver geeignet. Eine aktuelle Anleitung ist in folgender Datei (im Kolab CVS) enthal-ten: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/raw-howtos/move-rename-user.txt

5.3 Kontotypen

Zu jedem neu angelegten Benutzer muss einer der vier Kontotypen ausgewählt werden:

1. Benutzerkonto (voreingestellt)Dies ist der meist gebräuchliche Kontotyp. Die E-Mail-Adresse ist von außen erreichbar und der Benutzer ist im LDAP-Adressbuch sichtbar. Speicherort: Base-DN (z. B.: dc=example, dc=com)

2. Internes BenutzerkontoDieser 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

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/raw-howtos/move-rename-user.txt


außen empfangen. Er ist damit auch nicht im öffentlichen Kolab-Adressbuch geführt.Speicherort: unter cn=internal, Base-DN

3. GruppenkontoEin 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. RessourcenkontoMit dem Kolab Server können Ressourcen (wie z. B. ein Besprechungsraum, Dienstwagen oder Beamer) verwaltet werden. Ressourcenkonten haben bereits voreingestellt für den Benutzer calendar Schreibzugriff auf den eigenen Kalender-Ordner, um automatisch Einladungen anneh-men zu können (vgl. Abschnitt 5.7.1).Speicherort: unter cn=resources, Base-DN

Jedes Konto braucht einen Inhaber. Insbesondere bei Gruppen- und Ressourcenkonten ist es wichtig, dass es eine zuständige Person gibt, die das Konto pflegt und z. B. von unerwünschten Nachrichten bereinigt. Diese Person muss nicht der Systemadministrator sein; im Gegenteil: es sollte eher eine der Gruppe oder der Ressource inhaltlich nahe stehende Person damit beauftragt werden.

5.4 Nutzerlebenszyklus

Anlegen im Webinterface

➔ Der Webinterface-Code überprüft, ob die E-Mail-Adresse, die UID oder eines der Alias-Einträge mit bestehenden Nutzern, Verteilerlisten oder Adressbucheinträgen kollidiert und verweigert in diesem Fall das Anlegen.

➔ Das LDAP-Objekt im Kolab-Master wird angelegt.➔ Replikation auf Kolab-Slaves➔ Replikation zu allen kolabd-Prozessen➔ kolabd auf allen Servern legen IMAP-Mailboxen an.

Die INBOX wird nicht nur auf dem Kolab-Homeserver angelegt, damit IMAP-Klienten zum Lesen von freigegebenen Ordnern auch die anderen Server kontaktieren können.Auf dem Kolab-Homeserver bleiben die IMAP-ACLs auf den Standardwerten, bei Ressourcen-

34


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.comkolabDeleteflag: kolab-slave1.example.comkolabDeleteflag: 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 : 1kolab_remove_attributes : mail ou

35


5.5 EMail

Der nachfolgende Abschnitt beschreibt, wie der E-Mail-Betrieb auf dem Kolab Server funktioniert und an welchen Stellen der Administrator diesen Betrieb konfigurieren kann.

5.5.1 Die IMAP Spool Struktur

Der Cyrus IMAP-Server speichert alle E-Mails als einzelne Dateien in seinem Spool-Verzeichnis, das

bei einer typischen Kolab-Installation unter /kolab/var/imapd/spool liegt. Zur übersichtlicheren

Verwaltung bei sehr vielen Nutzern, verwendet der Kolab Server (seit Version 2.1) die Option hashimapspool: yes. Danach folgt die Struktur des Spool-Verzeichnisses dem Muster:

.../spool/domain/e/example.com/m/user/meier/[Ordner/...]

Die Domänen und Benutzer liegen in Verzeichnissen, die ihren jeweiligen Anfangsbuchstaben entspre-chen: in dem o. g. Beispiel liegt also das Verzeichnis für example.com in dem Verzeichnis e. Im Unter-

schied dazu werden Gruppenkonten unter ../user/<Gruppenname> und Ressourcenkonten unter

../user/<Ressourcenname> gespeichert.

Das eigentliche Benutzer-Verzeichnis entspricht der jeweiligen IMAP-Inbox, alle Unterverzeichnisse entsprechen den IMAP-Unterordnern. Die Ordner enthalten jeweils Dateien, deren Name eine Zahl gefolgt von einem Punkt ist. Diese Dateien enthalten die eigentlichen E-Mails. Im gleichen Ordner befinden sich die drei Dateien cyrus.cache, cyrus.header und cyrus.index, die bestimmte Metainforma-tionen der Nachrichten speichern.

Mit diesen Kenntnissen kann der Administrator leicht E-Mails eines bestimmten Anwenders im Backup

finden. Die unter /kolab/var/imapd/log liegenden Logdateien bieten zusätzliche Informationen,

wann aus welchen Postfächern E-Mails gelöscht wurden.

5.5.2 Der Weg einer EMail

Trifft eine E-Mail am Kolab-Server ein, durchläuft sie verschiedenen Komponenten des Servers. Dieser Weg einer E-Mail – vom SMTP-Eingangsserver bis in das IMAP-Ordner des Kolab-Nutzers – wird in Abbildung 5.4 veranschaulicht und in den folgenden Schritten erläutert:

1. Die E-Mail wird von Postfix auf dem SMTP-Port 25 entgegengenommen.2. Postfix konsultiert den kolab_policy (/kolab/etc/kolab/kolab_smtpdpolicy). Dieser

überprüft z. B., ob der Sender berechtigt ist an die adressierte Kolab Verteilerliste zu schreiben.3. Postfix übergibt anschließend die Nachricht an den kolabfilter (/kolab/var/kolab-filter

/scripts/kolabfilter.php). Handelt es sich bei der Empfänger-Adresse um eine Vertei-

lerliste oder eine Kolab Alias-Adresse, so wird vorher die Adresse in die primäre E-Mail-Adresse aufgelöst. Bei einer Verteilerliste existiert anschließend weiterhin noch eine E-Mail, jedoch mit allen einzelnen Empfänger-Adressen der Listenmitglieder.

4. Nachdem kolabfilter seine Aufgabe beendet hat, übergibt er die Mail per SMTP an Postfix (Port 10025).

36


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

Abbildung 5.4: Der Weg einer EMail im Kolab Server


5.5.3 Weiterleitung

Ein Benutzer ist berechtigt eine E-Mail-Weiterleitung an jede beliebige E-Mail-Adresse einzurichten. Die Aktivierung kann vom Benutzer selbständig im Kolab Web-Admin (innerhalb seiner eigenen Benut-zereinstellungen) erfolgen. Es besteht die Möglichkeit Kopien der weitergeleiteten E-Mails auf dem Kolab-Server zu belassen.

5.5.4 Abwesenheitsbenachrichtigung

Ein Benutzer kann in seiner Abwesenheit das automatische Versenden von Antworten auf eingehende E-Mails aktivieren. Die nötigen Einstellungen können innerhalb der Web-Admin-Benutzereinstellungen vorgenommen werden (vgl. Abbildung 5.5).

Anmerkung zum erneuten Benachrichtigungsversand: Die Einstellung in obiger Abbildung (7 Tage) bedeutet, dass das Senden einer Abwesenheitsbenachrichtigung aktiviert wurde und falls innerhalb von 7 Tagen weitere Mails desselben Absenders eingehen, nur die erste Nachricht automatisch beantwortet wird. Nach Ablauf dieser Frist wird erneut eine Abwesenheitsnachricht versandt. Dies soll unnötigen E-Mail-Verkehr vermeiden helfen.

Anmerkung zu Spam-Mails: Bei Aktivierung der Option Keine Abwesenheitsbenachrichtigungen auf Spamnachrichten senden wird keine Nachricht an den Absender geschickt, wenn die E-Mail als Spam deklariert wurde.

Anmerkung zur Domain-Angabe: Sofern eine Mail-Domäne angegeben wird, bekommen nur Absender dieser Domäne Abwesenheitsbenachrichtigungen zugesandt. Dadurch kann diese Funktion z. B. auf Nachrichten einer Organisation beschränkt werden.

39

Abbildung 5.5: Einstellungen für Abwesenheitsbenachrichtigungen im Kolab WebAdmin


5.5.5 Serverseitige Filterung mit Sieve

Sieve ist eine Skriptsprache, die speziell für das serverseitige Filtern von E-Mails konzipiert wurde. Die genaue Spezifikation kann im RFC 3028 nachgelesen werden. Der Kolab Server nutzt Sieve u. a. für Weiterleitungen und Abwesenheitsbenachrichtigungen (vgl. Abschnitt 5.5.3 und 5.5.4). Ein Benutzer kann immer nur ein Sieve-Skript zur gleichen Zeit aktiviert haben. Im Web-Admin kann aus drei vorde-finierten Sieve-Skripten – zum Verteilen, Weiterleiten und Verschicken von Abwesenheitsbenachrichti-gungen (vgl. vorhergehende Abschnitte) – ausgewählt werden.

Manchmal kann es nützlich sein, ein selbst erstelltes Sieve-Skript mit mehreren unterschiedlichen Filter-regeln zu definieren. Ein Weg das fertige Skript hochzuladen und zu aktivieren ist sieveshell. Es ist zu beachten, dass sieveshell eine unverschlüsselte Verbindung nutzt. Es wird daher dringendst empfohlen sieveshell nur direkt auf dem Kolab- Server oder über eine verschlüsselte Netzwerkverbindung auszu-führen.

Starten von sieveshell (das manager-Passwort wird dafür benötigt):/kolab/bin/sieveshell [email protected] --authname=manager localhost

Der Befehl muss als root ausgeführt werden, sofern das Sieve-Skript für eine andere Person gesetzt wer-den soll.

Mit nachfolgenden sieveshell-Befehlen lassen sich alle Sieve-Skripte des Nutzers auf dem Server anzei-

gen (list), das Skrip hochladen (put) und aktivieren (activate) und schließlich sieveshell wieder

beenden (quit):> list

> put example.siv

> activate example.siv

> quit

Mit help lassen sich alle sieveshell-Befehle mit einer kurzen Erklärung auflisten.

Um eintreffende E-Mails nicht alle im zentralen Posteingang des Benutzers zu haben, ist es mit Sieve möglich diese Nachrichten bereits serverseitig in bestimmte IMAP-Ordner einzusortieren (nützlich z. B. um E-Mails aus verschiedenen Mailinglisten automatisch in bestimmte Unterordner verschieben zu las-sen). Das nachfolgende Sieve-Skript-Beispiel demonstriert diesen Fall, wobei Sieve zusätzlich Abwesen-heitsbenachrichtigungen nur an Absender einer Mail-Domain sendet:

require "vacation";

require "fileinto";

if allof (not header :contains "X-Spam-Flag" "YES",

address :domain :contains "From" "example.com" ) { vacation :addresses [ "[email protected]", "[email protected]" ] :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


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 EMailVertreter

Wenn ein Benutzer einen Vertreter bestimmt, kann dieser Vertreter mit der E-Mail-Adresse des Benut-zers Nachrichten versenden. Dies ist dann hilfreich, wenn der Vertreter beispielsweise den Kalender des Benutzers verwalten darf und z. B. der Sekretär im Namen seines Chefs Einladungen verschicken kann. Vertreter dürfen sowohl für Benutzerkonten als auch für Gruppen- oder Ressourcenkonten definiert wer-den.

Es können nur Kolab-Nutzer als Vertreter bestimmt werden (aufgrund der Nachrichtenfilterregelung – vgl. Abschnitt 5.5.12). Ein externer Nutzer kann kein Vertreter sein. Das Bestimmen mehrerer Vertreter ist möglich.

Ein Benutzer kann seine Vertretung mit dem Eintragen der Vertreter-E-Mail-Adresse(n) innerhalb seiner Web-Admin-Benutzereinstellungen aktivieren.

Anmerkung: Wenn ein Vertreter im Namen des Benutzers Einladungen aussprechen können soll, müssen dem Vertreter auch Schreibrechte für den Kalenderordner des Benutzers erteilt werden. In KDE Kontact

z. B. kann der Benutzer dies unter Kontexmenü Kalender → Einstellungen →Zugriffskontrolle einstel-

len. Falls der Kalenderordner ausgeblendet ist, vorher unter Einstellungen → Kontact einrichten... → E-Mail → Diverses →Arbeitsgruppen → Arbeitsgruppenordner ausblenden das Häkchen deaktivieren.

Alternativ kann der Rechneradministrator mit dem cyradm-Kommando setaclmailbox die nötigen Rechte setzen2.Im Kolab-Klient des Vertreters muss entsprechend eine neue Identität eingerichtet werden. Die bisheri-gen SMTP-Einstellungen des Vertreters müssen für diese neue Identität nicht verändert werden.

1 http://www.holtmann.org/email/sieve/ [Abruf: 07.12.2007]2 http://www.oreilly.com/catalog/mimap/chapter/ch09.html#98759 [Abruf: 07.12.2007]

41

http://www.oreilly.com/catalog/mimap/chapter/ch09.html#98759

http://www.holtmann.org/email/sieve/


5.5.7 Verteilerlisten

Eine Verteilerliste wird zum Verteilen von E-Mails an alle eingetragene Mitglieder dieser Liste verwen-det und kann zum Setzen von Rechten verwendet werden. Jede Verteilerliste besitzt eine E-Mail-Adresse von der eintreffende E-Mails an alle Mitglieder der Liste weitergeleitet werden. Im Unterschied zu Grup-penkonten (siehe Abschnitt 5.3) können in Verteilerlisten auch externe Adressen aus dem Kolab-Adress-buch aufgenommen werden.

Verteilerlisten können nur von Administratoren, Verwalter oder Domänenverwalter erstellt und verwaltet werden. Nach dem Anlegen einer Verteilerliste ist diese sofort nutzbar. Abbildung 5.6 zeigt das Eingabe-formular im Kolab Web-Admin zum Anlegen einer neuen Verteilerliste. Bei Aktivierung der Option Ver-borgen steht eine Verteilerliste nur für authentifizierte Nutzer zur Verfügung; d. h. nur authentifizierte Nutzer sind berechtigt, an diese Liste E-Mails zu senden. Die Verteilerliste wird im Status Verborgen bei einer LDAP Suche mit einer nicht-authentifizierten Verbindung im Kolab-Klient nicht angezeigt.

Anmerkung: Ein authentifizierter Anwender ist ein Anwender, der sich mit seinem Benutzernamen und Passwort am Kolab-Server anmelden kann. Wenn ein nicht authentifizierten Nutzer (Nicht-Kolab-Nut-zer) in eine Verteilerliste aufgenommen werden soll, muss dieser zuvor im externen Adressbuch angelegt werden. Der Nutzer kann dadurch E-Mails, die an diese Liste gerichtet sind, empfangen. Falls die Ver-borgen-Option aktiviert ist, kann er aber keine E-Mails an diese Liste senden.

42

Abbildung 5.6: Anlegen einer neuen Verteilerliste im WebAdmin


5.5.8 VirenfilterKonfiguration

Der Kolab Server nutzt nach der Installation standardmäßig den Virenscanner amavisd-new3 in Verbin-dung mit Clam AntiVirus4. Im folgenden Abschnitt werden diese beiden Werkzeuge erläutert.

Amavisdnew

Amavisd-new bildet im Kolab Server die Schnittstelle zwischen Postfix auf der einen Seite sowie SpamAssassin und ClamAV auf der anderen. Amavisd-new ist der Nachfolger von AMaViS (= A Mail Virus Scanner).

Amavisdnew im Kolab Server 2.2

➔ Template: /kolab/etc/kolab/templates/amavisd.conf.template

➔ Konfigurationsdatei: /kolab/etc/amavisd/amavisd.conf

➔ Logdatei: /kolab/var/amavisd/amavisd.log

➔ Quarantäne-Verzeichnis: /kolab/var/amavisd/virusmails

➔ Start-Kommandos: /kolab/bin/openpkg rc amavisd {start|stop|status|restart}

Abbildung 5.5.2 auf Seite 38 veranschaulicht die Arbeitsweise von amavisd-new:Eine bei Postfix eintreffende E-Mail wird in Schritt 5 der Abbildung an amavisd-new (an Port 10024) übergeben. Amavisd-new filtert die Nachricht zunächst nach unerwünschten Absendern und nicht zuge-lassenen Anhängen und ruft zur Virenprüfung ClamAV [6] und anschließend (wenn die Nachricht viren-frei ist) SpamAssassin [7] auf. Wenn die E-Mail als harmlos befunden wurde, übergibt amavisd-new sie zurück zu Postfix an Port 10026 [8]. Andernfalls landet die Nachricht im Quarantäne-Verzeichnis (siehe Kasten oben).

Eine gebannte Nachricht aus dem Quarantäne-Verzeichnis kann z. B. (als Nuter kolab-r) durch/kolab/bin/cyrdeliver [email protected] < /kolab/var/amavisd/virusmails/banned-kXuJ2d3uGVCT

in das Postfach eines Kolab Nutzers manuell ausgeliefert werden.

Einstellungen zu den Viren-, Mail- und Spam-Filter (wie z. B. ClamAV und SpamAssassin) können über

das zentrale amavisd-Template /kolab/etc/kolab/templates/amavisd.conf.template defi-

niert werden. Um Änderungen im Template wirksam werden zu lassen, muss /kolab/sbin/kolab-

conf zum Generieren der Konfigurationsdatei ausgeführt (vgl. Abschnitt 2.4) und amavisd-new neu

gestartet (Kommando: siehe oben im Kasten) werden.

3 http://www.ijs.si/software/amavisd/ [Abruf: 07.12.2007]4 http://www.clamav.net/ [Abruf: 07.12.2007]

43

http://www.clamav.net/

http://www.ijs.si/software/amavisd/


ClamAV

ClamAV ist ein Freier-Software-Virenscanner und Phishing-Filter, der nach jeder Kolab Server Installa-tion standardmäßig als primärer Scanner aktiv ist. Clamscan ist der kommandozeilenbasierte Virenscan-

ner und kann z. B. auf das aktuelle Verzeichnis mit dem Befehl /kolab/bin/clamscan ausgeführt

werden. Clamscan wird automatisch dann zum Überprüfen von Viren in E-Mails eingesetzt, wenn alle anderen Virenscanner ausgefallen sind.

Es ist problemlos möglich andere, auch proprietäre, Virenscanner zu installieren und diese an Stelle von oder zusätzlich mit ClamAV auf dem Kolab Server zu nutzen. Dafür muss die ClamAV-Einstellung im amavisd-new Konfigurationstemplate editiert werden (vgl. externe Anleitung5).

ClamAV im Kolab Server 2.2

➔ Template: /kolab/etc/kolab/templates/clamd.conf.template

und /kolab/etc/kolab/templates/freshclam.conf.template

➔ Konfigurationsdatei: /kolab/etc/clamav/clamd.conf

und /kolab/etc/clamav/freshclam.conf

➔ Logdatei: /kolab/var/clamav/clamd.log

➔ Start-Kommandos: /kolab/bin/openpkg rc clamav {start|stop|status|restart}

➔ Update-Kommando (als kolab-r): /kolab/bin/freshclam

Die Virusinformations-Datenbank wird automatisch in regelmäßigen Abständen durch einen voreinge-

stellten Cronjob auf /kolab/bin/freshclam aktualisiert. Das voreingestellte Updateintervall von

einer Stunde kann im Template /kolab/etc/kolab/templates/rc.conf.template (in der Zeile

clamav_update = "hourly") geändert werden. In der /etc/crontab werden die Parameter

hourly und weitere definiert.

ClamAV überprüft auch alle Dateien innerhalb von Archiven (z. B. *.tar.gz oder *.zip).

5 http://www.activmedia.ch/groupware5.php#viren [Abruf: 07.12.2007]

44

http://www.activmedia.ch/groupware5.php#viren


5.5.9 SpamfilterKonfiguration

Unerwünschte Nachrichten lassen sich auf mehrere verschiedene Arten ausfiltern. Dieser Abschnitt kon-zentriert sich auf die Spamfilter-Möglichkeiten von SpamAssassin und erläutert dessen Konfiguration.

SpamAssassin

SpamAssassin im Kolab Server 2.2

➔ Template: –➔ Konfigurationsdatei: /kolab/etc/spamassassin/local.cf

➔ Logdatei: /kolab/var/spamassassin/spamassassin.log

➔ Bayes-Datenbank: /kolab/var/amavisd/.spamassassin

➔ Start-Kommandos: /kolab/bin/openpkg rc spamassassin {start|stop|status|restart}

Die Kommandos gelten nur für spamd, welcher von amavisd-new nicht verwendet wird und des-halb in rc.conf.template standardmäßig abgeschaltet ist. Wird SpamAssassin über amavisd-new genutzt, gelten nur die amavisd-new-Kommandos.

Nach der Installation von Kolab Server ist der Mailscanner amavisd-new so konfiguriert, dass der mit Kolab ausgelieferte Spamfilter SpamAssassin aktiv ist.Die Konfiguration erfolgt in der Datei /kolab/etc/spamassassin/local.cf. Einige Funktionen

von SpamAssassin sollten hier nicht mehr benutzt werden, da sie in amavisd-new integriert sind, wie z.B. Whitelist/Blacklist, Spam-Grenzwert und Header-/Body-Änderungen. Eingestellt werden hier also nur noch der statistische Bayes-Filter, eigene Regeln und Wertigkeiten für bestehende Regeln. Da SpamAssassin in amavisd-new integriert ist, muss nach Änderungen

/kolab/etc/rc amavisd restart

ausgeführt werden.

SpamAssassin arbeitet mit verschiedenen Tests, die je nach Ergebnis sogenannte X-Spam-Scores verge-ben. Diese Scores können positive oder negative Werte sein, je höher eine Nachricht am Ende bewertet ist, desto wahrscheinlicher ist sie Spam. Ab dem voreingestellten Schwellwert für X-Spam-Score von

$sa_tag_level_deflt = 3.0 (vgl. amavisd-Template) wird die Nachricht als Spam markiert.

Zusätzlich zu dieser Markierung wird eine unerwünschte Nachricht in das Quarantäne-Verzeichnis

kopiert (aufgrund der Voreinstellung im amavisd-Template: $final_spam_destiny = D_PASS;).

Sollen Spam-Mails ausschließlich in der Quarantäne (und nicht beim Empfänger) ankommen, dann ist

der Wert von D_PASS auf D_DISCARD umzustellen.

Im Gegensatz dazu werden Spam-Nachrichten nie in das Quarantäne-Verzeichnis kopiert, wenn der o. g.

X-Spam-Score auf $sa_tag_level_deflt = 999.0; gesetzt wird. In diesem Fall sollte

$final_spam_destiny = D_PASS; gesetzt sein, damit die Nachrichten an die Empfänger ausgelie-

fert werden.Jede als Spam bewertete E-Mail, wird ein X-Spam-Level-Feld im Header hinzugefügt.

45


SpamAssassin in der Grundkonfiguration ist noch nicht sehr mächtig. Um eine höhere Trefferquote zu erreichen, muss dieser lernen was Spam ist und was nicht. Dazu muss der verwendete Bayes-Filter trai-niert werden. Nachfolgend werden drei Methoden beschrieben, wie SpamAssassin zum Spam melden (und lernen) genutzt werden kann:

1. Eine Möglichkeit besteht darin einen neuen Benutzer anzulegen; z. B. [email protected]. 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 [email protected] 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 [email protected] 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


Nachdem SpamAssassin die ausgefilterten Spam-Mails gelernt hat, können diese E-Mails theoretisch direkt im Anschluss des Lern-Durchlaufs gelöscht werden. Ein manuelles Löschen der Mails hat aber den Vorteil, versehentlich als unerwünscht deklarierte Nachrichten ins Benutzerpostfach „zurückzuho-

len“. Mit dem Befehl ipurge lassen sich alle E-Mails löschen, die älter sind als x Tage. Hierbei muss

beachtet werden, dass der Befehl nur auf den Spam-Ordner ausgeführt wird. Eine Hilfe zu den mögli-

chen Parametern ist auf der Manual-Seite von ipurge zu finden (man ipurge als Nutzer kolab).

Weiterführende Informationen und Einstellmöglichkeiten zu SpamAssassin gibt es auf folgenden Inter-netseiten [Abruf: 07.12.2007]:

➔ die SpamAssassin Website: http://spamassassin.apache.org➔ die sa-learn Dokumentation: http://spamassassin.apache.org/full/3.2.x/dist/doc/sa-learn.html➔ ein Erfahrungsbericht über Kolab und Spam: http://grover.open2space.com/node/15

5.5.10 EMailDomänen

Der Kolab Server kann mehrere E-Mail-Domänen verwalten (er ist Multi-Domain-fähig). Über den Kolab Web-Admin in der Rubrik Dienste lassen sich Mail-Domänen hinzufügen oder entfernen (vgl. Abbildung 5.7).

5.5.11 Administrative EMailAdressen

Für jede E-Mail-Domäne muss ein Konto definiert werden, dass alle Nachrichten an administrative E-Mail-Adressen empfängt. Als administrative Adressen gelten:

➔ [email protected] ➔ [email protected] ➔ [email protected] ➔ [email protected] und ➔ [email protected].

Im Kolab Web-Admin kann unter Dienste eine E-Mail-Adresse zum Empfang solcher Nachrichten ein-gegeben werden. Anschließend werden für jede dieser administrativen Adresssen Verteilerlisten erzeugt, die später noch bearbeitet werden können.

47

Abbildung 5.7: Hinzufügen einer weiteren EMailDomäne im WebAdmin

http://grover.open2space.com/node/15

http://spamassassin.apache.org/full/3.0.x/dist/doc/sa-learn.html

http://spamassassin.apache.org/


5.5.12 Sicherheitseinstellungen

Privilegierte NetzwerkeAls privilegierte Netzwerke bezeichnet man solche Netzwerke, die Nachrichten über nicht-authentifi-zierte SMTP-Verbindungen an den Kolab Server verschicken dürfen. Voreingestellt werden automatisch alle eigenen Kolab-Server eingetragen. Wenn vorhanden, sollte in der Regel der zuständige SMTP Ein-gangsgateway als privilegiertes Netzwerk eingerichtet werden. Im Kolab Web-Admin unter Dienste wer-den diese Netzwerke im Format x.x.x.x/y eingetragen – mehrere Netze werden durch Kommata getrennt. Voreingestellt ist 127.0.0.0/8.

Nachrichten aus dem InternetDamit der Kolab Server Nachrichten aus anderen Internet-Domänen direkt (über nicht-authentifiziertes SMTP) empfangen kann, muss die Option Nachrichten aus dem Internet akzeptieren im Web-Admin unter Dienste aktiviert werden. Wenn diese Option ausgeschaltet ist, werden E-Mails nur von SMTP-Servern aus den privilegierten Netzwerken (oder mit Authentifizierung) angenommen.

SMTPSmarthost/RelayhostAls SMTP-Smarthost oder -Relayhost wird ein Mailserver bezeichnet, der E-Mails von einem Sender empfängt und an einen bestimmten Host weiterleitet. Bei Kolab spielt so ein Smarthost eine Rolle, wenn z. B. ein SMTP-Ausgangsserver genutzt werden muss (weil beispielsweise das Versenden von E-Mails über Port 25 durch den Provider nicht erlaubt wird). Zum Konfigurieren eines Smarthosts – im Kolab Web-Admin unter Dienste – wird der Hostname oder die IP-Adresse (mit optionaler Portangabe) benö-tigt.

NachrichtenfilterAbbildung 5.8 zeigt die voreingestellten Konfigurationsoptionen für den Nachrichtenfilter des Kolab Servers im Web-Admin (Rubrik Dienste).

Das Diagramm in Abbildung 5.9 veranschaulicht den Ablauf, wie eine E-Mail im Kolab Server gefiltert werden sollte. Abhängig von der Verbindungsart und der (unter Abb. 5.8 aktivierten) Filter- und Über-

48

Abbildung 5.8: Die Voreinstellungen des Nachrichtenfilters im Kolab WebAdmin.Sofern mindestens eine der beiden oberen PrüfOptionen aktiviert ist und

für eine Nachricht fehlschlägt, wird die darunter ausgewählte Maßnahme durchgeführt.


prüfoptionen wird eine E-Mail entweder angenommen (+), zurückgewiesen (-) oder als nicht vertrauens-würdig markiert (?).

Das Diagramm bildet das Konzept des Nachrichtenfilters vom Kolab Server ab, wie es für die Zukunft von Kolab geplant ist (SOLL-Zustand). Der IST-Zustand in Kolab Server 2.2 beta2 ist noch so: Der Kolab Server prüft an der im Diagramm mit * markierten Stelle nicht, ob die Sender-Header mit dem SMTP-Sender übereinstimmt, sondern ob die Sender-Header eine lokale Adresse ist.

49


50

Abbildung 5.9: Das Filtern von EMails im Kolab Server


5.6 Adressbuch

Das Kolab Adressbuch ist ein öffentliches Adressbuch und wird vom Verzeichnisdienst des Kolab-Server bereitgestellt. Das Adressbuch ist unabhängig von den Kolab-Benutzerkonten und den lokalen Adress-büchern der Kolab-Klienten. Adressbucheinträge werden auch als externe Adressen bezeichnet, da es sich hierbei um Nicht-Kolab-Nutzer handelt. Diese externen Adressen werden im Verzeichnis auf dem Kolab-Server gespeichert.

Verwalten von externen Adressen

Die Verwaltung des Kolab-Adressbuchs kann von Administratoren oder Verwaltern im Kolab Web-Admin übernommen werden (Abbildung 5.10 zeigt ein Formular zum Neuanlegen eines Adressbuchein-trags). Externe Adressen können über die LDAP-Suchfunktion im Kolab-Klient gesucht werden.

51

Abbildung 5.10: Das Hinzufügen einer externen Adresse ins Adressbuch (im Kolab WebAdmin)


5.7 Kalender

5.7.1 Einladungen

Der Kolab Server besitzt einen serverseitigen Mechanismus für das automatische Behandeln von Einla-dungen. Diese Funktion wird typischerweise zum Buchen von Ressourcen (z. B. ein Besprechungsraum, Auto, Beamer etc.) verwendet und wird durch bestimmte Regeln gesteuert.Diese Regeln, die so genannten Einladungsrichtlinien, definieren für jedes Konto, wie mit eintreffenden Einladungen umgegangen werden soll. Dabei gibt es fünf Möglichkeiten:

1. Immer annehmenEinladungen werden stets automatisch angenommen und in den Kalender bzw. in die Frei/Belegt-Liste des Eingeladenen eingetragen.

2. Immer ablehnenEinladungen werden stets automatisch abgelehnt.

3. Ablehnen im KonfliktfallEinladungen werden bei Terminkollisionen abgelehnt, andernfalls automatisch angenommen.

4. Im Konfliktfall manuell bearbeitenEinladungen werden bei Terminkollisionen als E-Mail zur manuellen Bearbeitung im Postfach des Eingeladenen abgelegt, andernfalls werden Einladungen automatisch angenommen.

5. Manuell (voreingestellt)Einladungen werden stets als E-Mail zur manuellen Bearbeitung im Postfach des Eingeladenen abgelegt.

Ausnahmeregelungen für bestimmte E-Mail-Adressen sind möglich. Es kann jede gültige E-Mail-Adres-sen für Einladungsrichtlinien verwendet werden. Also alle E-Mail-Adressen, die im Verzeichnisdienst gespeichert sind (also alle primären und Alias-E-Mail-Adressen der Kolab-Konten, alle Adressen der Verteilerlisten sowie alle externen Adressen aus dem Adressbuch) und darüber hinaus auch jede belie-bige externe E-Mail-Adresse, die nicht im Kolab-Adressbuch eingetragen ist.Um die Einladungsrichtlinien im Kolab Web-Admin zu definieren muss jede E-Mail-Adresse in ein separates Eingabefeld eingetragen werden (vgl. Abbildung 5.11).

Beim Eintreffen einer neuen E-Mail auf einem Kolab-Konto wird zunächst geprüft, ob die SMTP-Sen-der-Adresse exakt mit einer eingetragenen Adresse aus der Liste der Einladungsregeln übereinstimmt. Falls dem so ist, wird an dieser Stelle nicht weiter gesucht und die Regel ausgeführt. Andernfalls wird geprüft, ob eine Verteilerliste in die Einladungsrichtlinie eingetragen wurde und die Sender-Adresse Mit-glied dieser Verteilerliste ist. Gibt es eine Übereinstimmung, wird die Regel ausgeführt. Bei mehreren Übereinstimmung wird die Adresse verwendet, die in der Eingabereihenfolge zuerst (im Web-Admin an früherer Stelle stehend) eingetragen wurde. Der PHP-Quellcode zu dieser Überprüfung der Einladungs-

52

Abbildung 5.11: Das Setzen der Einladungsrichtlinien im WebAdmin für alle Benutzer mit Ausnahmebehandlung für user1


regelungen ist in der Datei /kolab/lib/php/Kolab/Filter/resmgr.php (Funktion getLDAP-

Data) zu finden.

Anmerkung: Damit Benutzerkonten Einladungen automatisch bearbeiten können, muss der Benutzer calendar Zugriff auf den Kalender-Ordner haben – dies ist nur für die Einladungsrichtlinie (1), (3) und (4) nötig.

Empfehlungen

➔ Für Ressourcenkonten wird empfohlen, die Einstellung Ablehnen im Konfliktfall (3) oder Im Konfliktfall manuell bearbeiten (4) zu wählen. Ressourcen können sich gut „selbst verwalten“; nur bei Terminkollision muss eine Einladung abgelehnt werden.

➔ Für Gruppenkonten wird empfohlen, die Einstellung Immer ablehnen (2) oder Manuell (5)zu wählen. Da hinter den Gruppen jeweils individuelle Benutzer (mit ihren individuellen Kalen-dern) stehen, ist hier eine manuelle Bearbeitung von Einladungen sinnvoll.

Für jedes Konto sollte stets ein Inhaber definiert sein (vgl. Anmerkung im Abschnitt 5.3).

5.7.2 Frei/BelegtListen

Frei/Belegt-Listen werden zur Organisation von Terminen mit mehreren Teilnehmern verwendet. Die Frei/Belegt-Liste eines Benutzers enthält den Startpunkt und die Dauer aller Termine eines bestimmten Zeitraums. Für die Abstimmung eines Termins mit mehreren Teilnehmern können im Kolab-Klienten die Frei/Belegt-Listen der anderen Teilnehmer eingesehen werden, um so einen freien Termin für alle Teil-nehmer zu finden. Unter https://kolab.example.com/fbview wird vom Kolab Server ein Web-Frontend zur Verfügung gestellt, das die Frei/Belegt-Listen von frei wählbaren Kolab-Nutzern als Gantt-Dia-gramm visualisiert (vgl. Abbildung 5.12). Benutzer können sich mit ihrem Kolab-Konto auf dem Free/Busy-Viewer einloggen. Der Web-Viewer basiert auf Komponenten von Horde (vgl. Abschnitt 6.3). Teilnehmerlisten für den Free/Busy-Viewer können gespeichert werden. Dies geschieht über Browser-Cookies. Alternativ zum Free/Busy-Viewer kann beispielsweise auch KDE Kontact zur Anzeige der Frei/Belegt-Listen genutzt werden.

Frei/Belegt-Listen werden über einen Webserver verwaltet und per HTTPS übertragen. In der Server-Voreinstellung ist eine verschlüsselte Authentisierung des Benutzers durch den Kolab-Klienten erforder-lich. Ist ein Zugriff auf die Frei/Belegt-Informationen ohne Authentisierung gewünscht, kann im Web-Admin (unter der Rubrik Dienste) die Einstellung Unauthentifiziertes Herunterladen von Frei/Belegt-Informationen erlauben aktiviert werden. Dann sollte aber das Netz den Zugriff einschränken.

Der Web-Admin bietet eine zusätzliche Einstellmöglichkeit, um die Anzahl der vergangenen Tage zu definieren, die beim Erzeugen der Frei/Belegt-Listen berücksichtigt werden sollen.

53


5.8 Notizen

Ein Nutzer kann sich private Notizen anlegen und diese auf dem Kolab-Server speichern. Notizen kön-nen per E-Mail verschickt oder mit anderen Kolab-Nutzern über IMAP ausgetauscht werden.

Notizen werden für jeden Kolab-Nutzer innerhalb eines eigenen IMAP-Benutzerordners auf dem Kolab-Server als multi-part-MIME-E-Mail gespeichert. Das exakte Dateiformat ist im Kolab2 Storage Format Specification zu finden (Link im Anhang A)

5.9 Aufgaben

Ein Nutzer kann sich private Aufgaben anlegen und diese auf dem Kolab-Server speichern. Aufgaben können per E-Mail verschickt und mit andern Kolab-Nutzern über IMAP ausgetauscht werden.

Aufgaben werden für jeden Kolab-Nutzer innerhalb eines eigenen IMAP-Benutzerordners auf dem Kolab-Server als multi-part MIME E-Mail gespeichert und folgt dem iCalendar-Standard (RFC 2446). Das exakte Dateiformat ist im Kolab2 Storage Format Specification zu finden (Link im Anhang A).

54

Abbildung 5.12: Der Frei/BelegtViewer von Kolab Server 2.2 beta2


5.10 Gemeinsames Nutzen von IMAPOrdnern

IMAP-Ordner können gleichzeitig von mehreren Benutzern genutzt werden. Dies lässt sich über zwei unterschiedliche Varianten realisieren:

1. Entweder über freigegebene IMAP-Benutzerordner, auf die andere Anwender Zugriffsberechti-gungen erhalten,

2. oder über gemeinsam genutzte IMAP-Ordner ohne Konto (kurz: kontolose Ordner), die zentral von Administratoren/Verwaltern/Domänenverwaltern auf dem Server eingerichtet werden.

Der folgende Abschnitt beschreibt die Nutzung dieser beiden Varianten.

Jeder Ordner kann vom Typ E-Mail, Aufgaben, Journal, Kalender, Kontakte oder Notizen sein. Unspe-zifizierte Ordner werden als E-Mail-Ordner angesehen.

Zugriffsrechte können allen Benutzern, bestimmten Gruppen oder individuellen Benutzern vergeben werden. Es ist möglich verschiedenen UIDs unterschiedliche Berechtigungen zuzuweisen. Der Zugang zu den freigegebenen bzw. kontolosen Ordnern wird über die Cyrus-ACL-Einstellungen geregelt.

5.10.1 Freigegebene Benutzerordner

Ein Nutzer kann in seinem Kolab-Klienten neue Unterordner innerhalb seines Kontos erzeugen. Alterna-

tiv kann der Systemadministrator mit dem Cyrus-Administrationswerkzeug /kolab/bin/cyradm und

dem Befehl createmailbox (cm) einen neuer Ordner für den Nutzer erstellen. Auf dem Kolab-Home-

server werden diese Ordner unterhalb des jeweiligen Kontopfades angelegt. Die Zugriffsrechte können entweder direkt vom Nutzer im Kolab-Klienten oder vom Systemadministra-

tor mit dem Befehl setaclmailbox (sam) im Cyrus-Administrationswerkzeug /kolab/bin/cyradm

festgelegt werden. Auf einen Ordner können folgende vordefinierte Zugriffsrechte (ACLs) angewandt werden:

➔ none

➔ read (lrs)

➔ post (lrsp)

➔ append (lrsip)

➔ write (lrswipkxte)

➔ delete (lrxte)

➔ all (lrswipkxte)

Darüber hinaus lässt sich jede Kombination der folgenden ACL-Codes anwenden:➔ l (Lookup)

➔ r (Read)

➔ s (Seen)

➔ w (Write)

➔ i (Insert)

➔ p (Post)

➔ k (Create mailbox)

➔ x (Delete mailbox)

➔ t (Delete messages)

➔ e (Perform)

➔ a (Administer)

Weitergehende Informationen zu den genauen Bedeutungen der Zugriffsrechte sind auf der Manual-Seite

von cyradm (unter dem Befehl sam) zu finden: /kolab/bin/openpkg man cyradm.

55


5.10.2 Gemeinsam genutzte IMAPOrdner ohne Konto

Achtung: Die Nutzung von kontolosen Ordnern wird nicht empfohlen! Grund: Viele Funktionen, die bei normalen Konten leicht funktionieren, sind bei kontolosen Ordnern nicht, nur schwierig oder nur über Umwege erreichbar (wie z. B. Unterordner, E-Mail-Zustellung, E-Mail-Alias-Einträge, Sieve-Skripte, Administrierbarkeit über IMAP-Klient).

Kontolose Ordner und deren Zugriffsrechte können nur von Administratoren, Verwaltern und Domänen-verwaltern direkt am Kolab Server angelegt und verwaltet werden (z. B. über den Web-Admin). Konto-lose Ordner befinden sich im Mail-Spool-Verzeichnis auf gleicher Ebene wie die Benutzerkonten. Der Speicherplatz für den Ordner ist unbegrenzt, sofern keine Plattenplatzbeschränkung angegeben wird.

56

Abbildung 5.13: Anlegen eines gemeinsam genutzten IMAPOrdners ohne Konto im WebAdmin


5.11 Quotas

Mit dem Kolab Server können Plattenplatzbeschränkungen der Benutzerkonten verwaltet werden. Es kann ein Hardquota und ein Prozentsatz, ab dem Quotawarnungen auftreten, definiert werden (siehe unten). Die Quota-Einstellungen werden vom Kolab Web-Admin (oder einem anderen Verzeichnis-dienst-Werkzeug) gesetzt und in den Verzeichnisdienst geschrieben. Kolabd leitet diese Änderungen an den Cyrus weiter (vgl. Abschnitt 2.4).

Ein Systemadministrator kann das Quotaverhalten seiner Nutzer beobachten, um ggf. immer wiederkeh-rende Quota-Warnungen eines Benutzers frühzeitig zu erkennen und das Überschreiten der Hardquota-Grenze zu verhindern. Mit dem Cyrus Quota Manager cyrquota kann eine Auflistung von allen Postfä-chern mit ihrer aktuellen Größe und ihren gültigen Quotas aufgerufen werden (als root oder kolab-r):

/kolab/bin/cyrquota

Wichtig: Es sollte beachtet werden, die Quota-Einstellungen nicht manuell im Cyrus zu setzen, da diese Änderungen von kolabd mit den bisherigen Einträgen aus dem LDAP-Baum beim nächsten Synchroni-sieren überschrieben werden können.

Hardquota

Administratoren, Verwalter und Domänenverwalter sind berechtigt den maximalen Speicherplatz (Hard-quota) von jedem Benutzer zu definieren. Wird kein Wert angegeben, hat der Benutzer unbegrenzt Spei-cherplatz zur Verfügung. Die Hardquota wird im Kolab Web-Admin in der Benutzerverwaltung konfigu-riert. Überschreitet ein Benutzer seine Hardquota, werden alle an diesen Benutzer adressierten E-Mails abgewiesen. Es ist dann auch nicht mehr möglich neue Daten in den betroffenen IMAP-Benutzerordnern zu speichern.

Quotawarnung

Überschreitet ein Benutzer einen definierten Prozentsatz an belegten Plattenplatz, erhält er so lange eine Quotawarnung (per E-Mail und beim IMAP-Synchronisieren im Kolab-Klienten) bis sein Speicherplatz wieder unter dem Grenzwert liegt. Der Prozentsatz wird im Web-Admin-Interface unter der Rubrik Dienste eingestellt. Die Voreinstellung ist 80%. Der definierte Prozentsatz gilt dann für alle Kolab-Benutzer. Das voreingestellte Quotaintervall (der Abstand, indem die Warnungen ausgegeben werden)

liegt bei 24 Stunden und kann in der Datei /kolab/etc/kolab/kolabquotawarn (Zeile: my

$warninterval = 60*60*24;) geändert werden.

57


5.12 Master und Slaveserver / Homeserver

Kolab kann mit mehreren, zusammenarbeitenden Kolab-Servern betrieben werden. Dies kann aus Grün-den der Leistung oder verschiedener Standorte sinnvoll sein (vgl. Abschnitt 3.4). Die Kolab-Server wer-den als Master und Slave bezeichnet.

Der Master-Server hält das Original des Verzeichnisdienstes. Der OpenLDAP-Replikationsmechanis-mus sorgt dafür, dass auf allen Slave-Servern der gleiche Stand des Verzeichnisdienstes vorgehalten wird. Ändern sich Daten im Verzeichnisdienst des Master-Servers, wird der Replikationsprozess ange-stoßen und die Daten werden mit allen Slave-Servern synchronisiert. Wichtig: Bei diesem Replikationsmechanismus werden nur die Verzeichnisdienstdaten (also z. B. Anga-ben zu allen angelegten Kolab-Konten) synchronisiert. Die eigentlichen IMAP-Benutzerordner (mit E-Mails, Kontakten, Terminen etc.) werden lediglich auf einem (Master- oder Slave-)Server vorgehalten – dem sogenannten Kolab-Homeserver (Näheres siehe unten).Nur der Master-Server kann auf den OpenLDAP-Verzeichnisdienst schreiben. Aus diesem Grund muss beim Einrichten eines neuen Slave-Servers die URI des Master-Servers angegeben werden (vgl. folgen-der Abschnitt Einrichten eines neuen Slave-Servers).

Für jedes Kolab-Konto muss ein Homeserver zugeordnet werden, auf dem die jeweiligen Nutzerdaten gespeichert werden (vgl. Abschnitt 5.2.4). Jeder Homeserver (egal ob Master oder Slave) kann E-Mails direkt annehmen, sofern dieser Server im MX-Record eingetragen ist. Zum Synchronisieren eines IMAP-Benutzerordners muss der Anwender in seinem Kolab Klienten die Adresse seines Homeservers einrichten.

Mit dem Web-Admin-Interface (in der Rubrik Dienste) können die verwendeten Kolab-Hosts verwaltet werden, indem Rechnernamen von weiteren Kolab-Slave-Servern gesetzt oder wieder entfernt werden.Vorsicht: Der Web-Admin in Kolab Server 2.2 beta2 ermöglicht, alle Hosts, und damit auch den Master-Server(!), zu löschen. Dies sollte unbedingt vermieden werden, da sonst keine Verbindung mehr zum Verzeichnisdienst besteht!

Einrichten eines neuen SlaveServers

1. Hinzufügen des neuen Servers zu der Liste der Kolab-Hosts im Web-Admin.

Unter /kolab/etc/openldap/slapd.replicas kann man sich vergewissern, dass der

neue Host in die Liste der Kolab-Hosts aufgenommen wurde.

2. Starten der initiale Konfiguration (Bootstrap) für den neuen Server:/kolab/etc/kolab/kolab_bootstrap -b

58

Abbildung 5.14: Das Interface zum Verwalten von KolabHosts (im WebAdmin)


Dabei sind folgende Einstellungen zu berücksichtigen:- Der Hosttyp ist „Slave“.- Die URI des LDAP-Server ist vom Muster „ldaps://master.example.com“.- Der Base-DN ist die des Master-Servers.- Das Manager-Passwort ist das gleiche wie beim Master-Server.

Das Bootstrap-Skript führt anschließend (als root) per ssh einige Kommandos auf dem Master-Server aus und kopiert per scp Daten vom Master- zum Slave-Server. Dafür wird einige Male das root-Passwort vom Master-Server benötigt. Daneben benutzt das Skript bei der Generierung eines SSL-Zertifikats für den neuen Server die Zertifizierungsstelle (CA) des Master-Servers. Dafür wird das CA-Passwort benötigt.

Anmerkung: Während des Kopierens der LDAP-Daten vom Master-Server wird der Master-LDAP-Server für ein kurze Zeit heruntergefahren und anschließend wieder gestartet. Dies wird automatisch vom Bootstrap-Skript durchgeführt.

3. Abschließend kann der neue Slave-Server gestartet werden:/kolab/bin/openpkg rc all start

5.13 Datensicherung und wiederherstellung

Datensicherung

Dieser Abschnitt gibt die Antwort auf die Frage: „Welche Daten sollten für eine Sicherung des Kolab-Servers berücksichtigt werden?“

Die Datensicherung des Kolab-Servers kann im laufenden Betrieb durchgeführt werden, um die Verfüg-barkeit des Servers zu gewährleisten. Wenn nicht anders angegeben, erfolgen alle Schritte bei der Datensicherung als root.

A) EMails

Es sollte das komplette Verzeichnis /kolab/var/imapd/spool gesichert werden. Der Cyrus

IMAP speichert hier alle E-Mails als einzelne Dateien in verschiedenen Unterordnern. Details zur IMAP Spool Struktur gibt es unter Abschnitt 5.5.Zusätzlich sollte das Verzeichnis /kolab/var/imapd/domain gesichert werden. Darin befin-

den sich die .seen- und die .sub-Dateien (analog zum Spool-Verzeichnis nach Domain und Nut-zer sortiert). seen sichert, welche E-Mails gelesen/ungelesen sind und sub (subscribe) speichert, welche Ordner vom Nutzer abonniert wurden. Werden während der Sicherung E-Mails empfangen/bearbeitet/gelöscht o.ä., läuft die Sicherung ohne Probleme weiter. Diese aktuellen Änderungen werden beim nächsten Backup erfasst.

59


B) mailboxes.db

Es sollte die Datei /kolab/var/imapd/mailboxes.db gesichert werden. Sie enthält eine

Liste aller E-Mail-Postfächer und deren ACL-Einstellungen.Es wird dringend empfohlen den Inhalt der (Berkeley) Datenbank-Datei vor dem Sichern als Textdatei zu konvertieren, um im Falle der Wiederherstellung unabhängig vom benutzten Daten-

bankformat zu sein. Es sollte eine Konvertierung von mailboxes.db ins Textformat erfolgen:/kolab/bin/db_dump /kolab/var/imapd/mailboxes.db > mailboxlist.txt

Bei Problemen kann die Sicherung auch wie folgt vorgenommen werden (als kolab-r):su - kolab-r -c "/kolab/bin/ctl_mboxlist -d" > mailboxlist.txt

C) annotations.db

Es sollte die Datei /kolab/var/imapd/annotations.db gesichert werden. Sie enthält u.

a. für alle IMAP-Ordner die Information, um welchen Ordnertyp es sich handelt (E-Mail, Kalen-der etc.).Es wird empfohlen den Inhalt der (Berkeley) Datenbank-Datei als Textdatei zu sichern:

/kolab/bin/db_dump /kolab/var/imapd/annotations.db > annotations_db_backup.txt

D) OpenLDAPDatenbank

Die OpenLDAP-Datenbank sollte im LDIF-Format in einer Textdatei gesichert werden:/kolab/sbin/slapcat -l ldap_db_backup.ldif

E) KolabKonfigurationsverzeichnis

Es sollte das komplette Verzeichnis /kolab/etc gesichert werden. Es enthält alle Konfigurati-

onsdateien und Templates für die einzelnen Kolab-Komponenten (vgl. Abschnitt 2.4).

F) SpamAssassin

Die Bayes Datenbank von SpamAssassin sollte in einer Textdatei gesichert werden (sofern Sie SpamAssassin zur Spamerkennung trainiert haben):

/kolab/bin/sa-learn --backup > sa_db_backup.txt

Nähere Information zu SpamAssassin finden Sie unter Abschnitt 5.5.9.

60


Datenwiederherstellung

Dieser Abschnitt gibt die Antwort auf die Frage: „Wie lassen sich Daten aus der Sicherung wiederherstel-

len?“

A) EMails

Zum Wiederherstellen der E-Mails von allen Benutzern muss das gesicherte IMAP-Spool-Ver-

zeichnisses vollständig in das Verzeichnis /kolab/var/imapd/spool zurückgespielt werden.

Dies kann z. B. mit rsync erfolgen.

Zusätzlich sollte in dem Verzeichnis /kolab/var/imapd/domain alle seen- und subscribe-

Informationen wiederhergestellt werden. Ein Kopieren dieses Verzeichnisses aus dem Backup sollte hier ausreichen.

Alternativ können verloren gegangene E-Mails eines oder mehrerer Benutzer bei laufendem Cyrus-Server in vier Schritten aus dem Backup wiederhergestellt werden:

1. Neuen Unterordner per cyradm anlegen Es wird empfohlen dem Benutzer die wiederhergestellten E-Mails in einem neuen Unterord-ner zur Verfügung zu stellen. Dies ist am sichersten, da so Konflikte vermieden werden. Darüber hinaus erkennt der Anwender leichter, welche E-Mails aus der Sicherung stammen.Mit Hilfe des Cyrus Administrator Werkzeugs cyradm wird nun dem Benutzer meier der Ordner restored auf dem Kolab Server angelegt: /kolab/bin/cyradm --user manager localhost > create "user/meier/[email protected]"

2. E-Mails in Ordner einspielenZurück auf der Konsole sollen nun alle wiederherzustellenden E-Mails in den angelegten Ordner kopiert werden. Da alle Dateien und Verzeichnisse im IMAP Spool dem speziellen Benutzer kolab-r gehören müssen, ist zunächst ein Wechsel auf diesen Benutzer nötig:

su – kolab-r cd /kolab/var/imapd/spool/domain/e/example.com/m/user/meier/ restored cp /tmp/mails/aus/backup/ordnerXY/*. . chmod 600 *

3. Indizes des Ordners neu aufbauenAbschließend müssen die Indizes des neuen Ordners restored wiederhergestellt werden: cyrreconstruct -f user/meier/[email protected]

Wenn der Befehl erfolgreich war, gibt cyrreconstruct das Postfach aus, welches bearbeitet wurde. Unglücklicherweise gibt cyrreconstruct keine Fehlermeldung aus, wenn die Opera-tion erfolglos war, oder das angegebene Postfach nicht existiert.

61


4. Quota wiederherstellenWenn auf dem Kolab-Server Quotas für Benutzer definiert sind, sollte nach manuellen Änderungen am IMAP-Spool-Verzeichnis der Befehl

cyrquota -f

aufgerufen werden. Dieser aktualisiert die vom Cyrus IMAP gespeicherten Quotainforma-tionen.

5. Seen- / Subscribe-Informationen wiederherstellenUm die Informationen über ungelesene E-Mails und abonnierter Ordner wiederherzustellen,

müssen in die entsprechenden Unterordnern von /kolab/var/imapd/domain alle gesi-

cherten seen- und subscribe-Dateien hineinkopiert werden.

Fertig. Der Anwender kann nun auf den neu erstellten Ordner und die darin wiederhergestellte E-Mails zugreifen.

B) mailboxes.db

Zum Wiederherstellen der mailboxes.db sollten die unter Abschnitt 5.13 B) angelegte mailboxlist.txt genutzt werden. Zuvor muss noch auf den Benutzer kolab-r gewechselt werden:

su – kolab-r/kolab/bin/ctl_mboxlist -u < mailboxlist.txt

C) annotations.db

Für die Wiederherstellung der annotations.db wird die gesicherte Textdatei annotations_db_backup.txt benötigt:

/kolab/bin/db_dump /kolab/var/imapd/annotations.db > annotations_db_backup.txt

D) OpenLDAPDatenbank

Die Wiederherstellung der OpenLDAP-Datenbank nutzt die gesicherte .ldif-Datei.su – kolabmv /kolab/var/openldap/openldap-data/ backup/tmpmkdir /kolab/var/openldap/openldap-data/

/kolab/sbin/slapadd -l backup/ldap_db_backup.ldif

An dieser Stelle wird eine Warnung ausgegeben, dass die DB_CONFIG nicht gefunden wurde. Diese Warnung kann ignoriert werden, da anschließend die DB_CONFIG neu generiert wird (dieser Befehl muss als root ausgeführt werden!):

/kolab/sbin/kolabconf

Nach erfolgreicher Wiederherstellung kann das backup/tmp-Verzeichnis gelöscht werden.

62


E) KolabKonfigurationsverzeichnis

Das vollständig gesicherte Konfigurationsverzeichnis sollte unter /kolab/etc wiederherge-

stellt werden (z. B. mit rsync).

F) SpamAssassin

Zum Wiederherstellen der Bayes-Datenbank von SpamAssassin wird die angelegte Textdatei benötigt:

/kolab/bin/sa-learn --restore sa_db_backup.txt

Die Bayes-Datenbank kann auch auf einen neuen Server wiederhergestellt werden. Es kann aber unter Umständen effektiver sein, wenn SpamAssassin von Grund auf neu lernt; insbesondere wenn es sich um unterschiedliche Domains handelt.

5.14 Dienste

Im Kolab Web-Admin lassen sich unter der Rubrik Dienste verschiedene Dienste des Kolab Servers aktivieren oder deaktivieren.

Anmerkung: Bei Kolab1 wurden Frei/Belegt-Informationen durch den Klient per FTP/HTTP hochgela-den. Kolab2 generiert diese Informationen nun serverseitig. Daher fehlt die FTP-Server-Variante und WebDAV ist im HTTP-Server deaktiviert.

63

Abbildung 5.15: WebAdminMaske zum Ein und Ausschalten von Diensten

6 KolabKlienten

Ziel dieses Kapitels ist es, einen allgemeinen Überblick über die verschiedenen Kolab-Klienten zu geben und auf weiterführende Dokumentationen zu verweisen.

6.1 KDE Kontact

KDE Kontact ist ein Groupware-Klient für KDE, der viele Einzelprogramme (u. a. KMail, KAdress-book, KOrganizer, KNotes) aus der KDE-Umgebung zu einem Programm bündelt. Eine Anleitung zur Konfiguration von Kontact ist in der Kolab-Dokumentation Doc2 zu finden (Link im Anhang A).

6.2 Microsoft Outlook

Um Microsoft Outlook als Kolab Klient verwenden zu können, muss ein Outlook-Konnektor, auf dem Windows-Rechner installiert sein. Es gibt zwei (proprietäre) Konnektoren für Outlook, die mit dem Kolab Server zusammenarbeiten [Stand: Dezember 2007]: der Toltec Connector und der KONSEC Kon-nektor. Im folgenden Abschnitt werden beide Konnektoren kurz vorgestellt und Verweise zum aktuellen Handbuch gegeben.

6.2.1 Toltec Connector

Der Toltec Connector1 ist ein proprietäres Plugin für Microsoft Outlook. Die Firma Radley Network Technologies CC (Südafrika) brachte Toltec Connector 1 im Oktober 2003 auf dem Markt. Die zweite Generation des Toltec Connectors implementiert das Kolab2 XML-Format.

Die derzeit aktuelle Version ist Toltec Connector 2.2.0 (vom 27.10.2007). Eine 30-Tage-Testversion kann auf der Toltec-Website heruntergeladen werden.

1 http://www.toltec.co.za [Abruf: 07.12.2007]

64

http://www.toltec.co.za/

http://www.toltec.co.za/

6 Kolab-Klienten

Die offizielle (englischsprachige) Dokumentation des Toltec Connectors (User Manual 2.0) mit detail-lierten Konfigurationsschritten ist unter http://www.toltec.co.za/downloads.html verfügbar.Eine (englischsprachige) Anleitung für die Konfiguration von Outlook2003 in Verbindung mit dem Tol-tec Connector ist in der Kolab-Dokumentation Doc3 verfügbar (vgl. Anhang A).Weitere (aktuelle) Informationen sind im Kolab-Wiki2 zu finden.

6.2.2 Konsec Konnektor

Im Gegensatz zum Toltec Connector ist der KONSEC Konnektor3 als MAPI Storage Provider für Micro-soft Outlook konzipiert und verwendet nicht die Outlook-Plugin-Schnittstelle.

Der Konnektor wird von der KONSEC GmbH in Stuttgart entwickelt. KONSEC Konnektor 1.0 ist im Juni 2005 erschienen. Die Version 1.1.6.4 wurde am 9.11.2007 veröffentlicht. Eine 30-Tage-Testversion kann auf der Internetseite von KONSEC heruntergeladen werden.Der KONSEC Konnector unterstützt aktuell die Sprachen Englisch, Deutsch und Französisch.

Die offizielle Dokumentation des KONSEC Konnektors ist mit ausführlicher Installations- und Konfigu-rationsanleitung unter http://download.konsec.com/ in Deutsch und Englisch verfügbar (Version 1.1 mit letzter Aktualisierung vom 18.10.2007).Weitere (aktuelle) Informationen sind im Kolab-Wiki4 zu finden.

6.3 Horde Webklient

Horde (http://horde.org) ist ein Webklient für Kolab mit dem Kolab-Benutzer Groupwarefunktionalitäten (wie E-Mail, Kalender, Adressbuch, Aufgaben etc.) im Webbrowser nutzen können. Horde ist Bestand-teil von Kolab Server 2.2. Das Webinterface kann über http://kolab.example.com/horde aufgerufen wer-den.Achtung:

➔ Die Anbindung von Horde ist aktuell noch in der Entwicklung und ist derzeit erst als Beta-Ver-sion in Kolab Server 2.2 integriert. Der Horde Webklient ist daher nur begrenzt für den produk-tiven Betrieb empfohlen.

➔ Zu beachten ist außerdem, dass Webklienten viel Last auf dem Server erzeugen können. Bei einer große Anzahl an Kolab-Nutzern ist es daher ratsam, den Webklienten auf einem getrennten Server laufen zu lassen.

2 http://wiki.kolab.org/index.php/Toltec_Connector [Abruf: 07.12.2007]3 http://www.konsec.com [Abruf: 07.12.2007]4 http://wiki.kolab.org/index.php/KONSEC_Konnektor [Abruf: 07.12.2007]

65

http://horde.org/

http://wiki.kolab.org/index.php/KONSEC_Konnektor

http://download.konsec.com/

http://www.konsec.com/

http://wiki.kolab.org/index.php/Toltec_Connector

http://www.toltec.co.za/downloads.html

Anhang

66

A Weiterführende

Informationen

Die offizielle Website von Kolabhttp://www.kolab.org

KolabWikihttp://wiki.kolab.orgDas Kolab-Wiki ist offen für die ganze Kolab-Gemeinschaft. Jeder kann, nach einer Anmeldung, selbst-ständig Anleitungen, Hinweise, etc. zu Kolab eintragen. Es handelt sich dabei in der Regel um nützliche, aber nicht offiziell geprüfte Angaben. Daher erfolgt die Verwendung auf eigenes Risiko.

KolabMailinglisten➔ kolab-users (http://kolab.org/mailman/listinfo/kolab-users)

Mailingliste für Kolab-Anwender und allgemeine Diskussionen. Englischsprachig.➔ kolab-devel (http://kolab.org/mailman/listinfo/kolab-devel)

Mailingliste zum Thema Kolab-Entwicklung. Englischsprachig.➔ kolab-announce (http://kolab.org/mailman/listinfo/kolab-announce)

Moderierte Mailingliste für offizielle Ankündigungen (neue Kolab-Versionen, Sicherheitshin-weise etc.). Englischsprachig.

➔ kolab-format (http://kolab.org/mailman/listinfo/kolab-format)Mailingliste für Diskussionen über die Kolab-Format-Spezifikation. Englischsprachig.

➔ kolab-commits (http://kolab.org/mailman/listinfo/kolab-commits)Mailingliste ausschließlich für automatische Commit-Mitteilungen des Kolab-Versionskontroll-systems CVS. Jede Änderung im CVS wird unmittelbar an diese Mailingliste gesendet. Eng-lischsprachig.

67

http://kolab.org/mailman/listinfo/kolab-commits

http://kolab.org/mailman/listinfo/kolab-format

http://kolab.org/mailman/listinfo/kolab-announce

http://kolab.org/mailman/listinfo/kolab-devel

http://kolab.org/mailman/listinfo/kolab-users

http://wiki.kolab.org/

http://www.kolab.org/

A Weiterführende Informationen

KolabCVS

Der Kolab-Server-Quellcode wird derzeit über das Versionskontrollsystem CVS verwaltet.Informationen zum CVS-Zugriff: http://kolab.org/cvs-kolab.htmlWeb-CVS-Viewer: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/

KolabIssueTracker

Um Fehler oder Wünsche an die Kolab Gemeinschaft zu richten, kann der Kolab-Issue-Tracker unterhttps://issues.kolab.org verwendet werden. Zum Eintragen ist eine Registrierung erforderlich. Englisch-sprachig.

KolabDokumentationen

Neben dieser vorliegenden Betriebsdokumentation gibt es unter http://kolab.org/documentation.html fol-gende weitere Dokumentationen zu Kolab2:

➔ doc2 – Installation und Konfiguration des Kolab-Servers und KDE-Klienten (Englisch, v1.72, Juni 2007 und Deutsch, v1.64, Mai 2005)

➔ doc3 – Konfiguration von Outlook2003 mit dem Toltec Connector (Englisch, v1.37, Juli 2007)➔ Kolab2 Architecture Paper (Englisch, Version Draft cvs20060921) ➔ Kolab2 Storage Format Specification (Englisch, Version Release Candidate 2.0rc5)

KolabRawHowtos (im CVS)

Nützliche Kurzanleitungen zur Konfiguration von Kolab2, so genannte Raw-Howtos, stehen unter http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/raw-howtos/ im Kolab CVS zur Verfügung.

➔ adding-new-hosts.txt➔ compiling-and-configuring-kpilot.txt➔ email-split-setup.txt➔ fix-ldap-database-on-slave.txt➔ freebusy-troubleshooting.txt➔ kolab_2.0_to_2.1_upgrade_instructions.txt➔ migrate_kmail_client_account_to_use_kolab.txt➔ move-rename-user.txt➔ moving-mailboxes.txt➔ mutts_for_kolab.txt➔ speaking-imap-for-debugging.txt➔ windows-zertifikate-imporieren.txt

68

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/raw-howtos/

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/

http://kolab.org/documentation.html

https://issues.kolab.org/

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/

http://kolab.org/cvs-kolab.html


AdministratorHinweise (auf dem Kolab Server)

Im Verzeichnis /kolab/share/doc/ befinden sich verschiedene Hilfedateien zur Konfiguration des

Kolab Servers:➔ ./kolabd/README.amavisd (Virus- und Spamfilter-Einstellungen)

➔ ./kolabd/README.ldapdelete (Löschen von LDAP Objekten)

➔ ./kolabd/README.outlook (Weiterleitung von iCalendar-Einladungen in Microsoft Out-

look)➔ ./kolabd/README.sieve (Standard Sieve Skripte vom Kolab Server) ➔ ./kolabd/README.webgui

Hinweise zu den Benutzergruppen und deren Zugriffsberechtigungen im Web-Admin sowie Zugriffsberechtigungen der LDAP-Attribute

➔ ./kolab-filter/INSTALL

Hinweise für die Installation von kolab-filter (nur relevant für nicht-OpenPKG-Plattformen)➔ ./kolab-freebusy/INSTALL

Hinweise für die Installation von kolab-freebusy (nur relevant für nicht-OpenPKG-Plattformen)

A.1 Die KolabGemeinschaft

Kolab ist ein Freie-Software-Produkt, bei dem jeder mithelfen kann, die Funktionalität der Software zu erweitern. Eine aktive, weltweite Gemeinschaft hat sich um Kolab herum gebildet. Für den Kontakt mit der Kolab-Gemeinschaft eignet sich am Besten die Kolab-Mailinglisten (siehe oben).

69


A.2 Das KolabKonsortium

Das Kolab-Konsortium steuert die Weiterentwicklung und bietet professionelle Beratung und Support für die Freie Groupwarelösung Kolab. Das Kolab-Konsortium wird getragen durch folgende drei Part-nerunternehmen:

Intevation GmbHGeorgstraße 449074 OsnabrückDeutschlandwww.intevation.de Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Klarälvdalens Datakonsult ABRysktorpSE-683 92 HagforsSwedenwww.klaralvdalens-datakonsult.seGeschäftsführer: Matthias Kalle Dalheimer

erfrakon PartGNobelstraße 1570569 StuttgartDeutschlandwww.erfrakon.dePartner: Tassilo Erlewein, Achim Frank, Martin Konold

Das Produkt Kolab wurde ursprünglich im Jahre 2002 durch ein Joint Venture der drei o. g. Firmen ins Leben gerufen (vgl. Abschnitt 1.2).

Kontakt:Kolab-Konsortiumc/o Intevation GmbHGeorgstraße 449074 OsnabrückDeutschland http://www.kolab-konsortium.de/ [email protected]: ++49-541-33 50 8 50

70

mailto:[email protected]

http://www.kolab-konsortium.de/

http://www.erfrakon.de/

http://www.klaralvdalens-datakonsult.se/

http://www.intevation.de/

B Glossar

Account Gleichzusetzen mit einem Konto

annotations.db Speichert u. a. für jeden IMAP-Ordner den Typ (E-Mail, Kalender, Kontakte, Notizen, Aufgaben, Journal).

Authentifizierte Nutzer Anwender, der sich mit Benutzername (UID) und Passwort am Kolab- Server angemeldet hat.

Benutzerkonto Ein „normales“ Benutzerkonto (vgl. Abschnitt 5.3).

Benutzername Zur Anmeldung am Kolab Web-Admin kann sowohl die UID als auch die primäre E-Mail-Adresse eines Nutzers als Benutzername verwendet werden.

Bevollmächtigter Gleichzusetzen mit einem Vertreter

Bootstrapping Die initiale Konfiguration des Kolab-Servers.

cyradm Ein kommandozeilenbasiertes Cyrus-Administrationswerkzeug.

EMailAlias Ein Synonym-Adresse für die primäre E-Mail-Adresse eines Benut-zers. Eintreffende Nachrichten werden an die primäre Adresse weiter-geleitet.

Eindeutige Identität Siehe unter UID

Externe Adresse Ein Nicht-Kolab-Benutzer, der im Kolab-Adressbuch und damit im Verzeichnis eingetragen ist.

Frei/BelegtListe Eine Option im Kalender zum Anzeigen von Frei/Belegt-Zeiten der ausgewählten Kolab-Konten (engl.: free/busy).

Kontoloser Ordner Ein IMAP-Ordner ohne zugehöriges Konto, auf den ausgewählte Kolab Benutzer Zugriff haben.Alternative: freigegebene Benutzerordner

Gruppenkonto Analog zum Benutzerkonto repräsentieren Gruppenkonten eine Grup-pen; vgl. Abschnitt 5.3).

HomeServer / Heimatserver Der Kolab-Server auf dem ein Konto gespeichert ist.

IMAP Das Internet Message Access Protocol erlaubt den Zugriff auf und die Verwaltung von empfangenen E-Mails.

71

B Glossar

IMAPOrdner Jedes Konto besteht aus einem oder mehreren IMAP-Ordnern. Zu jedem Ordner wird in der annotations.db u. a. der Ordner-Typ gespei-chert (E-Mail, Kalender, etc.). Ein Ordner kann auch mehrere Unter-ordner besitzen.

Internes Benutzerkonto Wie Benutzerkonto; jedoch ist die primäre E-Mail-Adresse nur inner-halb des (privilegierten) Kolab-Netzes gültig.

Konnektor Eine Software für Klienten wie Microsoft Outlook oder Thunderbird, um eine Verbindung mit dem Kolab-Server aufzubauen und Kolab-Groupwarefunktionalitäten zu nutzen.

Konto Zu jedem Kolab-Nutzer wird im Verzeichnisdienst ein Konto angelegt.

Kontotyp Jedem Kolab-Konto muss eines der vier Kontotypen zugeordnet sein: Benutzer-, Internes Benutzer-, Gruppen- oder Ressourcenkonto.

LDAP Das Lightweight Directory Access Protocol erlaubt die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes.

MasterServer Zentraler Kolab-Server mit dem ggf. ein oder mehrere Slave-Server verbunden sind.

MTA Ein Transfer Agent (auch Mail/Message Transport Agent) dient zum Transportieren und Verteilen von E-Mails.

Freigegebener Benutzerordner Ein IMAP-Benutzerordner ist dann freigegeben, wenn (anhand gesetz-ter ACLs) für ausgewählte Nutzer der Zugriff auf diesen Ordner ermöglicht wird.

Ordner Siehe unter IMAP-Ordner

Postfach Jedes Konto kann mehrere IMAP-Ordner besitzen. In jedem IMAP-Ordner können E-Mails empfangen werden. Somit kann jeder IMAP-Ordner als Postfach bezeichnet werden.

Primäre EMailAdresse Standard E-Mail-Adresse eines Kontos; kann identisch mit der UID sein. Die primäre Adresse ist nach dem Anlegen eines Kontos nicht mehr änderbar. Zur Anmeldung am Kolab Web-Admin kann sowohl die UID als auch die primäre E-Mail-Adresse eines Nutzers als Benut-zername verwendet werden.

Quota Quota beschreibt eine durch den Administrator definierte, serverba-sierte Speicherplatzbegrenzung für Benutzer. Der Benutzer erhält regel-mäßig Quotawarnungen, sobald er einen definierten Prozentsatz seines Speicherplatzes überschreitet.

Relayhost Mailserver, der E-Mails empfängt und an einen bestimmten Host wei-terleitet; je nach Funktion wird ein Relayhost auch als Smarthost bezeichnet.

Ressourcenkonto Ressourcenkonten dienen zum Verwalten von Ressourcen (wie z.B. Beamer, Besprechungsraum); vgl. Abschnitt 5.3

Sieve Skriptsprache zum serverseitigen Filtern von E-Mails nach RFC 3028.

SlaveServer Ein weiterer Kolab-Server, der mit dem Master-Server und ggf. weite-ren Slave-Servern verbunden ist und mit ihnen zusammen arbeitet.

Smarthost vgl. Relayhost

UID Die Unique Identity (UID) ist der Benutzername mit dem sich der Kolab-Nutzer am Server anmelden kann. Alternativ kann auch seine primäre E-Mail-Adresse als Benutzernamen genutzt werden.

Verteilerliste Eine Mailingliste, die am Kolab-Server eingerichtet wird. Mitglieder

72

B Glossar

einer Verteilerliste können nur Nutzer sein, deren E-Mail-Adresse im Verzeichnisdienst gespeichert ist - entweder im Kolab Konto oder im Kolab Adressbuch (engl.: distribution list).

Vertreter (EMail) Ein E-Mail-Vertreter darf im Namen des beauftragten Benutzers E-Mails versenden und. Vertreter werden auch als Bevollmächtigte (engl.: delegates) bezeichnet.

WebAdmin Ein Administrations-Webinterface zur Konfiguration des Verzeichnis-dienstes vom Kolab-Servers. Kolab-Nutzer können darüber ihre eige-nen Daten ändern und eins der drei vordefinierten Sieve-Skripte akti-vieren.

73

C GNU Free Documentation

License

Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of free-dom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in dura-tion, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

74

C GNU Free Documentation License

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relation-ship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is availa-ble to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subse-quent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprie-tary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or pro-cessing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word pro-cessors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in par-entheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warran-ties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

75


3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reaso-nably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-rea-dable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transpa-rent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retai-lers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

• A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of pre-vious versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

• B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

• C. State on the Title page the name of the publisher of the Modified Version, as the publisher. • D. Preserve all the copyright notices of the Document. • E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. • F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified

Version under the terms of this License, in the form shown in the Addendum below. • G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's

license notice. • H. Include an unaltered copy of this License. • I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new

authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

• J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Docu-ment, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

• K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

• L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

• M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. • N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. • O. Preserve any Warranty Disclaimers.

76


If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authorita-tive definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add ano-ther; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original docu-ments, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the indi-vidual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compila-tion is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not them-selves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggre-gate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

77


8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disa-greement between the translation and the original version of this License or a notice or disclaimer, the original version will pre-vail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Pre-serve its Title (section 1) will typically require changing the actual title.

9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered ver-sion of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Docu-ment does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

ADDENDUMTo use this License in a document you have written, include a copy of the License in the document and put the following copy-right and license notices just after the title page:

Copyright (c) YEAR YOUR NAME.Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Docu-mentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invari-ant 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".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:

with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

78

allgemeine betriebsdokumentation-kolab server22-20080103_1.0

Automotive