Allgemeine Betriebsdokumentation

Transkript

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

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

3 Inhaltsverzeichnis Kapitel 1: Einführung Was ist Kolab?...6 Entwicklungshistorie von Kolab...7 Was ist neu in Kolab Server 2.2?...8 Kapitel 2: Die Komponenten des Kolab Servers Übersicht...9 Interaktion der Komponenten...11 OpenPKG...12 Kolabspezifische Komponenten...13 Kapitel 3: Kolab Server Bedarfsplanung Festplattenspeicher...17 Rechenleistung / Hauptspeicher...18 Verfügbarkeit...18 Wer arbeitet mit wem?...19 Kapitel 4: Kolab Server Vorbereitung und Installation Installationsvorbereitung...20 Installation...22 Aktualisierung...25 Deinstallation...27 Kapitel 5: Kolab Server Konfiguration und Betrieb Kolab Web-Admin...28 Rollen Administrator Verwalter Domänenverwalter Benutzer...31 Kontotypen...33 Nutzerlebenszyklus Die IMAP Spool Struktur Der Weg einer Weiterleitung Abwesenheitsbenachrichtigung Serverseitige Filterung mit Sieve Vertreter Verteilerlisten

4 Virenfilter-Konfiguration Spamfilter-Konfiguration Domänen Administrative -Adressen Sicherheitseinstellungen...48 Adressbuch...51 Kalender Einladungen Frei/Belegt-Listen...53 Notizen...54 Aufgaben...54 Gemeinsames Nutzen von IMAP-Ordnern Freigegebene Benutzerordner Gemeinsam genutzte IMAP-Ordner ohne Konto...56 Quotas...57 Master- und Slaveserver / Homeserver...58 Datensicherung und -wiederherstellung...59 Dienste...63 Kapitel 6: Kolab Klienten KDE Kontact...64 Microsoft Outlook Toltec Connector Konsec Konnektor...65 Horde Webklient...65 Anhang 66 Anhang A: Weiterführende Informationen 67 A.1 Die Kolab-Gemeinschaft...69 A.2 Das Kolab-Konsortium...70 Anhang B: Glossar 71 Anhang C: GNU Free Documentation License 74 4

5 1 Einführung Kolab ist eine Freie Lösung, die Groupware-Funktionalitäten bietet. Kolab 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 für die Zusammenarbeit innerhalb einer Arbeitsgruppe konzipiert ist und die Arbeitsabläufe rationalisieren und automatisieren soll. In der Regel besteht Groupware aus Anwendungen, die typische Organizer-Funktionen (wie Kalender, Kontakte, Aufgaben, Notizen) sowie Funktionen für den Austausch von s und die gemeinsame Bearbeitung von Dateien bereitstellen. Die vorliegende Betriebsdokumentation konzentriert sich auf den Kolab Server und unterstützt beim Aufsetzen und Betreiben eines solchen Groupware-Servers. Diese Dokumentation richtet sich an Systemadministratoren, die Server-Anwendungen betreuen. Kenntnisse über den Kolab Server werden nicht vorausgesetzt. Grundlegende Erfahrungen mit Server-Anwendungen sind jedoch erforderlich; wünschenswert 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 Fähigkeiten für Wartung und Betrieb zu vermitteln. Es existieren sehr vielfältige Möglichkeiten und Einsatzszenarien den Kolab Server zu nutzen, die anhand einiger konkreter Beispiele dargestellt werden. Auf die dabei getroffenen Annahmen wird jeweils hingewiesen. 5

6 1 Einführung Diese Betriebsdokumentation bezieht sich auf die OpenPKG-Variante von Kolab Server 2.2 (vgl. Abschnitt 2.3). Da Version 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 grundsätzlichen Leitfragen die Bedarfsplanung für den Einsatz eines Kolab-Servers erarbeitet. Hinweise zur Installation sowie praktische Anleitungen zur Installation, zum Update und zur Deinstallation des Kolab Servers werden im Kapitel 4 gegeben. Das Kapitel 5 Kolab Server Konfiguration und Betrieb beschreibt ausführlich die wichtigsten Einstellmöglichkeiten am Kolab Server und gibt praktische Hinweise für die eigene Konfiguration. Einen allgemeiner Überblick über die verfügbaren Kolab-Klienten stellt Kapitel 6 dar. Weiterführende Quellen mit Kontaktmöglichkeiten 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 männliche gemeint sind bei Personen jedoch immer Männer und Frauen, wie bei Nutzern und Nutzerinnen. Das Produkt Kolab Server wird in dieser Dokumentation stets ohne Bindestrich geschrieben. Handelt es sich um eine beliebige Implementation oder eine spezielle Installation des Produkts Kolab Server, so wird Kolab-Server mit Bindestrich verwendet. 1.1 Was ist Kolab? Kolab ist in erster Linie ein Konzept, wie mit Freier Software eine skalierbare, stabile und sichere Groupware-Lösung umgesetzt werden kann. In dieser Idee unterscheidet sich Kolab bereits von vielen anderen Produkten, welche Kommunikation und Arbeitsgruppen unterstützen möchten. Ein Nutzen von Kolab entsteht aus der Kombination mehrerer Softwarekomponenten. Für Anwender ist allein der Nutzen entscheidend. Als Administrator ist es jedoch nützlich die Zusammenhänge zu kennen; sie sind für einen täglichen Betrieb zwar nicht direkt erforderlich, erlauben aber oft, den Nutzen der Lösung für alle Beteiligten zu erhöhen. Bei Kolab entsteht der Nutzen im Zusammenspiel von Klient und Kolab-Server. Es werden GroupwareFunktionen zum Austauschen von s, Freigeben und Bearbeiten von Dateien sowie Verwalten von Kontakten, Terminen, Aufgaben und Notizen auf Basis offener Standards geboten. Nachfolgend einige wesentliche Eigenschaften des Kolab Servers: 6

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

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

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

10 2 Die Komponenten des Kolab Servers OpenLDAP OpenLDAP ist ein Verzeichnisdienst, der sich über das Protokoll LDAP (Lightweight Directory Access Protocol) abfragen lässt. URL: Dokumentation: Manual Pages: Spam und Virenscanner amavisd-new Amavisd-new ist ein in Perl implementierter scanner, der Nachrichten vom Mailserver entgegennimmt, diese (inkl. Anhang) auspackt und an definierte Viren- und/oder Spamfilter zur Überprüfung übergibt. URL: Dokumentation: ClamAV ClamAV (ClamAntiVirus) ist ein Virenscanner, der insbesondere auf Mailservern zum Einsatz kommt. URL: Dokumentation: SpamAssassin SpamAssassin ist ein in Perl implementierter -Filter, der zur Überprüfung und Identifizierung von unerwünschten Nachrichten eingesetzt wird. URL: Dokumentation: Kolab Webklient Horde Horde ist ein webbasierter Klient für Kolab. URL: Dokumentation: Allgemein Apache (HTTP-Server) Der HTTP-Server von Apache ist der meist verbreitete (freie) Webserver im Internet. URL: Dokumentation: Perl Perl ist eine serverseitige, plattformunabhängige und interpretierte Skriptsprache. URL: Dokumentation: PHP PHP ist eine serverseitige und in HTML-Quelltext integrierbare Skriptsprache. URL: Dokumentation: 10

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

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

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

14 2 Die Komponenten des Kolab Servers Abbildung 2.3: Arbeitsweise des Kolab Server Konfigurationssystems vereinfacht für einen Dienst. Der Verzeichnisdienst OpenLDAP gibt die kolabspezifischen Einstellungen per LDAP heraus. Ändern sich Einstellungen, zum Beispiel durch eine Konfiguration über den Kolab Web-Admin, so werden 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 geändert hat. Dies wird entweder automatisch gemacht: Dazu hängt kolabd bei OpenLDAP als Replikationsziel und lauscht auf Port Sobald sich etwas im Verzeichnisdienst ändert, teilt OpenLDAP dies kolabd mit. Der andere Weg, um kolabd mitzuteilen, dass sich etwas geändert hat, ist manuell den Befehl /kolab/sbin/kolabconf ausführen (Schritt 2 in der Abbildung gestrichelter Pfeil). 3. Anschließend ruft kolabd die benötigten Angaben der Änderungen per LDAP vom 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, liest anschließend das entsprechende Template ein, generiert daraus die passende Konfigurationsdatei und informiert abschließend den zugehörigen Dienst, der dann ggf. neu gestartet wird. 14

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

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

17 3 Kolab Server Bedarfsplanung Es empfiehlt sich den eigenen Bedarf für den Server abzuschätzen. Anhand von einigen Rahmenbedingungen werden in diesem Kapitel Hinweise für eine Grob-Planung gegeben. Dabei ist zu beachten, dass das Nutzungsmuster einen starken Einfluss auf die Bedarfsplanung hat. In manchen Organisation reichen beispielsweise 50 Megabyte -Speicherplatz und es werden pro Nutzer weniger als dreistellige Termine gespeichert. Bei Anderen wird zur Ablage großer 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 Tätigkeit eines Kolab-Servers ist es, für die Klienten -Daten zu liefern. Jedes Groupware-Objekt ist ebenfalls eine . In der Regel haben die meisten Nutzer deutlich mehr normale s als andere Groupware-Objekte, eine Bedarfsschätzung sollte also bei der anfangen. Der durchschnittliche -Speicherplatz in den nächsten Jahren, multipliziert mit der Anzahl der Nutzer und etwas Puffer ergibt den zu erwartenden Plattenplatz der Nutzerdaten. Aus der erwarteten Änderungsrate lässt sich auch der Platz für die Datensicherung abschätzen. Gegenüber den normalen s fallen die Termine und Kontakte meist nicht ins Gewicht. Wird als Klient Microsoft Outlook mit einem der verfügbaren Konnektoren verwendet (vgl. Abschnitt 6.2), ist es möglich, dass sich die Größe mancher s in der Speicherung verdoppeln. Nur so können manche Objekt-Attribute gespeichert werden, welche nur für Outlook wichtig sind. Wer ganz sicher gehen möchte, migriert auf ein Testsystem die alten Daten einiger repräsentativer Nutzer. 17

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

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