Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Upcoming SlideShare
Loading in...5
×
 

Allgemeine betriebsdokumentation-kolab server22-20080103_1.0

on

  • 6,668 views

 

Statistics

Views

Total Views
6,668
Views on SlideShare
6,668
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Allgemeine betriebsdokumentation-kolab server22-20080103_1.0 Allgemeine betriebsdokumentation-kolab server22-20080103_1.0 Document Transcript

  • Allgemeine BetriebsdokumentationfürKolab Server 2.2Version: 1.0Osnabrück, am 3. Januar 2008
  • Änderungsverzeichnis Geänderte Änderung Beschreibung der Änderung Autor Kapitel Nr Datum Version 1 2008-01-03 1.0 Emanuel SchützeAktueller Status: Fertig gestelltImpressum© 2007 Intevation GmbHVersion: 1.0Autor: Emanuel SchützeFachliche Leitung: Bernhard Reiter, Thomas Arendsen HeinKontakt: emanuel.schuetze@intevation.de | http://intevation.org Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation  License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front­ Cover Texts, and no Back­Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation  License".Diese Kolab Server Betriebsdokumentation ist unter http://kolab.org erhältlich. 2
  • InhaltsverzeichnisKapitel 1:  Einführung 5 1.1 Was ist Kolab?.................................................................................6 1.2 Entwicklungshistorie von Kolab................................................................7 1.3 Was ist neu in Kolab Server 2.2?...............................................................8Kapitel 2:  Die Komponenten des Kolab Servers 9 2.1 Übersicht.......................................................................................9 2.2 Interaktion der Komponenten.................................................................11 2.3 OpenPKG.....................................................................................12 2.4 Kolabspezifische Komponenten...............................................................13Kapitel 3:  Kolab Server – Bedarfsplanung 17 3.1 Festplattenspeicher............................................................................17 3.2 Rechenleistung / Hauptspeicher...............................................................18 3.3 Verfügbarkeit.................................................................................18 3.4 Wer arbeitet mit wem?........................................................................19Kapitel 4:  Kolab Server – Vorbereitung und Installation 20 4.1 Installationsvorbereitung......................................................................20 4.2 Installation....................................................................................22 4.3 Aktualisierung................................................................................25 4.4 Deinstallation.................................................................................27Kapitel 5:  Kolab Server – Konfiguration und Betrieb 28 5.1 Kolab Web-Admin............................................................................28 5.2 Rollen.........................................................................................29 5.2.1 Administrator..........................................................................30 5.2.2 Verwalter..............................................................................30 5.2.3 Domänenverwalter.....................................................................30 5.2.4 Benutzer...............................................................................31 5.3 Kontotypen...................................................................................33 5.4 Nutzerlebenszyklus...........................................................................34 5.5 E-Mail........................................................................................36 5.5.1 Die IMAP Spool Struktur..............................................................36 5.5.2 Der Weg einer E-Mail..................................................................36 5.5.3 Weiterleitung...........................................................................39 5.5.4 Abwesenheitsbenachrichtigung........................................................39 5.5.5 Serverseitige Filterung mit Sieve.......................................................40 5.5.6 E-Mail-Vertreter.......................................................................41 5.5.7 Verteilerlisten..........................................................................42 3
  • 5.5.8 Virenfilter-Konfiguration..............................................................43 5.5.9 Spamfilter-Konfiguration..............................................................45 5.5.10 E-Mail-Domänen.....................................................................47 5.5.11 Administrative E-Mail-Adressen......................................................47 5.5.12 Sicherheitseinstellungen..............................................................48 5.6 Adressbuch...................................................................................51 5.7 Kalender......................................................................................52 5.7.1 Einladungen...........................................................................52 5.7.2 Frei/Belegt-Listen......................................................................53 5.8 Notizen.......................................................................................54 5.9 Aufgaben.....................................................................................54 5.10 Gemeinsames Nutzen von IMAP-Ordnern....................................................55 5.10.1 Freigegebene Benutzerordner.........................................................55 5.10.2 Gemeinsam genutzte IMAP-Ordner ohne Konto......................................56 5.11 Quotas........................................................................................57 5.12 Master- und Slaveserver / Homeserver........................................................58 5.13 Datensicherung und -wiederherstellung.......................................................59 5.14 Dienste........................................................................................63Kapitel 6:  Kolab­Klienten 64 6.1 KDE Kontact..................................................................................64 6.2 Microsoft Outlook............................................................................64 6.2.1 Toltec Connector.......................................................................64 6.2.2 Konsec Konnektor.....................................................................65 6.3 Horde Webklient..............................................................................65Anhang 66Anhang A:  Weiterführende Informationen 67 A.1 Die Kolab-Gemeinschaft......................................................................69 A.2 Das Kolab-Konsortium.......................................................................70Anhang B:  Glossar 71Anhang C:  GNU Free Documentation License 74 4
  • 1 Einführung Kolab ist eine Freie Lösung, die Groupware-Funktionalitäten bietet. Kolab spe- zifiziert ein Verhalten von Server und Klienten, welches als Freie Software in dem Kolab Server, dem Kolab KDE Klienten Kontact und dem Horde Webklien- ten implementiert ist. Das Konzept von Kolab, basierend auf offenen Standards, gestattet die Entwicklung von Kolab-Servern und -Klienten durch Drittanbieter. Als Groupware bezeichnet man eine Software, die für die Zusammenarbeit innerhalb einer Arbeitsgruppe konzipiert ist und die Arbeitsabläufe rationalisie- ren und automatisieren soll. In der Regel besteht Groupware aus Anwendungen, die typische Organizer-Funktionen (wie Kalender, Kontakte, Aufgaben, Notizen) sowie Funktionen für den Austausch von E-Mails und die gemeinsame Bearbei- tung von Dateien bereitstellen.Die vorliegende Betriebsdokumentation konzentriert sich auf den Kolab Server und unterstützt beimAufsetzen und Betreiben eines solchen Groupware-Servers.Diese Dokumentation richtet sich an Systemadministratoren, die Server-Anwendungen betreuen. Kennt-nisse über den Kolab Server werden nicht vorausgesetzt. Grundlegende Erfahrungen mit Server-Anwen-dungen sind jedoch erforderlich; wünschenswert auf GNU/Linux. Zu diesen Themen gibt es bereits zahl-reiche Literatur.Ziel dieser Arbeit ist es, einen Überblick über den Kolab Server zu geben und die Fähigkeiten für War-tung und Betrieb zu vermitteln. Es existieren sehr vielfältige Möglichkeiten und Einsatzszenarien denKolab Server zu nutzen, die anhand einiger konkreter Beispiele dargestellt werden. Auf die dabei getrof-fenen Annahmen wird jeweils hingewiesen. 5
  • 1 EinführungDiese Betriebsdokumentation bezieht sich auf die OpenPKG-Variante von Kolab Server 2.2 (vgl.Abschnitt 2.3). Da Version 2.2.0 zum Recherchezeitpunkt noch nicht erschienen ist, wurde Kolab Server2.2-beta2 genutzt.Gliederung ➔ Kapitel 1 und 2 geben einen allgemeinen Überblick über den Kolab Server und dessen Kompo- nenten. ➔ Im 3. Kapitel wird anhand von grundsätzlichen Leitfragen die Bedarfsplanung für den Einsatz eines Kolab-Servers erarbeitet. ➔ Hinweise zur Installation sowie praktische Anleitungen zur Installation, zum Update und zur Deinstallation des Kolab Servers werden im Kapitel 4 gegeben. ➔ Das Kapitel 5 Kolab Server – Konfiguration und Betrieb beschreibt ausführlich die wichtigsten Einstellmöglichkeiten am Kolab Server und gibt praktische Hinweise für die eigene Konfigura- tion. ➔ Einen allgemeiner Überblick über die verfügbaren Kolab-Klienten stellt Kapitel 6 dar. ➔ Weiterführende Quellen mit Kontaktmöglichkeiten zur Kolab-Gemeinschaft und dem Kolab- Konsortium sowie ein Glossar sind im Anhang A und B zu finden.KonventionenDer leichten Lesbarkeit wegen wird oft nur eine Form verwendet – meist die männliche – gemeint sindbei Personen jedoch immer Männer und Frauen, wie bei „Nutzern“ und „Nutzerinnen“.Das Produkt „Kolab Server“ wird in dieser Dokumentation stets ohne Bindestrich geschrieben.Handelt es sich um eine beliebige Implementation oder eine spezielle Installation des Produkts „KolabServer“, so wird „Kolab-Server“ mit Bindestrich verwendet.1.1  Was ist Kolab?Kolab ist in erster Linie ein Konzept, wie mit Freier Software eine skalierbare, stabile und sichereGroupware-Lösung umgesetzt werden kann. In dieser Idee unterscheidet sich Kolab bereits von vielenanderen Produkten, welche Kommunikation und Arbeitsgruppen unterstützen möchten. Ein Nutzen vonKolab entsteht aus der Kombination mehrerer Softwarekomponenten. Für Anwender ist allein der Nut-zen entscheidend. Als Administrator ist es jedoch nützlich die Zusammenhänge zu kennen; sie sind füreinen täglichen Betrieb zwar nicht direkt erforderlich, erlauben aber oft, den Nutzen der Lösung für alleBeteiligten zu erhöhen.Bei Kolab entsteht der Nutzen im Zusammenspiel von Klient und Kolab-Server. Es werden Groupware-Funktionen zum Austauschen von E-Mails, Freigeben und Bearbeiten von Dateien sowie Verwalten vonKontakten, Terminen, Aufgaben und Notizen auf Basis offener Standards geboten. Nachfolgend einigewesentliche Eigenschaften des Kolab Servers: 6
  • 1 Einführung ➔ Nutzerdaten werden in Ordnern auf dem Server gespeichert. ➔ Ein Ordner enthält Objekte eines Typs: Kontakte, Termine, Aufgaben, Notizen oder E-Mails. ➔ Jeder Nutzer verwaltet seine Ordner und kann diese anderen Nutzern freigeben. ➔ Nutzung von Abwesenheitsbenachrichtigung, E-Mail-Weiterleitung und -Vertretern. ➔ Frei-/Belegt-Listen unterstützen die Terminfindung. ➔ Einladungen können automatisch bearbeitet werden. ➔ Verschiedene Verzeichnisdienste können genutzt werden. ➔ Unterstützt IMAP, POP3, SMTP (optional verschlüsselt); damit für jeden Mail-Klient geeignet. ➔ Vollwertige Kolab-Klienten können offline arbeiten und dann synchronisieren. ➔ Inkrementelle Datensicherung ist leicht zu realisieren. ➔ Nur der Verzeichnisdienst ist zentral, alles andere ist verteil- und skalierbar.Mit Kolab lassen sich u. a. E-Mails, Kontakte und Kalendereinträge von Arbeitsplatz und Laptop einesNutzers synchronisieren und mit anderen Benutzern austauschen. Alles was dazu nötig ist, ist ein Kolab-kompatibler Klient. Für die gängigsten Konfigurationsmöglichkeiten des Kolab Servers wird ein Webin-terface zur Verfügung gestellt. Zur Speicherung der Daten dient der Verzeichnisdienst.Neben dem offiziellen Kolab Server sowie den Kolab-Klienten Kontact und Horde gibt es bereits wei-tere Entwicklungen von Drittanbietern1: Der Univention Groupware Server (UGS) als ein weitererKolab-Server sowie die Outlook-Konnektoren von Toltec und Konsec (vgl. Kapitel 6), die MicrosoftOutlook Groupware-Funktionalitäten eines Kolab Klienten ermöglichen. Weiter befinden sich in der Ent-wicklung: das Thunderbird Plugin Sync Kolab2 und der Bynary Insight Connector3 für MS Outlook.1.2  Entwicklungshistorie von KolabDie Entwicklung von Kolab, geht auf eine Ausschreibung des deutschen Bundesamtes für Sicherheit inder Informationstechnik (BSI) zurück. Ziel der Ausschreibung war die Bereitstellung einer Groupware-Lösung, welche eine heterogene Klientenlandschaft bedienen kann, für den eigenen Bedarf. Im Oktober2002 wurde die Ausschreibung von drei Unternehmen gewonnen, die das Projekt im Juli 2003 erfolg-reich zum Abschluss brachten. Die Intevation GmbH (Osnabrück) hatte die Projektleitung, die ErfrakonPartG (Stuttgart) war für die Entwicklung des Kolab Servers sowie das technischen Konzept verant-wortlich und Klarälvdalens Datakonsult AB (Schweden) realisierte den KDE-basierten Kolab-KlientenKontact. Der Auftrag trug den Kodenamen Kroupware. Das Konzept und die Software, welche u. a. ausdiesem Auftrag entstand, heißt Kolab. Entsprechend heißen die Softwarekomponenten Kolab Serversowie KDE Kolab Client. Am 17. Juli 2003 erschien die erste stabile Version von Kolab1: Kolab Server1.0 und KDE Kolab Client 1.0.Im Jahre 2004 wurde Kolab einer Generalüberholung unterzogen. Um Groupware-Daten plattformüber-greifend zugreifbar zu machen, wird in Kolab2 das Kolab XML Format eingeführt. Im Juni 2005 wurdeKolab Server 2.0 veröffentlicht, einige Monate nachdem Kolab Server 2 bereits im produktiven Einsatz1 Stand: Dezember 20072 http://www.gargan.org/extensions/synckolab.html [Abruf: 07.12.2007]3 http://www.bynari.net/ [Abruf: 07.12.2007] 7
  • 1 Einführungwar. Es folgte das Kolab Server 2.1 Release im Mai 2007. Kolab Server 2.2 ist aktuell in der Entwick-lung. Das stabile Release ist für Anfang 2008 geplant.1.3  Was ist neu in Kolab Server 2.2?Nachfolgend eine Auflistung der wesentlichen Neuerungen in Kolab Server 2.2 gegenüber Version 2.1:➔ Aufnahme des webbasierten Kolab-Klienten Horde (vgl. Abschnitt 6.3)➔ Upgrade des Apache-Servers von Generation 1 auf Version 2.2➔ Upgrade von PHP4 auf PHP5➔ Upgrade von Postfix auf Version 2.4. Damit sind keine kolabspezifischen Änderungen an Postfix mehr nötig.➔ Upgrade des Cyrus IMAP Server auf Version 2.3. Damit sind ebenfalls einige (nicht alle) kolabspe- zifischen Änderungen überflüssig geworden.➔ Strukturelle Verbesserungen von verschiedenen Serverkomponenten➔ Verbesserungen, Fehlerbeseitigung und aktualisierte Softwarekomponenten. Dazu gehört eine aktua- lisierte OpenPKG-Umgebung mit einer verbesserten Unterstützung für aktuelle Betriebssysteme und Hardware. 8
  • 2 Die Komponenten des  Kolab ServersDieses Kapitel gibt eine Übersicht über die im Kolab Server verwendeten Komponenten, erklärt derenZusammenspiel und beschreibt im Detail die Komponente OpenPKG sowie die kolabspezifischen Kern-komponenten kolabd und kolabconf.2.1  ÜbersichtDer Kolab Server 2.2 benutzt zahlreiche Freie-Software-Produkte. Nachfolgend eine Auswahl der wich-tigsten Serverkomponenten:E­Mail / Verzeichnisdienst ➔ Postfix Postfix ist ein freier Mail Transfer Agent (MTA), der den Transport und die Verteilung von Nachrichten übernimmt. URL: www.postfix.org Dokumentation: http://www.postfix.org/documentation.html ➔ Cyrus IMAP Daemon Der Cyrus-IMAP-Server ist ein skalierbarer Mail-Server und bietet Zugriff auf E-Mails über das IMAP-Protokoll (Internet Message Access Protocol). Zusätzlich verarbeitet der Server auch Anfragen über das POP3-Protokoll. URL/Dokumentation: http://cyrusimap.web.cmu.edu/imapd/ Manual Pages: http://cyrusimap.web.cmu.edu/imapd/man.html 9
  • 2 Die Komponenten des Kolab Servers ➔ OpenLDAP OpenLDAP ist ein Verzeichnisdienst, der sich über das Protokoll LDAP (Lightweight Directory Access Protocol) abfragen lässt. URL: http://www.openldap.org Dokumentation: http://www.openldap.org/doc/index.html Manual Pages: http://www.openldap.org/software/man.cgiSpam­ und Virenscanner ➔ amavisd-new Amavisd-new ist ein in Perl implementierter E-Mailscanner, der Nachrichten vom Mailserver entgegennimmt, diese (inkl. Anhang) auspackt und an definierte Viren- und/oder Spamfilter zur Überprüfung übergibt. URL: http://www.ijs.si/software/amavisd Dokumentation: http://www.ijs.si/software/amavisd/amavisd-new-docs.html ➔ ClamAV ClamAV (ClamAntiVirus) ist ein Virenscanner, der insbesondere auf Mailservern zum Einsatz kommt. URL: http://www.clamav.net Dokumentation: http://www.clamav.org/doc/latest/ ➔ SpamAssassin SpamAssassin ist ein in Perl implementierter E-Mail-Filter, der zur Überprüfung und Identifizie- rung von unerwünschten Nachrichten eingesetzt wird. URL: http://spamassassin.apache.org Dokumentation: http://spamassassin.apache.org/doc.htmlKolab Webklient ➔ Horde Horde ist ein webbasierter Klient für Kolab. URL: http://horde.org Dokumentation: http://www.horde.org/documentation.phpAllgemein ➔ Apache (HTTP-Server) Der HTTP-Server von Apache ist der meist verbreitete (freie) Webserver im Internet. URL: http://www.apache.org/ Dokumentation: http://httpd.apache.org/docs/ ➔ Perl Perl ist eine serverseitige, plattformunabhängige und interpretierte Skriptsprache. URL: http://www.perl.org Dokumentation: http://www.perl.org/docs.html ➔ PHP PHP ist eine serverseitige und in HTML-Quelltext integrierbare Skriptsprache. URL: http://www.php.net Dokumentation: http://www.php.net/docs.php 10
  • 2 Die Komponenten des Kolab ServersDie Kolab Server/OpenPKG-Version nutzt zusätzlich die freie Komponente OpenPKG: ➔ OpenPKG OpenPKG ist ein Paketmanagementsystem für Unix (basierend auf dem RPM-System) und erleichtert die Paketinstallation auf bekannten Unix-Plattformen (Linux, Solaris, FreeBSD). Weitere Informationen zu OpenPKG folgen im Abschnitt 2.3. URL: http://www.openpkg.org Dokumentation: http://www.openpkg.org/documentation/Der Kolab Server besteht aus weiteren spezifischen Elementen und Werkzeugen, welche die einzelnenKomponenten um Groupware-Funktionalitäten und ein gemeinsames Konfigurationssystem ergänzen.Alle kolabspezifischen Komponenten, insbesondere kolabd und kolabconf, werden im Abschnitt 2.4beschrieben.2.2  Interaktion der KomponentenDer Kolab-Dämon (kolabd) dient als zentrale Steuerungsinstanz des Kolab Servers. Er verwaltet dieKonfigurationen der einzelnen Serverkomponenten. Abbildung 2.1 veranschaulicht die Interaktion dieserKomponenten:Die Komponenten Cyrus IMAP und Postfix authentifizieren Benutzer über die von SASLauthd gestelltenMethoden per LDAP (slapd). Der Verzeichnisdienst sorgt über das LDAP-Protokoll außerdem für diedirekte Authentifizierung von Benutzern des Apache Webfrontends – dem Kolab Web-Admin. Der Ver-zeichnisdienst-Slave-Server slurpd dient der Replikation und redundanten Vorhaltung der Verzeichnisda-ten. Abbildung 2.1: Die Interaktion der Kolab Serverkomponenten 11
  • 2 Die Komponenten des Kolab Servers2.3  OpenPKGDie Kolab Server/OpenPKG-Variante nutzt eine Schicht zwischen Anwendung und Betriebssystem,names OpenPKG1. Im Ergebnis wird für den Anwendungsentwickler die Plattform vereinheitlicht. Wasfür die Entwickler und Tester des Kolab Servers eine Erleichterung bedeutet. Betrieben werden kann derKolab Server daher auf allen Betriebssystemen, auf denen auch OpenPKG läuft (vgl. dazu die Angabenvon OpenPKG). Am meisten getestet ist der Kolab Server/OpenPKG mit den verbreiten GNU/Linux-Distribution, also z. B. Debian und RedHat Enterprise.Abbildung 2.2 zeigt schematisch den Aufbau eines Kolab Servers mit OpenPKG. Abbildung 2.2: Die Schichten beim Kolab Server/OpenPKGOpenPKG bringt viele Komponenten selbst mit und verwaltet diese mit einer eigenen RPM-Datenbankzur Paketverwaltung. OpenPKG ist demnach von Bibliotheken auf dem eigentlichen Betriebssystemund dessen Paketverwaltung weitestgehend unabhängig. Das bringt viele Vorteile, aber auch einigeNachteile.Aus der Unabhängigkeit der Paketverwaltungssysteme voneinander folgt, 1. dass für OpenPKG andere Kommandos bzw. Pfade existieren. 2. dass auch die Paketverwaltung über OpenPKG-Kommandos erfolgt (z.B. /kolab/bin/openpkg rpm) und dafür OpenPKG Pakete gebraucht werden. 3. dass Konflikte um gemeinsame Ressourcen (wie Portnummern) im Blick behalten werden müs- sen. Welche das sind ist Abschnitt 4.1 zu entnehmen. 4. die Steuerung von Kolab Server/OpenPKG ist auf vielen Betriebssystemen gleich.OpenPKG hängt sich an einigen Punkten in das Betriebssystem ein, so werden für Kolab Server bei-spielsweise die Nutzer kolab-r, kolab-n und kolab sowie ein Startskript in /etc/init.d/kolab ange-legt.Um an die Anwendungen in der OpenPKG-Welt zu kommen, gibt es zwei grundsätzliche Vorgehenswei-sen: a) direktes Aufrufen von /kolab/bin/openpkg <Kommando>, z.B. lässt sich der Apache mit /kolab/bin/openpkg rc apache stop anhalten. Andere Kommandos lassen sich mit absoluten Pfaden aufrufen, wie /kolab/bin/cyrreconstruct.1 http://www.openpkg.org/ [Abruf: 07.12.2007] 12
  • 2 Die Komponenten des Kolab Servers b) setzen der Pfade in Umgebungsvariablen MANPATH, PATH, LIBRARY_PATH usw. Die Nut- zer kolab, kolab-r und kolab-n haben diese Pfade bereits gesetzt.Die Hilfeseiten (Manpages) von OpenPKG-Komponenten können z.B. mit: ➔ /kolab/bin/openpkg man ... oder ➔ man ... (als Benutzer kolab)aufgerufen werden.Hinweise für TechnikerDie Paketverwaltung von OpenPKG ist das bekannte RPM-System in Version 4. Um selbst Pakete bauenzu können, sollte beachten, dass die meisten Bibliotheken statisch gelinkt werden. Wird beispielsweisedb ausgetauscht, dann müssen auch die Anwendungen neu gebaut werden, welche diese Bibliothek hin-eingelinkt haben.OpenPKG verteilt Pakete im Quelltext, um durch die Übersetzung erst auf der genauen Zielplattform einoptimales Ergebnis zu erreichen. Die Binärpakete lassen sich aber auf Systemen mit ähnlicher Hardwareund Betriebssystem austauschen.2.4  Kolabspezifische KomponentenZu den kolabspezifischen Kernkomponenten gehören: ➔ kolabd ➔ kolabconf ➔ kolab-webadmin ➔ kolab-filter ➔ kolab-freebusy ➔ kolab-horde-framework ➔ kolab-horde-fbview ➔ kolab-ressource-handlersDer folgende Abschnitt konzentriert sich auf die Komponenten kolabd und kolabconf.Der Kolab-Dämon (kolabd) sowie kolabconf dienen als zentrale Steuerungsinstanzen des Kolab Servers.Kolabd führt die notwendigen Arbeiten aus, wenn ein Nutzer angelegt, geändert oder gelöscht wordenist. Kolabconf verwaltet die Konfigurationen der einzelnen Serverkomponenten und erzeugt die eigentli-chen Konfigurationsdateien aus Vorlagen, so genannten Templates.Ändert sich etwas an den Kolab-Nutzern oder Verteilerlisten ist nur kolabd (und nicht kolabconf) für dieBearbeitung zuständig; beispielsweise kann kolabd ein Konto auf dem Cyrus IMAPd anlegen, ändernoder löschen. Für die Arbeit am Cyrus-Server hält sich kolabd einen Zwischenspeicher von allen existie-renden Nutzer auf der Festplatte, um den IMAPd nicht mit weiteren Anfragen zu belegen.Abbildung 2.3 veranschaulicht die Arbeitsweise von kolabd und kolabconf. 13
  • 2 Die Komponenten des Kolab Servers Abbildung 2.3: Arbeitsweise des Kolab­Server­Konfigurationssystems – vereinfacht für einen Dienst.Der Verzeichnisdienst OpenLDAP gibt die kolabspezifischen Einstellungen per LDAP heraus. Ändernsich Einstellungen, zum Beispiel durch eine Konfiguration über den Kolab Web-Admin, so werden auto-matisch neue Konfigurationsdateien erzeugt und betroffene Dienste benachrichtigt. 1. Wie in Abbildung 2.3 veranschaulicht, schreibt der Kolab Web-Admin Änderungen in den Ver- zeichnisdienst (Schritt 1). 2. Der kolabd muss nun mitbekommen, dass sich im Verzeichnisdienst etwas geändert hat. ○ Dies wird entweder automatisch gemacht: Dazu hängt kolabd bei OpenLDAP als Replika- tionsziel und lauscht auf Port 9999. Sobald sich etwas im Verzeichnisdienst ändert, teilt OpenLDAP dies kolabd mit. ○ Der andere Weg, um kolabd mitzuteilen, dass sich etwas geändert hat, ist manuell den Befehl /kolab/sbin/kolabconf ausführen (Schritt 2 in der Abbildung – gestrichelter Pfeil). 3. Anschließend ruft kolabd die benötigten Angaben der Änderungen per LDAP vom Verzeichnis- dienst ab. 4. Nun muss kolabconf benachrichtigt werden: Dazu ruft kolabd im Schritt 4 /kolab/sbin/kolabconf auf. 5. Kolabconf liest alle relevanten Einstellungen aus dem Verzeichnisdienst, .. 6. ... liest anschließend das entsprechende Template ein, ... 7. ... generiert daraus die passende Konfigurationsdatei und ... 8. ... informiert abschließend den zugehörigen Dienst, der dann ggf. neu gestartet wird. 14
  • 2 Die Komponenten des Kolab ServersKonfiguration durch TemplatesDie Kolab-Komponenten werden durch Konfigurationsdateien konfiguriert, die von kolabconf ausTemplates generiert werden. Am Beispiel des Postfix-Dienstes wird nun die Funktionsweise vonTemplates erläutert:Alle Template-Dateien liegen im Verzeichnis /kolab/etc/kolab/templates und sind an derDateiendung .template zu erkennen. Aus dem Dateiname lässt sich erschließen, um welcheKonfiguration es sich handelt; so wird z. B. aus dem Template /kolab/etc/kolab/templates/main.cf.template die Konfigurationsdatei /kolab/etc/postfix/main.cf für Postfix generiert(vgl. Schritt 7 in der obigen Abbildung).In jeder Template-Datei steht zu Beginn ein Block mit Metainformationen; exemplarisch der Meta-Blockvon Postfix: KOLAB_META_START TARGET=/kolab/etc/postfix/main.cf PERMISSIONS=0644 OWNERSHIP=kolab-n:kolab-r KOLAB_META_ENDIn diesem Abschnitt wird festgelegt wo (TARGET) und mit welchen Zugriffsrechten (PERMISSIONS undOWNERSHIP) die generierte Konfigurationsdatei im Dateisystem abgelegt wird.Nachdem die Konfigurationsdateien neu generiert wurden, informiert kolabconf die zugehörigenDienste. Einige Dienste müssen nach Änderungen an ihren Konfigurationsdateien neu gestartet werden.Welche das sind, ist in Kolab Server 2.2 beta2 noch „hart“ im Kolab-Konfigurationssystem kodiert. Beikünftigen Kolab-Versionen soll auch diese Information in dem o. g. Metainformations-Block im Tem-plate festgelegt werden.Auffällig sind auch die von @@@ eingerahmten Schlüsselworte im Template. Im einfachsten Fall werdendiese beim Schreiben der Konfigurationsdateien eins zu eins durch entsprechende Werte aus dem Ver-zeichnisdienst ersetzt. Kolabconf liest dafür Werte aus dem vertrauenswürdigen Objekt: dn: k=kolab, dc=example, dc=comAnstatt eines Schlüsselwortes können auch konkrete Angaben direkt in das Template eintragen werden.Dazu wird das Schlüsselwort (inkl. dessen einrahmende @@@ Zeichen) einfach überschrieben. 15
  • 2 Die Komponenten des Kolab ServersProblemsuche in kolabd / kolabconfDer kolabd ist das Bindeglied zwischen dem Verzeichnisdienst und dem Cyrus-IMAP-Server. Kolabdkommt erst dann zum Einsatz, wenn Änderungen an der Konfiguration oder den Nutzereinstellungenvorgenommen werden. Probleme am kolabd werden also erst dann sichtbar, wenn Änderungen nichtabgearbeitet werden können.Typische Symptome für einen gestörten kolabd sind: a) Der im Verzeichnisdienst angelegte Nutzer kann sich nicht im Cyrus anmelden (der kolabd hat das Konto noch nicht angelegt). b) Die Löschung eines Nutzers dauert sehr lang.Ein Neustart des kolabd ist harmlos, da er selbst keinen Zustand hält und nicht zeitnah auf Anfragen ant-worten muss. Es schadet also nicht, den kolabd in den beiden oben beschriebenen Situation neu zu star-ten.Der kolabd protokolliert seine Arbeit in der normalen Log-Datei für Systemmeldungen, bei Debian istdas meist /var/log/syslog (Achtung: Dies ist nicht innerhalb der OpenPKG-Hierarchie). Um dortmehr Ausgaben zu erhalten, sollte in der Konfigurationsdatei /kolab/etc/kolab/kolab.conf derWert für log_level erhöht und kolabd neu gestartet werden. log_level steht nach der Installation vonKolab Server noch nicht in der kolab.conf; er muss also manuell eingetragen werden. Dessen voreinge-stellter Wert ist in der Regel 2 und steht in /kolab/etc/kolab/kolab.globals. Für die Ausgabenin syslog ist nur log_level (0 – 4) interessant. Analog kann für ein interaktives Debugging der Flagdebug (0/1) gesetzt werden.Voreinstellungen in /kolab/etc/kolab/kolab.globals: log_level : 2 debug : 0Änderung der Werte in /kolab/etc/kolab/kolab.conf, z.B.: log_level : 4 debug : 1Bedeutung der Werte: log_level: debug: 0: SILENT 0: send to syslog if log level >= message priority 1: ERROR 1: additionally print all messages to stdout 2: WARN 3: INFO 4: DEBUGSind mehrere Slave-Server im Betrieb, muss erst die Replikation des Verzeichnisdienstes funktionieren,bevor der kolabd auf den verschiedenen Servern tätig werden kann. Die obigen Symptome können alsoauch auf eine gestörte Replikation hinweisen. 16
  • 3 Kolab Server –  BedarfsplanungEs empfiehlt sich den eigenen Bedarf für den Server abzuschätzen. Anhand von einigen Rahmenbedin-gungen werden in diesem Kapitel Hinweise für eine Grob-Planung gegeben.Dabei ist zu beachten, dass das Nutzungsmuster einen starken Einfluss auf die Bedarfsplanung hat. Inmanchen Organisation reichen beispielsweise 50 Megabyte E-Mail-Speicherplatz und es werden proNutzer weniger als dreistellige Termine gespeichert. Bei Anderen wird E-Mail zur „Ablage“ großer Mul-timedia-Dateien verwendet und die 3000 Termine der ganzen Arbeitsgruppe der letzten drei Jahre archi-viert; hier wird ein Quota von 2 Gigabyte sicherlich schnell eng.3.1  FestplattenspeicherDie wichtigste Tätigkeit eines Kolab-Servers ist es, für die Klienten E-Mail-Daten zu liefern. JedesGroupware-Objekt ist ebenfalls eine E-Mail. In der Regel haben die meisten Nutzer deutlich mehr nor-male E-Mails als andere Groupware-Objekte, eine Bedarfsschätzung sollte also bei der E-Mail anfangen.Der durchschnittliche E-Mail-Speicherplatz in den nächsten Jahren, multipliziert mit der Anzahl der Nut-zer und etwas Puffer ergibt den zu erwartenden Plattenplatz der Nutzerdaten. Aus der erwarteten Ände-rungsrate lässt sich auch der Platz für die Datensicherung abschätzen. Gegenüber den normalen E-Mailsfallen die Termine und Kontakte meist nicht ins Gewicht.Wird als Klient Microsoft Outlook mit einem der verfügbaren Konnektoren verwendet (vgl. Abschnitt6.2), ist es möglich, dass sich die Größe mancher E-Mails in der Speicherung verdoppeln. Nur so könnenmanche Objekt-Attribute gespeichert werden, welche nur für Outlook wichtig sind. Wer ganz sichergehen möchte, migriert auf ein Testsystem die alten Daten einiger repräsentativer Nutzer. 17
  • 3 Kolab Server – BedarfsplanungEntscheidend wird der Umgang mit Alt-Daten im System sein. Was werden die Nutzer tun, wenn sie anihr Limit stoßen? Es empfiehlt sich, den Nutzern hier früh eine Möglichkeit anzubieten, z.B. zum selb-ständigen Archivieren. Die Klienten bieten meist Funktionen zum automatischen Löschen alter E-Mailsoder Termine an.3.2  Rechenleistung / HauptspeicherBeim Verfügbarmachen von E-Mails sind vor allem das Übermitteln von Daten, Platten- und Netzwerk-durchsatz, sowie die Netzlatenz limitierender als die Rechenleistung. Pro aktivem Klienten läuft etwa einCyrus-IMAPd, der grob um die 2 Megabyte Hauptspeicher benötigt.Ein „aktiver Klient“ steht in diesem Zusammenhang für einen Klienten, der einen Zwischenspeicherbesitzt und daher hauptsächlich nur zum Synchronisieren eine Netzwerkverbindung benötigt. Der ein-zelne Nutzer kommt also problemlos minutenlang ohne Verbindung aus. Es ist zu erwarten das durchgeschicktere Synchronisations-Algorithmen von Seiten der Klienten der Bedarf an Netzverbindungen inZukunft sogar sinken kann.Deutlich mehr Rechenleistung im Kolab-Server benötigen zwei andere Prozesse: 1. Das Scannen von E-Mails auf Schadsoftware und unerwünschte Werbung, 2. sowie das Erstellen von Frei/Belegt-Listen.Die Erstellungszeiten von Frei/Belegt-Listen sind von Kolab Server 2.0 auf 2.1 entscheidend verbessertworden. Langzeiterfahrungen fehlen, aber es wird eine deutliche Besserung erwartet, so dass dieses fürden Betrieb von 2.2 nicht mehr gesondert geplant werden muss. Im Gegensatz dazu hat der Ansturm anunerwünschten E-Mails zugenommen, was mehr Scan-Leistung erforderlich macht. Für das Scannen vonE-Mails ist deshalb bei größeren Installation ein eigener Rechner sinnvoll.Bei durchschnittlicher Nutzung ist zu erwarten, dass eine übliche Server-Hardware mit 2 Prozessorenund 4 Gigabyte Hauptspeicher mehrere tausend Nutzer bedienen kann. Das gilt pro Kolab-Server; durchden Einsatz von Slave-Servern ist hier eine gute Skalierung möglich.3.3  VerfügbarkeitDie Bedürfnisse an die Verfügbarkeit der Kolab-Server sind recht unterschiedlich. Wie im letzten Absatzbeschrieben, sind die Klienten auch ohne Netzverbindung grundsätzlich arbeitsfähig. Dennoch sollteeine hohe Verfügbarkeit von jedem Kolab-Servers angestrebt werden.Der Kolab-Server kann mit üblichen GNU/Linux Mechanismen abgesichert werden. Zum Beispiel durchein aktiv-passiv System, welches per Linux-HA1 den aktiven Rechner überwacht und bei Schwierigkei-ten den passiven einschaltet. Dazu muss der passive Rechner auf die Daten zugreifen können: z. B.durch ein gemeinsames SCSI Plattensystem / SAN, ggf. auch standortübergreifend.1 http://www.linux-ha.org/ [Abruf: 07.12.2007] 18
  • 3 Kolab Server – Bedarfsplanung3.4  Wer arbeitet mit wem?Es kann sinnvoll sein, aus Gründen der Leistung oder verschiedener Standorte, mehrere Kolab-Serverzu planen. Dabei ist zu beachten, wie die Arbeitsbeziehungen der Nutzer sind. Es ist empfehlenswert,eng zusammenarbeitende Nutzer auf einen Kolab Server zu legen – also beispielsweise lieber eine Abtei-lung X, als die Mitarbeiter von A bis H.Interessant sind dabei auch Fragen der Modellierung von gemeinsamen Ordner (z.B. für Termine):Ein Ordner steht zunächst nur Nutzern auf einem Server zur Verfügung. Kolab-Nutzer haben einenbestimmten Heimatserver, dürfen sich aber auf allen anderen anmelden. Das ist weniger nötig, wenn sichdie Nutzer einer Arbeitsgruppe schon auf einem gemeinsamen Heimatserver befinden. 19
  • 4 Kolab Server – Vorbereitung  und InstallationIn diesem Kapitel werden zunächst die nötigen Grundvoraussetzungen und Vorbereitungen für diedanach beschriebene Installationsanleitung des Kolab Servers erläutert. Anschließend wird das Vorgehenfür eine Aktualisierung und für die Deinstallation dargestellt.4.1  Installationsvorbereitung Speicherplatz/ ­ort Die Installation des Kolab Servers (inkl. Horde) belegt unter /kolab etwa 1 GB Speicherplatz. Falls das Verzeichnis nicht existiert, wird es angelegt. Ein Symlink kann genutzt werden. Die Nutzung eines NFS gemounteten Laufwerks ist nicht möglich, da es sonst zu Problemen mit dem Cyrus IMAP Server kommt1. Partitionierung Für einen produktiven Einsatz eines Kolab Servers wird empfohlen, getrennte Partitionen für Programme, Bewegungsdaten und Nutzerdaten zu verwenden. Nachfolgend eine Empfehlung für eine typische Installation, bei der Verzeichnisse von Kolab auf drei Partitionen verteilt werden: /kolab 2 - 4 GB (Programme) /kolab/var 2 - 4 GB (Bewegungsdaten) /kolab/var/imapd/spool nach geplanten Bedarf (Nutzerdaten) Dateisystem Es wird ein geeignetes Dateisystem benötigt. Die meisten Kolab-Server- Installationen werden mit ext3 betrieben, aber es existieren auch nennens- werte Erfahrung mit XFS. Bei der Nutzung von ext3 wird empfohlen, einen Linux Kernel ab 2.6.19.2 oder einen entsprechend gepatchten Kernel zu1 http://cyrusimap.web.cmu.edu/imapd/faq.html [Abruf: 07.12.2007] Der Cyrus IMAPd braucht ein lokales Dateisystem, mit Unix-Eigenschaften und funktionierender mmap()/write() Kombination. 20
  • 4 Kolab Server – Vorbereitung und Installation verwenden. Frühere Versionen haben einen Defekt im mmap(). Für ext3 spricht, dass es sich um ein vergleichsweise einfaches und damit sehr robustes Journaling-Dateisystem handelt. Sollte ein Dateisystem-Check trotzdem einmal nötig werden, dann dieser jedoch im Ernstfall längere Zeit benötigen. XFS ist ein komplizierteres Journaling-Dateisystem. Reservierte Benutzer Die folgenden Benutzer sollten noch nicht existieren, da OpenPKG diese anlegt: kolab, kolab-r, kolab-n. Pakete Es sollten nur Pakete verwendet werden, von deren Echtheit man sich über- zeugt hat. Unter http://kolab.org/mirrors.html gibt es eine Liste von Ser- vern, welche die Kolab-Server-Pakete zum kostenfreien Herunterladen anbieten. Nach dem Download sollten die Signaturen überprüft werden. Aus dem Verzeichnis server sollte die aktuelle Kolab-Server-Version herun- tergeladen werden – entweder die komplette Quellcodeversion im Verzeich- nis sources oder die binäre, vorkompilierte Version für Debian 4.0 (Etch) im Ordner ix86-debian4.0. Binär-Versionen für andere Distributionen kön- nen selbst gebaut oder über Kolab-Dienstleister bezogen werden (Kontakte im Anhang A.2). Ports Die folgenden Ports möchte der Kolab Server öffnen. Alle Anwendungen des Betriebssystems, die diese Ports ansonsten bräuchten, sollten gestoppt oder deinstalliert werden. 80/tcp http offen nach außen (bei Bedarf) 443/tcp https offen nach außen 25/tcp smtp offen nach außen 465/tcp smtps offen nach außen 110/tcp pop3 offen nach außen (bei Bedarf) 995/tcp pop3s offen nach außen (bei Bedarf) 143/tcp imap offen nach außen 993/tcp imaps offen nach außen 389/tcp ldap offen nach außen 636/tcp ldap offen nach außen 2000/tcp sieve offen nach außen (bei Bedarf) 2003/tcp lmtp nur intern offen 9999/tcp kolabd nur intern offen 10024/tcp amavis nur intern offen 21
  • 4 Kolab Server – Vorbereitung und Installation4.2  InstallationIm folgenden Abschnitt werden die Schritte zur Installation des Kolab Servers mit den unter Abschnitt4.1 heruntergeladenen Paketen beschrieben. Es sollte zusätzlich die bei den Paketen beiliegende1st.README-Datei beachtet werden.1. Die Installation Die Pakete in den Verzeichnissen sources und ix86-debian4.0 lassen sich mit dem enthaltenen install-kolab.sh-Skript (als root) installieren. Es steht eine Installation von den Quellcodepaketen (sources) oder von den für Debian 4.0 vorkompilierten ix86-Binärpaketen (ix86-debian4.0) zur Wahl. Dafür muss in das entsprechende Verzeichnis gewechselt werden. Anschließend wird die Installation gestartet mit: ./install-kolab.sh -H -F 2>&1 | tee kolab-install.log Um den Kolab Webklienten Horde und/oder den Frei/Belegt-Viewer nicht mitzuinstallieren, muss der Parameter -H und/oder -F in o. g. Befehlszeile weggelassen werden. Die Konsolenausgabe wird in der kolab-install.log protokolliert. Installationsdauer: Die Installation aus den Quellpaketen kann, je nach Rechenleistung, leicht einige Stunden dauern (z. B. bei einem P4 mit 3 GHz sind es ca. 3 Stunden). Bei der Binärpaket-Installa- tion kann mit ca. 3 bis 10 Minuten gerechnet werden. Bei Schwierigkeiten mit der Binärpaket-Installation sollte stets die Installation von den Quellen pro- biert werden.2. Das Bootstrapping Nach der Installation sollte die initiale Konfiguration (das Bootstrapping) des Kolab-Servers mit folgendem Befehl durchgeführt werden: /kolab/etc/kolab/kolab_bootstrap -b Dabei werden zunächst die benötigten Ports nach Verfügbarkeit getestet. Anschließend werden unterschiedliche Informationen zum Kolab-Server abgefragt. Nachfolgender Ausdruck zeigt exemplarisch das Konfigurieren eines Master-Servers mit einer eige- nen Zertifizierungsstelle für Testzwecke. Alle nötigen Eingaben sind fett gedruckt ([Enter] meint das Drücken der Enter/Return-Taste ohne weitere Eingabe) und dienen nur zur Demonstration des Bootstrapping-Prozesses. Für das Aufsetzen eines eigenen Systems sollten diese Eingaben unbe- dingt an die spezifischen Anforderungen angepasst werden. Wird ein Produktivsystem aufgesetzt, sollten Zertifikate einer „richtigen“ Zertifizierungsstelle (Cer- tification Authorities, kurz CA) zum Einsatz kommen. Unter http://www.pki-page.org gibt es eine ausführliche Liste weltweiter, aktueller Zertifizierungsstellen. Wichtig ist dabei, dass die Zertifikate in den Klienten als vertrauenswürdig anerkannt werden. 22
  • 4 Kolab Server – Vorbereitung und Installation Ein exemplarischer(!) Bootstrapping-Prozess Eingabe des Hostnamens > Please enter Hostname including Domain Name (e.g. thishost.domain.tld) [example]: kolab.example.com Proceeding with Hostname kolab.example.com Auswahl „Master Server“ > Do you want to set up (1) a master Kolab server or (2) a slave [1] (1/2): 1 Proceeding with master server setup Eingabe der Maildomain (Bestätigung der Defaultangabe mit Enter) > Please enter your Maildomain - if you do not know your mail domain use the fqdn from above [example.com]: [Enter] proceeding with Maildomain example.com Kolab primary email addresses will be of the type user@example.com Generating default configuration: Top level DN for Kolab [dc=example,dc=com]: base_dn : dc=example,dc=com bind_dn : cn=manager,cn=internal,dc=example,dc=com Eingabe eines sicheren Managerpasswortes (Bestätigung der Defaultangabe mit Enter) > Please choose a manager password [VG1rXCIxi22/c4DT]: [Enter] bind_pw : <managerpasswort> done modifying /kolab/etc/kolab/kolab.conf IMPORTANT NOTE: use login=manager and passwd=VG1rXCIxi22/c4DT when you log into the webinterface! Eingabe des Hostnames eines Slaveservers (ohne Slaveserver fortfahren durch Drücken von Enter) > Enter fully qualified hostname of slave kolab server e.g. thishost.domain.tld [empty when done]: [Enter] prepare LDAP database... temporarily starting slapd Waiting for OpenLDAP to start no dc=example,dc=com object found, creating one mynetworkinterfaces: 127.0.0.0/8 LDAP setup finished Create initial config files for postfix, apache, cyrus imap, saslauthd running /kolab/sbin/kolabconf -n kill temporary slapd OpenPKG: stop: openldap. Creating RSA keypair for resource password encryption /kolab/bin/openssl genrsa -out /kolab/etc/kolab/res_priv.pem 1024 Generating RSA private key, 1024 bit long modulus ....................++++++ ...............++++++ e is 65537 (0x10001) /kolab/bin/openssl rsa -in /kolab/etc/kolab/res_priv.pem -pubout -out /kolab/etc/kolab/res_pub.pem writing RSA key chown kolab:kolab-n /kolab/etc/kolab/res_pub.pem /kolab/etc/kolab/res_priv.pem Kolab can create and manage a certificate authority that can be used to create SSL certificates for use within the Kolab environment. You can choose to skip this section if you already have certificates for the Kolab server. 23
  • 4 Kolab Server – Vorbereitung und Installation Erstellen einer eigenen Test-Zertifizierungsstelle und eines Zertifikats > Do you want to create CA and certificates [y] (y/n): y Now we need to create a cerificate authority (CA) for Kolab and a server certificate. You will be prompted for a passphrase for the CA. ###################################################################### /kolab/etc/kolab/kolab_ca.sh -newca kolab.example.com > Enter organization name [Kolab]: [Enter] > Enter organizational unit [Test-CA]: [Enter] Using subject O=Kolab,OU=Test-CA,CN=kolab.example.com Using dn > CA certificate filename (or enter to create) [Enter] Making CA certificate ... Generating a 1024 bit RSA private key ....++++++ writing new private key to /kolab/etc/kolab/ca/private/cakey.pem > Enter PEM pass phrase: <passphrase> > Verifying - Enter PEM pass phrase: <passphrase> ----- /root /kolab/etc/kolab/kolab_ca.sh -newkey kolab.example.com /kolab/etc/kolab/key.pem Using dn Generating RSA private key, 1024 bit long modulus ......++++++ e is 65537 (0x10001) writing RSA key /root /kolab/etc/kolab/kolab_ca.sh -newreq kolab.example.com /kolab/etc/kolab/key.pem /kolab/etc/kolab/newreq.pem Using dn Request is in /kolab/etc/kolab/newreq.pem and private key is in /kolab/etc/kolab/key.pem /root /kolab/etc/kolab/kolab_ca.sh -sign /kolab/etc/kolab/newreq.pem /kolab/etc/kolab/cert.pem Using dn Using configuration from /kolab/etc/kolab/kolab-ssl.cnf > Enter pass phrase for /kolab/etc/kolab/ca/private/cakey.pem: <passphrase> Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Oct 19 07:24:15 2007 GMT Not After : Oct 16 07:24:15 2017 GMT Subject: commonName = kolab.example.com X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 65:CD:3E:49:47:34:B6:05:52:25:3B:C7:C5:4D:7D:09:92:13:6D:1B X509v3 Authority Key Identifier: DirName:/O=Kolab/OU=Test-CA/CN=kolab.example.com serial:85:3B:73:2D:BA:56:FC:67 > Certificate is to be certified until Oct 16 07:24:15 2017 GMT (3650 days) Sign the certificate? [y/n]: y > 1 out of 1 certificate requests certified, commit? [y/n] y Write out database with 1 new entries Data Base Updated Signed certificate is in /kolab/etc/kolab/cert.pem /root chgrp kolab-r /kolab/etc/kolab/key.pem; chmod 0640 /kolab/etc/kolab/key.pem; chgrp kolab-r /kolab/etc/kolab/cert.pem; chmod 0640 /kolab/etc/kolab/cert.pem; ###################################################################### CA and certificate creation complete. You can install /kolab/etc/kolab/ca/cacert.pem on your clients to allow them to verify the validity of your server certificates. <<Ende des exemplarischen Bootstrappings-Prozesses>> 24
  • 4 Kolab Server – Vorbereitung und Installation Am Ende des Bootstrappings sollte die Ausgabe der folgenden ähnlich sein: kolab is now ready to run! please run /kolab/bin/openpkg rc all start Use login=manager and passwd=VG1rXCIxi22/c4DT when you log into the webinterface https://kolab.example.com/admin ! Anmerkung: Es sollte zunächst der Master-Server konfiguriert werden. Das (optionale) Hinzufügen von weiteren Kolab-Slave-Servern ist im Abschnitt 5.12 beschrieben.3. Server starten Der Kolab Server ist erfolgreich installiert und kann nun mit folgendem Befehl gestartet werden: /kolab/bin/openpkg rc all startDas Verzeichnis /kolab/RPM/PKG/ wird nur zur Installation gebraucht und kann anschließendgelöscht oder für spätere Installationen archiviert werden (Größe: ca. 500 MB).4.3  Aktualisierung Achtung: Die Migration von Kolab Server 2.1 auf 2.2 wird zur Zeit noch getestet! Für Hinweise kann die Kolab-Mailinglisten, das Kolab-Wiki bzw. der Kolab-Issue-Tracker genutzt werden (vgl. Anhang A). Vor jeder Aktualisierung sollte in jedem Fall ein Backup von /kolab durchgeführt werden (vgl. Punkt 2 dieser Anleitung und Abschnitt 5.13).Hier folgt eine allgemeine Anleitung zum Aktualisieren des Kolab Servers.Die Installation von neuen Paketen läuft analog zur initialen Kolab-Server-Installation (vgl. Abschnitt4.2). Die Hinweise in der Datei 1st.README sind zusätzlich zu beachten. 1. Beenden aller Kolab Server Dienste: /kolab/bin/openpkg rc all stop und sicherstellen, dass kein LDAP-Prozess mehr läuft: /kolab/bin/openpkg rc openldap status und ps -AF | grep slapd 2. Sichern der vollständigen, alten Kolab-Installation! Zum Reduzieren der Server-Stillstandszeit (downtime) wird empfohlen, das Verzeichnis /kolab mit rsync zunächst von dem noch laufenden Server zu kopieren. Anschließend, bei gestoppten Server, müssen mit rsync nur noch die geänderten Dateien nachgesichert werden. Sofern ein ähnliches Vorstufen-System zur Verfügung steht („staging“) empfiehlt es sich, die Binärdateien dort zu bauen und diese dann zu kopieren. Dadurch wird entscheidende Zeit gespart. 25
  • 4 Kolab Server – Vorbereitung und Installation 3. Nach dem Aktualisieren der Kolab Server Pakete in dem Verzeichnis, in dem bereits die anderen Pakete liegen kann das Kolab Server Update (als root) gestartet werden: ./install-kolab.sh -H -F 2>&1 | tee kolab-update.log install-kolab.sh bestimmt in der Regel automatisch welche Pakete benötigt werden und instal- liert oder baut diese. Die Parameter -H und -F geben an, ob der Kolab Webklient Horde und der Frei/Belegt-Viewer nachinstalliert / aktualisiert werden. Die Konsolenausgabe wird in der kolab-update.log protokolliert. Der Server wird aktualisiert, ohne dass die bereits vorhandenen Konfigurationen und Daten überschrieben werden. Manuell geänderte Konfigurationsdateien werden mit der Dateinamener- weiterung *.rpmsave gespeichert. Bei Konfigurationsdateien, die von Templates generiert wer- den, müssen die *.conf.rpmsave Dateien zunächst gelöscht werden, um den entsprechenden Dienst starten zu können; z. B. für ClamAV: rm /kolab/etc/clamav/*.conf.rpmsave Die Änderungen aus den *.template.rpmsave Dateien (die angelegt werden, wenn Templates geändert wurden) können nun in die neuen Template-Dateien übertragen werden. Nun muss der OpenLDAP gestartet, die Konfigurationsdateien neu generiert und schließlich der komplette Kolab Server neu gestartet werden: /kolab/bin/openpkg rc openldap start /kolab/sbin/kolabconf /kolab/bin/openpkg rc all startDetailliertere Upgrade-Informationen – insbesondere zu Besonderheiten beim Upgrade von früherenKolab-Versionen – sind in den Readme-Dateien im CVS-Server-Verzeichnis 2 bzw. in der 1st.READMEim Installationsordner zu finden.SicherheitsupdatesZunächst ist der Benachrichtigungsweg relevant: Wie bekommt der Administrator Kenntnis von einemSicherheitsupdate? Entweder wird er von seinem Dienstleister benachrichtigt und mit einer genauenAnleitung versorgt, oder er muss sich selbst darum kümmern.Ist kein Dienstleister damit beauftragt, wird geraten, mindestens folgende Quellen zu verfolgen: ➔ die Kolab-Announce-Mailingliste (vgl. Anhang A) zu abonnieren ➔ die Sicherheitsrelevanten Informationen der genutzten Distribution (z.B. Debian security) zu beobachtenAnschließend sollte eine Bewertung der in Frage kommenden Updates durchgeführt werden.2 http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/ [Abruf: 07.12.2007] 26
  • 4 Kolab Server – Vorbereitung und InstallationTreten Unsicherheiten/Schwierigkeiten beim Durchführen von Sicherheitsupdates auf, sollte ein Dienst-leister zu Rate gezogen werden. Ein funktionierender Prozess, um zu Aktualisierungen zu kommen istwichtig, da ansonsten das eingesetzte System Gefahr läuft längere Zeit bekannte Angriffspunkte zu bie-ten.4.4  DeinstallationDer Kolab Server/OpenPKG kann in drei Schritten deinstalliert werden: 1. Kolab Server beenden: /kolab/bin/openpkg rc all stop 2. Alle Kolab-Pakete löschen: /kolab/bin/openpkg rpm -e `/kolab/bin/openpkg rpm -qa` rpm -qa listet alle Pakete innerhalb der OpenPKG Umgebung und rpm -e löscht diese. 3. Kolab-Verzeichnis löschen: rm -rf /kolab/Anschließend sollten ... ➔ ... alle kolabspezifischen cronjobs in /etc/crontab und die Datei /var/spool/cron/crontabs/kolab, ➔ ... alle kolabspezifischen Benutzer in /etc/passwd und in /etc/shadow, ➔ ... alle kolabspezifischen Gruppen in /etc/group, ➔ ... alle kolabspezifischen Einträge in /etc/shells, ➔ ... das Kolab/OpenPKG Initskript /etc/init.d/kolab mit den Symlinks in /etc/rc?.d/???kolab und ➔ ... das /kolab Verzeichnisdurch OpenPKG entfernt worden sein. 27
  • 5 Kolab Server – Konfiguration  und BetriebDieses Kapitel beschreibt die Konfigurationsmöglichkeiten des Kolab Servers und gibt darüber hinausfür den Betrieb nützliche Methoden und Einstellungen mit.Es gibt zwei grundsätzliche Strategien den Kolab Server zu konfigurieren: ➔ Über ein LDAP-Verzeichnisdienst-Werkzeug – beispielsweise mit dem Kolab Web-Admin (vgl. folgender Abschnitt) oder ➔ über die kolabspezifische Konfigurationskomponente kolabconf. Dabei können die Konfigurati- onstemplates und -dateien der einzelnen Kolab-Komponenten angepasst werden. Mithilfe des Befehls /kolab/sbin/kolabconf werden die Änderungen aus den Templates wirksam.Beide Strategien sollte ein Systemadministrator eines Kolab Servers anwenden können. Dieses Kapitelvermittelt die dafür nötigen Kenntnisse.5.1  Kolab Web­AdminDer Kolab Server stellt ein Webinterface – den Kolab Web-Admin – zur Verfügung, worüber die gän-gigsten Servereinstellungen konfiguriert werden können. Der Web-Admin ist unter dem Kolab-Rechner-namen https://kolab.example.com/admin im Web-Browser zu erreichen. Für den ersten Login kann dervoreingestellte Administratorname manager genutzt werden; das Passwort wurde während der Installa-tion vergeben. Für die regelmäßige, administrative Arbeit sollte jedoch ein Administrator-Account ange-legt werden. Nach dem Einloggen erhält der Nutzer eine Navigationsleiste (vgl. Abb. 5.1) mit Links zuEinstellmöglichkeiten des Kolab Servers. 28
  • 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.1: Navigationsleiste vom Kolab Web­Admin (manager­Ansicht)Der Web-Admin ist in PHP geschrieben und nutzt den Apache Webserver (mit mod_php). Das Webinter-face unterstützt SSL-Verschlüsselung und Authentifikation gegen den Verzeichnisdienst. Der Web-Admin ist ein LDAP-Verzeichnisdienst-Werkzeug und kommuniziert ausschließlich mit dem LDAP-Ser-ver (eine Ausnahme sind Sieve-Skripte). In dieser Betriebsdokumentation wird exemplarisch für einigeKonfigurationsmöglichkeiten auf den Web-Admin verwiesen. Weitere Informationen zur Konfigurationdes Kolab Servers mit dem Web-Admin sind in der Kolab-Dokumentation Doc2 zu finden (vgl. AnhangA).5.2  RollenDer Kolab Server stellt vier Rollen zur Verfügung, die nachfolgend beschrieben werden: 1. Administrator 2. Verwalter 3. Domänenverwalter 4. BenutzerDarüber hinaus nimmt der Rechner-Administrator (root) eine „Sonderrolle“ ein. Aus Sicherheitsgründenhaben die Kolab-Nutzer in der Regel keine Rechnerkonten und somit keinen direkten Zugriff (z.B. perssh) auf den Server.Abbildung 5.2 veranschaulicht den Zusammenhang der vier Rollen und deren Berechtigungen: DieRechte von Benutzer sind eine Untermenge von den Domänenverwalter-Rechten, diese wiederumUntermenge von Verwalter sind. Die Administratoren-Rechte umfasst alle genannten Berechtigungs-mengen. Eine detaillierte Auflistung der rollenspezifischen Rechte folgt in den nächsten Abschnitten. 29
  • 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.2: Die vier Benutzerrollen des Kolab Servers mit ihren Zugriffsberechtigungen auf den  Verzeichnisdienst5.2.1  AdministratorDie Benutzergruppe Administrator besitzt Lese- und Schreibberechtigung für den LDAP-Verzeichnis-baum. Ein Administrator hat Zugang zu allen Einstellmöglichkeiten innerhalb des Kolab Web-Admins.Das Passwort des voreingestellten Administrators manager wurde bei der Installation des Kolab Serversvergeben und ist bei Verlust in der folgender Datei wiederzufinden (Dies gilt ausschließlich nur für denmanager. Andere Administratoren werden hier nicht gespeichert!): /kolab/etc/kolab/kolab.conf (Zeile bind_pw).Zum Ändern des manager Passworts kann der Befehl /kolab/bin/kolabpasswdgenutzt werden.Ein Administrator ist berechtigt folgende Aufgaben durchzuführen: ➔ Hinzufügen, Ändern und Löschen von Administratoren ➔ Hinzufügen, Ändern und Löschen von Verwaltern ➔ Hinzufügen, Ändern und Löschen von Domänenverwaltern ➔ Hinzufügen, Ändern und Löschen von Benutzern ➔ Hinzufügen, Ändern und Löschen von externen Adressen ➔ Hinzufügen, Ändern und Löschen von gemeinsam genutzten Ordnern ➔ Hinzufügen, Ändern und Löschen von Verteilerlisten ➔ Konfiguration der Dienste ➔ eigenes Passwort ändern (außer manager) 30
  • 5 Kolab Server – Konfiguration und Betrieb5.2.2  VerwalterDie Rolle Verwalter ist die eines Administrators ähnlich – mit dem Unterschied, dass ein Verwalter nichtberechtigt ist, folgende Aufgaben durchzuführen: ➔ Hinzufügen, Ändern und Löschen von Administratoren ➔ Hinzufügen, Ändern und Löschen von Verwaltern ➔ Konfiguration der Dienste5.2.3  DomänenverwalterIm Vergleich zum Verwalter darf ein Domänenverwalter folgende Aufgaben nicht durchführen: ➔ Hinzufügen, Ändern und Löschen von Domänenverwaltern ➔ Hinzufügen, Ändern und Löschen von externen Adressen ➔ Hinzufügen, Ändern und Löschen von Benutzern für fremde (nicht berechtigte) Domänen5.2.4  BenutzerBenutzer werden von Administratoren, Verwaltern oder Domänenverwaltern angelegt. Abbildung 5.3zeigt das Eingabeformular zum Hinzufügen eines Benutzers im Kolab Web-Admin.Benutzer können sich selbständig über den Web-Admin anmelden und ihre persönlichen Daten ändern.In der Voreinstellung dürfen folgende Attribute jedoch nur vom Administrator, Verwalter oder Domänen-verwalter geändert werden: ● Vorname ● Nachname ● Eindeutige Identität (UID = Unique identity) ● Kontotyp ● E-Mail-Aliasnamen ● Plattenplatz des Benutzers in MegabytesAls Benutzername für den Login beim Kolab Web-Admin kann sowohl die UID also auch die primäreE-Mail-Adresse (PEM) eines Kontos genutzt werden. Die UID ist in der Voreinstellung gleichzeitig auchdie primäre E-Mail-Adresse. Diese kann aber jederzeit vom Administrator/(Domänen-)Verwalter geän-dert werden.Die primäre E-Mail-Adresse und der zugeordnete Kolab-Homeserver kann nach dem Anlegen einesKontos nicht mehr geändert werden. Was bei einer Namensänderung oder einer geplanten Migrierungeines Kontos auf einen anderen Homeserver zu tun ist, zeigt die zweite graue Box auf der übernächstenSeite. Weitere Informationen zu Kolab-Homeservern sind im Abschnitt 5.12 zu finden. 31
  • 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.3:  Anlegen eines neuen Benutzers im Kolab Web­AdminLDAP­Attribute ändernDie Sichtbarkeit und Zugriffsberechtigung der LDAP-Attribute im Web-Admin kann im Template/kolab/etc/kolab/templates/session_vars.php.template definiert werden. Wichtig:Diese LDAP-Attributseinstellungen gelten nur für den Kolab Web-Admin!Um ein Attribut zu ändern, muss dem Array $params[attribute_access] ein Element hinzuge-fügt werden. Deren möglichen Rechte sind: ➔ ro (readonly) ➔ rw (read/write) ➔ hidden (atribute removed from display) ➔ mandatory (read/write and must not be empty)Alle nicht im o. g. Array angegeben Attribute sind auf den voreingestellten Wert rw definiert. Ein Bei-spiel, wie nur die Attribute „firstname“ und „lastname“ auf „nur lesbar“ gesetzt werden: $params[attribute_access] = array(firstname=>ro,lastname=>ro);Um die Änderung in dem Template wirksam werden zu lassen, muss anschließend der Befehl/kolab/sbin/kolabconf aufgerufen werden (vgl. Abschnitt 2.4). 32
  • 5 Kolab Server – Konfiguration und Betrieb Wie findet man den Kolab­Homeserver zu einem bestimmten E­Mail­Konto? ...mit den Befehlen listusers und showuser: kolab listusers|grep user -> user1@example.com user2@example.com user3@example.com kolab showuser user1@example.com|grep -i kolabhome -> kolabHomeServer: kolab2.example.com Das Postfach des Benutzers user1@example.com befindet sich also auf kolab2.example.com. Lösungsalternative: Mit dem Befehl /kolab/sbin/slapcat lässt sich der vollständige Inhalt des Verzeichnisdienstes ausgeben und kann anschließend nach dem bestimmten E-Mail-Konto durch- sucht werden. Was muss man tun, wenn der Name (und damit die primäre E­Mail­Adresse) eines Benutzers sich  ändert (z. B. durch Heirat oder Scheidung)?  Wie lässt sich ein Benutzer auf einen anderen Kolab­Server migrieren? Der Name kann problemlos von einem Administrator/Verwalter geändert werden. Die primäre E- Mail-Adresse kann nach dem Anlegen eines Kontos allerdings nicht mehr bearbeitet werden. Die einfachste Lösung wäre, eine neue Alias-E-Mail-Adresse einzutragen und die UID auf einen neuen Benutzernamen (z. B. ebenfalls die neue Alias-Adresse) zu ändern. Alternativ müsste ein neues Benutzerkonto (mit neuem Nachnamen und primärer E-Mail-Adresse) auf dem (neuen) Kolab Server anlegt und alle alten Daten des Benutzers in das neue Konto kopiert werden. Diese Variante ist auch für das vollständige migrieren eines Benutzers auf einen anderen Kolab-Homeserver geeignet. Eine aktuelle Anleitung ist in folgender Datei (im Kolab CVS) enthal- ten: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/raw-howtos/move-rename-user.txt5.3  KontotypenZu jedem neu angelegten Benutzer muss einer der vier Kontotypen ausgewählt werden: 1. Benutzerkonto (voreingestellt) Dies ist der meist gebräuchliche Kontotyp. Die E-Mail-Adresse ist von außen erreichbar und der Benutzer ist im LDAP-Adressbuch sichtbar. Speicherort: Base-DN (z. B.: dc=example, dc=com) 2. Internes Benutzerkonto Dieser Kontotyp ist ähnlich zu (1), mit dem Unterschied, dass die E-Mail-Adresse des Benutzers nur intern gültig ist. Das bedeutet: der Benutzer kann keine E-Mails nach außen senden oder von 33
  • 5 Kolab Server – Konfiguration und Betrieb außen empfangen. Er ist damit auch nicht im öffentlichen Kolab-Adressbuch geführt. Speicherort: unter cn=internal, Base-DN 3. Gruppenkonto Ein Gruppenkonto ist für das Arbeiten von mehreren Nutzern in einer Gruppen konzipiert. Der Name des Kontos sollte (zur besseren Übersicht) für den Titel der Arbeitsgruppe stehen. Mit- hilfe von Sieve lassen sich eingehende E-Mails an eine Kolab-Verteilerliste weiterleiten, deren Abonnenten gewissermaßen die Mitglieder der Gruppe darstellen (vgl. Abschnitt 5.5.3 und 5.5.7). Um bestimmten Benutzern zu erlauben, E-Mails mit dem Gruppenkonto zu versenden, müssen deren E-Mail-Adressen als Vertreter eingetragen werden (vgl. Abschnitt 5.5.6.). Das gemeinsame Nutzen von IMAP-Ordnern innerhalb des Gruppenkontos ist (wie beim Benutzer- konto) durch das Setzen von Zugriffsrechten für bestimmte Nutzer möglich (vgl. Abschnitt 5.10). Gruppenkonten haben bereits voreingestellt für den Benutzer calendar Schreibzugriff auf den eigenen Kalender-Ordner, um automatisch Einladungen annehmen zu können (vgl. Abschnitt 5.7.1). Speicherort: unter cn=groups, Base-DN 4. Ressourcenkonto Mit dem Kolab Server können Ressourcen (wie z. B. ein Besprechungsraum, Dienstwagen oder Beamer) verwaltet werden. Ressourcenkonten haben bereits voreingestellt für den Benutzer calendar Schreibzugriff auf den eigenen Kalender-Ordner, um automatisch Einladungen anneh- men zu können (vgl. Abschnitt 5.7.1). Speicherort: unter cn=resources, Base-DNJedes Konto braucht einen Inhaber. Insbesondere bei Gruppen- und Ressourcenkonten ist es wichtig,dass es eine zuständige Person gibt, die das Konto pflegt und z. B. von unerwünschten Nachrichtenbereinigt. Diese Person muss nicht der Systemadministrator sein; im Gegenteil: es sollte eher eine derGruppe oder der Ressource inhaltlich nahe stehende Person damit beauftragt werden.5.4  NutzerlebenszyklusAnlegen im Webinterface ➔ Der Webinterface-Code überprüft, ob die E-Mail-Adresse, die UID oder eines der Alias-Einträge mit bestehenden Nutzern, Verteilerlisten oder Adressbucheinträgen kollidiert und verweigert in diesem Fall das Anlegen. ➔ Das LDAP-Objekt im Kolab-Master wird angelegt. ➔ Replikation auf Kolab-Slaves ➔ Replikation zu allen kolabd-Prozessen ➔ kolabd auf allen Servern legen IMAP-Mailboxen an. Die INBOX wird nicht nur auf dem Kolab-Homeserver angelegt, damit IMAP-Klienten zum Lesen von freigegebenen Ordnern auch die anderen Server kontaktieren können. Auf dem Kolab-Homeserver bleiben die IMAP-ACLs auf den Standardwerten, bei Ressourcen- 34
  • 5 Kolab Server – Konfiguration und Betrieb und Gruppenkonten wird zusätzlich noch dem calendar-Benutzer Zugriff gewährt. Auf den anderen Servern wird die Lookup-Berechtigung entfernt, so dass die Mailbox unsicht- bar ist.Umbenennen im Webinterface ➔ Der Webinterface-Code überprüft, ob der umzubenennende Benutzer ein Mitglied einer Vertei- lerliste ist und passt diese ggf. an. ➔ Das LDAP-Objekt im Kolab-Master wird umbenannt. ➔ Replikation auf Kolab-Slaves ➔ Da die primäre E-Mail-Adresse nicht geändert werden kann, müssen keine weiteren Änderungen durchgeführt werden.Löschen im Webinterface ➔ Der Webinterface-Code überprüft, ob der zu löschende Benutzer ein Mitglied einer Verteilerliste ist. Ist er das einzige Mitglied wird die Löschung verweigert, ansonsten wird der Benutzer aus der Verteilerliste entfernt. ➔ Das LDAP-Objekt kolabInetOrgPerson im Kolab-Master erhält kolabDeleteflag-Einträge für den Master-Server und alle Slave-Server, z.B.: kolabDeleteflag: kolab-master.example.com kolabDeleteflag: kolab-slave1.example.com kolabDeleteflag: kolab-slave2.example.com ➔ Replikation auf Kolab-Slaves ➔ Replikation zu allen kolabd-Prozessen ➔ kolabd auf allen Slaves löschen die lokalen IMAP-Mailboxen und entfernen danach ihren kolab- Deleteflag-Eintrag im LDAP des Kolab-Masters. ➔ Replikation zum kolabd-Prozess auf dem Master ➔ Wenn der kolabd auf dem Master feststellt, dass nur noch der eigene kolabDeleteflag-Eintrag vorhanden ist, löscht er die lokalen IMAP-Mailboxen, die Einträge im Kolab-uid-Cache und Mailbox-Quota-Cache und das Benutzerobjekt. Wenn die Kolab-Server in einem existierenden Verzeichnisdienst eingebunden werden, ist es oft sinnvoll, wenn der kolabd nicht das vollständige Objekt löscht, sondern nur die kolabspezifi- schen Teile. Hierzu muss in der kolab.conf ein Eintrag kolab_remove_objectclass : 1 ergänzt werden. Falls noch weitere Attribute entfernt werden sollen, können diese zusätzlich mit der Konfigurationsoption kolab_remove_attributes angegeben werden, z.B.: kolab_remove_objectclass : 1 kolab_remove_attributes : mail ou 35
  • 5 Kolab Server – Konfiguration und Betrieb5.5  E­MailDer nachfolgende Abschnitt beschreibt, wie der E-Mail-Betrieb auf dem Kolab Server funktioniert undan welchen Stellen der Administrator diesen Betrieb konfigurieren kann.5.5.1  Die IMAP Spool StrukturDer Cyrus IMAP-Server speichert alle E-Mails als einzelne Dateien in seinem Spool-Verzeichnis, dasbei einer typischen Kolab-Installation unter /kolab/var/imapd/spool liegt. Zur übersichtlicherenVerwaltung bei sehr vielen Nutzern, verwendet der Kolab Server (seit Version 2.1) die Optionhashimapspool: yes. Danach folgt die Struktur des Spool-Verzeichnisses dem Muster: .../spool/domain/e/example.com/m/user/meier/[Ordner/...]Die Domänen und Benutzer liegen in Verzeichnissen, die ihren jeweiligen Anfangsbuchstaben entspre-chen: in dem o. g. Beispiel liegt also das Verzeichnis für example.com in dem Verzeichnis e. Im Unter-schied dazu werden Gruppenkonten unter ../user/<Gruppenname> und Ressourcenkonten unter../user/<Ressourcenname> gespeichert.Das eigentliche Benutzer-Verzeichnis entspricht der jeweiligen IMAP-Inbox, alle Unterverzeichnisseentsprechen den IMAP-Unterordnern. Die Ordner enthalten jeweils Dateien, deren Name eine Zahlgefolgt von einem Punkt ist. Diese Dateien enthalten die eigentlichen E-Mails. Im gleichen Ordnerbefinden sich die drei Dateien cyrus.cache, cyrus.header und cyrus.index, die bestimmte Metainforma-tionen der Nachrichten speichern.Mit diesen Kenntnissen kann der Administrator leicht E-Mails eines bestimmten Anwenders im Backupfinden. Die unter /kolab/var/imapd/log liegenden Logdateien bieten zusätzliche Informationen,wann aus welchen Postfächern E-Mails gelöscht wurden.5.5.2  Der Weg einer E­MailTrifft eine E-Mail am Kolab-Server ein, durchläuft sie verschiedenen Komponenten des Servers. DieserWeg einer E-Mail – vom SMTP-Eingangsserver bis in das IMAP-Ordner des Kolab-Nutzers – wird inAbbildung 5.4 veranschaulicht und in den folgenden Schritten erläutert: 1. Die E-Mail wird von Postfix auf dem SMTP-Port 25 entgegengenommen. 2. Postfix konsultiert den kolab_policy (/kolab/etc/kolab/kolab_smtpdpolicy). Dieser überprüft z. B., ob der Sender berechtigt ist an die adressierte Kolab Verteilerliste zu schreiben. 3. Postfix übergibt anschließend die Nachricht an den kolabfilter (/kolab/var/kolab-filter /scripts/kolabfilter.php). Handelt es sich bei der Empfänger-Adresse um eine Vertei- lerliste oder eine Kolab Alias-Adresse, so wird vorher die Adresse in die primäre E-Mail- Adresse aufgelöst. Bei einer Verteilerliste existiert anschließend weiterhin noch eine E-Mail, jedoch mit allen einzelnen Empfänger-Adressen der Listenmitglieder. 4. Nachdem kolabfilter seine Aufgabe beendet hat, übergibt er die Mail per SMTP an Postfix (Port 10025). 36
  • 5 Kolab Server – Konfiguration und Betrieb 5. Sofern E-Mail-Scanning mit amavisd-new aktiviert ist, wird die Nachricht von Postfix über SMTP an amavisd-new (Port 10025) zugestellt (Ist amavisd-new deaktiviert, wird mit Schritt 9 fortgesetzt.) Amavisd-new filtert die Mail zunächst nach unerwünschten Absendern und nicht zugelassenen Anhängen, ... 6. ... bevor amavisd-new die Nachricht von ClamAV auf Viren... 7. ... und anschließend von SpamAssassin auf Spam überprüfen lässt. 8. Nachdem die E-Mail als harmlos befunden wurde, wird sie per SMTP an Postfix an den Port 10026 übergeben. 9. Postfix stellt die gefilterte Nachricht an den kolabmailboxfilter (/kolab/var/kolab- filter /scripts/kolabmailboxfilter.php) zu. Bei einer Nachrichten an mehrere Empfänger werden daraus vorher mehrere Nachrichten mit jeweils nur einem Empfänger (aufgrund der Postfix-Voreinstellung: local_destination_recipient_limit=1). Der kolabmailboxfilter übergibt die E-Mail an den LMTP-Port 2003, vgl. /kolab/lib/php/Kolab/Filter/ kolabmailtransport.php. 10. Auf Port 2003 lauscht der Cyrus LMTPD, der die Nachricht entgegen nimmt, ... 11. ... sofern vorhanden, ein aktiviertes Sieve-Skript ausführt (andernfalls wird dieser Schritt igno- riert) ... 12. ... und die Nachricht in den entsprechenden IMAP-Benutzerordner ausliefert. 37
  • 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.4: Der Weg einer E­Mail im Kolab Server 38
  • 5 Kolab Server – Konfiguration und Betrieb5.5.3  WeiterleitungEin Benutzer ist berechtigt eine E-Mail-Weiterleitung an jede beliebige E-Mail-Adresse einzurichten.Die Aktivierung kann vom Benutzer selbständig im Kolab Web-Admin (innerhalb seiner eigenen Benut-zereinstellungen) erfolgen. Es besteht die Möglichkeit Kopien der weitergeleiteten E-Mails auf demKolab-Server zu belassen.5.5.4  AbwesenheitsbenachrichtigungEin Benutzer kann in seiner Abwesenheit das automatische Versenden von Antworten auf eingehende E-Mails aktivieren. Die nötigen Einstellungen können innerhalb der Web-Admin-Benutzereinstellungenvorgenommen werden (vgl. Abbildung 5.5). Abbildung 5.5: Einstellungen für Abwesenheitsbenachrichtigungen im Kolab Web­AdminAnmerkung zum erneuten Benachrichtigungsversand: Die Einstellung in obiger Abbildung (7 Tage)bedeutet, dass das Senden einer Abwesenheitsbenachrichtigung aktiviert wurde und falls innerhalb von 7Tagen weitere Mails desselben Absenders eingehen, nur die erste Nachricht automatisch beantwortetwird. Nach Ablauf dieser Frist wird erneut eine Abwesenheitsnachricht versandt. Dies soll unnötigen E-Mail-Verkehr vermeiden helfen.Anmerkung zu Spam-Mails: Bei Aktivierung der Option Keine Abwesenheitsbenachrichtigungen aufSpamnachrichten senden wird keine Nachricht an den Absender geschickt, wenn die E-Mail als Spamdeklariert wurde.Anmerkung zur Domain-Angabe: Sofern eine Mail-Domäne angegeben wird, bekommen nur Absenderdieser Domäne Abwesenheitsbenachrichtigungen zugesandt. Dadurch kann diese Funktion z. B. aufNachrichten einer Organisation beschränkt werden. 39
  • 5 Kolab Server – Konfiguration und Betrieb5.5.5  Serverseitige Filterung mit SieveSieve ist eine Skriptsprache, die speziell für das serverseitige Filtern von E-Mails konzipiert wurde. Diegenaue Spezifikation kann im RFC 3028 nachgelesen werden. Der Kolab Server nutzt Sieve u. a. fürWeiterleitungen und Abwesenheitsbenachrichtigungen (vgl. Abschnitt 5.5.3 und 5.5.4). Ein Benutzerkann immer nur ein Sieve-Skript zur gleichen Zeit aktiviert haben. Im Web-Admin kann aus drei vorde-finierten Sieve-Skripten – zum Verteilen, Weiterleiten und Verschicken von Abwesenheitsbenachrichti-gungen (vgl. vorhergehende Abschnitte) – ausgewählt werden.Manchmal kann es nützlich sein, ein selbst erstelltes Sieve-Skript mit mehreren unterschiedlichen Filter-regeln zu definieren. Ein Weg das fertige Skript hochzuladen und zu aktivieren ist sieveshell. Es ist zubeachten, dass sieveshell eine unverschlüsselte Verbindung nutzt. Es wird daher dringendst empfohlensieveshell nur direkt auf dem Kolab- Server oder über eine verschlüsselte Netzwerkverbindung auszu-führen.Starten von sieveshell (das manager-Passwort wird dafür benötigt):/kolab/bin/sieveshell --user=user@example.com --authname=manager localhostDer Befehl muss als root ausgeführt werden, sofern das Sieve-Skript für eine andere Person gesetzt wer-den soll.Mit nachfolgenden sieveshell-Befehlen lassen sich alle Sieve-Skripte des Nutzers auf dem Server anzei-gen (list), das Skrip hochladen (put) und aktivieren (activate) und schließlich sieveshell wiederbeenden (quit): > list > put example.siv > activate example.siv > quitMit help lassen sich alle sieveshell-Befehle mit einer kurzen Erklärung auflisten.Um eintreffende E-Mails nicht alle im zentralen Posteingang des Benutzers zu haben, ist es mit Sievemöglich diese Nachrichten bereits serverseitig in bestimmte IMAP-Ordner einzusortieren (nützlich z. B.um E-Mails aus verschiedenen Mailinglisten automatisch in bestimmte Unterordner verschieben zu las-sen). Das nachfolgende Sieve-Skript-Beispiel demonstriert diesen Fall, wobei Sieve zusätzlich Abwesen-heitsbenachrichtigungen nur an Absender einer Mail-Domain sendet: require "vacation"; require "fileinto"; if allof (not header :contains "X-Spam-Flag" "YES", address :domain :contains "From" "example.com" ) { vacation :addresses [ "usera@example.com", "mr.a@example.org" ] :days 7 text: Ich bin bis 01.12.2007 abwesend. In dringenden Fällen nehmen Sie bitte mit <Urlaubsvertretung> Kontakt auf. E-Mail: <E-Mail-Adresse der Urlaubsvertretung> Telefon: +49 711 1111 11 Fax: +49 711 1111 12 40
  • 5 Kolab Server – Konfiguration und Betrieb Mit freundlichen Grüßen, Max Mustermann ; } if header :contains ["X-Kolab-Scheduling-Message"] ["FALSE"] { fileinto "INBOX/incoming"; } if header :contains ["List-Id"] ["list.example.com"] { fileinto "INBOX/list"; stop; }Sieve-Skripte eignen sich auch gut zum Ausfiltern von Spam-Nachrichten (vgl. Abschnitt 5.5.9).Eine ausführliche Beschreibung von Sieve, dessen Befehle und Syntax sowie weiterführenden Beispie-len ist in diesem deutschsprachigen Artikel1 zu finden.5.5.6  E­Mail­VertreterWenn ein Benutzer einen Vertreter bestimmt, kann dieser Vertreter mit der E-Mail-Adresse des Benut-zers Nachrichten versenden. Dies ist dann hilfreich, wenn der Vertreter beispielsweise den Kalender desBenutzers verwalten darf und z. B. der Sekretär im Namen seines Chefs Einladungen verschicken kann.Vertreter dürfen sowohl für Benutzerkonten als auch für Gruppen- oder Ressourcenkonten definiert wer-den.Es können nur Kolab-Nutzer als Vertreter bestimmt werden (aufgrund der Nachrichtenfilterregelung –vgl. Abschnitt 5.5.12). Ein externer Nutzer kann kein Vertreter sein. Das Bestimmen mehrerer Vertreterist möglich.Ein Benutzer kann seine Vertretung mit dem Eintragen der Vertreter-E-Mail-Adresse(n) innerhalb seinerWeb-Admin-Benutzereinstellungen aktivieren.Anmerkung: Wenn ein Vertreter im Namen des Benutzers Einladungen aussprechen können soll, müssendem Vertreter auch Schreibrechte für den Kalenderordner des Benutzers erteilt werden. In KDE Kontactz. B. kann der Benutzer dies unter Kontexmenü Kalender → Einstellungen → Zugriffskontrolle einstel-len. Falls der Kalenderordner ausgeblendet ist, vorher unter Einstellungen → Kontact einrichten... →E-Mail → Diverses → Arbeitsgruppen → Arbeitsgruppenordner ausblenden das Häkchen deaktivieren.Alternativ kann der Rechneradministrator mit dem cyradm-Kommando setaclmailbox die nötigenRechte setzen2.Im Kolab-Klient des Vertreters muss entsprechend eine neue Identität eingerichtet werden. Die bisheri-gen SMTP-Einstellungen des Vertreters müssen für diese neue Identität nicht verändert werden.1 http://www.holtmann.org/email/sieve/ [Abruf: 07.12.2007]2 http://www.oreilly.com/catalog/mimap/chapter/ch09.html#98759 [Abruf: 07.12.2007] 41
  • 5 Kolab Server – Konfiguration und Betrieb5.5.7  VerteilerlistenEine Verteilerliste wird zum Verteilen von E-Mails an alle eingetragene Mitglieder dieser Liste verwen-det und kann zum Setzen von Rechten verwendet werden. Jede Verteilerliste besitzt eine E-Mail-Adressevon der eintreffende E-Mails an alle Mitglieder der Liste weitergeleitet werden. Im Unterschied zu Grup-penkonten (siehe Abschnitt 5.3) können in Verteilerlisten auch externe Adressen aus dem Kolab-Adress-buch aufgenommen werden.Verteilerlisten können nur von Administratoren, Verwalter oder Domänenverwalter erstellt und verwaltetwerden. Nach dem Anlegen einer Verteilerliste ist diese sofort nutzbar. Abbildung 5.6 zeigt das Eingabe-formular im Kolab Web-Admin zum Anlegen einer neuen Verteilerliste. Bei Aktivierung der Option Ver-borgen steht eine Verteilerliste nur für authentifizierte Nutzer zur Verfügung; d. h. nur authentifizierteNutzer sind berechtigt, an diese Liste E-Mails zu senden. Die Verteilerliste wird im Status Verborgen beieiner LDAP Suche mit einer nicht-authentifizierten Verbindung im Kolab-Klient nicht angezeigt.Anmerkung: Ein authentifizierter Anwender ist ein Anwender, der sich mit seinem Benutzernamen undPasswort am Kolab-Server anmelden kann. Wenn ein nicht authentifizierten Nutzer (Nicht-Kolab-Nut-zer) in eine Verteilerliste aufgenommen werden soll, muss dieser zuvor im externen Adressbuch angelegtwerden. Der Nutzer kann dadurch E-Mails, die an diese Liste gerichtet sind, empfangen. Falls die Ver-borgen-Option aktiviert ist, kann er aber keine E-Mails an diese Liste senden. Abbildung 5.6: Anlegen einer neuen Verteilerliste im Web­Admin 42
  • 5 Kolab Server – Konfiguration und Betrieb5.5.8  Virenfilter­KonfigurationDer Kolab Server nutzt nach der Installation standardmäßig den Virenscanner amavisd-new3 in Verbin-dung mit Clam AntiVirus4. Im folgenden Abschnitt werden diese beiden Werkzeuge erläutert.Amavisd­new Amavisd-new bildet im Kolab Server die Schnittstelle zwischen Postfix auf der einen Seite sowieSpamAssassin und ClamAV auf der anderen. Amavisd-new ist der Nachfolger von AMaViS (= A MailVirus Scanner). Amavisd­new im Kolab Server 2.2 ➔ Template: /kolab/etc/kolab/templates/amavisd.conf.template ➔ Konfigurationsdatei: /kolab/etc/amavisd/amavisd.conf ➔ Logdatei: /kolab/var/amavisd/amavisd.log ➔ Quarantäne-Verzeichnis: /kolab/var/amavisd/virusmails ➔ Start-Kommandos: /kolab/bin/openpkg rc amavisd {start|stop|status| restart}Abbildung 5.5.2 auf Seite 38 veranschaulicht die Arbeitsweise von amavisd-new:Eine bei Postfix eintreffende E-Mail wird in Schritt 5 der Abbildung an amavisd-new (an Port 10024)übergeben. Amavisd-new filtert die Nachricht zunächst nach unerwünschten Absendern und nicht zuge-lassenen Anhängen und ruft zur Virenprüfung ClamAV [6] und anschließend (wenn die Nachricht viren-frei ist) SpamAssassin [7] auf. Wenn die E-Mail als harmlos befunden wurde, übergibt amavisd-new siezurück zu Postfix an Port 10026 [8]. Andernfalls landet die Nachricht im Quarantäne-Verzeichnis (sieheKasten oben).Eine gebannte Nachricht aus dem Quarantäne-Verzeichnis kann z. B. (als Nuter kolab-r) durch /kolab/bin/cyrdeliver user@example.com < /kolab/var/amavisd/virusmails/banned-kXuJ2d3uGVCTin das Postfach eines Kolab Nutzers manuell ausgeliefert werden.Einstellungen zu den Viren-, Mail- und Spam-Filter (wie z. B. ClamAV und SpamAssassin) können überdas zentrale amavisd-Template /kolab/etc/kolab/templates/amavisd.conf.template defi-niert werden. Um Änderungen im Template wirksam werden zu lassen, muss /kolab/sbin/kolab-conf zum Generieren der Konfigurationsdatei ausgeführt (vgl. Abschnitt 2.4) und amavisd-new neugestartet (Kommando: siehe oben im Kasten) werden.3 http://www.ijs.si/software/amavisd/ [Abruf: 07.12.2007]4 http://www.clamav.net/ [Abruf: 07.12.2007] 43
  • 5 Kolab Server – Konfiguration und BetriebClamAV ClamAV ist ein Freier-Software-Virenscanner und Phishing-Filter, der nach jeder Kolab Server Installa-tion standardmäßig als primärer Scanner aktiv ist. Clamscan ist der kommandozeilenbasierte Virenscan-ner und kann z. B. auf das aktuelle Verzeichnis mit dem Befehl /kolab/bin/clamscan ausgeführtwerden. Clamscan wird automatisch dann zum Überprüfen von Viren in E-Mails eingesetzt, wenn alleanderen Virenscanner ausgefallen sind.Es ist problemlos möglich andere, auch proprietäre, Virenscanner zu installieren und diese an Stelle vonoder zusätzlich mit ClamAV auf dem Kolab Server zu nutzen. Dafür muss die ClamAV-Einstellung imamavisd-new Konfigurationstemplate editiert werden (vgl. externe Anleitung5). ClamAV im Kolab Server 2.2 ➔ Template: /kolab/etc/kolab/templates/clamd.conf.template und /kolab/etc/kolab/templates/freshclam.conf.template ➔ Konfigurationsdatei: /kolab/etc/clamav/clamd.conf und /kolab/etc/clamav/freshclam.conf ➔ Logdatei: /kolab/var/clamav/clamd.log ➔ Start-Kommandos: /kolab/bin/openpkg rc clamav {start|stop|status| restart} ➔ Update-Kommando (als kolab-r): /kolab/bin/freshclamDie Virusinformations-Datenbank wird automatisch in regelmäßigen Abständen durch einen voreinge-stellten Cronjob auf /kolab/bin/freshclam aktualisiert. Das voreingestellte Updateintervall voneiner Stunde kann im Template /kolab/etc/kolab/templates/rc.conf.template (in der Zeileclamav_update = "hourly") geändert werden. In der /etc/crontab werden die Parameterhourly und weitere definiert.ClamAV überprüft auch alle Dateien innerhalb von Archiven (z. B. *.tar.gz oder *.zip).5 http://www.activmedia.ch/groupware5.php#viren [Abruf: 07.12.2007] 44
  • 5 Kolab Server – Konfiguration und Betrieb5.5.9  Spamfilter­KonfigurationUnerwünschte Nachrichten lassen sich auf mehrere verschiedene Arten ausfiltern. Dieser Abschnitt kon-zentriert sich auf die Spamfilter-Möglichkeiten von SpamAssassin und erläutert dessen Konfiguration.SpamAssassin SpamAssassin im Kolab Server 2.2 ➔ Template: – ➔ Konfigurationsdatei: /kolab/etc/spamassassin/local.cf ➔ Logdatei: /kolab/var/spamassassin/spamassassin.log ➔ Bayes-Datenbank: /kolab/var/amavisd/.spamassassin ➔ Start-Kommandos: /kolab/bin/openpkg rc spamassassin {start|stop|status| restart} Die Kommandos gelten nur für spamd, welcher von amavisd-new nicht verwendet wird und des- halb in rc.conf.template standardmäßig abgeschaltet ist. Wird SpamAssassin über amavisd-new genutzt, gelten nur die amavisd-new-Kommandos.Nach der Installation von Kolab Server ist der Mailscanner amavisd-new so konfiguriert, dass der mitKolab ausgelieferte Spamfilter SpamAssassin aktiv ist.Die Konfiguration erfolgt in der Datei /kolab/etc/spamassassin/local.cf. Einige Funktionenvon SpamAssassin sollten hier nicht mehr benutzt werden, da sie in amavisd-new integriert sind, wiez.B. Whitelist/Blacklist, Spam-Grenzwert und Header-/Body-Änderungen. Eingestellt werden hier alsonur noch der statistische Bayes-Filter, eigene Regeln und Wertigkeiten für bestehende Regeln. DaSpamAssassin in amavisd-new integriert ist, muss nach Änderungen /kolab/etc/rc amavisd restartausgeführt werden.SpamAssassin arbeitet mit verschiedenen Tests, die je nach Ergebnis sogenannte X-Spam-Scores verge-ben. Diese Scores können positive oder negative Werte sein, je höher eine Nachricht am Ende bewertetist, desto wahrscheinlicher ist sie Spam. Ab dem voreingestellten Schwellwert für X-Spam-Score von$sa_tag_level_deflt = 3.0 (vgl. amavisd-Template) wird die Nachricht als Spam markiert.Zusätzlich zu dieser Markierung wird eine unerwünschte Nachricht in das Quarantäne-Verzeichniskopiert (aufgrund der Voreinstellung im amavisd-Template: $final_spam_destiny = D_PASS;).Sollen Spam-Mails ausschließlich in der Quarantäne (und nicht beim Empfänger) ankommen, dann istder Wert von D_PASS auf D_DISCARD umzustellen.Im Gegensatz dazu werden Spam-Nachrichten nie in das Quarantäne-Verzeichnis kopiert, wenn der o. g.X-Spam-Score auf $sa_tag_level_deflt = 999.0; gesetzt wird. In diesem Fall sollte$final_spam_destiny = D_PASS; gesetzt sein, damit die Nachrichten an die Empfänger ausgelie-fert werden.Jede als Spam bewertete E-Mail, wird ein X-Spam-Level-Feld im Header hinzugefügt. 45
  • 5 Kolab Server – Konfiguration und BetriebSpamAssassin in der Grundkonfiguration ist noch nicht sehr mächtig. Um eine höhere Trefferquote zuerreichen, muss dieser lernen was Spam ist und was nicht. Dazu muss der verwendete Bayes-Filter trai-niert werden. Nachfolgend werden drei Methoden beschrieben, wie SpamAssassin zum Spam melden(und lernen) genutzt werden kann:1. Eine Möglichkeit besteht darin einen neuen Benutzer anzulegen; z. B. spam@example.com. In sei- nem IMAP-Postfach werden zwei Unterordner erstellt – spam und nospam – mit entsprechenden Lese-/Schreibzugriffen für die gewünschten Benutzer, welche diese Ordner pflegen sollen. Diese Benutzer können nun eintreffende Spam-Mails, welche als solche nicht erkannt wurden, in den Ord- ner /user/spam/spam verschieben. Abschließend werden zwei cronjob-Einträge vorgenommen, um mit Hilfe der manuell einsortierten Spam-Nachrichten die SpamAssassin-Datenbank stündlich (hier zu jeder vollen Stunde) auf den neusten Stand zu bringen. Dazu muss in die Datei /etc/crontab folgende zwei Zeilen hinzugefügt werden (als root): 0 * * * * kolab-r /kolab/bin/sa-learn --dbpath /kolab/var/amavisd/.spamassassin --spam /kolab/var/imapd/spool/domain/e/example.com/s/user/spam/spam --ham /kolab/var/imapd/spool/domain/e/example.com/s/user/spam/nospam Anmerkung: Eine effektive Methode, um SpamAssassin neuen Spam beizubringen, ist eine „Spam- Falle“. Dazu kann die oben angelegte spam@example.com Adresse in diversen spamverdächtigen Internetseiten veröffentlicht/eingetragen werden. Nach kurzer Zeit werden so kontinuierlich neue Spam-Mails eintreffen, die sich gut zum Spam-Erlernen eignen.2. Methode (1) lässt sich auch ohne der Freigabe von IMAP-Ordner realisieren: Um Spam-E-Mails zu melden, leiten Benutzer unerwünschte Nachrichten einfach an die Adresse spam@example.com weiter. Der Posteingang dieses Kontos kann so vollständig zum Spam-Lernen genutzt werden.3. Eine weitere Variante von Methode (1), um auf einen gemeinsamen Spam-Ordner zu verzichten, ist ein lokaler IMAP-Order des Benutzers. Das sa-lern-Kommando wird dann mit cronjobs auf den lokalen Spam-Ordnern aller Benutzer ausgeführt.4. Eine andere Möglichkeit Spam zu melden besteht darin, zwei (gemeinsam genutzte) kontolose Ord- ner für den Spam-Lern-Prozess einzusetzen. Die angelegten Spam-/Nicht-Spam-Ordner liegen auf gleicher Ebene wie die Benutzerpostfächer (im Spool-Verzeichnis). Diese Möglichkeit wird jedoch aus Gründen der Instabilität von kontolosen Ordnern nicht empfoh- len (vgl. Abschnitt 5.10.2). 46
  • 5 Kolab Server – Konfiguration und BetriebNachdem SpamAssassin die ausgefilterten Spam-Mails gelernt hat, können diese E-Mails theoretischdirekt im Anschluss des Lern-Durchlaufs gelöscht werden. Ein manuelles Löschen der Mails hat aberden 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 mussbeachtet 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/155.5.10  E­Mail­DomänenDer Kolab Server kann mehrere E-Mail-Domänen verwalten (er ist Multi-Domain-fähig). Über denKolab Web-Admin in der Rubrik Dienste lassen sich Mail-Domänen hinzufügen oder entfernen (vgl.Abbildung 5.7). Abbildung 5.7: Hinzufügen einer weiteren E­Mail­Domäne im Web­Admin5.5.11  Administrative E­Mail­AdressenFü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: ➔ hostmaster@yourdomain.tld ➔ postmaster@yourdomain.tld ➔ MAILER-DAEMON@yourdomain.tld ➔ abuse@yourdomain.tld und ➔ virusalert@yourdomain.tld.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
  • 5 Kolab Server – Konfiguration und Betrieb5.5.12  SicherheitseinstellungenPrivilegierte NetzwerkeAls privilegierte Netzwerke bezeichnet man solche Netzwerke, die Nachrichten über nicht-authentifi-zierte SMTP-Verbindungen an den Kolab Server verschicken dürfen. Voreingestellt werden automatischalle 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-authentifiziertesSMTP) empfangen kann, muss die Option Nachrichten aus dem Internet akzeptieren im Web-Adminunter Dienste aktiviert werden. Wenn diese Option ausgeschaltet ist, werden E-Mails nur von SMTP-Servern aus den privilegierten Netzwerken (oder mit Authentifizierung) angenommen.SMTP­Smarthost/RelayhostAls SMTP-Smarthost oder -Relayhost wird ein Mailserver bezeichnet, der E-Mails von einem Senderempfängt und an einen bestimmten Host weiterleitet. Bei Kolab spielt so ein Smarthost eine Rolle, wennz. 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 KolabWeb-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 KolabServers im Web-Admin (Rubrik Dienste). Abbildung 5.8: Die Voreinstellungen des Nachrichtenfilters im Kolab Web­Admin. Sofern mindestens eine der beiden oberen Prüf­Optionen aktiviert ist und  für eine Nachricht fehlschlägt, wird die darunter ausgewählte Maßnahme durchgeführt.Das Diagramm in Abbildung 5.9 veranschaulicht den Ablauf, wie eine E-Mail im Kolab Server gefiltertwerden sollte. Abhängig von der Verbindungsart und der (unter Abb. 5.8 aktivierten) Filter- und Über- 48
  • 5 Kolab Server – Konfiguration und Betriebprü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 Zukunftvon Kolab geplant ist (SOLL-Zustand). Der IST-Zustand in Kolab Server 2.2 beta2 ist noch so: DerKolab Server prüft an der im Diagramm mit * markierten Stelle nicht, ob die Sender-Header mit demSMTP-Sender übereinstimmt, sondern ob die Sender-Header eine lokale Adresse ist. 49
  • 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.9: Das Filtern von E­Mails im Kolab Server 50
  • 5 Kolab Server – Konfiguration und Betrieb5.6  AdressbuchDas Kolab Adressbuch ist ein öffentliches Adressbuch und wird vom Verzeichnisdienst des Kolab-Serverbereitgestellt. 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 essich hierbei um Nicht-Kolab-Nutzer handelt. Diese externen Adressen werden im Verzeichnis auf demKolab-Server gespeichert.Verwalten von externen AdressenDie 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. Abbildung 5.10: Das Hinzufügen einer externen Adresse ins Adressbuch (im Kolab Web­Admin) 51
  • 5 Kolab Server – Konfiguration und Betrieb5.7  Kalender5.7.1  EinladungenDer 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 eintreffendenEinladungen umgegangen werden soll. Dabei gibt es fünf Möglichkeiten: 1. Immer annehmen Einladungen werden stets automatisch angenommen und in den Kalender bzw. in die Frei/Belegt-Liste des Eingeladenen eingetragen. 2. Immer ablehnen Einladungen werden stets automatisch abgelehnt. 3. Ablehnen im Konfliktfall Einladungen werden bei Terminkollisionen abgelehnt, andernfalls automatisch angenommen. 4. Im Konfliktfall manuell bearbeiten Einladungen 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 Verzeichnisdienstgespeichert sind (also alle primären und Alias-E-Mail-Adressen der Kolab-Konten, alle Adressen derVerteilerlisten 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 einseparates Eingabefeld eingetragen werden (vgl. Abbildung 5.11). Abbildung 5.11: Das Setzen der Einladungsrichtlinien im Web­Admin für alle Benutzer  mit Ausnahmebehandlung für user1Beim 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 wirdgeprü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 anfrüherer Stelle stehend) eingetragen wurde. Der PHP-Quellcode zu dieser Überprüfung der Einladungs- 52
  • 5 Kolab Server – Konfiguration und Betriebregelungen 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 Benutzercalendar 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/Belegt­ListenFrei/Belegt-Listen werden zur Organisation von Terminen mit mehreren Teilnehmern verwendet. DieFrei/Belegt-Liste eines Benutzers enthält den Startpunkt und die Dauer aller Termine eines bestimmtenZeitraums. Für die Abstimmung eines Termins mit mehreren Teilnehmern können im Kolab-Klienten dieFrei/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-Frontendzur 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 demFree/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 derFrei/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 zudefinieren, die beim Erzeugen der Frei/Belegt-Listen berücksichtigt werden sollen. 53
  • 5 Kolab Server – Konfiguration und Betrieb Abbildung 5.12: Der Frei/Belegt­Viewer von Kolab Server 2.2 beta25.8  NotizenEin 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 FormatSpecification zu finden (Link im Anhang A)5.9  AufgabenEin Nutzer kann sich private Aufgaben anlegen und diese auf dem Kolab-Server speichern. Aufgabenkö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 demKolab-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
  • 5 Kolab Server – Konfiguration und Betrieb5.10  Gemeinsames Nutzen von IMAP­OrdnernIMAP-Ordner können gleichzeitig von mehreren Benutzern genutzt werden. Dies lässt sich über zweiunterschiedliche 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 vergebenwerden. Es ist möglich verschiedenen UIDs unterschiedliche Berechtigungen zuzuweisen. Der Zugangzu den freigegebenen bzw. kontolosen Ordnern wird über die Cyrus-ACL-Einstellungen geregelt.5.10.1  Freigegebene BenutzerordnerEin Nutzer kann in seinem Kolab-Klienten neue Unterordner innerhalb seines Kontos erzeugen. Alterna-tiv kann der Systemadministrator mit dem Cyrus-Administrationswerkzeug /kolab/bin/cyradm unddem 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/cyradmfestgelegt werden. Auf einen Ordner können folgende vordefinierte Zugriffsrechte (ACLs) angewandtwerden: ➔ 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) ➔ k (Create mailbox) ➔ r (Read) ➔ x (Delete mailbox) ➔ s (Seen) ➔ t (Delete messages) ➔ w (Write) ➔ e (Perform) ➔ i (Insert) ➔ a (Administer) ➔ p (Post)Weitergehende Informationen zu den genauen Bedeutungen der Zugriffsrechte sind auf der Manual-Seitevon cyradm (unter dem Befehl sam) zu finden: /kolab/bin/openpkg man cyradm. 55
  • 5 Kolab Server – Konfiguration und Betrieb5.10.2  Gemeinsam genutzte IMAP­Ordner ohne KontoAchtung: Die Nutzung von kontolosen Ordnern wird nicht empfohlen!Grund: Viele Funktionen, die bei normalen Konten leicht funktionieren, sind bei kontolosen Ordnernnicht, 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. DerSpeicherplatz für den Ordner ist unbegrenzt, sofern keine Plattenplatzbeschränkung angegeben wird. Abbildung 5.13: Anlegen eines gemeinsam genutzten IMAP­Ordners ohne Konto im Web­Admin 56
  • 5 Kolab Server – Konfiguration und Betrieb5.11  QuotasMit dem Kolab Server können Plattenplatzbeschränkungen der Benutzerkonten verwaltet werden. Eskann ein Hardquota und ein Prozentsatz, ab dem Quotawarnungen auftreten, definiert werden (sieheunten). Die Quota-Einstellungen werden vom Kolab Web-Admin (oder einem anderen Verzeichnis-dienst-Werkzeug) gesetzt und in den Verzeichnisdienst geschrieben. Kolabd leitet diese Änderungen anden 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/cyrquotaWichtig: 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.HardquotaAdministratoren, 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-Mailsabgewiesen. Es ist dann auch nicht mehr möglich neue Daten in den betroffenen IMAP-Benutzerordnernzu speichern.QuotawarnungÜberschreitet ein Benutzer einen definierten Prozentsatz an belegten Plattenplatz, erhält er so lange eineQuotawarnung (per E-Mail und beim IMAP-Synchronisieren im Kolab-Klienten) bis sein Speicherplatzwieder unter dem Grenzwert liegt. Der Prozentsatz wird im Web-Admin-Interface unter der RubrikDienste 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 Kolab Server – Konfiguration und Betrieb5.12  Master­ und Slaveserver / HomeserverKolab 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 vorgehaltenwird. Ä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 mussbeim 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 Nutzerdatengespeichert werden (vgl. Abschnitt 5.2.4). Jeder Homeserver (egal ob Master oder Slave) kann E-Mailsdirekt annehmen, sofern dieser Server im MX-Record eingetragen ist. Zum Synchronisieren einesIMAP-Benutzerordners muss der Anwender in seinem Kolab Klienten die Adresse seines Homeserverseinrichten.Mit dem Web-Admin-Interface (in der Rubrik Dienste) können die verwendeten Kolab-Hosts verwaltetwerden, 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 zumVerzeichnisdienst besteht! Abbildung 5.14: Das Interface zum Verwalten von Kolab­Hosts (im Web­Admin)Einrichten eines neuen Slave­Servers 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
  • 5 Kolab Server – Konfiguration und Betrieb 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 start5.13  Datensicherung und ­wiederherstellungDatensicherungDieser 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) E­Mails 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
  • 5 Kolab Server – Konfiguration und Betrieb 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) OpenLDAP­Datenbank Die OpenLDAP-Datenbank sollte im LDIF-Format in einer Textdatei gesichert werden: /kolab/sbin/slapcat -l ldap_db_backup.ldif E) Kolab­Konfigurationsverzeichnis 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
  • 5 Kolab Server – Konfiguration und BetriebDatenwiederherstellungDieser Abschnitt gibt die Antwort auf die Frage: „Wie lassen sich Daten aus der Sicherung wiederherstel-len?“ A) E­Mails 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/restored@example.com" 2. E-Mails in Ordner einspielen Zurü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 aufbauen Abschließend müssen die Indizes des neuen Ordners restored wiederhergestellt werden: cyrreconstruct -f user/meier/restored@example.com 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
  • 5 Kolab Server – Konfiguration und Betrieb 4. Quota wiederherstellen Wenn 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 wiederherstellen Um 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) OpenLDAP­Datenbank Die Wiederherstellung der OpenLDAP-Datenbank nutzt die gesicherte .ldif-Datei. su – kolab mv /kolab/var/openldap/openldap-data/ backup/tmp mkdir /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
  • 5 Kolab Server – Konfiguration und Betrieb E) Kolab­Konfigurationsverzeichnis 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  DiensteIm Kolab Web-Admin lassen sich unter der Rubrik Dienste verschiedene Dienste des Kolab Serversaktivieren 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 undWebDAV ist im HTTP-Server deaktiviert. Abbildung 5.15: Web­Admin­Maske zum Ein­ und Ausschalten von Diensten 63
  • 6 Kolab­KlientenZiel dieses Kapitels ist es, einen allgemeinen Überblick über die verschiedenen Kolab-Klienten zu gebenund auf weiterführende Dokumentationen zu verweisen.6.1  KDE KontactKDE 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 zurKonfiguration von Kontact ist in der Kolab-Dokumentation Doc2 zu finden (Link im Anhang A).6.2  Microsoft OutlookUm Microsoft Outlook als Kolab Klient verwenden zu können, muss ein Outlook-Konnektor, auf demWindows-Rechner installiert sein. Es gibt zwei (proprietäre) Konnektoren für Outlook, die mit demKolab Server zusammenarbeiten [Stand: Dezember 2007]: der Toltec Connector und der KONSEC Kon-nektor. Im folgenden Abschnitt werden beide Konnektoren kurz vorgestellt und Verweise zum aktuellenHandbuch gegeben.6.2.1  Toltec ConnectorDer Toltec Connector1 ist ein proprietäres Plugin für Microsoft Outlook. Die Firma Radley NetworkTechnologies CC (Südafrika) brachte Toltec Connector 1 im Oktober 2003 auf dem Markt. Die zweiteGeneration 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-Testversionkann auf der Toltec-Website heruntergeladen werden.1 http://www.toltec.co.za [Abruf: 07.12.2007] 64
  • 6 Kolab-KlientenDie 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 KonnektorIm 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 imJuni 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 mitletzter Aktualisierung vom 18.10.2007).Weitere (aktuelle) Informationen sind im Kolab-Wiki4 zu finden.6.3  Horde WebklientHorde (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
  • Anhang66
  •  A  Weiterführende  InformationenDie offizielle Website von Kolabhttp://www.kolab.orgKolab­Wikihttp://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.Kolab­Mailinglisten ➔ 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
  • A Weiterführende InformationenKolab­CVS 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/Kolab­Issue­TrackerUm 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.Kolab­DokumentationenNeben 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)Kolab­Raw­Howtos (im CVS)Nützliche Kurzanleitungen zur Konfiguration von Kolab2, so genannte Raw-Howtos, stehen unterhttp://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
  • A Weiterführende InformationenAdministrator­Hinweise (auf dem Kolab Server)Im Verzeichnis /kolab/share/doc/ befinden sich verschiedene Hilfedateien zur Konfiguration desKolab 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 Kolab­GemeinschaftKolab ist ein Freie-Software-Produkt, bei dem jeder mithelfen kann, die Funktionalität der Software zuerweitern. Eine aktive, weltweite Gemeinschaft hat sich um Kolab herum gebildet. Für den Kontakt mitder Kolab-Gemeinschaft eignet sich am Besten die Kolab-Mailinglisten (siehe oben). 69
  • A Weiterführende InformationenA.2 Das Kolab­KonsortiumDas Kolab-Konsortium steuert die Weiterentwicklung und bietet professionelle Beratung und Supportfür die Freie Groupwarelösung Kolab. Das Kolab-Konsortium wird getragen durch folgende drei Part-nerunternehmen: Intevation GmbH Georgstraße 4 49074 Osnabrück Deutschland www.intevation.de Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner Klarälvdalens Datakonsult AB Rysktorp SE-683 92 Hagfors Sweden www.klaralvdalens-datakonsult.se Geschäftsführer: Matthias Kalle Dalheimer erfrakon PartG Nobelstraße 15 70569 Stuttgart Deutschland www.erfrakon.de Partner: Tassilo Erlewein, Achim Frank, Martin KonoldDas Produkt Kolab wurde ursprünglich im Jahre 2002 durch ein Joint Venture der drei o. g. Firmen insLeben gerufen (vgl. Abschnitt 1.2).Kontakt:Kolab-Konsortiumc/o Intevation GmbHGeorgstraße 449074 OsnabrückDeutschlandhttp://www.kolab-konsortium.de/info@kolab-konsortium.deTelefon: ++49-541-33 50 8 50 70
  •  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. E­Mail­Alias 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/Belegt­Liste 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).Home­Server / 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 IMAP­Ordner 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. Master­Server 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 E­Mail­Adresse 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. Slave­Server 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 (E­Mail­) Ein E-Mail-Vertreter darf im Namen des beauftragten Benutzers E- Mails versenden und. Vertreter werden auch als Bevollmächtigte (engl.: delegates) bezeichnet. Web­Admin 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  LicenseVersion 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 ornoncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while notbeing 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 samesense. 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 limitedto software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printedbook. 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 sayingit 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. Anymember of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the workin a way requiring permission under copyright law. 74
  • C GNU Free Documentation LicenseA "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, orwith 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 Documents overall subject (or to related matters) and contains nothingthat could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a SecondarySection may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or withrelated 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 thenotice that says that the Document is released under this License. If a section does not fit the above definition of Secondarythen it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document doesnot 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 thatsays that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text maybe 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 imagescomposed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable forinput to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made inan 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 inputformat, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designedfor 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, thematerial this License requires to appear in the title page. For works in formats which do not have any title page as such, "TitlePage" means the text near the most prominent appearance of the works 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 mentionedbelow, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a sectionwhen 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 thisLicense, 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 orcontrol the reading or further copying of the copies you make or distribute. However, you may accept compensation inexchange 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
  • C GNU Free Documentation License3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than100, and the Documents license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly andlegibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers mustalso clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words ofthe title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited tothe covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying inother 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 fromwhich 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, whenyou begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at thestated 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 ofcopies, 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 thatyou release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thuslicensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must dothese 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 Documents 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
  • C GNU Free Documentation LicenseIf the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain nomaterial copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, addtheir titles to the list of Invariant Sections in the Modified Versions license notice. These titles must be distinct from any othersection titles.You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version byvarious 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 theend of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text maybe added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the samecover, 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 toassert 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 abovefor 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 alltheir Warranty Disclaimers.The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced witha single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each suchsection 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 ofthe combined work.In the combination, you must combine any sections Entitled "History" in the various original documents, forming one sectionEntitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". Youmust 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 youfollow 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 inserta copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying ofthat document.7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or ona 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 compilations users beyond what the individual works permit. Whenthe 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 onehalf of the entire aggregate, the Documents 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 coversthat bracket the whole aggregate. 77
  • C GNU Free Documentation License8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may includetranslations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include atranslation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you alsoinclude 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. Anyother attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights underthis License. However, parties who have received copies, or rights, from you under this License will not have their licensesterminated 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 thatspecified 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 FreeSoftware 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 suitthe situation.If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel underyour choice of free software license, such as the GNU General Public License, to permit their use in free software. 78