Allgemeine-Betriebsdokumentation-KolabServer22 20080103 1.0

AllgemeineBetriebsdokumentation
fr KolabServer2.2
Version:1.0
Osnabrck,am3.Januar2008
nderungsverzeichnis
nderung Nr 1 Datum 2008-01-03 Version 1.0 Emanuel Schtze Genderte Kapitel Beschreibung der nderung Autor
Aktueller Status: Fertig gestellt
Impressum
2007IntevationGmbH
Version:1.0 Autor:EmanuelSchtze FachlicheLeitung:BernhardReiter,ThomasArendsenHein Kontakt:emanuel.schuetze@intevation.de|http://intevation.org Permissionisgrantedtocopy,distributeand/ormodifythisdocumentunderthetermsoftheGNUFreeDocumentation License,Version1.2oranylaterversionpublishedbytheFreeSoftwareFoundation;withnoInvariantSections,noFront CoverTexts,andnoBackCoverTexts.Acopyofthelicenseisincludedinthesectionentitled"GNUFreeDocumentation License". DieseKolabServerBetriebsdokumentationistunterhttp://kolab.orgerhltlich.
Inhaltsverzeichnis
Kapitel1:Einfhrung
1.1 1.2 1.3
Was ist Kolab?.................................................................................6 Entwicklungshistorie von Kolab................................................................7 Was ist neu in Kolab Server 2.2?...............................................................8
Kapitel2:DieKomponentendesKolabServers
2.1 2.2 2.3 2.4
bersicht.......................................................................................9 Interaktion der Komponenten.................................................................11 OpenPKG.....................................................................................12 Kolabspezifische Komponenten...............................................................13
Kapitel3:KolabServerBedarfsplanung
3.1 3.2 3.3 3.4
17
Festplattenspeicher............................................................................17 Rechenleistung / Hauptspeicher...............................................................18 Verfgbarkeit.................................................................................18 Wer arbeitet mit wem?........................................................................19
Kapitel4:KolabServerVorbereitungundInstallation
4.1 4.2 4.3 4.4
20
Installationsvorbereitung......................................................................20 Installation....................................................................................22 Aktualisierung................................................................................25 Deinstallation.................................................................................27
Kapitel5:KolabServerKonfigurationundBetrieb
5.1 5.2
28
5.3 5.4 5.5
Kolab Web-Admin............................................................................28 Rollen.........................................................................................29 5.2.1 Administrator..........................................................................30 5.2.2 Verwalter..............................................................................30 5.2.3 Domnenverwalter.....................................................................30 5.2.4 Benutzer...............................................................................31 Kontotypen...................................................................................33 Nutzerlebenszyklus...........................................................................34 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
5.6 5.7
5.8 5.9 5.10
5.11 5.12 5.13 5.14
5.5.8 Virenfilter-Konfiguration..............................................................43 5.5.9 Spamfilter-Konfiguration..............................................................45 5.5.10 E-Mail-Domnen.....................................................................47 5.5.11 Administrative E-Mail-Adressen......................................................47 5.5.12 Sicherheitseinstellungen..............................................................48 Adressbuch...................................................................................51 Kalender......................................................................................52 5.7.1 Einladungen...........................................................................52 5.7.2 Frei/Belegt-Listen......................................................................53 Notizen.......................................................................................54 Aufgaben.....................................................................................54 Gemeinsames Nutzen von IMAP-Ordnern....................................................55 5.10.1 Freigegebene Benutzerordner.........................................................55 5.10.2 Gemeinsam genutzte IMAP-Ordner ohne Konto......................................56 Quotas........................................................................................57 Master- und Slaveserver / Homeserver........................................................58 Datensicherung und -wiederherstellung.......................................................59 Dienste........................................................................................63
Kapitel6:KolabKlienten
6.1 6.2
64
6.3
KDE Kontact..................................................................................64 Microsoft Outlook............................................................................64 6.2.1 Toltec Connector.......................................................................64 6.2.2 Konsec Konnektor.....................................................................65 Horde Webklient..............................................................................65
Anhang AnhangA:WeiterfhrendeInformationen
66 67
A.1 Die Kolab-Gemeinschaft......................................................................69 A.2 Das Kolab-Konsortium.......................................................................70
AnhangB:Glossar AnhangC:GNUFreeDocumentationLicense
71 74
1 Einfhrung
Kolab ist eine Freie Lsung, die Groupware-Funktionalitten bietet. Kolab spezifiziert ein Verhalten von Server und Klienten, welches als Freie Software in dem Kolab Server, dem Kolab KDE Klienten Kontact und dem Horde Webklienten 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 fr die Zusammenarbeit innerhalb einer Arbeitsgruppe konzipiert ist und die Arbeitsablufe rationalisieren und automatisieren soll. In der Regel besteht Groupware aus Anwendungen, die typische Organizer-Funktionen (wie Kalender, Kontakte, Aufgaben, Notizen) sowie Funktionen fr den Austausch von E-Mails und die gemeinsame Bearbeitung von Dateien bereitstellen.
Die vorliegende Betriebsdokumentation konzentriert sich auf den Kolab Server und untersttzt beim Aufsetzen und Betreiben eines solchen Groupware-Servers. Diese Dokumentation richtet sich an Systemadministratoren, die Server-Anwendungen betreuen. Kenntnisse ber den Kolab Server werden nicht vorausgesetzt. Grundlegende Erfahrungen mit Server-Anwendungen sind jedoch erforderlich; wnschenswert auf GNU/Linux. Zu diesen Themen gibt es bereits zahlreiche Literatur. Ziel dieser Arbeit ist es, einen berblick ber den Kolab Server zu geben und die Fhigkeiten fr Wartung und Betrieb zu vermitteln. Es existieren sehr vielfltige Mglichkeiten und Einsatzszenarien den Kolab Server zu nutzen, die anhand einiger konkreter Beispiele dargestellt werden. Auf die dabei getroffenen Annahmen wird jeweils hingewiesen.
1 Einfhrung
Diese Betriebsdokumentation bezieht sich auf die OpenPKG-Variante von Kolab Server 2.2 (vgl. Abschnitt 2.3). Da Version 2.2.0 zum Recherchezeitpunkt noch nicht erschienen ist, wurde Kolab Server 2.2-beta2 genutzt. Gliederung

Kapitel 1 und 2 geben einen allgemeinen berblick ber den Kolab Server und dessen Komponenten. Im 3. Kapitel wird anhand von grundstzlichen Leitfragen die Bedarfsplanung fr 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 ausfhrlich die wichtigsten Einstellmglichkeiten am Kolab Server und gibt praktische Hinweise fr die eigene Konfiguration. Einen allgemeiner berblick ber die verfgbaren Kolab-Klienten stellt Kapitel 6 dar. Weiterfhrende Quellen mit Kontaktmglichkeiten zur Kolab-Gemeinschaft und dem KolabKonsortium sowie ein Glossar sind im Anhang A und B zu finden.
Konventionen Der leichten Lesbarkeit wegen wird oft nur eine Form verwendet meist die mnnliche gemeint sind bei Personen jedoch immer Mnner und Frauen, wie bei Nutzern und Nutzerinnen. Das Produkt Kolab Server wird in dieser Dokumentation stets ohne Bindestrich geschrieben. Handelt es sich um eine beliebige Implementation oder eine spezielle Installation des Produkts Kolab Server, so wird Kolab-Server mit Bindestrich verwendet.
1.1 WasistKolab?
Kolab ist in erster Linie ein Konzept, wie mit Freier Software eine skalierbare, stabile und sichere Groupware-Lsung umgesetzt werden kann. In dieser Idee unterscheidet sich Kolab bereits von vielen anderen Produkten, welche Kommunikation und Arbeitsgruppen untersttzen mchten. Ein Nutzen von Kolab entsteht aus der Kombination mehrerer Softwarekomponenten. Fr Anwender ist allein der Nutzen entscheidend. Als Administrator ist es jedoch ntzlich die Zusammenhnge zu kennen; sie sind fr einen tglichen Betrieb zwar nicht direkt erforderlich, erlauben aber oft, den Nutzen der Lsung fr alle Beteiligten zu erhhen. Bei Kolab entsteht der Nutzen im Zusammenspiel von Klient und Kolab-Server. Es werden GroupwareFunktionen zum Austauschen von E-Mails, Freigeben und Bearbeiten von Dateien sowie Verwalten von Kontakten, Terminen, Aufgaben und Notizen auf Basis offener Standards geboten. Nachfolgend einige wesentliche Eigenschaften des Kolab Servers:
1 Einfhrung

Nutzerdaten werden in Ordnern auf dem Server gespeichert. Ein Ordner enthlt 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 untersttzen die Terminfindung. Einladungen knnen automatisch bearbeitet werden. Verschiedene Verzeichnisdienste knnen genutzt werden. Untersttzt IMAP, POP3, SMTP (optional verschlsselt); damit fr jeden Mail-Klient geeignet. Vollwertige Kolab-Klienten knnen 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 Kalendereintrge von Arbeitsplatz und Laptop eines Nutzers synchronisieren und mit anderen Benutzern austauschen. Alles was dazu ntig ist, ist ein Kolabkompatibler Klient. Fr die gngigsten Konfigurationsmglichkeiten des Kolab Servers wird ein Webinterface zur Verfgung gestellt. Zur Speicherung der Daten dient der Verzeichnisdienst. Neben dem offiziellen Kolab Server sowie den Kolab-Klienten Kontact und Horde gibt es bereits weitere Entwicklungen von Drittanbietern1: Der Univention Groupware Server (UGS) als ein weiterer Kolab-Server sowie die Outlook-Konnektoren von Toltec und Konsec (vgl. Kapitel 6), die Microsoft Outlook Groupware-Funktionalitten eines Kolab Klienten ermglichen. Weiter befinden sich in der Entwicklung: das Thunderbird Plugin Sync Kolab2 und der Bynary Insight Connector3 fr MS Outlook.
1.2 EntwicklungshistorievonKolab
Die Entwicklung von Kolab, geht auf eine Ausschreibung des deutschen Bundesamtes fr Sicherheit in der Informationstechnik (BSI) zurck. Ziel der Ausschreibung war die Bereitstellung einer GroupwareLsung, welche eine heterogene Klientenlandschaft bedienen kann, fr den eigenen Bedarf. Im Oktober 2002 wurde die Ausschreibung von drei Unternehmen gewonnen, die das Projekt im Juli 2003 erfolgreich zum Abschluss brachten. Die Intevation GmbH (Osnabrck) hatte die Projektleitung, die Erfrakon PartG (Stuttgart) war fr die Entwicklung des Kolab Servers sowie das technischen Konzept verantwortlich und Klarlvdalens Datakonsult AB (Schweden) realisierte den KDE-basierten Kolab-Klienten Kontact. Der Auftrag trug den Kodenamen Kroupware. Das Konzept und die Software, welche u. a. aus diesem Auftrag entstand, heit Kolab. Entsprechend heien die Softwarekomponenten Kolab Server sowie KDE Kolab Client. Am 17. Juli 2003 erschien die erste stabile Version von Kolab1: Kolab Server 1.0 und KDE Kolab Client 1.0. Im Jahre 2004 wurde Kolab einer Generalberholung unterzogen. Um Groupware-Daten plattformbergreifend zugreifbar zu machen, wird in Kolab2 das Kolab XML Format eingefhrt. Im Juni 2005 wurde Kolab Server 2.0 verffentlicht, einige Monate nachdem Kolab Server 2 bereits im produktiven Einsatz
1 2 3
Stand: Dezember 2007 http://www.gargan.org/extensions/synckolab.html [Abruf: 07.12.2007] http://www.bynari.net/ [Abruf: 07.12.2007]
1 Einfhrung
war. Es folgte das Kolab Server 2.1 Release im Mai 2007. Kolab Server 2.2 ist aktuell in der Entwicklung. Das stabile Release ist fr Anfang 2008 geplant.
1.3 WasistneuinKolabServer2.2?
Nachfolgend eine Auflistung der wesentlichen Neuerungen in Kolab Server 2.2 gegenber 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 ntig. Upgrade des Cyrus IMAP Server auf Version 2.3. Damit sind ebenfalls einige (nicht alle) kolabspezifischen nderungen berflssig geworden. Strukturelle Verbesserungen von verschiedenen Serverkomponenten Verbesserungen, Fehlerbeseitigung und aktualisierte Softwarekomponenten. Dazu gehrt eine aktualisierte OpenPKG-Umgebung mit einer verbesserten Untersttzung fr aktuelle Betriebssysteme und Hardware.
2 DieKomponentendes KolabServers
Dieses Kapitel gibt eine bersicht ber die im Kolab Server verwendeten Komponenten, erklrt deren Zusammenspiel und beschreibt im Detail die Komponente OpenPKG sowie die kolabspezifischen Kernkomponenten kolabd und kolabconf.
2.1 bersicht
Der Kolab Server 2.2 benutzt zahlreiche Freie-Software-Produkte. Nachfolgend eine Auswahl der wichtigsten Serverkomponenten: EMail/Verzeichnisdienst
Postfix Postfix ist ein freier Mail Transfer Agent (MTA), der den Transport und die Verteilung von Nachrichten bernimmt.
URL: www.postfix.org Dokumentation: http://www.postfix.org/documentation.html
Cyrus IMAP Daemon Der Cyrus-IMAP-Server ist ein skalierbarer Mail-Server und bietet Zugriff auf E-Mails ber das IMAP-Protokoll (Internet Message Access Protocol). Zustzlich 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
2 Die Komponenten des Kolab Servers
OpenLDAP OpenLDAP ist ein Verzeichnisdienst, der sich ber das Protokoll LDAP (Lightweight Directory Access Protocol) abfragen lsst.
URL: http://www.openldap.org Dokumentation: http://www.openldap.org/doc/index.html Manual Pages: http://www.openldap.org/software/man.cgi
SpamundVirenscanner
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 berprfung 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 berprfung und Identifizierung von unerwnschten Nachrichten eingesetzt wird.
URL: http://spamassassin.apache.org Dokumentation: http://spamassassin.apache.org/doc.html
KolabWebklient
Horde Horde ist ein webbasierter Klient fr Kolab.

URL: http://horde.org Dokumentation: http://www.horde.org/documentation.php
Allgemein
Apache (HTTP-Server) Der HTTP-Server von Apache ist der meist verbreitete (freie) Webserver im Internet.
URL: http://www.apache.org/ Dokumentation: http://httpd.apache.org/docs/
Perl Perl ist eine serverseitige, plattformunabhngige 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
Die Kolab Server/OpenPKG-Version nutzt zustzlich die freie Komponente OpenPKG: OpenPKG OpenPKG ist ein Paketmanagementsystem fr Unix (basierend auf dem RPM-System) und erleichtert die Paketinstallation auf bekannten Unix-Plattformen (Linux, Solaris, FreeBSD). Weitere Informationen zu OpenPKG folgen im Abschnitt 2.3.
URL: http://www.openpkg.org Dokumentation: http://www.openpkg.org/documentation/
Der Kolab Server besteht aus weiteren spezifischen Elementen und Werkzeugen, welche die einzelnen Komponenten um Groupware-Funktionalitten und ein gemeinsames Konfigurationssystem ergnzen. Alle kolabspezifischen Komponenten, insbesondere kolabd und kolabconf, werden im Abschnitt 2.4 beschrieben.
2.2 InteraktionderKomponenten
Der Kolab-Dmon (kolabd) dient als zentrale Steuerungsinstanz des Kolab Servers. Er verwaltet die Konfigurationen der einzelnen Serverkomponenten. Abbildung 2.1 veranschaulicht die Interaktion dieser Komponenten: Die Komponenten Cyrus IMAP und Postfix authentifizieren Benutzer ber die von SASLauthd gestellten Methoden per LDAP (slapd). Der Verzeichnisdienst sorgt ber das LDAP-Protokoll auerdem fr die direkte Authentifizierung von Benutzern des Apache Webfrontends dem Kolab Web-Admin. Der Verzeichnisdienst-Slave-Server slurpd dient der Replikation und redundanten Vorhaltung der Verzeichnisdaten.
Abbildung2.1:DieInteraktionderKolabServerkomponenten
11
2.3 OpenPKG
Die Kolab Server/OpenPKG-Variante nutzt eine Schicht zwischen Anwendung und Betriebssystem, names OpenPKG1. Im Ergebnis wird fr den Anwendungsentwickler die Plattform vereinheitlicht. Was fr die Entwickler und Tester des Kolab Servers eine Erleichterung bedeutet. Betrieben werden kann der Kolab Server daher auf allen Betriebssystemen, auf denen auch OpenPKG luft (vgl. dazu die Angaben von OpenPKG). Am meisten getestet ist der Kolab Server/OpenPKG mit den verbreiten GNU/LinuxDistribution, also z. B. Debian und RedHat Enterprise. Abbildung 2.2 zeigt schematisch den Aufbau eines Kolab Servers mit OpenPKG.
Abbildung2.2:DieSchichtenbeimKolabServer/OpenPKG
OpenPKG bringt viele Komponenten selbst mit und verwaltet diese mit einer eigenen RPM-Datenbank zur Paketverwaltung. OpenPKG ist demnach von Bibliotheken auf dem eigentlichen Betriebssystem und dessen Paketverwaltung weitestgehend unabhngig. Das bringt viele Vorteile, aber auch einige Nachteile. Aus der Unabhngigkeit der Paketverwaltungssysteme voneinander folgt, 1. dass fr OpenPKG andere Kommandos bzw. Pfade existieren. 2. dass auch die Paketverwaltung ber OpenPKG-Kommandos erfolgt (z.B. /kolab/bin/openpkg rpm) und dafr OpenPKG Pakete gebraucht werden. 3. dass Konflikte um gemeinsame Ressourcen (wie Portnummern) im Blick behalten werden mssen. Welche das sind ist Abschnitt 4.1 zu entnehmen. 4. die Steuerung von Kolab Server/OpenPKG ist auf vielen Betriebssystemen gleich. OpenPKG hngt sich an einigen Punkten in das Betriebssystem ein, so werden fr Kolab Server beispielsweise die Nutzer kolab-r, kolab-n und kolab sowie ein Startskript in /etc/init.d/kolab angelegt. Um an die Anwendungen in der OpenPKG-Welt zu kommen, gibt es zwei grundstzliche Vorgehensweisen: a) direktes Aufrufen von /kolab/bin/openpkg <Kommando>, z.B. lsst 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
b) setzen der Pfade in Umgebungsvariablen MANPATH, PATH, LIBRARY_PATH usw. Die Nutzer kolab, kolab-r und kolab-n haben diese Pfade bereits gesetzt. Die Hilfeseiten (Manpages) von OpenPKG-Komponenten knnen z.B. mit: /kolab/bin/openpkg man ... oder man ... (als Benutzer kolab) aufgerufen werden. HinweisefrTechniker Die Paketverwaltung von OpenPKG ist das bekannte RPM-System in Version 4. Um selbst Pakete bauen zu knnen, sollte beachten, dass die meisten Bibliotheken statisch gelinkt werden. Wird beispielsweise db ausgetauscht, dann mssen auch die Anwendungen neu gebaut werden, welche diese Bibliothek hineingelinkt haben. OpenPKG verteilt Pakete im Quelltext, um durch die bersetzung erst auf der genauen Zielplattform ein optimales Ergebnis zu erreichen. Die Binrpakete lassen sich aber auf Systemen mit hnlicher Hardware und Betriebssystem austauschen.
2.4 KolabspezifischeKomponenten
Zu den kolabspezifischen Kernkomponenten gehren: kolabd kolabconf kolab-webadmin kolab-filter kolab-freebusy kolab-horde-framework kolab-horde-fbview kolab-ressource-handlers Der folgende Abschnitt konzentriert sich auf die Komponenten kolabd und kolabconf. Der Kolab-Dmon (kolabd) sowie kolabconf dienen als zentrale Steuerungsinstanzen des Kolab Servers. Kolabd fhrt die notwendigen Arbeiten aus, wenn ein Nutzer angelegt, gendert oder gelscht worden ist. Kolabconf verwaltet die Konfigurationen der einzelnen Serverkomponenten und erzeugt die eigentlichen Konfigurationsdateien aus Vorlagen, so genannten Templates. ndert sich etwas an den Kolab-Nutzern oder Verteilerlisten ist nur kolabd (und nicht kolabconf) fr die Bearbeitung zustndig; beispielsweise kann kolabd ein Konto auf dem Cyrus IMAPd anlegen, ndern oder lschen. Fr die Arbeit am Cyrus-Server hlt sich kolabd einen Zwischenspeicher von allen existierenden Nutzer auf der Festplatte, um den IMAPd nicht mit weiteren Anfragen zu belegen. Abbildung 2.3 veranschaulicht die Arbeitsweise von kolabd und kolabconf.
13
Abbildung2.3:ArbeitsweisedesKolabServerKonfigurationssystemsvereinfachtfreinenDienst.
Der Verzeichnisdienst OpenLDAP gibt die kolabspezifischen Einstellungen per LDAP heraus. ndern sich Einstellungen, zum Beispiel durch eine Konfiguration ber den Kolab Web-Admin, so werden automatisch neue Konfigurationsdateien erzeugt und betroffene Dienste benachrichtigt. 1. Wie in Abbildung 2.3 veranschaulicht, schreibt der Kolab Web-Admin nderungen in den Verzeichnisdienst (Schritt 1). 2. Der kolabd muss nun mitbekommen, dass sich im Verzeichnisdienst etwas gendert hat. Dies wird entweder automatisch gemacht: Dazu hngt kolabd bei OpenLDAP als Replikationsziel 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 gendert hat, ist manuell den Befehl /kolab/sbin/kolabconf ausfhren (Schritt 2 in der Abbildung gestrichelter Pfeil). 3. Anschlieend ruft kolabd die bentigten Angaben der nderungen per LDAP vom Verzeichnisdienst 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 anschlieend das entsprechende Template ein, ... 7. ... generiert daraus die passende Konfigurationsdatei und ... 8. ... informiert abschlieend den zugehrigen Dienst, der dann ggf. neu gestartet wird.
14
KonfigurationdurchTemplates Die Kolab-Komponenten werden durch Konfigurationsdateien konfiguriert, die von kolabconf aus Templates generiert werden. Am Beispiel des Postfix-Dienstes wird nun die Funktionsweise von Templates erlutert: Alle Template-Dateien liegen im Verzeichnis /kolab/etc/kolab/templates und sind an der Dateiendung .template zu erkennen. Aus dem Dateiname lsst sich erschlieen, um welche Konfiguration es sich handelt; so wird z. B. aus dem Template /kolab/etc/kolab/templates/ main.cf.template die Konfigurationsdatei /kolab/etc/postfix/main.cf fr Postfix generiert (vgl. Schritt 7 in der obigen Abbildung). In jeder Template-Datei steht zu Beginn ein Block mit Metainformationen; exemplarisch der Meta-Block von Postfix:
KOLAB_META_START TARGET=/kolab/etc/postfix/main.cf PERMISSIONS=0644 OWNERSHIP=kolab-n:kolab-r KOLAB_META_END
In diesem Abschnitt wird festgelegt wo (TARGET) und mit welchen Zugriffsrechten (PERMISSIONS und OWNERSHIP) die generierte Konfigurationsdatei im Dateisystem abgelegt wird. Nachdem die Konfigurationsdateien neu generiert wurden, informiert kolabconf die zugehrigen Dienste. Einige Dienste mssen nach nderungen an ihren Konfigurationsdateien neu gestartet werden. Welche das sind, ist in Kolab Server 2.2 beta2 noch hart im Kolab-Konfigurationssystem kodiert. Bei knftigen Kolab-Versionen soll auch diese Information in dem o. g. Metainformations-Block im Template festgelegt werden. Auffllig sind auch die von @@@ eingerahmten Schlsselworte im Template. Im einfachsten Fall werden diese beim Schreiben der Konfigurationsdateien eins zu eins durch entsprechende Werte aus dem Verzeichnisdienst ersetzt. Kolabconf liest dafr Werte aus dem vertrauenswrdigen Objekt:
dn: k=kolab, dc=example, dc=com
Anstatt eines Schlsselwortes knnen auch konkrete Angaben direkt in das Template eintragen werden. Dazu wird das Schlsselwort (inkl. dessen einrahmende @@@ Zeichen) einfach berschrieben.
15
Problemsucheinkolabd/kolabconf Der kolabd ist das Bindeglied zwischen dem Verzeichnisdienst und dem Cyrus-IMAP-Server. Kolabd kommt erst dann zum Einsatz, wenn nderungen an der Konfiguration oder den Nutzereinstellungen vorgenommen werden. Probleme am kolabd werden also erst dann sichtbar, wenn nderungen nicht abgearbeitet werden knnen. Typische Symptome fr einen gestrten kolabd sind: a) Der im Verzeichnisdienst angelegte Nutzer kann sich nicht im Cyrus anmelden (der kolabd hat das Konto noch nicht angelegt). b) Die Lschung eines Nutzers dauert sehr lang. Ein Neustart des kolabd ist harmlos, da er selbst keinen Zustand hlt und nicht zeitnah auf Anfragen antworten muss. Es schadet also nicht, den kolabd in den beiden oben beschriebenen Situation neu zu starten. Der kolabd protokolliert seine Arbeit in der normalen Log-Datei fr Systemmeldungen, bei Debian ist das meist /var/log/syslog (Achtung: Dies ist nicht innerhalb der OpenPKG-Hierarchie). Um dort mehr Ausgaben zu erhalten, sollte in der Konfigurationsdatei /kolab/etc/kolab/kolab.conf der Wert fr log_level erhht und kolabd neu gestartet werden. log_level steht nach der Installation von Kolab Server noch nicht in der kolab.conf; er muss also manuell eingetragen werden. Dessen voreingestellter Wert ist in der Regel 2 und steht in /kolab/etc/kolab/kolab.globals. Fr die Ausgaben in syslog ist nur log_level (0 4) interessant. Analog kann fr ein interaktives Debugging der Flag debug (0/1) gesetzt werden. Voreinstellungen in /kolab/etc/kolab/kolab.globals:
log_level : 2 debug : 0
nderung der Werte in /kolab/etc/kolab/kolab.conf, z.B.:

log_level : 4 debug : 1
Bedeutung der Werte:

log_level: 0: SILENT 1: ERROR 2: WARN 3: INFO 4: DEBUG debug: 0: send to syslog if log level >= message priority 1: additionally print all messages to stdout
Sind mehrere Slave-Server im Betrieb, muss erst die Replikation des Verzeichnisdienstes funktionieren, bevor der kolabd auf den verschiedenen Servern ttig werden kann. Die obigen Symptome knnen also auch auf eine gestrte Replikation hinweisen.
16
3 KolabServer Bedarfsplanung
Es empfiehlt sich den eigenen Bedarf fr den Server abzuschtzen. Anhand von einigen Rahmenbedingungen werden in diesem Kapitel Hinweise fr eine Grob-Planung gegeben. Dabei ist zu beachten, dass das Nutzungsmuster einen starken Einfluss auf die Bedarfsplanung hat. In manchen Organisation reichen beispielsweise 50 Megabyte E-Mail-Speicherplatz und es werden pro Nutzer weniger als dreistellige Termine gespeichert. Bei Anderen wird E-Mail zur Ablage groer Multimedia-Dateien verwendet und die 3000 Termine der ganzen Arbeitsgruppe der letzten drei Jahre archiviert; hier wird ein Quota von 2 Gigabyte sicherlich schnell eng.
3.1 Festplattenspeicher
Die wichtigste Ttigkeit eines Kolab-Servers ist es, fr die Klienten E-Mail-Daten zu liefern. Jedes Groupware-Objekt ist ebenfalls eine E-Mail. In der Regel haben die meisten Nutzer deutlich mehr normale E-Mails als andere Groupware-Objekte, eine Bedarfsschtzung sollte also bei der E-Mail anfangen. Der durchschnittliche E-Mail-Speicherplatz in den nchsten Jahren, multipliziert mit der Anzahl der Nutzer und etwas Puffer ergibt den zu erwartenden Plattenplatz der Nutzerdaten. Aus der erwarteten nderungsrate lsst sich auch der Platz fr die Datensicherung abschtzen. Gegenber den normalen E-Mails fallen die Termine und Kontakte meist nicht ins Gewicht. Wird als Klient Microsoft Outlook mit einem der verfgbaren Konnektoren verwendet (vgl. Abschnitt 6.2), ist es mglich, dass sich die Gre mancher E-Mails in der Speicherung verdoppeln. Nur so knnen manche Objekt-Attribute gespeichert werden, welche nur fr Outlook wichtig sind. Wer ganz sicher gehen mchte, migriert auf ein Testsystem die alten Daten einiger reprsentativer Nutzer.
17
3 Kolab Server Bedarfsplanung
Entscheidend wird der Umgang mit Alt-Daten im System sein. Was werden die Nutzer tun, wenn sie an ihr Limit stoen? Es empfiehlt sich, den Nutzern hier frh eine Mglichkeit anzubieten, z.B. zum selbstndigen Archivieren. Die Klienten bieten meist Funktionen zum automatischen Lschen alter E-Mails oder Termine an.
3.2 Rechenleistung/Hauptspeicher
Beim Verfgbarmachen von E-Mails sind vor allem das bermitteln von Daten, Platten- und Netzwerkdurchsatz, sowie die Netzlatenz limitierender als die Rechenleistung. Pro aktivem Klienten luft etwa ein Cyrus-IMAPd, der grob um die 2 Megabyte Hauptspeicher bentigt. Ein aktiver Klient steht in diesem Zusammenhang fr einen Klienten, der einen Zwischenspeicher besitzt und daher hauptschlich nur zum Synchronisieren eine Netzwerkverbindung bentigt. Der einzelne Nutzer kommt also problemlos minutenlang ohne Verbindung aus. Es ist zu erwarten das durch geschicktere Synchronisations-Algorithmen von Seiten der Klienten der Bedarf an Netzverbindungen in Zukunft sogar sinken kann. Deutlich mehr Rechenleistung im Kolab-Server bentigen zwei andere Prozesse: 1. Das Scannen von E-Mails auf Schadsoftware und unerwnschte Werbung, 2. sowie das Erstellen von Frei/Belegt-Listen. Die Erstellungszeiten von Frei/Belegt-Listen sind von Kolab Server 2.0 auf 2.1 entscheidend verbessert worden. Langzeiterfahrungen fehlen, aber es wird eine deutliche Besserung erwartet, so dass dieses fr den Betrieb von 2.2 nicht mehr gesondert geplant werden muss. Im Gegensatz dazu hat der Ansturm an unerwnschten E-Mails zugenommen, was mehr Scan-Leistung erforderlich macht. Fr das Scannen von E-Mails ist deshalb bei greren Installation ein eigener Rechner sinnvoll. Bei durchschnittlicher Nutzung ist zu erwarten, dass eine bliche Server-Hardware mit 2 Prozessoren und 4 Gigabyte Hauptspeicher mehrere tausend Nutzer bedienen kann. Das gilt pro Kolab-Server; durch den Einsatz von Slave-Servern ist hier eine gute Skalierung mglich.
3.3 Verfgbarkeit
Die Bedrfnisse an die Verfgbarkeit der Kolab-Server sind recht unterschiedlich. Wie im letzten Absatz beschrieben, sind die Klienten auch ohne Netzverbindung grundstzlich arbeitsfhig. Dennoch sollte eine hohe Verfgbarkeit von jedem Kolab-Servers angestrebt werden. Der Kolab-Server kann mit blichen GNU/Linux Mechanismen abgesichert werden. Zum Beispiel durch ein aktiv-passiv System, welches per Linux-HA1 den aktiven Rechner berwacht und bei Schwierigkeiten den passiven einschaltet. Dazu muss der passive Rechner auf die Daten zugreifen knnen: z. B. durch ein gemeinsames SCSI Plattensystem / SAN, ggf. auch standortbergreifend.
http://www.linux-ha.org/ [Abruf: 07.12.2007]
18
3 Kolab Server Bedarfsplanung
3.4 Werarbeitetmitwem?
Es kann sinnvoll sein, aus Grnden der Leistung oder verschiedener Standorte, mehrere Kolab-Server zu planen. Dabei ist zu beachten, wie die Arbeitsbeziehungen der Nutzer sind. Es ist empfehlenswert, eng zusammenarbeitende Nutzer auf einen Kolab Server zu legen also beispielsweise lieber eine Abteilung X, als die Mitarbeiter von A bis H. Interessant sind dabei auch Fragen der Modellierung von gemeinsamen Ordner (z.B. fr Termine): Ein Ordner steht zunchst nur Nutzern auf einem Server zur Verfgung. Kolab-Nutzer haben einen bestimmten Heimatserver, drfen sich aber auf allen anderen anmelden. Das ist weniger ntig, wenn sich die Nutzer einer Arbeitsgruppe schon auf einem gemeinsamen Heimatserver befinden.
19
4 KolabServerVorbereitung undInstallation
In diesem Kapitel werden zunchst die ntigen Grundvoraussetzungen und Vorbereitungen fr die danach beschriebene Installationsanleitung des Kolab Servers erlutert. Anschlieend wird das Vorgehen fr eine Aktualisierung und fr 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 mglich, da es sonst zu Problemen mit dem Cyrus IMAP Server kommt1. Partitionierung Fr einen produktiven Einsatz eines Kolab Servers wird empfohlen, getrennte Partitionen fr Programme, Bewegungsdaten und Nutzerdaten zu verwenden. Nachfolgend eine Empfehlung fr 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) Es wird ein geeignetes Dateisystem bentigt. Die meisten Kolab-ServerDateisystem Installationen werden mit ext3 betrieben, aber es existieren auch nennenswerte Erfahrung mit XFS. Bei der Nutzung von ext3 wird empfohlen, einen Linux Kernel ab 2.6.19.2 oder einen entsprechend gepatchten Kernel zu
1 http://cyrusimap.web.cmu.edu/imapd/faq.html [Abruf: 07.12.2007] Der Cyrus IMAPd braucht ein lokales Dateisystem, mit Unix-Eigenschaften und funktionierender mmap()/write() Kombination.
20
4 Kolab Server Vorbereitung und Installation
verwenden. Frhere Versionen haben einen Defekt im mmap(). Fr ext3 spricht, dass es sich um ein vergleichsweise einfaches und damit sehr robustes Journaling-Dateisystem handelt. Sollte ein Dateisystem-Check trotzdem einmal ntig werden, dann dieser jedoch im Ernstfall lngere Zeit bentigen. XFS ist ein komplizierteres Journaling-Dateisystem. ReservierteBenutzer 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 berzeugt hat. Unter http://kolab.org/mirrors.html gibt es eine Liste von Servern, welche die Kolab-Server-Pakete zum kostenfreien Herunterladen anbieten. Nach dem Download sollten die Signaturen berprft werden. Aus dem Verzeichnis server sollte die aktuelle Kolab-Server-Version heruntergeladen werden entweder die komplette Quellcodeversion im Verzeichnis sources oder die binre, vorkompilierte Version fr Debian 4.0 (Etch) im Ordner ix86-debian4.0. Binr-Versionen fr andere Distributionen knnen selbst gebaut oder ber Kolab-Dienstleister bezogen werden (Kontakte im Anhang A.2). Ports Die folgenden Ports mchte der Kolab Server ffnen. Alle Anwendungen des Betriebssystems, die diese Ports ansonsten bruchten, sollten gestoppt oder deinstalliert werden. 80/tcp http offen nach auen (bei Bedarf) 443/tcp https offen nach auen 25/tcp smtp offen nach auen 465/tcp smtps offen nach auen 110/tcp pop3 offen nach auen (bei Bedarf) 995/tcp pop3s offen nach auen (bei Bedarf) 143/tcp imap offen nach auen 993/tcp imaps offen nach auen 389/tcp ldap offen nach auen 636/tcp ldap offen nach auen 2000/tcp sieve offen nach auen (bei Bedarf) 2003/tcp lmtp nur intern offen 9999/tcp kolabd nur intern offen 10024/tcp amavis nur intern offen
21
4.2 Installation
Im folgenden Abschnitt werden die Schritte zur Installation des Kolab Servers mit den unter Abschnitt 4.1 heruntergeladenen Paketen beschrieben. Es sollte zustzlich die bei den Paketen beiliegende 1st.README-Datei beachtet werden. 1. DieInstallation 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 fr Debian 4.0 vorkompilierten ix86-Binrpaketen (ix86-debian4.0) zur Wahl. Dafr muss in das entsprechende Verzeichnis gewechselt werden. Anschlieend 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 Binrpaket-Installation kann mit ca. 3 bis 10 Minuten gerechnet werden. Bei Schwierigkeiten mit der Binrpaket-Installation sollte stets die Installation von den Quellen probiert werden. 2. DasBootstrapping Nach der Installation sollte die initiale Konfiguration (das Bootstrapping) des Kolab-Servers mit folgendem Befehl durchgefhrt werden:
/kolab/etc/kolab/kolab_bootstrap -b
Dabei werden zunchst die bentigten Ports nach Verfgbarkeit getestet. Anschlieend werden unterschiedliche Informationen zum Kolab-Server abgefragt. Nachfolgender Ausdruck zeigt exemplarisch das Konfigurieren eines Master-Servers mit einer eigenen Zertifizierungsstelle fr Testzwecke. Alle ntigen Eingaben sind fett gedruckt ([Enter] meint das Drcken der Enter/Return-Taste ohne weitere Eingabe) und dienen nur zur Demonstration des Bootstrapping-Prozesses. Fr das Aufsetzen eines eigenen Systems sollten diese Eingaben unbedingt an die spezifischen Anforderungen angepasst werden. Wird ein Produktivsystem aufgesetzt, sollten Zertifikate einer richtigen Zertifizierungsstelle (Certification Authorities, kurz CA) zum Einsatz kommen. Unter http://www.pki-page.org gibt es eine ausfhrliche Liste weltweiter, aktueller Zertifizierungsstellen. Wichtig ist dabei, dass die Zertifikate in den Klienten als vertrauenswrdig anerkannt werden.
22
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 (Besttigung 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 (Besttigung 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 Drcken von Enter)
> Enter fully qualified hostname of slave kolab server e.g. thishost.domain.tld [empty when done]: [Enter] prepare LDAP database... temporarily starting slapd Waiting for OpenLDAP to start no dc=example,dc=com object found, creating one mynetworkinterfaces: 127.0.0.0/8 LDAP setup finished Create initial config files for postfix, apache, cyrus imap, saslauthd running /kolab/sbin/kolabconf -n kill temporary slapd OpenPKG: stop: openldap. Creating RSA keypair for resource password encryption /kolab/bin/openssl genrsa -out /kolab/etc/kolab/res_priv.pem 1024 Generating RSA private key, 1024 bit long modulus ....................++++++ ...............++++++ e is 65537 (0x10001) /kolab/bin/openssl rsa -in /kolab/etc/kolab/res_priv.pem -pubout -out /kolab/etc/kolab/res_pub.pem writing RSA key chown kolab:kolab-n /kolab/etc/kolab/res_pub.pem /kolab/etc/kolab/res_priv.pem Kolab can create and manage a certificate authority that can be used to create SSL certificates for use within the Kolab environment. You can choose to skip this section if you already have certificates for the Kolab server.
23
Erstellen einer eigenen Test-Zertifizierungsstelle und eines Zertifikats

> Do you want to create CA and certificates [y] (y/n): y Now we need to create a cerificate authority (CA) for Kolab and a server certificate. You will be prompted for a passphrase for the CA. ###################################################################### /kolab/etc/kolab/kolab_ca.sh -newca kolab.example.com > Enter organization name [Kolab]: [Enter] > Enter organizational unit [Test-CA]: [Enter] Using subject O=Kolab,OU=Test-CA,CN=kolab.example.com Using dn > CA certificate filename (or enter to create) [Enter] Making CA certificate ... Generating a 1024 bit RSA private key ....++++++ writing new private key to '/kolab/etc/kolab/ca/private/cakey.pem' > Enter PEM pass phrase: <passphrase> > Verifying - Enter PEM pass phrase: <passphrase> ----/root /kolab/etc/kolab/kolab_ca.sh -newkey kolab.example.com /kolab/etc/kolab/key.pem Using dn Generating RSA private key, 1024 bit long modulus ......++++++ e is 65537 (0x10001) writing RSA key /root /kolab/etc/kolab/kolab_ca.sh -newreq kolab.example.com /kolab/etc/kolab/key.pem /kolab/etc/kolab/newreq.pem Using dn Request is in /kolab/etc/kolab/newreq.pem and private key is in /kolab/etc/kolab/key.pem /root /kolab/etc/kolab/kolab_ca.sh -sign /kolab/etc/kolab/newreq.pem /kolab/etc/kolab/cert.pem Using dn Using configuration from /kolab/etc/kolab/kolab-ssl.cnf > Enter pass phrase for /kolab/etc/kolab/ca/private/cakey.pem: <passphrase> Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Oct 19 07:24:15 2007 GMT Not After : Oct 16 07:24:15 2017 GMT Subject: commonName = kolab.example.com X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 65:CD:3E:49:47:34:B6:05:52:25:3B:C7:C5:4D:7D:09:92:13:6D:1B X509v3 Authority Key Identifier: DirName:/O=Kolab/OU=Test-CA/CN=kolab.example.com serial:85:3B:73:2D:BA:56:FC:67 > Certificate is to be certified until Oct 16 07:24:15 2017 GMT (3650 days) Sign the certificate? [y/n]: y > 1 out of 1 certificate requests certified, commit? [y/n] y Write out database with 1 new entries Data Base Updated Signed certificate is in /kolab/etc/kolab/cert.pem /root chgrp kolab-r /kolab/etc/kolab/key.pem; chmod 0640 /kolab/etc/kolab/key.pem; chgrp kolab-r /kolab/etc/kolab/cert.pem; chmod 0640 /kolab/etc/kolab/cert.pem; ###################################################################### CA and certificate creation complete. You can install /kolab/etc/kolab/ca/cacert.pem on your clients to allow them to verify the validity of your server certificates.
<<Ende des exemplarischen Bootstrappings-Prozesses>>
24
Am Ende des Bootstrappings sollte die Ausgabe der folgenden hnlich sein:
kolab is now ready to run! please run '/kolab/bin/openpkg rc all start' Use login=manager and passwd=VG1rXCIxi22/c4DT when you log into the webinterface https://kolab.example.com/admin !
Anmerkung: Es sollte zunchst der Master-Server konfiguriert werden. Das (optionale) Hinzufgen von weiteren Kolab-Slave-Servern ist im Abschnitt 5.12 beschrieben. 3. Serverstarten Der Kolab Server ist erfolgreich installiert und kann nun mit folgendem Befehl gestartet werden:
/kolab/bin/openpkg rc all start
Das Verzeichnis /kolab/RPM/PKG/ wird nur zur Installation gebraucht und kann anschlieend gelscht oder fr sptere Installationen archiviert werden (Gre: ca. 500 MB).
4.3 Aktualisierung
Achtung: Die Migration von Kolab Server 2.1 auf 2.2 wird zur Zeit noch getestet! Fr 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 durchgefhrt 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 luft analog zur initialen Kolab-Server-Installation (vgl. Abschnitt 4.2). Die Hinweise in der Datei 1st.README sind zustzlich zu beachten. 1. Beenden aller Kolab Server Dienste:
/kolab/bin/openpkg rc all stop
und sicherstellen, dass kein LDAP-Prozess mehr luft:

/kolab/bin/openpkg rc openldap status und ps -AF | grep slapd
2. Sichern der vollstndigen, alten Kolab-Installation! Zum Reduzieren der Server-Stillstandszeit (downtime) wird empfohlen, das Verzeichnis /kolab mit rsync zunchst von dem noch laufenden Server zu kopieren. Anschlieend, bei gestoppten Server, mssen mit rsync nur noch die genderten Dateien nachgesichert werden. Sofern ein hnliches Vorstufen-System zur Verfgung steht (staging) empfiehlt es sich, die Binrdateien dort zu bauen und diese dann zu kopieren. Dadurch wird entscheidende Zeit gespart.
25
3. Nach dem Aktualisieren der Kolab Server Pakete in dem Verzeichnis, in dem bereits die anderen Pakete liegen kann das Kolab Server Update (als root) gestartet werden:
./install-kolab.sh -H -F 2>&1 | tee kolab-update.log
install-kolab.sh bestimmt in der Regel automatisch welche Pakete bentigt werden und installiert 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 genderte Konfigurationsdateien werden mit der Dateinamenerweiterung *.rpmsave gespeichert. Bei Konfigurationsdateien, die von Templates generiert werden, mssen die *.conf.rpmsave Dateien zunchst gelscht werden, um den entsprechenden Dienst starten zu knnen; z. B. fr ClamAV:
rm /kolab/etc/clamav/*.conf.rpmsave
Die nderungen aus den *.template.rpmsave Dateien (die angelegt werden, wenn Templates gendert wurden) knnen nun in die neuen Template-Dateien bertragen werden. Nun muss der OpenLDAP gestartet, die Konfigurationsdateien neu generiert und schlielich der komplette Kolab Server neu gestartet werden:
/kolab/bin/openpkg rc openldap start /kolab/sbin/kolabconf /kolab/bin/openpkg rc all start
Detailliertere Upgrade-Informationen insbesondere zu Besonderheiten beim Upgrade von frheren Kolab-Versionen sind in den Readme-Dateien im CVS-Server-Verzeichnis 2 bzw. in der 1st.README im Installationsordner zu finden. Sicherheitsupdates Zunchst ist der Benachrichtigungsweg relevant: Wie bekommt der Administrator Kenntnis von einem Sicherheitsupdate? Entweder wird er von seinem Dienstleister benachrichtigt und mit einer genauen Anleitung versorgt, oder er muss sich selbst darum kmmern. Ist kein Dienstleister damit beauftragt, wird geraten, mindestens folgende Quellen zu verfolgen: die Kolab-Announce-Mailingliste (vgl. Anhang A) zu abonnieren die Sicherheitsrelevanten Informationen der genutzten Distribution (z.B. Debian security) zu beobachten Anschlieend sollte eine Bewertung der in Frage kommenden Updates durchgefhrt werden.
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/ [Abruf: 07.12.2007]
26
Treten Unsicherheiten/Schwierigkeiten beim Durchfhren von Sicherheitsupdates auf, sollte ein Dienstleister zu Rate gezogen werden. Ein funktionierender Prozess, um zu Aktualisierungen zu kommen ist wichtig, da ansonsten das eingesetzte System Gefahr luft lngere Zeit bekannte Angriffspunkte zu bieten.
4.4 Deinstallation
Der Kolab Server/OpenPKG kann in drei Schritten deinstalliert werden: 1. Kolab Server beenden:
/kolab/bin/openpkg rc all stop
2. Alle Kolab-Pakete lschen:

/kolab/bin/openpkg rpm -e `/kolab/bin/openpkg rpm -qa`
rpm -qa listet alle Pakete innerhalb der OpenPKG Umgebung und rpm -e lscht diese. 3. Kolab-Verzeichnis lschen:
rm -rf /kolab/
Anschlieend 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 Eintrge in /etc/shells, ... das Kolab/OpenPKG Initskript /etc/init.d/kolab mit den Symlinks in /etc/rc?.d/???kolab und ... das /kolab Verzeichnis durch OpenPKG entfernt worden sein.
27
5 KolabServerKonfiguration undBetrieb
Dieses Kapitel beschreibt die Konfigurationsmglichkeiten des Kolab Servers und gibt darber hinaus fr den Betrieb ntzliche Methoden und Einstellungen mit. Es gibt zwei grundstzliche 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 knnen die Konfigurationstemplates 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 knnen. Dieses Kapitel vermittelt die dafr ntigen Kenntnisse.
5.1 KolabWebAdmin
Der Kolab Server stellt ein Webinterface den Kolab Web-Admin zur Verfgung, worber die gngigsten Servereinstellungen konfiguriert werden knnen. Der Web-Admin ist unter dem Kolab-Rechnernamen https://kolab.example.com/admin im Web-Browser zu erreichen. Fr den ersten Login kann der voreingestellte Administratorname manager genutzt werden; das Passwort wurde whrend der Installation vergeben. Fr die regelmige, administrative Arbeit sollte jedoch ein Administrator-Account angelegt werden. Nach dem Einloggen erhlt der Nutzer eine Navigationsleiste (vgl. Abb. 5.1) mit Links zu Einstellmglichkeiten des Kolab Servers.
28
5 Kolab Server Konfiguration und Betrieb
Abbildung5.1:NavigationsleistevomKolabWebAdmin(managerAnsicht)
Der Web-Admin ist in PHP geschrieben und nutzt den Apache Webserver (mit mod_php). Das Webinterface untersttzt SSL-Verschlsselung und Authentifikation gegen den Verzeichnisdienst. Der WebAdmin ist ein LDAP-Verzeichnisdienst-Werkzeug und kommuniziert ausschlielich mit dem LDAP-Server (eine Ausnahme sind Sieve-Skripte). In dieser Betriebsdokumentation wird exemplarisch fr einige Konfigurationsmglichkeiten auf den Web-Admin verwiesen. Weitere Informationen zur Konfiguration des Kolab Servers mit dem Web-Admin sind in der Kolab-Dokumentation Doc2 zu finden (vgl. Anhang A).
5.2 Rollen
Der Kolab Server stellt vier Rollen zur Verfgung, die nachfolgend beschrieben werden: 1. Administrator 2. Verwalter 3. Domnenverwalter 4. Benutzer Darber hinaus nimmt der Rechner-Administrator (root) eine Sonderrolle ein. Aus Sicherheitsgrnden haben die Kolab-Nutzer in der Regel keine Rechnerkonten und somit keinen direkten Zugriff (z.B. per ssh) auf den Server. Abbildung 5.2 veranschaulicht den Zusammenhang der vier Rollen und deren Berechtigungen: Die Rechte von Benutzer sind eine Untermenge von den Domnenverwalter-Rechten, diese wiederum Untermenge von Verwalter sind. Die Administratoren-Rechte umfasst alle genannten Berechtigungsmengen. Eine detaillierte Auflistung der rollenspezifischen Rechte folgt in den nchsten Abschnitten.
29
Abbildung5.2:DievierBenutzerrollendesKolabServersmitihrenZugriffsberechtigungenaufden Verzeichnisdienst
5.2.1 Administrator Die Benutzergruppe Administrator besitzt Lese- und Schreibberechtigung fr den LDAP-Verzeichnisbaum. Ein Administrator hat Zugang zu allen Einstellmglichkeiten innerhalb des Kolab Web-Admins. Das Passwort des voreingestellten Administrators manager wurde bei der Installation des Kolab Servers vergeben und ist bei Verlust in der folgender Datei wiederzufinden (Dies gilt ausschlielich nur fr den manager. Andere Administratoren werden hier nicht gespeichert!): /kolab/etc/kolab/kolab.conf (Zeile bind_pw). Zum ndern des manager Passworts kann der Befehl
/kolab/bin/kolabpasswd
genutzt werden. Ein Administrator ist berechtigt folgende Aufgaben durchzufhren: Hinzufgen, ndern und Lschen von Administratoren Hinzufgen, ndern und Lschen von Verwaltern Hinzufgen, ndern und Lschen von Domnenverwaltern Hinzufgen, ndern und Lschen von Benutzern Hinzufgen, ndern und Lschen von externen Adressen Hinzufgen, ndern und Lschen von gemeinsam genutzten Ordnern Hinzufgen, ndern und Lschen von Verteilerlisten Konfiguration der Dienste eigenes Passwort ndern (auer manager)
30
5.2.2 Verwalter Die Rolle Verwalter ist die eines Administrators hnlich mit dem Unterschied, dass ein Verwalter nicht berechtigt ist, folgende Aufgaben durchzufhren: Hinzufgen, ndern und Lschen von Administratoren Hinzufgen, ndern und Lschen von Verwaltern Konfiguration der Dienste 5.2.3 Domnenverwalter Im Vergleich zum Verwalter darf ein Domnenverwalter folgende Aufgaben nicht durchfhren: Hinzufgen, ndern und Lschen von Domnenverwaltern Hinzufgen, ndern und Lschen von externen Adressen Hinzufgen, ndern und Lschen von Benutzern fr fremde (nicht berechtigte) Domnen 5.2.4 Benutzer Benutzer werden von Administratoren, Verwaltern oder Domnenverwaltern angelegt. Abbildung 5.3 zeigt das Eingabeformular zum Hinzufgen eines Benutzers im Kolab Web-Admin. Benutzer knnen sich selbstndig ber den Web-Admin anmelden und ihre persnlichen Daten ndern. In der Voreinstellung drfen folgende Attribute jedoch nur vom Administrator, Verwalter oder Domnenverwalter gendert werden: Vorname Nachname Eindeutige Identitt (UID = Unique identity) Kontotyp E-Mail-Aliasnamen Plattenplatz des Benutzers in Megabytes Als Benutzername fr den Login beim Kolab Web-Admin kann sowohl die UID also auch die primre E-Mail-Adresse (PEM) eines Kontos genutzt werden. Die UID ist in der Voreinstellung gleichzeitig auch die primre E-Mail-Adresse. Diese kann aber jederzeit vom Administrator/(Domnen-)Verwalter gendert werden. Die primre E-Mail-Adresse und der zugeordnete Kolab-Homeserver kann nach dem Anlegen eines Kontos nicht mehr gendert werden. Was bei einer Namensnderung oder einer geplanten Migrierung eines Kontos auf einen anderen Homeserver zu tun ist, zeigt die zweite graue Box auf der bernchsten Seite. Weitere Informationen zu Kolab-Homeservern sind im Abschnitt 5.12 zu finden.
31
Abbildung5.3:AnlegeneinesneuenBenutzersimKolabWebAdmin
LDAPAttributendern Die Sichtbarkeit und Zugriffsberechtigung der LDAP-Attribute im Web-Admin kann im Template /kolab/etc/kolab/templates/session_vars.php.template definiert werden. Wichtig: Diese LDAP-Attributseinstellungen gelten nur fr den Kolab Web-Admin! Um ein Attribut zu ndern, muss dem Array $params['attribute_access'] ein Element hinzugefgt werden. Deren mglichen 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 Beispiel, 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 anschlieend der Befehl /kolab/sbin/kolabconf aufgerufen werden (vgl. Abschnitt 2.4).
32
WiefindetmandenKolabHomeserverzueinembestimmtenEMailKonto? ...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. Lsungsalternative: Mit dem Befehl /kolab/sbin/slapcat lsst sich der vollstndige Inhalt des Verzeichnisdienstes ausgeben und kann anschlieend nach dem bestimmten E-Mail-Konto durchsucht werden.
Wasmussmantun,wennderName(unddamitdieprimreEMailAdresse)einesBenutzerssich ndert(z.B.durchHeiratoderScheidung)? WielsstsicheinBenutzeraufeinenanderenKolabServermigrieren? Der Name kann problemlos von einem Administrator/Verwalter gendert werden. Die primre EMail-Adresse kann nach dem Anlegen eines Kontos allerdings nicht mehr bearbeitet werden. Die einfachste Lsung wre, eine neue Alias-E-Mail-Adresse einzutragen und die UID auf einen neuen Benutzernamen (z. B. ebenfalls die neue Alias-Adresse) zu ndern. Alternativ msste ein neues Benutzerkonto (mit neuem Nachnamen und primrer 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 fr das vollstndige migrieren eines Benutzers auf einen anderen Kolab-Homeserver geeignet. Eine aktuelle Anleitung ist in folgender Datei (im Kolab CVS) enthalten: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/raw-howtos/move-rename-user.txt
5.3 Kontotypen
Zu jedem neu angelegten Benutzer muss einer der vier Kontotypen ausgewhlt werden: 1. Benutzerkonto (voreingestellt) Dies ist der meist gebruchliche Kontotyp. Die E-Mail-Adresse ist von auen 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 gltig ist. Das bedeutet: der Benutzer kann keine E-Mails nach auen senden oder von
33
auen empfangen. Er ist damit auch nicht im ffentlichen Kolab-Adressbuch gefhrt. Speicherort: unter cn=internal, Base-DN 3. Gruppenkonto Ein Gruppenkonto ist fr das Arbeiten von mehreren Nutzern in einer Gruppen konzipiert. Der Name des Kontos sollte (zur besseren bersicht) fr den Titel der Arbeitsgruppe stehen. Mithilfe von Sieve lassen sich eingehende E-Mails an eine Kolab-Verteilerliste weiterleiten, deren Abonnenten gewissermaen 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, mssen 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 Benutzerkonto) durch das Setzen von Zugriffsrechten fr bestimmte Nutzer mglich (vgl. Abschnitt 5.10). Gruppenkonten haben bereits voreingestellt fr den Benutzer calendar Schreibzugriff auf den eigenen Kalender-Ordner, um automatisch Einladungen annehmen zu knnen (vgl. Abschnitt 5.7.1). Speicherort: unter cn=groups, Base-DN 4. Ressourcenkonto Mit dem Kolab Server knnen Ressourcen (wie z. B. ein Besprechungsraum, Dienstwagen oder Beamer) verwaltet werden. Ressourcenkonten haben bereits voreingestellt fr den Benutzer calendar Schreibzugriff auf den eigenen Kalender-Ordner, um automatisch Einladungen annehmen zu knnen (vgl. Abschnitt 5.7.1). Speicherort: unter cn=resources, Base-DN Jedes Konto braucht einen Inhaber. Insbesondere bei Gruppen- und Ressourcenkonten ist es wichtig, dass es eine zustndige Person gibt, die das Konto pflegt und z. B. von unerwnschten Nachrichten bereinigt. Diese Person muss nicht der Systemadministrator sein; im Gegenteil: es sollte eher eine der Gruppe oder der Ressource inhaltlich nahe stehende Person damit beauftragt werden.
5.4 Nutzerlebenszyklus
AnlegenimWebinterface
Der Webinterface-Code berprft, ob die E-Mail-Adresse, die UID oder eines der Alias-Eintrge mit bestehenden Nutzern, Verteilerlisten oder Adressbucheintrgen 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 knnen. Auf dem Kolab-Homeserver bleiben die IMAP-ACLs auf den Standardwerten, bei Ressourcen-
34
und Gruppenkonten wird zustzlich noch dem calendar-Benutzer Zugriff gewhrt. Auf den anderen Servern wird die Lookup-Berechtigung entfernt, so dass die Mailbox unsichtbar ist. UmbenennenimWebinterface Der Webinterface-Code berprft, ob der umzubenennende Benutzer ein Mitglied einer Verteilerliste ist und passt diese ggf. an. Das LDAP-Objekt im Kolab-Master wird umbenannt. Replikation auf Kolab-Slaves Da die primre E-Mail-Adresse nicht gendert werden kann, mssen keine weiteren nderungen durchgefhrt werden.
LschenimWebinterface Der Webinterface-Code berprft, ob der zu lschende Benutzer ein Mitglied einer Verteilerliste ist. Ist er das einzige Mitglied wird die Lschung verweigert, ansonsten wird der Benutzer aus der Verteilerliste entfernt. Das LDAP-Objekt kolabInetOrgPerson im Kolab-Master erhlt kolabDeleteflag-Eintrge fr 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 lschen die lokalen IMAP-Mailboxen und entfernen danach ihren kolabDeleteflag-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, lscht er die lokalen IMAP-Mailboxen, die Eintrge 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 vollstndige Objekt lscht, sondern nur die kolabspezifischen Teile. Hierzu muss in der kolab.conf ein Eintrag kolab_remove_objectclass : 1 ergnzt werden. Falls noch weitere Attribute entfernt werden sollen, knnen diese zustzlich mit der Konfigurationsoption kolab_remove_attributes angegeben werden, z.B.:
kolab_remove_objectclass : 1 kolab_remove_attributes : mail ou
35
5.5 EMail
Der nachfolgende Abschnitt beschreibt, wie der E-Mail-Betrieb auf dem Kolab Server funktioniert und an welchen Stellen der Administrator diesen Betrieb konfigurieren kann. 5.5.1 DieIMAPSpoolStruktur Der Cyrus IMAP-Server speichert alle E-Mails als einzelne Dateien in seinem Spool-Verzeichnis, das bei einer typischen Kolab-Installation unter /kolab/var/imapd/spool liegt. Zur bersichtlicheren Verwaltung bei sehr vielen Nutzern, verwendet der Kolab Server (seit Version 2.1) die Option hashimapspool: yes. Danach folgt die Struktur des Spool-Verzeichnisses dem Muster:
.../spool/domain/e/example.com/m/user/meier/[Ordner/...]
Die Domnen und Benutzer liegen in Verzeichnissen, die ihren jeweiligen Anfangsbuchstaben entsprechen: in dem o. g. Beispiel liegt also das Verzeichnis fr example.com in dem Verzeichnis e. Im Unterschied dazu werden Gruppenkonten unter ../user/<Gruppenname> und Ressourcenkonten unter ../user/<Ressourcenname> gespeichert. Das eigentliche Benutzer-Verzeichnis entspricht der jeweiligen IMAP-Inbox, alle Unterverzeichnisse entsprechen den IMAP-Unterordnern. Die Ordner enthalten jeweils Dateien, deren Name eine Zahl gefolgt von einem Punkt ist. Diese Dateien enthalten die eigentlichen E-Mails. Im gleichen Ordner befinden sich die drei Dateien cyrus.cache, cyrus.header und cyrus.index, die bestimmte Metainformationen der Nachrichten speichern. Mit diesen Kenntnissen kann der Administrator leicht E-Mails eines bestimmten Anwenders im Backup finden. Die unter /kolab/var/imapd/log liegenden Logdateien bieten zustzliche Informationen, wann aus welchen Postfchern E-Mails gelscht wurden. 5.5.2 DerWegeinerEMail Trifft eine E-Mail am Kolab-Server ein, durchluft sie verschiedenen Komponenten des Servers. Dieser Weg einer E-Mail vom SMTP-Eingangsserver bis in das IMAP-Ordner des Kolab-Nutzers wird in Abbildung 5.4 veranschaulicht und in den folgenden Schritten erlutert: 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 berprft z. B., ob der Sender berechtigt ist an die adressierte Kolab Verteilerliste zu schreiben. 3. Postfix bergibt anschlieend die Nachricht an den kolabfilter (/kolab/var/kolab-filter /scripts/kolabfilter.php). Handelt es sich bei der Empfnger-Adresse um eine Verteilerliste oder eine Kolab Alias-Adresse, so wird vorher die Adresse in die primre E-MailAdresse aufgelst. Bei einer Verteilerliste existiert anschlieend weiterhin noch eine E-Mail, jedoch mit allen einzelnen Empfnger-Adressen der Listenmitglieder. 4. Nachdem kolabfilter seine Aufgabe beendet hat, bergibt er die Mail per SMTP an Postfix (Port 10025).
36
5. Sofern E-Mail-Scanning mit amavisd-new aktiviert ist, wird die Nachricht von Postfix ber SMTP an amavisd-new (Port 10025) zugestellt (Ist amavisd-new deaktiviert, wird mit Schritt 9 fortgesetzt.) Amavisd-new filtert die Mail zunchst nach unerwnschten Absendern und nicht zugelassenen Anhngen, ... 6. ... bevor amavisd-new die Nachricht von ClamAV auf Viren... 7. ... und anschlieend von SpamAssassin auf Spam berprfen lsst. 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/kolabfilter /scripts/kolabmailboxfilter.php) zu. Bei einer Nachrichten an mehrere Empfnger werden daraus vorher mehrere Nachrichten mit jeweils nur einem Empfnger (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 ausfhrt (andernfalls wird dieser Schritt ignoriert) ... 12. ... und die Nachricht in den entsprechenden IMAP-Benutzerordner ausliefert.
37
Abbildung5.4:DerWegeinerEMailimKolabServer
38
5.5.3 Weiterleitung Ein Benutzer ist berechtigt eine E-Mail-Weiterleitung an jede beliebige E-Mail-Adresse einzurichten. Die Aktivierung kann vom Benutzer selbstndig im Kolab Web-Admin (innerhalb seiner eigenen Benutzereinstellungen) erfolgen. Es besteht die Mglichkeit Kopien der weitergeleiteten E-Mails auf dem Kolab-Server zu belassen. 5.5.4 Abwesenheitsbenachrichtigung Ein Benutzer kann in seiner Abwesenheit das automatische Versenden von Antworten auf eingehende EMails aktivieren. Die ntigen Einstellungen knnen innerhalb der Web-Admin-Benutzereinstellungen vorgenommen werden (vgl. Abbildung 5.5).
Abbildung5.5:EinstellungenfrAbwesenheitsbenachrichtigungenimKolabWebAdmin
Anmerkung zum erneuten Benachrichtigungsversand: Die Einstellung in obiger Abbildung (7 Tage) bedeutet, dass das Senden einer Abwesenheitsbenachrichtigung aktiviert wurde und falls innerhalb von 7 Tagen weitere Mails desselben Absenders eingehen, nur die erste Nachricht automatisch beantwortet wird. Nach Ablauf dieser Frist wird erneut eine Abwesenheitsnachricht versandt. Dies soll unntigen EMail-Verkehr vermeiden helfen. Anmerkung zu Spam-Mails: Bei Aktivierung der Option Keine Abwesenheitsbenachrichtigungen auf Spamnachrichten senden wird keine Nachricht an den Absender geschickt, wenn die E-Mail als Spam deklariert wurde. Anmerkung zur Domain-Angabe: Sofern eine Mail-Domne angegeben wird, bekommen nur Absender dieser Domne Abwesenheitsbenachrichtigungen zugesandt. Dadurch kann diese Funktion z. B. auf Nachrichten einer Organisation beschrnkt werden.
39
5.5.5 ServerseitigeFilterungmitSieve Sieve ist eine Skriptsprache, die speziell fr das serverseitige Filtern von E-Mails konzipiert wurde. Die genaue Spezifikation kann im RFC 3028 nachgelesen werden. Der Kolab Server nutzt Sieve u. a. fr Weiterleitungen und Abwesenheitsbenachrichtigungen (vgl. Abschnitt 5.5.3 und 5.5.4). Ein Benutzer kann immer nur ein Sieve-Skript zur gleichen Zeit aktiviert haben. Im Web-Admin kann aus drei vordefinierten Sieve-Skripten zum Verteilen, Weiterleiten und Verschicken von Abwesenheitsbenachrichtigungen (vgl. vorhergehende Abschnitte) ausgewhlt werden. Manchmal kann es ntzlich sein, ein selbst erstelltes Sieve-Skript mit mehreren unterschiedlichen Filterregeln zu definieren. Ein Weg das fertige Skript hochzuladen und zu aktivieren ist sieveshell. Es ist zu beachten, dass sieveshell eine unverschlsselte Verbindung nutzt. Es wird daher dringendst empfohlen sieveshell nur direkt auf dem Kolab- Server oder ber eine verschlsselte Netzwerkverbindung auszufhren. Starten von sieveshell (das manager-Passwort wird dafr bentigt):
/kolab/bin/sieveshell --user=user@example.com --authname=manager localhost
Der Befehl muss als root ausgefhrt werden, sofern das Sieve-Skript fr eine andere Person gesetzt werden soll. Mit nachfolgenden sieveshell-Befehlen lassen sich alle Sieve-Skripte des Nutzers auf dem Server anzeigen (list), das Skrip hochladen (put) und aktivieren (activate) und schlielich sieveshell wieder beenden (quit):
> > > > list put example.siv activate example.siv quit
Mit help lassen sich alle sieveshell-Befehle mit einer kurzen Erklrung auflisten. Um eintreffende E-Mails nicht alle im zentralen Posteingang des Benutzers zu haben, ist es mit Sieve mglich diese Nachrichten bereits serverseitig in bestimmte IMAP-Ordner einzusortieren (ntzlich z. B. um E-Mails aus verschiedenen Mailinglisten automatisch in bestimmte Unterordner verschieben zu lassen). Das nachfolgende Sieve-Skript-Beispiel demonstriert diesen Fall, wobei Sieve zustzlich Abwesenheitsbenachrichtigungen 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 Fllen nehmen Sie bitte mit <Urlaubsvertretung> Kontakt auf. E-Mail: <E-Mail-Adresse der Urlaubsvertretung> Telefon: +49 711 1111 11 Fax: +49 711 1111 12
40

Mit freundlichen Gren, 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 ausfhrliche Beschreibung von Sieve, dessen Befehle und Syntax sowie weiterfhrenden Beispielen ist in diesem deutschsprachigen Artikel1 zu finden. 5.5.6 EMailVertreter Wenn ein Benutzer einen Vertreter bestimmt, kann dieser Vertreter mit der E-Mail-Adresse des Benutzers Nachrichten versenden. Dies ist dann hilfreich, wenn der Vertreter beispielsweise den Kalender des Benutzers verwalten darf und z. B. der Sekretr im Namen seines Chefs Einladungen verschicken kann. Vertreter drfen sowohl fr Benutzerkonten als auch fr Gruppen- oder Ressourcenkonten definiert werden. Es knnen nur Kolab-Nutzer als Vertreter bestimmt werden (aufgrund der Nachrichtenfilterregelung vgl. Abschnitt 5.5.12). Ein externer Nutzer kann kein Vertreter sein. Das Bestimmen mehrerer Vertreter ist mglich. Ein Benutzer kann seine Vertretung mit dem Eintragen der Vertreter-E-Mail-Adresse(n) innerhalb seiner Web-Admin-Benutzereinstellungen aktivieren. Anmerkung: Wenn ein Vertreter im Namen des Benutzers Einladungen aussprechen knnen soll, mssen dem Vertreter auch Schreibrechte fr den Kalenderordner des Benutzers erteilt werden. In KDE Kontact z. B. kann der Benutzer dies unter Kontexmen Kalender Einstellungen Zugriffskontrolle einstellen. Falls der Kalenderordner ausgeblendet ist, vorher unter Einstellungen Kontact einrichten... E-Mail Diverses Arbeitsgruppen Arbeitsgruppenordner ausblenden das Hkchen deaktivieren. Alternativ kann der Rechneradministrator mit dem cyradm-Kommando setaclmailbox die ntigen Rechte setzen2. Im Kolab-Klient des Vertreters muss entsprechend eine neue Identitt eingerichtet werden. Die bisherigen SMTP-Einstellungen des Vertreters mssen fr diese neue Identitt nicht verndert werden.
1 2
http://www.holtmann.org/email/sieve/ [Abruf: 07.12.2007] http://www.oreilly.com/catalog/mimap/chapter/ch09.html#98759 [Abruf: 07.12.2007]
41
5.5.7 Verteilerlisten Eine Verteilerliste wird zum Verteilen von E-Mails an alle eingetragene Mitglieder dieser Liste verwendet und kann zum Setzen von Rechten verwendet werden. Jede Verteilerliste besitzt eine E-Mail-Adresse von der eintreffende E-Mails an alle Mitglieder der Liste weitergeleitet werden. Im Unterschied zu Gruppenkonten (siehe Abschnitt 5.3) knnen in Verteilerlisten auch externe Adressen aus dem Kolab-Adressbuch aufgenommen werden. Verteilerlisten knnen nur von Administratoren, Verwalter oder Domnenverwalter erstellt und verwaltet werden. Nach dem Anlegen einer Verteilerliste ist diese sofort nutzbar. Abbildung 5.6 zeigt das Eingabeformular im Kolab Web-Admin zum Anlegen einer neuen Verteilerliste. Bei Aktivierung der Option Verborgen steht eine Verteilerliste nur fr authentifizierte Nutzer zur Verfgung; d. h. nur authentifizierte Nutzer sind berechtigt, an diese Liste E-Mails zu senden. Die Verteilerliste wird im Status Verborgen bei einer LDAP Suche mit einer nicht-authentifizierten Verbindung im Kolab-Klient nicht angezeigt. Anmerkung: Ein authentifizierter Anwender ist ein Anwender, der sich mit seinem Benutzernamen und Passwort am Kolab-Server anmelden kann. Wenn ein nicht authentifizierten Nutzer (Nicht-Kolab-Nutzer) in eine Verteilerliste aufgenommen werden soll, muss dieser zuvor im externen Adressbuch angelegt werden. Der Nutzer kann dadurch E-Mails, die an diese Liste gerichtet sind, empfangen. Falls die Verborgen-Option aktiviert ist, kann er aber keine E-Mails an diese Liste senden.
Abbildung5.6:AnlegeneinerneuenVerteilerlisteimWebAdmin
42
5.5.8 VirenfilterKonfiguration Der Kolab Server nutzt nach der Installation standardmig den Virenscanner amavisd-new3 in Verbindung mit Clam AntiVirus4. Im folgenden Abschnitt werden diese beiden Werkzeuge erlutert. Amavisdnew Amavisd-new bildet im Kolab Server die Schnittstelle zwischen Postfix auf der einen Seite sowie SpamAssassin und ClamAV auf der anderen. Amavisd-new ist der Nachfolger von AMaViS (= A Mail Virus Scanner). AmavisdnewimKolabServer2.2

Template: /kolab/etc/kolab/templates/amavisd.conf.template Konfigurationsdatei: /kolab/etc/amavisd/amavisd.conf Logdatei: /kolab/var/amavisd/amavisd.log Quarantne-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 zunchst nach unerwnschten Absendern und nicht zugelassenen Anhngen und ruft zur Virenprfung ClamAV [6] und anschlieend (wenn die Nachricht virenfrei ist) SpamAssassin [7] auf. Wenn die E-Mail als harmlos befunden wurde, bergibt amavisd-new sie zurck zu Postfix an Port 10026 [8]. Andernfalls landet die Nachricht im Quarantne-Verzeichnis (siehe Kasten oben). Eine gebannte Nachricht aus dem Quarantne-Verzeichnis kann z. B. (als Nuter kolab-r) durch
/kolab/bin/cyrdeliver user@example.com < /kolab/var/amavisd/virusmails/banned-kXuJ2d3uGVCT
in das Postfach eines Kolab Nutzers manuell ausgeliefert werden. Einstellungen zu den Viren-, Mail- und Spam-Filter (wie z. B. ClamAV und SpamAssassin) knnen ber das zentrale amavisd-Template /kolab/etc/kolab/templates/amavisd.conf.template definiert werden. Um nderungen im Template wirksam werden zu lassen, muss /kolab/sbin/kolabconf zum Generieren der Konfigurationsdatei ausgefhrt (vgl. Abschnitt 2.4) und amavisd-new neu gestartet (Kommando: siehe oben im Kasten) werden.
3 4
http://www.ijs.si/software/amavisd/ [Abruf: 07.12.2007] http://www.clamav.net/ [Abruf: 07.12.2007]
43
ClamAV ClamAV ist ein Freier-Software-Virenscanner und Phishing-Filter, der nach jeder Kolab Server Installation standardmig als primrer Scanner aktiv ist. Clamscan ist der kommandozeilenbasierte Virenscanner und kann z. B. auf das aktuelle Verzeichnis mit dem Befehl /kolab/bin/clamscan ausgefhrt werden. Clamscan wird automatisch dann zum berprfen von Viren in E-Mails eingesetzt, wenn alle anderen Virenscanner ausgefallen sind. Es ist problemlos mglich andere, auch proprietre, Virenscanner zu installieren und diese an Stelle von oder zustzlich mit ClamAV auf dem Kolab Server zu nutzen. Dafr muss die ClamAV-Einstellung im amavisd-new Konfigurationstemplate editiert werden (vgl. externe Anleitung5). ClamAVimKolabServer2.2 Template: /kolab/etc/kolab/templates/clamd.conf.template und /kolab/etc/kolab/templates/freshclam.conf.template Konfigurationsdatei: /kolab/etc/clamav/clamd.conf und /kolab/etc/clamav/freshclam.conf Logdatei: /kolab/var/clamav/clamd.log Start-Kommandos: /kolab/bin/openpkg rc clamav {start|stop|status|
restart}
Update-Kommando (als kolab-r): /kolab/bin/freshclam
Die Virusinformations-Datenbank wird automatisch in regelmigen Abstnden durch einen voreingestellten Cronjob auf /kolab/bin/freshclam aktualisiert. Das voreingestellte Updateintervall von einer Stunde kann im Template /kolab/etc/kolab/templates/rc.conf.template (in der Zeile clamav_update = "hourly") gendert werden. In der /etc/crontab werden die Parameter hourly und weitere definiert. ClamAV berprft auch alle Dateien innerhalb von Archiven (z. B. *.tar.gz oder *.zip).
http://www.activmedia.ch/groupware5.php#viren [Abruf: 07.12.2007]
44
5.5.9 SpamfilterKonfiguration Unerwnschte Nachrichten lassen sich auf mehrere verschiedene Arten ausfiltern. Dieser Abschnitt konzentriert sich auf die Spamfilter-Mglichkeiten von SpamAssassin und erlutert dessen Konfiguration. SpamAssassin SpamAssassinimKolabServer2.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 fr spamd, welcher von amavisd-new nicht verwendet wird und deshalb in rc.conf.template standardmig abgeschaltet ist. Wird SpamAssassin ber amavisd-new genutzt, gelten nur die amavisd-new-Kommandos. Nach der Installation von Kolab Server ist der Mailscanner amavisd-new so konfiguriert, dass der mit Kolab ausgelieferte Spamfilter SpamAssassin aktiv ist. Die Konfiguration erfolgt in der Datei /kolab/etc/spamassassin/local.cf. Einige Funktionen von SpamAssassin sollten hier nicht mehr benutzt werden, da sie in amavisd-new integriert sind, wie z.B. Whitelist/Blacklist, Spam-Grenzwert und Header-/Body-nderungen. Eingestellt werden hier also nur noch der statistische Bayes-Filter, eigene Regeln und Wertigkeiten fr bestehende Regeln. Da SpamAssassin in amavisd-new integriert ist, muss nach nderungen
/kolab/etc/rc amavisd restart
ausgefhrt werden. SpamAssassin arbeitet mit verschiedenen Tests, die je nach Ergebnis sogenannte X-Spam-Scores vergeben. Diese Scores knnen positive oder negative Werte sein, je hher eine Nachricht am Ende bewertet ist, desto wahrscheinlicher ist sie Spam. Ab dem voreingestellten Schwellwert fr X-Spam-Score von $sa_tag_level_deflt = 3.0 (vgl. amavisd-Template) wird die Nachricht als Spam markiert. Zustzlich zu dieser Markierung wird eine unerwnschte Nachricht in das Quarantne-Verzeichnis kopiert (aufgrund der Voreinstellung im amavisd-Template: $final_spam_destiny = D_PASS;). Sollen Spam-Mails ausschlielich in der Quarantne (und nicht beim Empfnger) ankommen, dann ist der Wert von D_PASS auf D_DISCARD umzustellen. Im Gegensatz dazu werden Spam-Nachrichten nie in das Quarantne-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 Empfnger ausgeliefert werden. Jede als Spam bewertete E-Mail, wird ein X-Spam-Level-Feld im Header hinzugefgt.
45
SpamAssassin in der Grundkonfiguration ist noch nicht sehr mchtig. Um eine hhere Trefferquote zu erreichen, muss dieser lernen was Spam ist und was nicht. Dazu muss der verwendete Bayes-Filter trainiert werden. Nachfolgend werden drei Methoden beschrieben, wie SpamAssassin zum Spam melden (und lernen) genutzt werden kann: 1. Eine Mglichkeit besteht darin einen neuen Benutzer anzulegen; z. B. spam@example.com. In seinem IMAP-Postfach werden zwei Unterordner erstellt spam und nospam mit entsprechenden Lese-/Schreibzugriffen fr die gewnschten Benutzer, welche diese Ordner pflegen sollen. Diese Benutzer knnen nun eintreffende Spam-Mails, welche als solche nicht erkannt wurden, in den Ordner /user/spam/spam verschieben. Abschlieend werden zwei cronjob-Eintrge vorgenommen, um mit Hilfe der manuell einsortierten Spam-Nachrichten die SpamAssassin-Datenbank stndlich (hier zu jeder vollen Stunde) auf den neusten Stand zu bringen. Dazu muss in die Datei /etc/crontab folgende zwei Zeilen hinzugefgt 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 SpamFalle. Dazu kann die oben angelegte spam@example.com Adresse in diversen spamverdchtigen Internetseiten verffentlicht/eingetragen werden. Nach kurzer Zeit werden so kontinuierlich neue Spam-Mails eintreffen, die sich gut zum Spam-Erlernen eignen. 2. Methode (1) lsst sich auch ohne der Freigabe von IMAP-Ordner realisieren: Um Spam-E-Mails zu melden, leiten Benutzer unerwnschte Nachrichten einfach an die Adresse spam@example.com weiter. Der Posteingang dieses Kontos kann so vollstndig 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 ausgefhrt. 4. Eine andere Mglichkeit Spam zu melden besteht darin, zwei (gemeinsam genutzte) kontolose Ordner fr den Spam-Lern-Prozess einzusetzen. Die angelegten Spam-/Nicht-Spam-Ordner liegen auf gleicher Ebene wie die Benutzerpostfcher (im Spool-Verzeichnis). Diese Mglichkeit wird jedoch aus Grnden der Instabilitt von kontolosen Ordnern nicht empfohlen (vgl. Abschnitt 5.10.2).
46
Nachdem SpamAssassin die ausgefilterten Spam-Mails gelernt hat, knnen diese E-Mails theoretisch direkt im Anschluss des Lern-Durchlaufs gelscht werden. Ein manuelles Lschen der Mails hat aber den Vorteil, versehentlich als unerwnscht deklarierte Nachrichten ins Benutzerpostfach zurckzuholen. Mit dem Befehl ipurge lassen sich alle E-Mails lschen, die lter sind als x Tage. Hierbei muss beachtet werden, dass der Befehl nur auf den Spam-Ordner ausgefhrt wird. Eine Hilfe zu den mglichen Parametern ist auf der Manual-Seite von ipurge zu finden (man ipurge als Nutzer kolab). Weiterfhrende Informationen und Einstellmglichkeiten zu SpamAssassin gibt es auf folgenden Internetseiten [Abruf: 07.12.2007]: die SpamAssassin Website: http://spamassassin.apache.org die sa-learn Dokumentation: http://spamassassin.apache.org/full/3.2.x/dist/doc/sa-learn.html ein Erfahrungsbericht ber Kolab und Spam: http://grover.open2space.com/node/15
5.5.10 EMailDomnen Der Kolab Server kann mehrere E-Mail-Domnen verwalten (er ist Multi-Domain-fhig). ber den Kolab Web-Admin in der Rubrik Dienste lassen sich Mail-Domnen hinzufgen oder entfernen (vgl. Abbildung 5.7).
Abbildung5.7:HinzufgeneinerweiterenEMailDomneimWebAdmin
5.5.11 AdministrativeEMailAdressen Fr jede E-Mail-Domne muss ein Konto definiert werden, dass alle Nachrichten an administrative EMail-Adressen empfngt. 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 eingegeben werden. Anschlieend werden fr jede dieser administrativen Adresssen Verteilerlisten erzeugt, die spter noch bearbeitet werden knnen.
47
5.5.12 Sicherheitseinstellungen PrivilegierteNetzwerke Als privilegierte Netzwerke bezeichnet man solche Netzwerke, die Nachrichten ber nicht-authentifizierte SMTP-Verbindungen an den Kolab Server verschicken drfen. Voreingestellt werden automatisch alle eigenen Kolab-Server eingetragen. Wenn vorhanden, sollte in der Regel der zustndige SMTP Eingangsgateway als privilegiertes Netzwerk eingerichtet werden. Im Kolab Web-Admin unter Dienste werden diese Netzwerke im Format x.x.x.x/y eingetragen mehrere Netze werden durch Kommata getrennt. Voreingestellt ist 127.0.0.0/8. NachrichtenausdemInternet Damit der Kolab Server Nachrichten aus anderen Internet-Domnen direkt (ber nicht-authentifiziertes SMTP) empfangen kann, muss die Option Nachrichten aus dem Internet akzeptieren im Web-Admin unter Dienste aktiviert werden. Wenn diese Option ausgeschaltet ist, werden E-Mails nur von SMTPServern aus den privilegierten Netzwerken (oder mit Authentifizierung) angenommen. SMTPSmarthost/Relayhost Als SMTP-Smarthost oder -Relayhost wird ein Mailserver bezeichnet, der E-Mails von einem Sender empfngt und an einen bestimmten Host weiterleitet. Bei Kolab spielt so ein Smarthost eine Rolle, wenn z. B. ein SMTP-Ausgangsserver genutzt werden muss (weil beispielsweise das Versenden von E-Mails ber Port 25 durch den Provider nicht erlaubt wird). Zum Konfigurieren eines Smarthosts im Kolab Web-Admin unter Dienste wird der Hostname oder die IP-Adresse (mit optionaler Portangabe) bentigt. Nachrichtenfilter Abbildung 5.8 zeigt die voreingestellten Konfigurationsoptionen fr den Nachrichtenfilter des Kolab Servers im Web-Admin (Rubrik Dienste).
Abbildung5.8:DieVoreinstellungendesNachrichtenfiltersimKolabWebAdmin. SofernmindestenseinederbeidenoberenPrfOptionenaktiviertistund freineNachrichtfehlschlgt,wirddiedarunterausgewhlteManahmedurchgefhrt.
Das Diagramm in Abbildung 5.9 veranschaulicht den Ablauf, wie eine E-Mail im Kolab Server gefiltert werden sollte. Abhngig von der Verbindungsart und der (unter Abb. 5.8 aktivierten) Filter- und ber-
48
prfoptionen wird eine E-Mail entweder angenommen (+), zurckgewiesen (-) oder als nicht vertrauenswrdig markiert (?). Das Diagramm bildet das Konzept des Nachrichtenfilters vom Kolab Server ab, wie es fr die Zukunft von Kolab geplant ist (SOLL-Zustand). Der IST-Zustand in Kolab Server 2.2 beta2 ist noch so: Der Kolab Server prft an der im Diagramm mit * markierten Stelle nicht, ob die Sender-Header mit dem SMTP-Sender bereinstimmt, sondern ob die Sender-Header eine lokale Adresse ist.
49
Abbildung5.9:DasFilternvonEMailsimKolabServer
50
5.6 Adressbuch
Das Kolab Adressbuch ist ein ffentliches Adressbuch und wird vom Verzeichnisdienst des Kolab-Server bereitgestellt. Das Adressbuch ist unabhngig von den Kolab-Benutzerkonten und den lokalen Adressbchern der Kolab-Klienten. Adressbucheintrge werden auch als externe Adressen bezeichnet, da es sich hierbei um Nicht-Kolab-Nutzer handelt. Diese externen Adressen werden im Verzeichnis auf dem Kolab-Server gespeichert. VerwaltenvonexternenAdressen Die Verwaltung des Kolab-Adressbuchs kann von Administratoren oder Verwaltern im Kolab WebAdmin bernommen werden (Abbildung 5.10 zeigt ein Formular zum Neuanlegen eines Adressbucheintrags). Externe Adressen knnen ber die LDAP-Suchfunktion im Kolab-Klient gesucht werden.
Abbildung5.10:DasHinzufgeneinerexternenAdresseinsAdressbuch(imKolabWebAdmin)
51
5.7 Kalender
5.7.1 Einladungen Der Kolab Server besitzt einen serverseitigen Mechanismus fr das automatische Behandeln von Einladungen. 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 fr jedes Konto, wie mit eintreffenden Einladungen umgegangen werden soll. Dabei gibt es fnf Mglichkeiten: 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 fr bestimmte E-Mail-Adressen sind mglich. Es kann jede gltige E-Mail-Adressen fr Einladungsrichtlinien verwendet werden. Also alle E-Mail-Adressen, die im Verzeichnisdienst gespeichert sind (also alle primren und Alias-E-Mail-Adressen der Kolab-Konten, alle Adressen der Verteilerlisten sowie alle externen Adressen aus dem Adressbuch) und darber hinaus auch jede beliebige externe E-Mail-Adresse, die nicht im Kolab-Adressbuch eingetragen ist. Um die Einladungsrichtlinien im Kolab Web-Admin zu definieren muss jede E-Mail-Adresse in ein separates Eingabefeld eingetragen werden (vgl. Abbildung 5.11).
Abbildung5.11:DasSetzenderEinladungsrichtlinienimWebAdminfralleBenutzer mitAusnahmebehandlungfruser1
Beim Eintreffen einer neuen E-Mail auf einem Kolab-Konto wird zunchst geprft, ob die SMTP-Sender-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 ausgefhrt. Andernfalls wird geprft, ob eine Verteilerliste in die Einladungsrichtlinie eingetragen wurde und die Sender-Adresse Mitglied dieser Verteilerliste ist. Gibt es eine bereinstimmung, wird die Regel ausgefhrt. Bei mehreren bereinstimmung wird die Adresse verwendet, die in der Eingabereihenfolge zuerst (im Web-Admin an frherer Stelle stehend) eingetragen wurde. Der PHP-Quellcode zu dieser berprfung der Einladungs-
52
regelungen ist in der Datei /kolab/lib/php/Kolab/Filter/resmgr.php (Funktion getLDAPData) zu finden. Anmerkung: Damit Benutzerkonten Einladungen automatisch bearbeiten knnen, muss der Benutzer calendar Zugriff auf den Kalender-Ordner haben dies ist nur fr die Einladungsrichtlinie (1), (3) und (4) ntig. Empfehlungen Fr Ressourcenkonten wird empfohlen, die Einstellung Ablehnen im Konfliktfall (3) oder Im Konfliktfall manuell bearbeiten (4) zu whlen. Ressourcen knnen sich gut selbst verwalten; nur bei Terminkollision muss eine Einladung abgelehnt werden. Fr Gruppenkonten wird empfohlen, die Einstellung Immer ablehnen (2) oder Manuell (5)zu whlen. Da hinter den Gruppen jeweils individuelle Benutzer (mit ihren individuellen Kalendern) stehen, ist hier eine manuelle Bearbeitung von Einladungen sinnvoll.
Fr jedes Konto sollte stets ein Inhaber definiert sein (vgl. Anmerkung im Abschnitt 5.3). 5.7.2 Frei/BelegtListen Frei/Belegt-Listen werden zur Organisation von Terminen mit mehreren Teilnehmern verwendet. Die Frei/Belegt-Liste eines Benutzers enthlt den Startpunkt und die Dauer aller Termine eines bestimmten Zeitraums. Fr die Abstimmung eines Termins mit mehreren Teilnehmern knnen im Kolab-Klienten die Frei/Belegt-Listen der anderen Teilnehmer eingesehen werden, um so einen freien Termin fr alle Teilnehmer zu finden. Unter https://kolab.example.com/fbview wird vom Kolab Server ein Web-Frontend zur Verfgung gestellt, das die Frei/Belegt-Listen von frei whlbaren Kolab-Nutzern als Gantt-Diagramm visualisiert (vgl. Abbildung 5.12). Benutzer knnen sich mit ihrem Kolab-Konto auf dem Free/Busy-Viewer einloggen. Der Web-Viewer basiert auf Komponenten von Horde (vgl. Abschnitt 6.3). Teilnehmerlisten fr den Free/Busy-Viewer knnen gespeichert werden. Dies geschieht ber BrowserCookies. Alternativ zum Free/Busy-Viewer kann beispielsweise auch KDE Kontact zur Anzeige der Frei/Belegt-Listen genutzt werden. Frei/Belegt-Listen werden ber einen Webserver verwaltet und per HTTPS bertragen. In der ServerVoreinstellung ist eine verschlsselte Authentisierung des Benutzers durch den Kolab-Klienten erforderlich. Ist ein Zugriff auf die Frei/Belegt-Informationen ohne Authentisierung gewnscht, kann im WebAdmin (unter der Rubrik Dienste) die Einstellung Unauthentifiziertes Herunterladen von Frei/BelegtInformationen erlauben aktiviert werden. Dann sollte aber das Netz den Zugriff einschrnken. Der Web-Admin bietet eine zustzliche Einstellmglichkeit, um die Anzahl der vergangenen Tage zu definieren, die beim Erzeugen der Frei/Belegt-Listen bercksichtigt werden sollen.
53
Abbildung5.12:DerFrei/BelegtViewervonKolabServer2.2beta2
5.8 Notizen
Ein Nutzer kann sich private Notizen anlegen und diese auf dem Kolab-Server speichern. Notizen knnen per E-Mail verschickt oder mit anderen Kolab-Nutzern ber IMAP ausgetauscht werden. Notizen werden fr jeden Kolab-Nutzer innerhalb eines eigenen IMAP-Benutzerordners auf dem KolabServer als multi-part-MIME-E-Mail gespeichert. Das exakte Dateiformat ist im Kolab2 Storage Format Specification zu finden (Link im Anhang A)
5.9 Aufgaben
Ein Nutzer kann sich private Aufgaben anlegen und diese auf dem Kolab-Server speichern. Aufgaben knnen per E-Mail verschickt und mit andern Kolab-Nutzern ber IMAP ausgetauscht werden. Aufgaben werden fr jeden Kolab-Nutzer innerhalb eines eigenen IMAP-Benutzerordners auf dem Kolab-Server als multi-part MIME E-Mail gespeichert und folgt dem iCalendar-Standard (RFC 2446). Das exakte Dateiformat ist im Kolab2 Storage Format Specification zu finden (Link im Anhang A).
54
5.10 GemeinsamesNutzenvonIMAPOrdnern
IMAP-Ordner knnen gleichzeitig von mehreren Benutzern genutzt werden. Dies lsst sich ber zwei unterschiedliche Varianten realisieren: 1. Entweder ber freigegebene IMAP-Benutzerordner, auf die andere Anwender Zugriffsberechtigungen erhalten, 2. oder ber gemeinsam genutzte IMAP-Ordner ohne Konto (kurz: kontolose Ordner), die zentral von Administratoren/Verwaltern/Domnenverwaltern 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. Unspezifizierte Ordner werden als E-Mail-Ordner angesehen. Zugriffsrechte knnen allen Benutzern, bestimmten Gruppen oder individuellen Benutzern vergeben werden. Es ist mglich verschiedenen UIDs unterschiedliche Berechtigungen zuzuweisen. Der Zugang zu den freigegebenen bzw. kontolosen Ordnern wird ber die Cyrus-ACL-Einstellungen geregelt. 5.10.1 FreigegebeneBenutzerordner Ein Nutzer kann in seinem Kolab-Klienten neue Unterordner innerhalb seines Kontos erzeugen. Alternativ kann der Systemadministrator mit dem Cyrus-Administrationswerkzeug /kolab/bin/cyradm und dem Befehl createmailbox (cm) einen neuer Ordner fr den Nutzer erstellen. Auf dem Kolab-Homeserver werden diese Ordner unterhalb des jeweiligen Kontopfades angelegt. Die Zugriffsrechte knnen entweder direkt vom Nutzer im Kolab-Klienten oder vom Systemadministrator mit dem Befehl setaclmailbox (sam) im Cyrus-Administrationswerkzeug /kolab/bin/cyradm festgelegt werden. Auf einen Ordner knnen folgende vordefinierte Zugriffsrechte (ACLs) angewandt werden:
none read (lrs) post (lrsp) append (lrsip) write (lrswipkxte) delete (lrxte) all (lrswipkxte)
Darber hinaus lsst 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-Seite von cyradm (unter dem Befehl sam) zu finden: /kolab/bin/openpkg man cyradm.
55
5.10.2 GemeinsamgenutzteIMAPOrdnerohneKonto Achtung: Die Nutzung von kontolosen Ordnern wird nicht empfohlen! Grund: Viele Funktionen, die bei normalen Konten leicht funktionieren, sind bei kontolosen Ordnern nicht, nur schwierig oder nur ber Umwege erreichbar (wie z. B. Unterordner, E-Mail-Zustellung, EMail-Alias-Eintrge, Sieve-Skripte, Administrierbarkeit ber IMAP-Klient). Kontolose Ordner und deren Zugriffsrechte knnen nur von Administratoren, Verwaltern und Domnenverwaltern direkt am Kolab Server angelegt und verwaltet werden (z. B. ber den Web-Admin). Kontolose Ordner befinden sich im Mail-Spool-Verzeichnis auf gleicher Ebene wie die Benutzerkonten. Der Speicherplatz fr den Ordner ist unbegrenzt, sofern keine Plattenplatzbeschrnkung angegeben wird.
Abbildung5.13:AnlegeneinesgemeinsamgenutztenIMAPOrdnersohneKontoimWebAdmin
56
5.11 Quotas
Mit dem Kolab Server knnen Plattenplatzbeschrnkungen der Benutzerkonten verwaltet werden. Es kann ein Hardquota und ein Prozentsatz, ab dem Quotawarnungen auftreten, definiert werden (siehe unten). Die Quota-Einstellungen werden vom Kolab Web-Admin (oder einem anderen Verzeichnisdienst-Werkzeug) gesetzt und in den Verzeichnisdienst geschrieben. Kolabd leitet diese nderungen an den Cyrus weiter (vgl. Abschnitt 2.4). Ein Systemadministrator kann das Quotaverhalten seiner Nutzer beobachten, um ggf. immer wiederkehrende Quota-Warnungen eines Benutzers frhzeitig zu erkennen und das berschreiten der HardquotaGrenze zu verhindern. Mit dem Cyrus Quota Manager cyrquota kann eine Auflistung von allen Postfchern mit ihrer aktuellen Gre und ihren gltigen Quotas aufgerufen werden (als root oder kolab-r):
/kolab/bin/cyrquota
Wichtig: Es sollte beachtet werden, die Quota-Einstellungen nicht manuell im Cyrus zu setzen, da diese nderungen von kolabd mit den bisherigen Eintrgen aus dem LDAP-Baum beim nchsten Synchronisieren berschrieben werden knnen. Hardquota Administratoren, Verwalter und Domnenverwalter sind berechtigt den maximalen Speicherplatz (Hardquota) von jedem Benutzer zu definieren. Wird kein Wert angegeben, hat der Benutzer unbegrenzt Speicherplatz zur Verfgung. Die Hardquota wird im Kolab Web-Admin in der Benutzerverwaltung konfiguriert. berschreitet ein Benutzer seine Hardquota, werden alle an diesen Benutzer adressierten E-Mails abgewiesen. Es ist dann auch nicht mehr mglich neue Daten in den betroffenen IMAP-Benutzerordnern zu speichern. Quotawarnung berschreitet ein Benutzer einen definierten Prozentsatz an belegten Plattenplatz, erhlt er so lange eine Quotawarnung (per E-Mail und beim IMAP-Synchronisieren im Kolab-Klienten) bis sein Speicherplatz wieder unter dem Grenzwert liegt. Der Prozentsatz wird im Web-Admin-Interface unter der Rubrik Dienste eingestellt. Die Voreinstellung ist 80%. Der definierte Prozentsatz gilt dann fr alle KolabBenutzer. 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;) gendert werden.
57
5.12 MasterundSlaveserver/Homeserver
Kolab kann mit mehreren, zusammenarbeitenden Kolab-Servern betrieben werden. Dies kann aus Grnden der Leistung oder verschiedener Standorte sinnvoll sein (vgl. Abschnitt 3.4). Die Kolab-Server werden als Master und Slave bezeichnet. Der Master-Server hlt das Original des Verzeichnisdienstes. Der OpenLDAP-Replikationsmechanismus sorgt dafr, dass auf allen Slave-Servern der gleiche Stand des Verzeichnisdienstes vorgehalten wird. ndern sich Daten im Verzeichnisdienst des Master-Servers, wird der Replikationsprozess angestoen und die Daten werden mit allen Slave-Servern synchronisiert. Wichtig: Bei diesem Replikationsmechanismus werden nur die Verzeichnisdienstdaten (also z. B. Angaben zu allen angelegten Kolab-Konten) synchronisiert. Die eigentlichen IMAP-Benutzerordner (mit EMails, Kontakten, Terminen etc.) werden lediglich auf einem (Master- oder Slave-)Server vorgehalten dem sogenannten Kolab-Homeserver (Nheres siehe unten). Nur der Master-Server kann auf den OpenLDAP-Verzeichnisdienst schreiben. Aus diesem Grund muss beim Einrichten eines neuen Slave-Servers die URI des Master-Servers angegeben werden (vgl. folgender Abschnitt Einrichten eines neuen Slave-Servers). Fr jedes Kolab-Konto muss ein Homeserver zugeordnet werden, auf dem die jeweiligen Nutzerdaten gespeichert werden (vgl. Abschnitt 5.2.4). Jeder Homeserver (egal ob Master oder Slave) kann E-Mails direkt annehmen, sofern dieser Server im MX-Record eingetragen ist. Zum Synchronisieren eines IMAP-Benutzerordners muss der Anwender in seinem Kolab Klienten die Adresse seines Homeservers einrichten. Mit dem Web-Admin-Interface (in der Rubrik Dienste) knnen die verwendeten Kolab-Hosts verwaltet werden, indem Rechnernamen von weiteren Kolab-Slave-Servern gesetzt oder wieder entfernt werden. Vorsicht: Der Web-Admin in Kolab Server 2.2 beta2 ermglicht, alle Hosts, und damit auch den MasterServer(!), zu lschen. Dies sollte unbedingt vermieden werden, da sonst keine Verbindung mehr zum Verzeichnisdienst besteht!
Abbildung5.14:DasInterfacezumVerwaltenvonKolabHosts(imWebAdmin)
EinrichteneinesneuenSlaveServers 1. Hinzufgen 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) fr den neuen Server:
/kolab/etc/kolab/kolab_bootstrap -b
58
Dabei sind folgende Einstellungen zu bercksichtigen: - 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 fhrt anschlieend (als root) per ssh einige Kommandos auf dem MasterServer aus und kopiert per scp Daten vom Master- zum Slave-Server. Dafr wird einige Male das root-Passwort vom Master-Server bentigt. Daneben benutzt das Skript bei der Generierung eines SSL-Zertifikats fr den neuen Server die Zertifizierungsstelle (CA) des Master-Servers. Dafr wird das CA-Passwort bentigt. Anmerkung: Whrend des Kopierens der LDAP-Daten vom Master-Server wird der MasterLDAP-Server fr ein kurze Zeit heruntergefahren und anschlieend wieder gestartet. Dies wird automatisch vom Bootstrap-Skript durchgefhrt. 3. Abschlieend kann der neue Slave-Server gestartet werden:
/kolab/bin/openpkg rc all start
5.13 Datensicherungundwiederherstellung
Datensicherung Dieser Abschnitt gibt die Antwort auf die Frage: Welche Daten sollten fr eine Sicherung des KolabServers bercksichtigt werden? Die Datensicherung des Kolab-Servers kann im laufenden Betrieb durchgefhrt werden, um die Verfgbarkeit des Servers zu gewhrleisten. Wenn nicht anders angegeben, erfolgen alle Schritte bei der Datensicherung als root. A) EMails Es sollte das komplette Verzeichnis /kolab/var/imapd/spool gesichert werden. Der Cyrus IMAP speichert hier alle E-Mails als einzelne Dateien in verschiedenen Unterordnern. Details zur IMAP Spool Struktur gibt es unter Abschnitt 5.5. Zustzlich sollte das Verzeichnis /kolab/var/imapd/domain gesichert werden. Darin befinden sich die .seen- und die .sub-Dateien (analog zum Spool-Verzeichnis nach Domain und Nutzer sortiert). seen sichert, welche E-Mails gelesen/ungelesen sind und sub (subscribe) speichert, welche Ordner vom Nutzer abonniert wurden. Werden whrend der Sicherung E-Mails empfangen/bearbeitet/gelscht o.., luft die Sicherung ohne Probleme weiter. Diese aktuellen nderungen werden beim nchsten Backup erfasst.
59
B) mailboxes.db Es sollte die Datei /kolab/var/imapd/mailboxes.db gesichert werden. Sie enthlt eine Liste aller E-Mail-Postfcher 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 unabhngig vom benutzten Datenbankformat 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 enthlt u. a. fr alle IMAP-Ordner die Information, um welchen Ordnertyp es sich handelt (E-Mail, Kalender etc.). Es wird empfohlen den Inhalt der (Berkeley) Datenbank-Datei als Textdatei zu sichern:
/kolab/bin/db_dump /kolab/var/imapd/annotations.db > annotations_db_backup.txt
D) OpenLDAPDatenbank Die OpenLDAP-Datenbank sollte im LDIF-Format in einer Textdatei gesichert werden:

/kolab/sbin/slapcat -l ldap_db_backup.ldif
E) KolabKonfigurationsverzeichnis Es sollte das komplette Verzeichnis /kolab/etc gesichert werden. Es enthlt alle Konfigurationsdateien und Templates fr 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
Nhere Information zu SpamAssassin finden Sie unter Abschnitt 5.5.9.
60
Datenwiederherstellung Dieser Abschnitt gibt die Antwort auf die Frage: Wie lassen sich Daten aus der Sicherung wiederherstellen? A) EMails Zum Wiederherstellen der E-Mails von allen Benutzern muss das gesicherte IMAP-Spool-Verzeichnisses vollstndig in das Verzeichnis /kolab/var/imapd/spool zurckgespielt werden. Dies kann z. B. mit rsync erfolgen. Zustzlich sollte in dem Verzeichnis /kolab/var/imapd/domain alle seen- und subscribeInformationen wiederhergestellt werden. Ein Kopieren dieses Verzeichnisses aus dem Backup sollte hier ausreichen.
Alternativ knnen 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 Unterordner zur Verfgung zu stellen. Dies ist am sichersten, da so Konflikte vermieden werden. Darber 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 Zurck 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 gehren mssen, ist zunchst ein Wechsel auf diesen Benutzer ntig:
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 Abschlieend mssen 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. Unglcklicherweise gibt cyrreconstruct keine Fehlermeldung aus, wenn die Operation erfolglos war, oder das angegebene Postfach nicht existiert.
61
4. Quota wiederherstellen Wenn auf dem Kolab-Server Quotas fr Benutzer definiert sind, sollte nach manuellen nderungen am IMAP-Spool-Verzeichnis der Befehl
cyrquota -f
aufgerufen werden. Dieser aktualisiert die vom Cyrus IMAP gespeicherten Quotainformationen. 5. Seen- / Subscribe-Informationen wiederherstellen Um die Informationen ber ungelesene E-Mails und abonnierter Ordner wiederherzustellen, mssen in die entsprechenden Unterordnern von /kolab/var/imapd/domain alle gesicherten 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 Fr die Wiederherstellung der annotations_db_backup.txt bentigt: annotations.db wird die gesicherte Textdatei
/kolab/bin/db_dump /kolab/var/imapd/annotations.db > annotations_db_backup.txt
D) OpenLDAPDatenbank Die Wiederherstellung der OpenLDAP-Datenbank nutzt die gesicherte .ldif-Datei.

su 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 anschlieend die DB_CONFIG neu generiert wird (dieser Befehl muss als root ausgefhrt werden!):
/kolab/sbin/kolabconf
Nach erfolgreicher Wiederherstellung kann das backup/tmp-Verzeichnis gelscht werden.
62
E) KolabKonfigurationsverzeichnis Das vollstndig gesicherte Konfigurationsverzeichnis sollte unter /kolab/etc wiederhergestellt werden (z. B. mit rsync). F) SpamAssassin Zum Wiederherstellen der Bayes-Datenbank von SpamAssassin wird die angelegte Textdatei bentigt:
/kolab/bin/sa-learn --restore sa_db_backup.txt
Die Bayes-Datenbank kann auch auf einen neuen Server wiederhergestellt werden. Es kann aber unter Umstnden effektiver sein, wenn SpamAssassin von Grund auf neu lernt; insbesondere wenn es sich um unterschiedliche Domains handelt.
5.14 Dienste
Im Kolab Web-Admin lassen sich unter der Rubrik Dienste verschiedene Dienste des Kolab Servers aktivieren oder deaktivieren. Anmerkung: Bei Kolab1 wurden Frei/Belegt-Informationen durch den Klient per FTP/HTTP hochgeladen. Kolab2 generiert diese Informationen nun serverseitig. Daher fehlt die FTP-Server-Variante und WebDAV ist im HTTP-Server deaktiviert.
Abbildung5.15:WebAdminMaskezumEinundAusschaltenvonDiensten
63
6 KolabKlienten
Ziel dieses Kapitels ist es, einen allgemeinen berblick ber die verschiedenen Kolab-Klienten zu geben und auf weiterfhrende Dokumentationen zu verweisen.
6.1 KDEKontact
KDE Kontact ist ein Groupware-Klient fr KDE, der viele Einzelprogramme (u. a. KMail, KAdressbook, KOrganizer, KNotes) aus der KDE-Umgebung zu einem Programm bndelt. Eine Anleitung zur Konfiguration von Kontact ist in der Kolab-Dokumentation Doc2 zu finden (Link im Anhang A).
6.2 MicrosoftOutlook
Um Microsoft Outlook als Kolab Klient verwenden zu knnen, muss ein Outlook-Konnektor, auf dem Windows-Rechner installiert sein. Es gibt zwei (proprietre) Konnektoren fr Outlook, die mit dem Kolab Server zusammenarbeiten [Stand: Dezember 2007]: der Toltec Connector und der KONSEC Konnektor. Im folgenden Abschnitt werden beide Konnektoren kurz vorgestellt und Verweise zum aktuellen Handbuch gegeben. 6.2.1 ToltecConnector Der Toltec Connector1 ist ein proprietres Plugin fr Microsoft Outlook. Die Firma Radley Network Technologies CC (Sdafrika) brachte Toltec Connector 1 im Oktober 2003 auf dem Markt. Die zweite Generation des Toltec Connectors implementiert das Kolab2 XML-Format. Die derzeit aktuelle Version ist Toltec Connector 2.2.0 (vom 27.10.2007). Eine 30-Tage-Testversion kann auf der Toltec-Website heruntergeladen werden.
http://www.toltec.co.za [Abruf: 07.12.2007]
64
6 Kolab-Klienten
Die offizielle (englischsprachige) Dokumentation des Toltec Connectors (User Manual 2.0) mit detaillierten Konfigurationsschritten ist unter http://www.toltec.co.za/downloads.html verfgbar. Eine (englischsprachige) Anleitung fr die Konfiguration von Outlook2003 in Verbindung mit dem Toltec Connector ist in der Kolab-Dokumentation Doc3 verfgbar (vgl. Anhang A). Weitere (aktuelle) Informationen sind im Kolab-Wiki2 zu finden. 6.2.2 KonsecKonnektor Im Gegensatz zum Toltec Connector ist der KONSEC Konnektor3 als MAPI Storage Provider fr Microsoft Outlook konzipiert und verwendet nicht die Outlook-Plugin-Schnittstelle. Der Konnektor wird von der KONSEC GmbH in Stuttgart entwickelt. KONSEC Konnektor 1.0 ist im Juni 2005 erschienen. Die Version 1.1.6.4 wurde am 9.11.2007 verffentlicht. Eine 30-Tage-Testversion kann auf der Internetseite von KONSEC heruntergeladen werden. Der KONSEC Konnector untersttzt aktuell die Sprachen Englisch, Deutsch und Franzsisch. Die offizielle Dokumentation des KONSEC Konnektors ist mit ausfhrlicher Installations- und Konfigurationsanleitung unter http://download.konsec.com/ in Deutsch und Englisch verfgbar (Version 1.1 mit letzter Aktualisierung vom 18.10.2007). Weitere (aktuelle) Informationen sind im Kolab-Wiki4 zu finden.
6.3 HordeWebklient
Horde (http://horde.org) ist ein Webklient fr Kolab mit dem Kolab-Benutzer Groupwarefunktionalitten (wie E-Mail, Kalender, Adressbuch, Aufgaben etc.) im Webbrowser nutzen knnen. Horde ist Bestandteil von Kolab Server 2.2. Das Webinterface kann ber http://kolab.example.com/horde aufgerufen werden. Achtung: Die Anbindung von Horde ist aktuell noch in der Entwicklung und ist derzeit erst als Beta-Version in Kolab Server 2.2 integriert. Der Horde Webklient ist daher nur begrenzt fr den produktiven Betrieb empfohlen. Zu beachten ist auerdem, dass Webklienten viel Last auf dem Server erzeugen knnen. Bei einer groe Anzahl an Kolab-Nutzern ist es daher ratsam, den Webklienten auf einem getrennten Server laufen zu lassen.
2 3 4
http://wiki.kolab.org/index.php/Toltec_Connector [Abruf: 07.12.2007] http://www.konsec.com [Abruf: 07.12.2007] http://wiki.kolab.org/index.php/KONSEC_Konnektor [Abruf: 07.12.2007]
65
Anhang
66
A Weiterfhrende Informationen
DieoffizielleWebsitevonKolab http://www.kolab.org KolabWiki http://wiki.kolab.org Das Kolab-Wiki ist offen fr die ganze Kolab-Gemeinschaft. Jeder kann, nach einer Anmeldung, selbststndig Anleitungen, Hinweise, etc. zu Kolab eintragen. Es handelt sich dabei in der Regel um ntzliche, aber nicht offiziell geprfte Angaben. Daher erfolgt die Verwendung auf eigenes Risiko. KolabMailinglisten

kolab-users (http://kolab.org/mailman/listinfo/kolab-users) Mailingliste fr 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 fr offizielle Ankndigungen (neue Kolab-Versionen, Sicherheitshinweise etc.). Englischsprachig. kolab-format (http://kolab.org/mailman/listinfo/kolab-format) Mailingliste fr Diskussionen ber die Kolab-Format-Spezifikation. Englischsprachig. kolab-commits (http://kolab.org/mailman/listinfo/kolab-commits) Mailingliste ausschlielich fr automatische Commit-Mitteilungen des Kolab-Versionskontrollsystems CVS. Jede nderung im CVS wird unmittelbar an diese Mailingliste gesendet. Englischsprachig.
67
KolabCVS Der Kolab-Server-Quellcode wird derzeit ber das Versionskontrollsystem CVS verwaltet. Informationen zum CVS-Zugriff: http://kolab.org/cvs-kolab.html Web-CVS-Viewer: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/ KolabIssueTracker Um Fehler oder Wnsche an die Kolab Gemeinschaft zu richten, kann der Kolab-Issue-Tracker unter https://issues.kolab.org verwendet werden. Zum Eintragen ist eine Registrierung erforderlich. Englischsprachig. KolabDokumentationen Neben dieser vorliegenden Betriebsdokumentation gibt es unter http://kolab.org/documentation.html folgende weitere Dokumentationen zu Kolab2: doc2 Installation und Konfiguration des Kolab-Servers und KDE-Klienten (Englisch, v1.72, Juni 2007 und Deutsch, v1.64, Mai 2005) doc3 Konfiguration von Outlook2003 mit dem Toltec Connector (Englisch, v1.37, Juli 2007) Kolab2 Architecture Paper (Englisch, Version Draft cvs20060921) Kolab2 Storage Format Specification (Englisch, Version Release Candidate 2.0rc5) KolabRawHowtos(imCVS) Ntzliche Kurzanleitungen zur Konfiguration von Kolab2, so genannte Raw-Howtos, stehen unter http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/raw-howtos/ im Kolab CVS zur Verfgung. 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
AdministratorHinweise(aufdemKolabServer) Im Verzeichnis /kolab/share/doc/ befinden sich verschiedene Hilfedateien zur Konfiguration des Kolab Servers: ./kolabd/README.amavisd (Virus- und Spamfilter-Einstellungen) ./kolabd/README.ldapdelete (Lschen von LDAP Objekten) ./kolabd/README.outlook (Weiterleitung von iCalendar-Einladungen in Microsoft Outlook) ./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 fr die Installation von kolab-filter (nur relevant fr nicht-OpenPKG-Plattformen)

./kolab-freebusy/INSTALL
Hinweise fr die Installation von kolab-freebusy (nur relevant fr nicht-OpenPKG-Plattformen)
A.1 DieKolabGemeinschaft
Kolab ist ein Freie-Software-Produkt, bei dem jeder mithelfen kann, die Funktionalitt der Software zu erweitern. Eine aktive, weltweite Gemeinschaft hat sich um Kolab herum gebildet. Fr den Kontakt mit der Kolab-Gemeinschaft eignet sich am Besten die Kolab-Mailinglisten (siehe oben).
69
A.2 DasKolabKonsortium
Das Kolab-Konsortium steuert die Weiterentwicklung und bietet professionelle Beratung und Support fr die Freie Groupwarelsung Kolab. Das Kolab-Konsortium wird getragen durch folgende drei Partnerunternehmen: IntevationGmbH Georgstrae 4 49074 Osnabrck Deutschland www.intevation.de Geschftsfhrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner KlarlvdalensDatakonsultAB Rysktorp SE-683 92 Hagfors Sweden www.klaralvdalens-datakonsult.se Geschftsfhrer: Matthias Kalle Dalheimer erfrakonPartG Nobelstrae 15 70569 Stuttgart Deutschland www.erfrakon.de Partner: Tassilo Erlewein, Achim Frank, Martin Konold Das Produkt Kolab wurde ursprnglich im Jahre 2002 durch ein Joint Venture der drei o. g. Firmen ins Leben gerufen (vgl. Abschnitt 1.2). Kontakt: Kolab-Konsortium c/o Intevation GmbH Georgstrae 4 49074 Osnabrck Deutschland http://www.kolab-konsortium.de/ info@kolab-konsortium.de Telefon: ++49-541-33 50 8 50
70
B Glossar
cyradm Ein kommandozeilenbasiertes Cyrus-Administrationswerkzeug. EMailAlias Ein Synonym-Adresse fr die primre E-Mail-Adresse eines Benutzers. Eintreffende Nachrichten werden an die primre Adresse weitergeleitet. EindeutigeIdentitt Siehe unter UID ExterneAdresse Ein Nicht-Kolab-Benutzer, der im Kolab-Adressbuch und damit im Verzeichnis eingetragen ist. Frei/BelegtListe Eine Option im Kalender zum Anzeigen von Frei/Belegt-Zeiten der ausgewhlten Kolab-Konten (engl.: free/busy). KontoloserOrdner Ein IMAP-Ordner ohne zugehriges Konto, auf den ausgewhlte Kolab Benutzer Zugriff haben. Alternative: freigegebene Benutzerordner Gruppenkonto Analog zum Benutzerkonto reprsentieren Gruppenkonten eine Gruppen; vgl. Abschnitt 5.3). HomeServer/Heimatserver Der Kolab-Server auf dem ein Konto gespeichert ist. IMAP Das Internet Message Access Protocol erlaubt den Zugriff auf und die Verwaltung von empfangenen E-Mails.
Account Gleichzusetzen mit einem Konto annotations.db Speichert u. a. fr jeden IMAP-Ordner den Typ (E-Mail, Kalender, Kontakte, Notizen, Aufgaben, Journal). AuthentifizierteNutzer Anwender, der sich mit Benutzername (UID) und Passwort am KolabServer angemeldet hat. Benutzerkonto Ein normales Benutzerkonto (vgl. Abschnitt 5.3). Benutzername Zur Anmeldung am Kolab Web-Admin kann sowohl die UID als auch die primre E-Mail-Adresse eines Nutzers als Benutzername verwendet werden. Bevollmchtigter Gleichzusetzen mit einem Vertreter Bootstrapping Die initiale Konfiguration des Kolab-Servers.
71
B Glossar
Kontotyp Jedem Kolab-Konto muss eines der vier Kontotypen zugeordnet sein: Benutzer-, Internes Benutzer-, Gruppen- oder Ressourcenkonto. LDAP Das Lightweight Directory Access Protocol erlaubt die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes. MasterServer Zentraler Kolab-Server mit dem ggf. ein oder mehrere Slave-Server verbunden sind. MTA Ein Transfer Agent (auch Mail/Message Transport Agent) dient zum Transportieren und Verteilen von E-Mails. FreigegebenerBenutzerordner Ein IMAP-Benutzerordner ist dann freigegeben, wenn (anhand gesetzter ACLs) fr ausgewhlte Nutzer der Zugriff auf diesen Ordner ermglicht wird. Ordner Siehe unter IMAP-Ordner
IMAPOrdner Jedes Konto besteht aus einem oder mehreren IMAP-Ordnern. Zu jedem Ordner wird in der annotations.db u. a. der Ordner-Typ gespeichert (E-Mail, Kalender, etc.). Ein Ordner kann auch mehrere Unterordner besitzen. InternesBenutzerkonto Wie Benutzerkonto; jedoch ist die primre E-Mail-Adresse nur innerhalb des (privilegierten) Kolab-Netzes gltig. Konnektor Eine Software fr Klienten wie Microsoft Outlook oder Thunderbird, um eine Verbindung mit dem Kolab-Server aufzubauen und KolabGroupwarefunktionalitten zu nutzen. Konto Zu jedem Kolab-Nutzer wird im Verzeichnisdienst ein Konto angelegt.
Postfach Jedes Konto kann mehrere IMAP-Ordner besitzen. In jedem IMAPOrdner knnen E-Mails empfangen werden. Somit kann jeder IMAPOrdner als Postfach bezeichnet werden. PrimreEMailAdresse Standard E-Mail-Adresse eines Kontos; kann identisch mit der UID sein. Die primre Adresse ist nach dem Anlegen eines Kontos nicht mehr nderbar. Zur Anmeldung am Kolab Web-Admin kann sowohl die UID als auch die primre E-Mail-Adresse eines Nutzers als Benutzername verwendet werden. Quota Quota beschreibt eine durch den Administrator definierte, serverbasierte Speicherplatzbegrenzung fr Benutzer. Der Benutzer erhlt regelmig Quotawarnungen, sobald er einen definierten Prozentsatz seines Speicherplatzes berschreitet. Relayhost Mailserver, der E-Mails empfngt und an einen bestimmten Host weiterleitet; je nach Funktion wird ein Relayhost auch als Smarthost bezeichnet. Ressourcenkonto Ressourcenkonten dienen zum Verwalten von Ressourcen (wie z.B. Beamer, Besprechungsraum); vgl. Abschnitt 5.3 Sieve Skriptsprache zum serverseitigen Filtern von E-Mails nach RFC 3028. SlaveServer Ein weiterer Kolab-Server, der mit dem Master-Server und ggf. weiteren 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 primre E-Mail-Adresse als Benutzernamen genutzt werden. Verteilerliste Eine Mailingliste, die am Kolab-Server eingerichtet wird. Mitglieder
72
B Glossar
einer Verteilerliste knnen nur Nutzer sein, deren E-Mail-Adresse im Verzeichnisdienst gespeichert ist - entweder im Kolab Konto oder im Kolab Adressbuch (engl.: distribution list). Vertreter(EMail) Ein E-Mail-Vertreter darf im Namen des beauftragten Benutzers EMails versenden und. Vertreter werden auch als Bevollmchtigte (engl.: delegates) bezeichnet. WebAdmin Ein Administrations-Webinterface zur Konfiguration des Verzeichnisdienstes vom Kolab-Servers. Kolab-Nutzer knnen darber ihre eigenen Daten ndern und eins der drei vordefinierten Sieve-Skripte aktivieren.
73
C GNUFreeDocumentation License
Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
0.PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
1.APPLICABILITYANDDEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
74
C GNU Free Documentation License

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
2.VERBATIMCOPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies.
75
3.COPYINGINQUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) 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-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
4.MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers.
76

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
5.COMBININGDOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements."
6.COLLECTIONSOFDOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
7.AGGREGATIONWITHINDEPENDENTWORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When
the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
77
8.TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
9.TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
10.FUTUREREVISIONSOFTHISLICENSE
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 version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
ADDENDUM
To use this License in a document you have written, include a copy of the License in the document and put the following copyright 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 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". If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this: with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
78

Allgemeine-Betriebsdokumentation-KolabServer22 20080103 1.0

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Allgemeine-Betriebsdokumentation-KolabServer22 20080103 1.0

Hochgeladen von

Copyright:

Verfügbare Formate

AllgemeineBetriebsdokumentation

Aktueller Status: Fertig gestellt

5.3 5.4 5.5

5.8 5.9 5.10

5.11 5.12 5.13 5.14

A.1 Die Kolab-Gemeinschaft......................................................................69 A.2 Das Kolab-Konsortium.......................................................................70

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

2 Die Komponenten des Kolab Servers

Horde Horde ist ein webbasierter Klient fr Kolab.

Perl Perl ist eine serverseitige, plattformunabhngige und interpretierte Skriptsprache.

PHP PHP ist eine serverseitige und in HTML-Quelltext integrierbare Skriptsprache.

2 Die Komponenten des Kolab Servers

2 Die Komponenten des Kolab Servers

2 Die Komponenten des Kolab Servers

2 Die Komponenten des Kolab Servers

2 Die Komponenten des Kolab Servers

2 Die Komponenten des Kolab Servers

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

Bedeutung der Werte:

3 Kolab Server Bedarfsplanung

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

3 Kolab Server Bedarfsplanung

4 Kolab Server Vorbereitung und Installation

4 Kolab Server Vorbereitung und Installation

4 Kolab Server Vorbereitung und Installation

Ein exemplarischer(!) Bootstrapping-Prozess Eingabe des Hostnamens

Auswahl Master Server

Eingabe der Maildomain (Besttigung der Defaultangabe mit Enter)

Eingabe eines sicheren Managerpasswortes (Besttigung der Defaultangabe mit Enter)

4 Kolab Server Vorbereitung und Installation

Erstellen einer eigenen Test-Zertifizierungsstelle und eines Zertifikats

<<Ende des exemplarischen Bootstrappings-Prozesses>>

4 Kolab Server Vorbereitung und Installation

und sicherstellen, dass kein LDAP-Prozess mehr luft:

4 Kolab Server Vorbereitung und Installation

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/ [Abruf: 07.12.2007]

4 Kolab Server Vorbereitung und Installation

2. Alle Kolab-Pakete lschen:

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

WiefindetmandenKolabHomeserverzueinembestimmtenEMailKonto? ...mit den Befehlen listusers und showuser:

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

kolabDeleteflag: kolab-master.example.com kolabDeleteflag: kolab-slave1.example.com kolabDeleteflag: kolab-slave2.example.com

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

address :domain :contains "From" "example.com" ) {

5 Kolab Server Konfiguration und Betrieb

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

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb

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

5 Kolab Server Konfiguration und Betrieb

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

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

5 Kolab Server Konfiguration und Betrieb

5 Kolab Server Konfiguration und Betrieb