Category Archives: Open-Xchange

Beiträge zum Einsatz von Open-Xchange am Beispiel der anracon-Installation

Kontact 4.7 und OX 6 unter Opensuse 11.4 – Teil I

Posted on by

Einleitung

KDE 4.7 ist da. Damit erfolgte auch im KDE Factory Repository von Opensuse der Umstieg auf das akonadi-abhängige Kmail 2 – jetzt unter der Bzeichnung Kmail 4.7. Das aktuelle Gespann “Kontact 4.7/Kmail 4.7/Akonadi” hat aber ein Manko:

Es bietet keine Konnektoren mehr zum OpenXchange Server der Version 5 an. Siehe KDE-Bug https://bugs.kde.org/show_bug.cgi?id=258711.

Natürlich funktioniert der Zugriff von Kontact/Kmail 4.7 auf einen externen IMAP-Server – aber der ist eben unabhängig von spezifischen OX-Diensten wie der Pflege von Kontakt- und Adressdaten, von Kalender-Daten oder aber von Dokumenten.

D.h., die neueste KDE PIM Suite lässt sich z.Z. nur mehr mit dem Open-Xchange Server in der Version 6 (OX 6) betreiben. Für mich ist somit der Tag gekommen, an dem ich ernsthaft den schon seit längerem geplanten Umstieg von OX 5 auf OX 6 vorbereiten muss.

Kennt man Open-Xchange 6 gar nicht, so ist ein vernünftiger erster Schritt sicher der, den OX 6 zunächst einmal auf einem Testsystem auszuprobieren. In einem fehlertoleranten Umfeld mit (sehr) wenigen Usern reicht die Open-Xchange Community Edition [OX CE] auf einem Server, den man sich z.B. mit Opensuse 11.4 konfiguriert hat, für eine Testphase vollkommen aus. Bei uns läuft der OX 6 in diesem Sinne gerade testweise auf einem virtuellen, Opensuse 11.4 basierten Server unter XEN. Eine Diskussion der Gründe, warum ich als Basis für den OX-Server nicht unseren SLES 11 nehmen werde, würde hier zu weit führen.

Nachfolgend beschreibe ich in drei Blog-Beiträgen eine einfache Testinstallation auf einem Opensuse 11.4-System. (Ob dieses dabei XEN-basiert ist, ist bzgl. der OX-Funktionalität irrelevant.) Bei der Beschreibung gehe ich kurz auch auf Fallstricke, die z.B. bzgl. der Anbindung eines externe IMAP-Servers auftreten, ein.

Vor allem will ich aber testen, ob der KDE/Kontact 4.7 Zugriff auf den OX 6 funktioniert.
Mein Testszenario sieht daher etwa wie folgt aus:

OX6 Test

D.h., ich nutze einen bereits vorhanden Cyrus-IMAP-Server in unserem Netz. Ist ein solcher nicht vorhanden, kann man sein “OX 6”-Versuchssystem aber auch gegen einen externen IMAP-Server im Internet testen, bei dem man ggf. einen E-Mail-Account hat. Der Zugriff auf den OX6-Server soll über 2 Varianten möglich sein:

  • Einerseits möchte ich per Browser auf das OX6-Web-Frontend zugreifen. Dabei soll mir das Frontend nicht nur die Verwaltung von Kalendereinträgen, Tasks, Ressourcen unterstützen, sondern auch die Mails auf dem IMAP-Server anzeigen.
  • Andererseits wünsche ich mir natürlich den Zugriff auf Kalender-, Task- und Addressbuchfunktionalitäten des OX6 per KDE’s Kontact. Natürlich will ich per Kmail auch die Mails sehen – aber dass Kmail mit IMAP-Servern umgehen kann, ist bei unserem Test weniger von Belang, weil von Haus aus klar.

Zielsetzung Teil I / Ausblick auf Teil II

In diesem ersten Teil wollen wir auf einem Opensuse 11.4-Testsystem zunächst die Grundinstallation eines lokalen OX-Servers [ OX CE] ohne Installation eines IMAP-Servers durchführen. Letzteren setzen wir auf einem separaten Server im Netzwerk voraus. (Die Beschreibung einer Postfix/Imap-Installation würde hier zu weit führen. Erste grundsätzliche Hinweise zum Aufsetzen eines Postfix/Imap-Systems findet man hier “https://linux-blog.anracom.com/2009/01/29/kmail-kde-42-postfix-und-cyrus-imap-unter-ox/“).

nWir führen ferner keine Cluster-Installation mit Lastverteilung durch. Bis auf IMAP laufen alle erforderlichen Services lokal auf dem Testsystem ab.

Im zweiten Teil legen wir schließlich einen OX-Default-Kontext mit OX-Usern an und greifen über den OX6 auch auf den IMAP-Server zu. Testen werden wir das über die OX-eigene Web-Oberfläche für den Anwender. Danach – im dritten Beitrag – verbinden wir schließlich unsere Kontact/Kmail 4.7-Clients mit dem OX6- und dem IMAP-Server.

Zur Klarheit: Es geht um eine “OX CE”-Testinstallation, nicht um eine Produktivumgebung und nicht um die kommerziellen OX-Versionen. [ Open-Xchange rät vom Einsatz der nicht supporteten Community Edition in einem produktiven Umfeld ab, obwohl die CE im Kern keine funktionalen Einschränkungen aufweisen soll. Solche Einschränkungen gibt es aber bzgl. von Konnektoren und der Admin GUI. Die Community Edition kann nach meinem Verständnis auch nicht für das kommerzielle Hosting oder Verleihen von OX-Diensten eingesetzt werden. ]

Vorbemerkungen / Voraussetzungen der Installation / Referenzinstallationsanleitung für OX 6 unter Opensuse 11.4

Eine “Single Server”-Basisinstallation geht wesentlich schneller, als man das von früheren Experimenten mit dem SLOX oder OX5 unter SLES gewohnt sein mag. Im besonderen muss man sich nicht zwingend mit einer Anbindung an einen vorhandenen LDAP-Server. Eine Tomcat-Integration ist auch nicht erforderlich. OX6 ist hier schlanker als OX5.

Grundsätzlich sollte man für eine Testinstallation den entsprechenden Texten im OX Wiki [http://oxpedia.org/index.php?title=Main_Page_CE#quickinstall] folgen. Für Opensuse 11.4 und die OX Community Edition hält man sich an die Referenz-Installationsanleitung für Opensuse 11.0:

Referenzanleitung zur Installation: http://oxpedia.org/wiki/index.php?title=Open-Xchange_Installation_Guide_for_openSUSE_11.0

Sie führt mit ein wenig Geduld auch unter Opensuse 11.4 zum Erfolg. Der Text ist aus meiner Sicht knapp, aber ausreichend. Trotz der Komprimiertheit der Anweisungen umfasst der Text immerhin ca. 12 Seiten. Einiges davon sind aber Inhalte von Konfigurationsdateien. Man sollte sich durch den Umfang der Installationsanleitung also nicht abschrecken lassen.

Eine deutsche Übersetzung findet man hier:
http://www.pcwelt.de/ratgeber/Mailserver-Open-Xchange-Server-6-installieren-konfigurieren-355910.html und nachfolgende Webseiten.

Weiere Dokumentationen zur Administration und Nutzung des OX6 findet man hier: http://oxpedia.org/index.php?title=Main_Page_CE#documentation

Ich folge weiter unten im wesentlichen genau den Schritten der oben genannten Referenz-Installationsanleitung, werde aber bei einigen Punkten auf Schwierigkeiten eingehen, die auf meinem Test-System auftraten. Die Referenzanleitung sollte man auf jeden Fall elektronisch herunterladen, um Inhalte für Konfigurationsdateien per Copy/Paste übernehmen zu können.

Voraussetzungen der Installation

Voraussetzungen der Installation werden hier diskutiert:
http://www.pcwelt.de/ratgeber/Download-und-Installation-Mailserver-355914.html

Hier noch ein paar Anmerkungen von meiner Seite:

  • Erforderl. Skill-Level: Die OX6-Installation ist aus meiner Sicht nichts für Linux-Anfänger. Man sollte schon
    einige Linux-Administrationskenntnisse haben, sein Opensuse gut kennen und natürlich schon mal einen Apache- und MySQL-Server aufgesetzt haben. Tiefgehende Spezialkenntnisse sind allerdings für eine Testinstallation nicht erforderlich. (Für eine professionelle, dauerhaft produktive Installation im Firmennetz ist natürlich ein breiteres Wissen erforderlich.)
  • Natürlich muss auf dem Opensuse 11.4-Testsystem, das den OX 6 beherbergen soll, zuvor ein Apache Web-Server laufen. Für eine schnelle Test-Installation siehe https://linux-blog.anracom.com/2010/07/25/lokaler-apache-test-server-fur-php5/
  • Auf dem OX6-Testsystem muss auch eine MySQL-Datenbank installiert sein. PhpMyAdmin zum Verwalten des RDBMS ist ferner von Vorteil, da wir in Teil II bei Bedarf Inhalte der OX6-Datenbank modifzieren werden. Zu einer einfachen MySQL-Testinstallation siehe https://linux-blog.anracom.com/2010/08/28/lokale-mysql-phpmyadmin-installation/
  • Eine Java Runtime Umgebung (z.B. OpenJDK) muss laufen. Ich selbst habe OpenJDK und die Pakete von Sun installiert. Ich habe noch nicht ausprobiert, ob es reichen würde, OpenJDK einzusetzen. Vermutlich ja (obwohl es dazu bereits eine Fehlermeldung gibt: https://bugs.open-xchange.com/show_bug.cgi?id=15987). Zumindest zeigt die Paketverwaltung nach einem “rpm -q –requires open-xchange-server | grep java” an, dass “java-openjdk” benötigt wird.
  • Die Namensauflösung zum externen IMAP-Server und zum lokalen System muss im hauseigenen Netzwerk funktionieren und änderbar sein. Gründe: Je nach Konfiguration des auf dem Testsystem vorhandenen Apache möchte man ggf. unterschiedliche Services des Web-Servers von Client-Systemen aus unter unterschiedlichen Namen ansprechen. Der OX 6 Dienst entspräche dann nur einer von mehreren virtuellen Web-Domainen. Ferner kann man den IMAP-Server dem OX6 auch über dessen Namen bekanntmachen, um von IP-Adressen unabhängig zu werden.
    Bei fehlendem DNS-Server muss man die Namensauflösung halt über die “/etc/hosts”-Files auf den betroffenen Systemen vornehmen.
  • Wir unterlassen in diesem Test – wie oben angekündigt – eine Anbindung an einen LDAP-Server.
  • Im Paketmanager unter YAST muss man auf dem Testsystem das Repository
    “http://download.opensuse.org/repositories/server:/OX:/ox6/openSUSE_11.4/”
    auf dem gewohnten opensuse-spezifischen Weg einbinden.
  • Eine Admin GUI sucht man in der OX 6 Community Edition vergeblich. “Peters OX Server Admin GUI” (s. http://oxgui.wordpress.com/category/einfuhrung/) klammere ich in diesem Beitrag aus. Ohne eine GUI muss man die User-Verwaltung für die Tests händisch und über Scripts durchführen. Auch das sollte einen nicht abschrecken.

Installation der benötigten RPM-Pakete

Ist das OX-Repository “http://download.opensuse.org/repositories/server:/OX:/ox6/openSUSE_11.4/” in YASTs Paketmanager vorhanden, installiert man sich vor allen weiteren Schritten die notwendigen OX-Pakete für einen Betrieb auf einem einzigen Server.

Die Pakete sind im obigen Installationsleitfaden in einem umrandeten Kasten (Seite 4 im Abschnitt “Updating repositories and install packages” – zypper install mysql \ …” ) einzeln angegeben und werden hier aus Platzgründen nicht aufgelistet.

Die Installationsfiles für den OX-Server sowie zugehörige Admin-Skripts landen im Zuge der Paketinstallation dann im Verzeichnis “/opt/open-xchange” (mit
“root” als Owner und ansonsten mit einem gewöhnlichen “755”-Rechtekamm).

Vorsicht und Zurückhaltung bei der Paketinstallation:

Bitte anfänglich ausschließlich nur die Pakete installieren, die in der oben genannten Installationsanleitung angegeben sind. Unter anderem nicht das Paket “open-xchange-admin-plugin-autocontextid” installieren. Das führt im Rahmen des im “Installation Guide” beschriebenen Installationsverlaufs unweigerlich zu Fehlern.

Ich selbst hatte auch mit entsprechenden Fehlern (s. Teil 2, Kontextanlage) zu kämpfen, weil ich mir aus Bequemlichkeit im ersten Anlauf einfach alle OX-Pakete installiert hatte. Das sollte man besser nicht tun.

Kontexte und einige wichtige Accounts im Zusammenhang mit OX6

Kontexte / Default-Kontext

Open-Xchange 6 kennt sog. “Kontexte”. Das sind logische Bereiche, die ihre spezifischen User, Gruppen und Ressourcen beinhalten. Daten eines Kontextes sind in anderen Kontexten nicht sichtbar oder zugänglich. Ein Kontext definiert damit für die User auch eine bestimmte Login- und Arbeitsumgebung.

Jeder Kontext hat eine eindeutige “context id”, und jedem Kontext ist auch ein eigener Kontext-Administrator zugeordnet, der z.B. die User und Gruppen des Kontextes kreiert und verwaltet. User, die in einem Kontext angelegt werden, erben von ihrem Kontext Rechte bzgl. des Zugangs zu bestimmten Arbeits-Modulen.

Ein Kontext kann nur über den sog. “oxadminmaster” (Hauptverwalter des OX 6-Systems) angelegt werden. Dieser definiert auch den zum Kontext zugehörigen Kontext-Administrator, der seinen Kontext verwaltet. Kontexte sind ferner mit sog. Kontext-“Domainen” des OX-Servers verbunden.

Im OX-System gibt es genau einen ausgezeichneten “Default Context”, der während des Installationsvorgangs definiert werden muss. Ein OX-User muss in anderen, normalen Kontexten neben seiner UID auch seine Kontextdomaine angeben, um sich einzuloggen. Beim Default-Kontext genügt für den Login die OX-UID.

Über Kontexte kann man u.U. Unternehmensbereiche abbilden, die getrennt voneinander operieren und separat verwaltet werden sollen. Pro Kontext können auch Quotas hinsichtlich des Speicherplatzes angelegt werden.

Genaueres zu “Kontexten” findet man im “OX6 Provisioning Guide” (http://software.open-xchange.com/OX6/doc/OX6-Provisioning.pdf. (Siehe etwa den Beginn des dortigen Chapter 1.)

Die Installationsanweisung sieht lediglich die Anlage eines einzigen Kontextes – nämlich des “Default Context” – vor. Für unseren Test – und für eine kleine Firma – ist das auch ausreichend.

Spezielle Accounts / Admin-Accounts

Folgende (Administrator-) Accounts spielen im Zusammenhang mit dem OX6-Server eine wichtige Rolle:

  • Datenbankuser – “openexchange” : Dieser User erhält die notwendigen Rechte bzgl. der unter MySQL noch anzulegenden “openxchange”-Datenbank und ihrer Tabellen. Das wird ein administrativer MySQL-Account. Er erhält standardmäßig umfassende Rechte im RDBMS, u.a. auch das erforderliche Recht zum Anlegen von Datenbanken ! (Ich habe noch nicht ausprobiert, wie weit sich die Rechte an anderen Stellen beschneiden lassen).
  • Administrator für den OX-Server – “oxadminmaster” : Dieser User nimmt Grundeinstellungen des Servers vor. U.a. kreiert er die oben erwähnten Kontexte und die Kontext-Admins.
  • Context Administrator – “oxadmin” : Dieser User ist ein Beispiel für einen ersten Kontext-Administrator. Er
    legt später die ersten Accounts zu dem vom “oxadminmaster” kreierten “Default Context” an.
  • Linux System-User und System-Gruppe – “open-xchange” : Auf der Linux-Systemebene wird während der Installation ein (System-) User “open-xchange” und eine (System-) Gruppe “open-xchange” angelegt. Unter der entsprechenden UID/GID erfolgt später der Zugriff auf bestimmte Dateien des OX6-Systems.

Die Namen der ersten drei Accounts können eigentlich frei vergeben werden. Wir halten uns hier aber an die Namen, die die Installationsanweisung vorschlägt.

Wir ordnen diesen Accounts Passwörter zu. Für diesen Text verwenden wir folgende Platzhalter, die jeder selbst mit den geeigneten Passwörtern füllen muss:

  • openexchange – Password: MY_OX_MYSQL_PWD
  • oxadminmaster – Password: MY_OX_MASTER_ADMIN_PWD
  • oxadmin – Password: MY_OX_CONTEXT_ADMIN_PWD
  • MySql Root Admin – Password: MY_MYSQL_ROOT_PWD

Für den System-User “open-xchange” ist keine Passwortvergabe erforderlich. Er erhält auch keine Login-Shell.

Serverbezeichnung

Der zu installierende OX6-Server muss im Rahmen der Installation eine Bezeichnung erhalten. Wir verwenden hierfür im Text den Platzhalter

MY_OX_SERVER_NAME

den jeder durch seinen eigenen Servernamen ersetzen muss.

Hinweis: Wir installieren hier nur genau einen Server, der gleichzeitig als Admin-, Application-, Web- und Datenbankserver fungiert. In einer verteilten Hochleistungs-Installation können die Aufgaben auf mehrere Server verteilt werden, die alle zu benennen und in der zentralen Konfigurationsdatenbank des OX-Systems zu registrieren sind. Sehen Sie hierzu die Administrationsdokumentation unter http://software.open-xchange.com/OX6/doc/OX6-Installation-and-Administration.pdf.

Die Installation von Open-Xchange 6 unter Opensuse 11.4 im Einzelnen

Vor Beginn der eigentlichen Installationsarbeiten prüfe ich, ob mein MySQL-Servers läuft. Unter Opensuse z.B. mit

#  rcmysql status

Alternativ mit der Mysql Workbench oder PhpMyAdmin. Zur Not muss der Service gestartet werden:

#  rcmysql start

oder auf anderen Systemen mittels “/etc/init.d/mysql start”. Für den künftigen Gebrauch sollte man den Dienst per “Runlevel”-Verwaltung (z.B. per Runlevel-Editor unter YAST) oder aber manuell in die Startscript-Directories für diejenigen “Runlevel” eintragen, auf denen man den Service benötigt. Typischerweise 3 und 5.

Schritt 1: Anlegen und Initialisierung der zentralen OX6 Konfigurations-Datenbank und ihrer Tabellen

Nun sollte man sich als root (gemeint ist hier natürlich der Linux “root”-Account und nicht der MySQL-“Root”-User) auf einem Terminal einloggen und versuchsweise folgendes Kommando absetzen :

#  /opt/open-xchange/sbin/initconfigdb  −−configdb-pass=MY_OX_MYSQL_PWD  −a

Die “-a”-Option dient zur Anlage des administrativen MySQL-Users “openxchange”.

Bei mir schlug das Kommando prompt fehl.

Ein Blick in das Script “initconfigdb” zeigt, dass zum Anlegen des neuen administrativen Accounts natürlich eine Authorisierung als
“MySQL-Root”-Administrator erforderlich ist. Man kann das lt. Script durch einen zusätzlichen Übergabeparameter “−−mysql-root-passwd=….” lösen. Ich selbst habe mir das Leben für die Tests einfacher gemacht und

  • die Lese- und Ausführungsrechte für die Script-Datei “/opt/open-xchange/sbin/initconfigdb” auf root begrenzt
  • und in die Script-Datei im Bereich “#defaults” das MySQL-Root-Passwort in die zugehörige Zeile explizit eingetragen.

    #defaults
    …
    MYSQL_ROOT_PASSWD=MY_MYSQL_ROOT_PWD
    …….

So ausgestattet lief das Script dann per

#   /opt/open-xchange/sbin/initconfigdb  −−configdb-pass=MY_OX_MYSQL_PWD  −a

anstandslos durch. Ein Blick in die MySQL-Datenbank zeigt denn auch, dass eine Datenbank “configdb” und zugehörige Tabellen angelegt wurden. Ferner ist ein MySQL-User “openxchange” mit sehr umfassenden Rechten angelegt worden.

Hinweise:

  • Will man ganz sicher gehen, so kann man beim letzten Kommando vermutlich auch ein zusätzliches “−i” als Option angeben. Dann wird eine evtl. doch schon vorhandene Datenbank “configdb” in dem MySQL-RDBMS zunächst wieder entfernt und dann die Datenbank neu angelegt.
  • Ferner wird im OX6-System alles mögliche mit Index-Nummern versehen. Bei mir haben mehrere Anläufe im Zusammenhang mit dem initconfigdb-Script vermutlich zu einer “id=5” in der Tabelle “configdb_sequence” geführt. Diese Sequenz-Nummer fließt dann später in den Namen der Datenbank ein, in der die eigentlichen Bewegungsdaten (Kontexte, user, Kontakte, Kalendereinträge, etc.) hinterlegt werden. Das hat offenbar nicht geschadet – für eine saubere Installation ist aber die erwähnte “-i”-Option hilfreich.
  • Bzgl. des MySQL-Users “openxchange” kann man z.B. mit Hilfe von PhpMyAdmin prophylaktisch noch genauer festlegen, von welchen Systemen aus man einen Zugriff – außer von localhost aus – noch zulassen will.
  • Hinweis: Nach erfolgreichem Abschluss der Tests entfernt man den Eintrag mit dem MySql-Root-Passwort aus Sicherheitsgründen natürlich wieder aus dem Script !

Schritt 2: Setup und Initialisieren von Konfigurationsfiles

Das Initialisieren und Konfigurieren der OX6-Systemkomponenten und der zugehörigen Konfigurationsdateien geschieht nun mit Hilfe eines weiteren Scripts – “oxinstaller”:

#  /opt/open-xchange/sbin/oxinstaller  −−no-license  −−servername=MY_OX_SERVER_NAME  −−configdb-pass=MY_OX_MYSQL_PWD  −−master-pass=MY_OX_MASTER_ADMIN_PWD  −−ajp-bind-port=localhost

Der Platzhalter “MY_OX_SERVER_NAME” steht – wie gesagt – für einen frei vergebbaren Namen des künftigen OX-Servers. Das “–no-license” bezieht sich offenbar auf die “Community Edition”.

Im System wird während der Installation übrigens auch ein User “open-xchange” und eine Gruppe “open-xchange” angelegt.

Im MySQL-RDBMS findet sich nun auch eine Datenbank

“oxdatabase_INDEX”,

wobei “INDEX” für die oben erwähnte id in der Tabelle “configdb_sequence” der Konfigurationsdatenbank steht. In meinem Fall also “oxdatabase_5”. Diese Datenbank nimmt später die eigentlichen Daten des OX-Systems und seiner Kontexte auf.

Schritt 3: “Registrieren” des Servers

Wir starten zunächst die OX
6 Administrations-Services

#  /etc/init.d/open-xchange-admin start

Der resultierende Prozess läuft übrigens unter der nichtssagenden Bezeichnung “java” unter dem User “root”. Dass er der korrekte OX6 Daemonprozess ist, erkennt man erst über einen pid-Eintrag unter

/var/run/open-xchange-admindaemon.pid

Ein “cat” für dieses File zeigt einem dann die PID des Prozesses.

Nun muss der installierte Server in der zentralen Konfigurationsdatenbank “configdb” registriert werden. Dies geschieht wieder durch ein Script:

#  /opt/open-xchange/sbin/registerserver  −n MY_OX_SERVER_NAME  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD

Als Ergebnis erhält man u.a. einen Eintrag in der Tabelle “server” der Bank “configdb”.

Schritt 4: Anlegen eines Verzeichnisses zum Speichern von Files und Dokumenten des “Infostore”

OX 6 kennt ein minimales Dokumenten-Management. Letzteres präsentiert sich als sog. “Infostore”. Der zugehörige “Filestore” – ein Verzeichnis auf der Festplatte – enthält später alle im Infostore verwalteten Dokumente, aber auch Anhänge an andere Groupware Objekte wie z.B. Tasks. Das “filestore”-Verzeichnis muss angelegt und in der Konfigurationsdatenbank registriert werden. Der Ort des Filestores ist im Grunde beliebig. Ein Verzeichnis unter “/var” bietet sich an. Ich habe folgende Kommandos benutzt:

#  mkdir /var/opt/filestore

#  chown open-xchange:open-xchange /var/opt/filestore/

#  /opt/open-xchange/sbin/registerfilestore −A oxadminmaster −P MY_OX_MASTER_ADMIN_PWD  −t file:/var/opt/filestore

Schritt 5: Registrieren der Groupware-Datenbank”

Die bereits angelegte Datenbank “oxdatabase_…” wird registriert:

#  /opt/open-xchange/sbin/registerdatabase  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −n oxdatabase  −p MY_OX_MYSQL_PWD  −m true

Schritt 6: Apache konfigurieren”

Module

Auf dem lokalen Apache-Server müssen mehrere Module laufen :

proxy, proxy_ajp, expires, deflate, headers, rewrite, proxy_balancer.

Mit

#  a2enmod  −l

verschafft man sich zunächst einen Überblick, über die bereits laufenden Module. Den fehlenden Rest aus der obigen Liste lädt man dann per “a2enmod” nach. In meinem Fall:

#  a2enmod proxy && a2enmod proxy_ajp && a2enmod deflate && a2enmod headers && a2enmod rewrite && a2enmod proxy_balancer

Eintrag in “/etc/sysconfig/apache2”

Danach legt man unter Opensuse über den “sysconfig”-Mechanismus fest, welche Module Apache2 laden soll. Die richtige Datei editiert man entweder über Yast und den dortigen “Editor für /etc/sysconfig”, oder man editiert mit einem Text-Editor direkt die Datei “/etc/sysconfig/apache2
” und dort die Zeile für die APACHE_MODULES:

APACHE_MODULES=”actions alias auth_basic authn_file authz_host authz_groupfile authz_default authz_user autoindex cgi dir env expires include log_config mime negotiation setenvif ssl suexec userdir php5 proxy proxy_ajp deflate headers rewrite proxy_balancer”

Ort der OX 6-Dateien auf dem Apache-Server

Die ausführbaren Dateien, auf die der Webserver zugreift, liegen auf einem Opensuse-System unter

/srv/www/htdocs/ox6

Auf diesen Ordner wird natürlich in der Domain-Konfiguration des Web-Servers Bezug genommen.

Konfigurationsfiles

Nun legt man als root zwei neue Konfigurationsfiles für den Apache-Server an:

  • /etc/apache2/conf.d/proxy_ajp.conf
  • /etc/apache2/vhosts.d/ox.conf

Die Inhalte dieser Dateien übernimmt man mit Hilfe eines Editors und Copy/Paste exakt der oben angegebenen Referenzinstallationsanleitung. Wir lassen das hier aus Platzgründen weg.

Das erste File regelt den Zugang zu Axis/Soap-Services und dient u.a. der Konfiguration eines Web-“Load-Balancers” für die OX6-Aufgaben, die in einer komplexen Installation ja auch auf mehrere (geclusterte) Web-Server verteilt werden könnten. In unserem Fall reduziert sich die Konfiguration auf genau ein System, nämlich localhost. Ein Blick in die Konfigurationsdatei ist ganz instruktiv.

Das zweite File konfiguriert den Apache-Server so, dass ein Zugriff auf den lokalen Apache immer (!) auf der Login-Seite für den OX endet! Hierfür wird der Zugriff auf das Verzeichnis “/srv/www/htdocs/ox6” umgelenkt.

Abändern der Konfigurationsfiles für einen namensbasierten Aufruf der OX-Seiten auf dem Apache-Server

Für das Testsystem ist die vollständige Umstellung des Apache-Servers auf die OX-Seiten vielleicht OK. In der Realität – und gerade in kleinen Firmen – möchte man aber auf einem Web-Server unter einer IP-Adresse mehrere unterschiedlich benannte Web-Domainen zur Verfügung stellen. Deswegen ist der nachfolgende Text nicht ganz so “off topic” wie es zunächst erscheinen mag.

Ich z.B. möchte meine aktuelle Apache-Services unter der Adresse des Testsystems unverändert lassen und deshalb den OX-Service bei mir im internen Netz nur unter dem (verkürzten http-Domain-) Namen “oxs3” erreichen. Bei einem lokalen Standardzugriff “http:/localhost” auf dem Testsystem selbst sollen andere Dateien erscheinen – nämlich die, die bisher schon im Verzeichnis “/srv/www/htdocs/” vorhanden waren. Auch von extern sollen die Dateien unter “/srv/www/htdocs/”, wenn der Server unter seinem Standardnamen “http:/mytestserver” aufgerufen wird.

Ich möchte also trotz evtl. gleicher IP-Adresse eine saubere Trennung der Web-Dienste haben, wenn ich den Server von innen und außen mit unterschiedlichen (“Domain”)-Namen und IP-Adressen aufrufe. Nehmen wir an, der Server des Testsystems habe im lokalen Netz die IP-Adresse 192.168.0.2 und sei DNS-seitig unter dem Namen mytestserver, ruxa, ruxb bekannt. Dann sollen folgende Aufrufe folgendes Ergebnis zeitigen :

  • http://localhost >> Anzeige von Inhalten unter /srv/www/htdocs/
  • http://127.0.0.1 (auf dem lokalen System) >> Anzeige von Inhalten unter /srv/www/htdocs/
  • http://192.168.0.2 (von innen und von extern) >> Anzeige von Inhalten unter /srv/www/htdocs/
  • http://mytestserver (von innen und von extern) >> Anzeige von Inhalten unter /srv/www/htdocs/
  • http://oxs3 (von innen und von extern) >> Anzeige von Inhalten unter /srv/www/htdocs/ox6
  • http://127.0.0.2 (auf dem lokalen System) >> Anzeige von Inhalten
    unter /srv/www/htdocs/ox6
  • https://ruxa (von innen und von extern) >> TLS/SSL-gesicherte Anzeige von Inhalten unter /srv/www/htdocs/ruxa
  • https://ruxb (von innen und von extern) >> TLS/SSL-gesicherte Anzeige von Inhalten unter /srv/www/htdocs/ruxb

Unter solchen Voraussetzungen muss man die Konfiguration natürlich etwas ändern. Ich kann das hier nur andeuten. In die Datei “/etc/apache2/listen.conf” des Testservers nehme ich folgende Zeilen für “NameVirtualHost” zu den involvierten IP-Adressen auf:

Listen 80
<IfDefine SSL>
   <IfDefine !NOSSL>
      <IfModule mod_ssl.c>
         Listen 443
      </IfModule>
   </IfDefine>
</IfDefine>
NameVirtualHost 127.0.0.2:443
NameVirtualHost 192.168.0.2:443
NameVirtualHost 127.0.0.2:80
NameVirtualHost 192.168.0.2:80

Die Datei /etc/apache2/vhosts.d/ox.conf ergänze ich wie folgt – es werden nur die wichtigsten Einträge gezeigt:

<VirtualHost 127.0.0.1:80 192.168.0.2:80 >
   …
   DocumentRoot /srv/www/htdocs
   # hier keinen Servername angeben !
   ….
   <Directory /srv/www/htdocs>
      AllowOverride None
      Order allow,deny
      allow from all
   </Directory>
…
</VirtualHost>

<VirtualHost 127.0.0.2:80 192.168.0.2:80>
   ….
   DocumentRoot /srv/www/htdocs
   ServerName mytestserver:80

   <Directory /srv/www/htdocs>
      AllowOverride None
      Order allow,deny
      allow from all
   </Directory>
…..
</VirtualHost>

############################
### Einträge für den OX Server-Dienst ###
############################

<VirtualHost 127.0.0.2:80 192.168.0.2:80>
   ….
   DocumentRoot /srv/www/htdocs
   ServerName oxs3:80

   <Directory /srv/www/htdocs>
      AllowOverride None
      Order allow,deny
      allow from all
      RedirectMatch ^/$ /ox6/
      Options +FollowSymLinks +SymLinksIfOwnerMatch
   </Directory>
   # deflate
   AddOutputFilterByType DEFLATE text/html text/plain text/javascript application/javascript text/css text/xml application/xml text/x-js application/x-javascript

   # pre-compressed files
   AddType text/javascript .jsz
   AddType text/css .cssz
   AddType text/xml .xmlz
   AddType text/plain .po

   AddEncoding gzip .jsz .cssz .xmlz
   SetEnvIf Request_URI “\.(jsz|cssz|xmlz)$” no-gzip

   ExpiresActive On

   <Location /ox6>
      … Inhalte wie in der Referenzanleitung …
   </Location>
   <Location /ox6/ox.html>
      … Inhalte wie in der Referenzanleitung …
   </Location>
   <Location /ox6/index.html>
      … Inhalte wie in der Referenzanleitung …
r
   </Location>
</VirtualHost>

Für die SSL-Domainen habe ich eine eigene Datei “/etc/apache2vhosts.d/vhost-ssl.conf” mit ungefähr folgendem Inhalt

<IfDefine SSL>
<IfDefine !NOSSL>

## SSL Virtual Host Context

<VirtualHost 127.0.0.2:443 192.168.02.:443>

   # General setup for the virtual host
   DocumentRoot “/srv/www/htdocs/ruxa”
   ServerName ruxa:443
   …
   …
   # SSL Engine Switch:
      SSLEngine on

   # SSL Cipher Suite:
      SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   ….
# Server Certificate:
      ….
  ….
  ….
</VirtualHost>

<VirtualHost 127.0.0.2:443>
   DocumentRoot “/srv/www/htdocs/ruxb”
   ServerName ruxb:443
   …
   ….
</VirtualHost>

</IfDefine>
</IfDefine>

Hieraus sollte hervorgehen, wie man einen namensbasierten Zugriff erreicht. Die Zugriffsregeln – oben ist oft “allow from all” gesetzt muss man natürlich anpassen. Auf die Konfiguration eines SSL-Servers kann ich hier nicht eingehen. Siehe aber die Links in https://linux-blog.anracom.com/2010/07/25/lokaler-apache-test-server-fur-php5/.

Die diversen Namen (oxs3, mytestserver) unter denen der Web-Server erreichbar sein soll, muss man natürlich über seinen DNS-Server bekannt machen oder aber entsprechende Einträge in den “/etc/hosts”-Dateien vornehmen. In meinem Beispiel etwa sind folgende Daten auf dem Testsystem selbst relevant:

127.0.0.1         localhost
# special IPv6 addresses
::1         localhost ipv6-localhost ipv6-loopback
fe00::0         ipv6-localnet
ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts
127.0.0.2         oxs3
127.0.0.2         ruxa
127.0.0.2         ruxb
192.168.0.2         mytestserver.anracona.de mytestserver
192.168.0.2         oxs3.anracona.de oxs3

Hierbei bin ich von einer Zugehörigkeit der Server zu einer Domaine “anracona.de” ausgegangen, die auf dem DNS-Server des Netzes angelegt und konfiguriert sein muss.

Hat man seinen Apache konfiguriert, muss er erneut gestartet werden:

#  rcapache2 restart

Schritt 7: Groupware-Dienste starten / erster Test

Die Groupware-Dienste/Dämonen startet man unter Opensuse mit :

#  rcopen-xchange-groupware start

oder

#  /etc/init.d/open-xchange-groupware start

Erster Test
Nun sollte man bei einem Aufruf des Webservers über den Browser einen Login-Schirm sehen. Hat man die
Apache-Konfiguration gegenüber der Standardinstallationsanleitung nicht geändert, so genügt zum Testen die Adresse “http://localhost”.

Ist man dagegen meinem Beispiel bzgl. eines namensbasierten Aufrufes gefolgt, so erreicht man den OX-Login-Schirm lokal auf dem Testsystem über die Eingabe der Adressen “http://oxs3” oder “http://127.0.0.2” – und gerade nicht über “http://localhost”.

Natürlich gibt es für einen echten Login-Vorgang noch keinen User. Diese legen wir in Teil II an.

Schritt 8: Benötigte Dienste den Runlevels zuordnen

Bevor wir den Default-Kontext erstellen und einen User anlegen, sollten wir die benötigten Serverdienste noch den gewünschten Runleveln zuordnen, damit sie beim nächsten System-Boot automatisch gestartet werden. Ich erledige das für die Dienste “mysql, apache2, open-xchange-groupware und open-xchange-admin” über “YAST > Systemdienste (Runlevel) > Expertenmodus”, da ich dort die Startlevel selber angeben kann. Nimmt man die vorgesehen Standardlevel, so genügt auch:

# insserv mysql; insserv apache2; insserv open-xchange-groupware; insserv open-xchange-admin

Damit ist die Grundinstallation des OX6-Servers [CE] erledigt. Im nächsten Beitrag zu diesem Thema legen wir den Default-Kontext und einige User an, die auch auf den IMAP-Server zugreifen sollen.

Opensuse 11.4 – Kontact/Kmail 4.7.0 – Probleme

Posted on by

Mutig (oder dumm?) wie ich bin, habe ich am Wochenende gewagt, eine unser Linux-Arbeitsstationen unter Opensuse 11.4 von KDE 4.6 auf KDE 4.7 umzustellen. Dabei nutzte ich – wie bei früheren KDE Updates auch – das Opensuse KDE Factory Repository.

Leider hatte ich es versäumt, mir den neuen Inhalt des KDE Factory Repositories genauer anzusehen. Dabei wäre mir nämlich folgendes aufgefallen:

Suse hatte die KDE PIM-Pakete und Akonadi bislang auf dem Stand der KDE 4.4 ausgeliefert (also z.B. Kmail 1.13. statt Kmail 2.x). Gründe hierfür waren sicher die vielen Probleme mit den neuen Versionen und deren Zusammenspiel mit Akonadi – siehe hierzu meine eigenen Beiträge in diesem Blog. (U.a. gab es Probleme mit dem enormen CPU-Verbrauch von Nepomuk und virtuso-t.) Nun hat aber auch SUSE die neuen Versionen Kontact 4.7, Kmail 4.7 und weitere Programme sowie die zugehörigen Akonadi-Versionen ins KDE Factory Repository aufgenommen.

Das hatte ich nach meinem Urlaub nicht mitbekommen – und das blieb leider nicht ohne Folgen:

Problem 1: Kmail und Kontact 4.7.0 ließen sich nicht starteten

Das erste Problem war, dass sich Kontact wegen Kmail nicht mehr starten ließ bzw. wegen eines “schweren Fehlers”

“In KMail ist ein schwerwiegender Fehler aufgetreten. Das Programm wird beendet.
Die Fehlermeldung lautet: Fehler beim Einholen der Ressourcen-Sammlung. … ”

immer wieder geschlossen wurde. Siehe hierzu auch:


https://bugzilla.novell.com/show_bug.cgi?id=708977
http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/463408-kde-4-7-out-2.html
http://www.kde-forum.de/post/13239/kontact-4-7-0-und-akonadi-funktionieren-nicht.html#post13239
http://www.linuxforen.de/forums/showthread.php?p=1779066

Ziemlich sarkastische – aber aus meiner Sicht auch angemessene Kommentare findet man hier:
https://bbs.archlinux.de/viewtopic.php?id=19453


Problembehebung:
Mich hat die Behebung dieses Problems alles in allem etwa 2 Stunden gekostet. Zunächst habe ich mit einem jungfräulichen Benutzeraccount versucht, Kontact/Kmail 4.7 zum Laufen zu bewegen. Dieser Test ist bei KDE-Updates immer nützlich, denn nach dem Aufsetzen eines jungfräulichen Users gibt es keine alten Konfigurationsdateien unter ~/.kde4/share und den dortigen Subverzeichnissen. Da es dann mit dem jungfräulichen User ging, war klar, wo ich weitermachen musste.

Ich musste letztlich “alle” alten Dateien zu Kmail und Akonadi in meinen eigenen Subverzeichnissen von “~/.kde” eliminieren sowie den Akonadi-Server und die Akonadi-Ressourcen komplett neu einrichten.

Es reichte übrigens nicht, die “kmail*rc”-Dateien in “~/.kde/share/config” zu eliminieren/umzubenennen. Ich musste auch Dateien unter dem Subverzeichnis “~/.kde/share/apps” entfernen. Dabei muss KDE immer mal wieder neu gestartet werden (z.B. mit init 3 – init 5).

Schließlich habe ich es so nach mehreren Anläufen geschafft, Kmail 4.7 zum Laufen zu bringen und auch an einen IMAP-Server in unserem Netz anzubinden.

Problem 2: In Kmail macht die initiale Einrichtung von Spam-Filtern das Weiterarbeiten unmöglich

Naiv wie ich bin, habe ich dann versucht, Spam-Filter einzurichten. Dies hat sich als sehr schlechte Idee erwiesen, da diese Filter beim initialen Lauf über große Mailordner (und davon habe ich viele) ein Bedienen der Kontact-
Oberfläche völlig unmöglich machten. Man sieht den “Fortschritt” der Mail-Analyse – das lief doch unglaublich langsam ab. Ich habe Kontact schließlich gewaltsam beendet und die Filter-Einstellungen (Bogo-Filter und/oder Spam-Assassin) wieder aus den Kmail-Konfigurationsdateien entfernt.

Spam-Filter werde ich deshalb erst wieder bei der Version KDE 4.7.1 wieder ausprobieren. Frühestens ….

Problem 3: Das manuelle Einstellen der Reihenfolge der Mailordner funktioniert unter Kmail 4.7 nicht mehr

In der Ansicht der Mailfolder konnte man bislang die Reihenfolge der angezeigten Mailordner nicht nur alphabetisch oder nach anderen Anzeigespalten sortieren lassen, sondern die Darstellung der Reihenfolge auch manuell festlegen. Das funktioniert unter Kmail 4.7 im Moment schlicht nicht mehr. Bei unserer doch umfänglichen Ordnerlandschaft ist das einfach ärgerlich.

Problem 4: Keine Kontact-Verbindungen zu einem OX 5 Server – nur zu OX6

Leider nutzt einem Kmail alleine auch nicht viel, wenn man nicht mehr an einen Teil seiner Kontakte und Adressdaten herankommt und auch seine Kalender-Einträge nicht mehr öffnen kann. Bei uns liegen Kontakte und Kalender zu einem größeren Teil nämlich immer noch auf einem Open-Xchange Server der Version 5. Wir betreiben zwar auch einen Open-Xchange Server der Version 6 (aus Kostengründen in der Community Edition) auf einem Opensuse 11.0-System. Aber die Migration aller alten OX5 Daten – insbesondere auch der umfänglichen Wissenseinträge oder des Dokumentenarchivs vom OX 5 zum neueren OX 6 System hatten wir bislang nie vollständig vollzogen. Warum auch, wenn man zwei fehlerfrei laufende Serversysteme hat.

Die schlechte Nachricht ist nun die:

Die Akonadi-Konnektoren zu OpenXchange Ressourcen funktionieren bei KDE/Kontact 4.7.0 im Gegensatz zu älteren Versionen (z.B. unter KDE 4.4) nur noch für den OpenXchange Server 6 aber nicht mehr für den OX 5. Ob sich das bei künftigen Versionen noch ändern wir, weiß ich nicht.

Schade eigentlich, dass die KDE-Entwickler die bis KDE 4.4 anstandslos funktionierenden Schnittstellen zu OX5 nicht auch in die neuen Kontact/Korganizer/Kontakt-Versionen übernommen haben. Das ist für mich nicht nachvollziehbar.

Jedenfalls kann ich im Moment den Zugriff von meinem KDE 4.7 System auf den alten OX 5 Server vergessen – und damit auch den direkten Zugriff unter Kontakt auf die dort liegenden Informationen. Das ist schon ziemlich blöd, wenn einem plötzlich in der täglichen Arbeit einige Adressbücher und E-Mail-Adressen fehlen.

Wer also produktiv mit einem OX 5 Server arbeiten will oder muss, sollte von einem KDE Update auf KDE 4.7 unter Opensuse besser die Finger lassen.

Gott sei Dank habe ich Zugriff auf mehrere Opensuse 11.4-Systeme, auf denen noch eine 14 Tage alte KDE 4.6-Version mit den KDEPIM-Komponenten von KDE 4.4 läuft..

Was Positives

Nun aber auch ein paar gute Nachrichten:

a) Ich habe dann am Sonntag mal testhalber einen OX 6 Server unter Opensuse 11.4 aufgesetzt. Hierzu mehr in einem anderen Beitrag. Dies ist praktisch genauso einfach oder schwierig wie unter Opensuse 11.0.

b) Die Anbindung des Gespanns Kontact/Akonadi von KDE 4.7 an die Ressourcen (Adressbücher, Kalender, Tasks) der OX 6 Server unter Opensuse 11.0 und Opensuse 11.4 funktioniert doch sehr ordentlich. Ich konnte beim ersten Rumspielen zumindest keine echten Probleme erkennen.

c) In Kmail wurde ein alter, ärgerlicher Regressions-Fehler von Anfang 2009 nun endlich behoben: Beim Ziehen von Mails aus der Mailliste über die Ordner im Ordnerbereich öffnet sich die Ordnerhierarchie nun wieder. Das erleichtert die Mailverschieberei in der komplexen Ordnerstruktur eines Unternehmens doch erheblich.

r
d) Die in einem früheren Beitrag zu Kmail 2 und unter https://bugs.kde.org/show_bug.cgi?id=246678 kritisierten Problemen mit dem hohen CPU-Verbrauch von Nepomuk und Virtuoso beim Indizieren neuer Mails scheinen behoben zu sein. Nepomuk läuft jedenfalls bei mir und ich kann die früheren extremen Ausschläge in der CPU-Belastung nicht mehr sehen.

Fazit

Der Schritt auf KDE/Kontact 4.7 ist mit Kinderkrankheiten verbunden. OX 5 Nutzer sollten den Schritt auf KDE 4.7 unter Opensuse lieber bleiben lassen oder vorab ernsthaft eine Migration auf OX 6 in Angriff nehmen.

KDE 4.6 Beta, K3b, Kmail, Akonadi, virtuoso-t, OX5

Posted on by

No risk no fun ! Dachte ich und habe mir mal KDE 4.6 Beta auf einem meiner Opensuse 11.3 Systeme installiert. Aus drei Gründen war das für mich ein interessantes Experiment :

  1. Weil unter KDE 4.5.2, KDE 4.5.3 K3b nicht mehr funktionierte und ich gemäß der Einträge bei den entsprechenden KDE-Bugs aber die Hoffnung bekam, es könne nun wieder laufen.
  2. Weil unter KDE 4.6 das Akonadi-Subsystem nicht mehr nur für das Adressbuch sondern auch für die Verwaltung der Mailordner zuständig wird. Hier ist das Wechselspiel mit IMAP-Systemen interessant.
  3. Weil Akonadi auch mit den Kalender-Ressourcen eines Open-Xchange 5 Servers zusammenarbeiten sollte.

Um es vorweg deutlich zu sagen: Solche Experimente mit Beta-Systemen wie zu Punkt 2 sollten keine produktiven IMAP- oder OX-Server einbeziehen, sondern nur Server, die Kopien der eigentlichen IMAP-Mail-Ordner und Kalenderdaten beinhalten! Zur Not richtet man sich einen IMAP-Testserver halt auf einem Laptop oder einem virtuellen System ein. Bei OX5 oder OX6 ist das zugegebenermaßen schon schwieriger.

Zu Punkt 1 – K3b:

K3b läuft unter Opensuse 11.3 und KDE 4.6 wieder – allerdings nur mit den letzten K3b RPM-Paketen 2.0.1-44.1 im Opensuse Factory Repository. Eine CD habe ich mal testweise gebrannt – das lief ohne Probleme. Genauer getestet habe ich das Brennen von unterschiedlichen Medien (DVD+-R, DVD+RW, etc. aber noch nicht. Das Rippen von CDs läuft mit der aktuellen Version aber wie gewohnt. Anzumerken bleibt: Die aktuellen RPMs von Packman 2.0.1.pm.2.26 laufen nicht. (Vermutlich wegen der erfolgten Änderungen im HAL-Bereich)

Zu Punkt 2 – Kmail, Akonadi, IMAP – und die problematische Wirkung von Filtern :

Die Verwaltung von Mailordnern durch Akonadi stelle ich mir persönlich als eine komplexe Angelegenheit vor. Im Besonderen dann, wenn die Mailordner auf einem IMAP-Server liegen und die Filterung von Mails (Spam und andere Filter) aber lokal unter KDE’s Kmail erfolgt. Ich habe auf meinem Desktop-System eine ganze Reihe von Filtern eingestellt. Nicht nur zum zusätzlichen Filtern von Spam, der auf dem Server nicht erkannt oder zu vorsichtig behandelt wurde, sondern auch themen- und kundenbezogene Filter.

Für mich als Anwender stellt sich doch die Frage, wie der mindestens zweistufige Weg der Filterung von Kmail über die Akonadi-Maschinerie hin zum IMAP-Server abläuft. Kmail als Frontend zu Akonadi initiiert die Filterung und als Reaktion werden dann ggf. Verschiebungen von Mails aus dem Posteingangsordner hin zu anderen Ordnern durchgeführt. Das Ergebnis muss sich zunächst auf dem lokalen Akonadi-System und dessen Abbildung der Mailordner niederschlagen. Die vorgenommenen Ergebnisse der Filteraktionen wie Löschungen im Ursprungsordner und entsprechende Neuzugang in definierten Zielordnern müssen ja aber auch periodisch zwischen Akonadi und dem IMAP-Server abgeglichen werden. In einer solchen Verarbeitungskette – MUA-Client <> Akonadi (als zwischengeschobenes zentraler Puffer) <> IMAP-Server – eröffnen sich zahlreiche Möglichkeiten für Fehler.

Meine Erfahrungen waren entsprechend :
Die Migration der vorhandenen Mail-Ordner aus dem alten Kmail hin zu Akonadi ging grundsätzlich ohne Probleme vonstatten. Es dauerte allerdings etliche Minuten, da unsere Mailordner mehrere Gigabyte umfassen. Die Zeitdauer für die Migration war aus meiner Sicht absolut OK. Probleme verursachten dann aber die bereits konfigurierten Mail-Filter aus meiner KDE 4.5.3-Kmail-Version. Diese fingen nämlich beim Füllen meiner doch zahlreichen Mailordner an zu wirken – und zwar nicht in der gewohnten Weise. Es wurde in andere lokale Ordner verschoben, die begonnen Filtervorgänge schluckten
enorm viel CPU-Zeit, die Kmail-Oberfläche kam letztlich zum Stillstand und war nicht mehr bedienbar …. Ursache war hier vermutlich, dass viele Mailordner im Zuge der Migration gleichzeitig neu befüllt wurden.

Kurzum:
Die Filter verursachten zeitversetzt und im Nachgang zum eigentlichen Migrationslauf zunächst ein ziemliches Chaos und ungewohnte Verschiebungen in lokale (!) Spam- und Trash-Ordner. Offenabr war ein teil der alten Konfiguration – nämlich die Festlegung der Zielordner – verloren gegangen. Nun ließen sich die laufenden Filterprozesse wegen des Stillstands der Kmail-Oberfläche leider auf konventionellem Wege auch nicht mehr aufhalten. Ein Killen der entsprechenden Prozesse, ein Löschen der Konfigurationsdatei kmail2rc und ein Neustart verhalfen mir schließlich zu der Möglichkeit, meine Filter zu entfernen und komplett neu anzulegen. Danach verhielt sich Kmail ruhiger und ließ sich fast (s.u.) normal bedienen. Die fälschlich verschobenen Mails habe ich dann wieder in ihre Ursprungsordner einstellen können.

Ich kann daher jedem, der größere Mailordner sein eigen nennt, nur raten, vor einem Umstieg auf das neue KDE und sein Kmail alle eingerichteten Filter zunächst mindestens zu deaktivieren, wenn nicht gar zu löschen – und sie erst im Nachheinein neu einzurichten.

Aber auch dann bereiten die lokalen Filter in Kmail noch weitere Probleme:

Im Gegensatz zu früheren Kmail-Varianten werden nämlich alle auf dem IMAP-Server für das Löschen markierte – aber im IMAP-System aus den Ursprungsordnern physikalisch noch nicht gelöschte Mails – erneut in den Mail-Ordnern von Kmail angezeigt (in grauer Schriftfarbe). Regeln zur Kompaktifizierung der IMAP-Ordner – sprich zu einem sofortigen Löschen von Mails in den IMAP-Ordnern auf dem Server – sind bei mir deaktiviert. Mails werden daher auf dem IMAP-Server bei Lösch- oder Verschiebe-Vorgängen in ihrem Ursprungsordner nur zum Löschen markiert. Die eigentlichen Löschungen laufen dann am IMAP-Server zwar periodisch, aber mit deutlichem zeitlichem Abstand. Das ist eine reine Vorsichtsmaßnahme, von der die User an ihren Clients (wie dem alten Kmail) normalerweise gar nichts mitbekommen.

Aus der Anzeige der zum Löschen markierten Mails in Kmail lässt sich schließen, dass Akonadi beim Filtern und Verschieben der Mails in neue Ordner also mitbekommt, dass die verschobenen Mails auf dem IMAP-Server noch im Ursprungsordner vorhanden sind – wenn auch mit geändertem Status. Nun wirkt sich das leider negativ auf die Filter in Kmail aus. Die Filter bewerten die markierten Mails offenbar als neu eingegangene (möglicherweise wegen der Statusänderung) und filtern sie deshalb auch erneut. Obwohl sie ja schon früher behandelt und in andere Ordner verschoben wurden. Und das setzt sich dann so fort ….

Ergebnis:
Nach einigen periodischen Abgleichen zwischen Akonadi und dem Imap-Server wächst der Inhalt in Trash oder Spam-Ordnern linear an. Mit immer den gleichen Dateien. Das ist im Produktivbetrieb ein Desaster. Als Anwender kann man hier das Gesamtsystem nur so einstellen, dass bei der Löschung/Verschiebung einer Mail aus einem Ordner durch eine Kmail-Aktion auch eine sofortige Löschung der Mail in ihrem Ursprungsordner auf dem IMAP-Server vorgenommen wird. Das ist zumindest riskant. Oder man muss die Filter um sehr spezielle Einstellungen und Kriterien erweitern – was man vom normalen User nicht verlangen kann.

Die Lösung aus meiner Sicht wäre eine andere Behandlung von Mails, die auf dem IMAP-Server zum Löschen markiert sind, in Akonadi wie in der Anzeige und den Filter-Routinen von Kmail.

In der jetzigen Form ist das Kmail/Akonadi-Verhalten im Zusammenspiel mit IMAP-Servern zwar schon erstaunlich stabil und auch die Migration der Mailordner zu Akonadi-Ressourcen funktioniert im Kern schon richtig. Aber die Behandlung von Mails, die aufgrund von Client-Aktionen auf den IMAP-Servern zum Löschen vormarkiert werden, muss für den produktiven Einsatz geändert werden.

Hinzu
kommt ein weiteres Problem, dessen Ende ich auf meinem Versuchssystem noch nicht absehen kann. Mindestens am ersten Tag der Umstellung fraß der “virtuoso-d”-Prozess mit führendem Abstand die allermeiste CPU-Zeit auf meinem System (in Form von nice-Last). Ursache ist die Indizierung von Mails durch Nepomuk mit Virtuoso als Backend (virtuoso-t ist wohl ein zugehöriger Datenbank-Prozess).

Dabei war die Konkurrenz um die Prozessorzeit keineswegs gering – auf zwei von 4 CPU-Cores habe ich andauernd unter VMware auf einem virtuellen Windows-System gearbeitet. Normalerweise würde VMware die meiste CPU-Zeit beanspruchen. Bei KDE 4.6 Beta war es bislang aber der Prozess “virtuoso-d”. Er verbrauchte doppelt soviel CPU-Zeit wie VMware – und zwar im bereich mehrerer Stunden. Das ist wirklich viel!

Ob das daran liegt, dass ich Gigabytes an Mails habe, vermag ich im Moment nicht zu sagen. Ich hoffe jedenfalls noch, dass “virtuoso-t” nach vielleicht weiteren 12 Stunden endlich Ruhe gibt. Im Moment ist er immer noch fleißig am Werkeln. Fairerweise muss ich sagen, dass vituoso-t sich auf einen Prozessor-Core beschränkt und nach ersten Eindrücken auch nur dann so richtig aktiv wird, wenn tatsächlich noch CPU-Zeit verfügbar ist. Na ja, wir werden sehen, ob die Nepomuk- Indizierung auch mal zu einem Ende kommt. Insgesamt ist das Ganze aber in Indiz dafür, dass man Virtuoso oder aber das Zusammenspiel von Akonadi und Virtuoso ggf. noch effizienter machen muss.

Im Moment würde ich wegen der geschilderten Erfahrungen noch niemanden raten, auf produktiven Systemen auf das neue Kmail umzusteigen.

Zu Punkt 3 – Korganizer, Kadressbuch, OX5:

Das funktioniert im Moment schlicht und einfach nicht. Die Einrichtung von Kalendern als Teil einer OX5-Verbindung zu Kontakt scheitert. Einen entsprechenden Bug habe ich eingestellt. Das ist für mich im Moment übrigens der Hauptgrund, bei KDE 4.5.3 zu bleiben.

Auf einige Ungereimtheiten beim Umgang mit dem OX5-Adressbuch mag ich hier nicht mehr eingehen. Das läuft zwar als Relikt aus 4.5.3 zwar irgendwie, aber dennoch habe ich den Eindruck, dass die zugehörige Akonadi-Ressource nicht wirklich migriert wurde. Denn wenn ich auf die Eigenschaften der entsprechenden Akonadi-Resource zum OX5-Adressbuch gehe, öffnet sich ein Dialog zur Migration – in dem leider Open-Xchange gar nicht als Alternative erscheint. Womöglich arbeitet das “übernommene” Adressbuch also auf einer alten, nicht upgedateten Akonadi-Resource, die keine Verbindung zum OX-Server mehr aufweist. Bin im Moment aber zu faul, mir das genauer anzusehen.

Fazit:

Interessant war es schon, Akonadi nun mal im breiten Einsatz für Gigabytes an Mail zu sehen und nicht nur als Quelle für simple und in der Anzahl überschaubare Adressbuch-Daten. Im Kern funktioniert das schon. Bis auf “Kleinigkeiten” wie die Anzeige von zum Löschen markierten Mails des IMAP-Server und die Behandlung von Filteraktionen für solche Mails.

Ich bin daher sehr gespannt, wie sich KDE 4.6.Beta 2 bzw. der Release-Kandidat präsentieren werden. Im Moment ist Kontact KDE 4.6 in unserem Arbeits-Umfeld jedenfalls noch nicht reif für den produktiven Einsatz. Was ich bei einer ersten Beta-Version auch keinesfalls überbewerten will, sondern als normal ansehe.

Nachtrag: Problem mit der FROM-Adresse

Gerade macht mich meine Frau darauf aufmerksam, dass Mails, die ich von meiner Testinstallation verschicke, eine leere FROM-Envelope-Adresse aufweisen. Dies geschieht seit der Installation der letzten Kmail-RPM-Variante 4.5.80-261.2 vom Opensuse Factory-Repository unter KDE 4.6 Beta. Obwohl alle notwendigen Daten in der Kmail-“Identität” gepflegt sind. Na ja, Beta halt ……

Kmail mit Postfix und Cyrus Imap unter OX

Posted on by

Einige unserer Bekannten, die unsere Mail-Konfiguration unter Linux gesehen haben, spielen jetzt mit dem Gedanken, in Ihrem Netz einen eigenen kleinen IMAP-Server zu installieren, um die Mail-Verwaltung und vor allem die Mailsicherung zu zentralisieren. Besonders Mutige möchten dabei sogar einen Open-Xchange-Server einsetzen. Als Client ist KDEs Kmail geplant (unter dem kommenden KDE 4.2).

Ein solches Vorhaben ist grundsätzlich lobenswert: Schon in einer dreiköpfigen Familie kann sich der Linux-Freund viel Zeit und Ärger ersparen, wenn er mit einem Server arbeitet.

Er sei aber gewarnt: Eine Mail-Server-Konfiguration ist nicht gerade eine einfache Übung. Die anfängliche Zeit- und Aufwands-Investition in ein solches Unterfangen ist erheblich. Als ich damit anfing, versuchte ich erst einmal, 2 Bücher zu dem Thema wenigstens ansatzweise zu verstehen, bevor ich praktisch loslegte. Es gibt einfach wahnsinnig viele Dinge, die man vorab wissen und richtig einordnen sollte.

Wir können in diesem Beitrag nur ganz kurz auf den Server eingehen – es geht uns mehr um die Anbindung von KDEs Kmail an den laufenden Server. Dennoch wollen wir wenigstens skizzieren, wie die Gesamtkonfiguration für ein kleines Netzwerk aussehen kann.

Mögliche Serverkonfiguration und Mailtransfer

Wir beschreiben der Einfachheit halber eine “isolierte” Server-Konstellation für ein kleines privates Netz oder das Netz einer kleinen Firma. Der Mailserver beinhaltet dabei folgende Komponenten:

  • Fetchmail [zum Abholen von Mails aus Postboxen bei Mail-Providern im Internet]
  • Postfix ( Mail Transfer Agent) [Fetchmail leitet Mails in die SMTP-Eingangsqueue von Postfix. Nach einer Aufbearbeitung gibt Postfix die Mails an einen IMAP-Server weiter. Postfix transferiert zudem ausgehende Mails über seine SMTP-Queues an einen SMTP-Relay-Server beim Provider weiter].
  • Cyrus IMAP [Der IMAP-Server organisiert und verwaltet Mails, die ihm Postfix zuliefert in strukturierten Mailboxen (besser Mail-Directories). Auf diese Mailboxen greifen dann Linux-Clients im LAN mit Hilfe von Kmail als MUA (Mail User Agent) zu].
  • Groupware-Komponenten von Open-Xchange [Kalender, Task-Folder etc., auf die mit KDE Kontact/Korganizer zugegriffen werden soll. Die Open-Xchange-Accounts sind dabei aber engstens mit den lokalen Mail-Accounts verbunden.]
  • Ggf. eine lokale Firewall (z.B. auf Basis von IPtables)

Private Domaine im LAN vs. registrierte Domaine im Internet

Die Komponenten Postfix und Cyrus sind dabei nur zuständig für die lokale private Domaine des Firmen-LANs und die zugehörigen Mail-Accounts. Der Mail-Server hängt nicht direkt am Internet und darf nur von internen Clients zur Weiterleitung von Mails an einen SMTP-Server im Internet benutzt werden. Der lokale Mailserver liegt also möglicherweise hinter einer Firewall, die von außen keinen SMTP-Verkehr ins LAN hinein zulässt.

Der Mailverkehr im Internet läuft dagegen über Mailboxen und SMTP-Server bei einem Service-Provider ab: Der lokale Mailserver des LANs kommuniziert über Fetchmail bzw. SMTP mit den POP/IMAP- bzw. SMTP-Server des Providers, wenn Mails geholt bzw. Mails versendet werden.

Weitere Merkmale und Eigenschaften der Konfiguration sind:

  1. Der MTA Postfix ist nur der “privaten” internen Domaine des lokalen Netzwerkes
    zugeordnet. Er ist als Endstation eines Mailtransfers ausschließlich für Mail-Accounts (Postboxen) von Usern dieser Domaine zuständig. Diese “Domaine” hat keine Entsprechung zu realen, registrierten Domainen im Internet. Sie ist nur einem lokalen DNS-Server im LAN, nicht aber offiziellen DNS-Servern im Internet bekannt.
  2. Die Postboxen der lokalen Domaine sind die des IMAP-Servers. Sie können aus dem Internet nicht direkt beliefert werden. “Reale” Mailaccounts, die aus dem Internet beliefert werden können, befinden sich nur beim Mail-Service-Provider. Auch der Postversand ins Internet erfolgt über einen SMTP-Server beim Provider: der dortige SMTP-Server wird also als Zwischenstation – als sog. “Relay-Server” – verwendet.
  3. Der “Cyrus” IMAP-Server ist dem Postfix-System nachgelagert. Postfix interagiert mit dem IMAP-Server über das Protokoll LMTP. Mail-Clients (MUAs) wie Kmail unterhalten sich mit dem IMAP-Server dagegen über das IMAP-Protokoll.
  4. Postfix empfängt Mails über ein vorgeschaltetes Fetchmail-Modul, dass periodisch E-Mails aus den Postfächern bei Providern abholt (i.d.R. über POP3). Die Einspeisung in Postfix erfolgt lokal über SMTP. Postfix übermittelt dem Cyrus IMAP Server dann die eingegangenen Mails über LMTP weiter.

    Das skizziert allerdings nur die Grundstruktur der Behandlung eingehender Mails auf dem Server. Die Einbindung von Viren- und Spamscannern in die Postfix-Verarbeitungsmechanismen erfordert natürlich zusätzliche Maßnahmen. Wir setzen in diesem Zshg. z.B. auch “procmail” für Filteraufgaben ein. Auf Details können wir an dieser Stelle leider nicht eingehen.

  5. Der Mailversand der Clients erfolgt über das SMTP-Protokoll zunächst an Postfix; Postfix leitet die Mails dann an den SMTP-Server des Providers (Relay-Server) weiter. Erst von dort werden die Mails in Richtung auf den Empfänger im Internet weitergeleitet. Auf dem Relay-Server muss Postfix sich i.d.R. authentifizieren. Hierzu müssen ensprechende Authentifizierungs- und Verschlüsselungsverfahren von Postfix unterstützt werden.

    Die Postfix-Konfigurationsdatei “main.cf” muss den passenden Relay-Server-Eintrag enthalten. Je nach Auth-Mechanismus beim Service-Provider müssen zudem passende sasl-Libs vorhanden sein. Ein Auszug aus der “/etc/postfix/main.cf” zeigt das Wesentliche:

    relayhost = smtp.strato.de
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    smtp_always_send_ehlo = yes
    smtp_sasl_security_options = noanonymous

    Die Zugangsdaten sind in der Datei sasl_passwd zu hinterlegen und über das “postmap”-Komando zu aktivieren.

  6. Die “realen” Mailadressen beim Provider (für eine im Internet registrierte eigene oder fremde Domaine) müssen auf die internen Accounts des IMAP-Servers in der “privaten” Domaine abgebildet werden. Auf dem Weg von der Mailbox beim Serviceprovider zum eigenen Postfix- und dem IMAP-Server erfolgt die Adress-Umsetzung dagegen durch Fetchmail, das entsprechend konfiguriert sein muss (Datei /etc/fetchmailc). Auf dem Weg nach außen erledigt dies dagegen Postfix über entsprechend konfigurierte “canonical maps” (Datei “/etc/postfix/sender_canonical” und Befehl “postmap”!).

Konfiguration und Anbindung von Kmail

Die Anbindung von Kmail an einen IMAP-Server (z.B auf einem Open-Xchange-Server) im eigenen LAN ist im Grunde simpel. Eine Sache gibt es es bei der Einrichtung aber doch zu beachten – die Festlegung der sog. Identität. Diese muss zu den eingerichteten Accounts des Open-Xchange [OX]-Systems passen – sonst lassen sich später (private) Kalender-Folder und Task-Folder wegen fehlender Rechte nicht sauber in Kontact/KOrganizer einbinden. Schwierigkeiten kann
es dann auch bzgl. der Organisator-Rolle bei der Anlage von Gruppenterminen geben.

Folgende Punkte sind bei einer Anbindung von Kmail anzupassen:

Festlegung der sog. Kontact/Kmail – “Identität”

Die Konfiguration erfolgt über den Menüpunkt “Einstellungen -> Kmail einrichten”. Im sich öffnenden Fenster legt man die zu verwendende Identität unter der Rubrik “Identitäten” fest. (Die Möglichkeit, mehrere Identitäten anzulegen, blenden wir nachfolgend aus.)

Hinweis für OX-Clients:
Bei der Identitätsdefinition ist es wichtig, unter dem Reiter “Allgemein” bei der Email-Adresse exakt die Adresse anzugeben, die auch auf dem OX-Server verwendet wird und nicht diejenige Adresse, die im externen Mailverkehr als Antwortadresse verwendet wird. Der Grund hierfür liegt im OX-Rechtesystem. Will man später seine Kalenderordner an Kontakt anbinden, so werden die Rechte an den zugehörigen privaten Kalender-Ordnern des OX-Systems anhand des Mail-Accounts überprüft. Ferner wird die Mailadresse auch benutzt, wenn man als Organisator von Gruppenterminen im Kalender auftritt. Die Festlegung der Identität hat also Auswirkungen bei der Termin- und Aufgabenplanung im Team (Kontact – Kalender-Modul).

Um die Unterschiede zwischen den Mailangaben für die interne Identität und den Eigenschaften einer externen Mailidentität im Internet beim Mailverkehr nach aussen zu kompensieren, müssen entsprechende Einträge in der Postfix-Konfigurations-Datei “sender_canonical” vorgenommen werden (nicht vergessen “postmap” auszuführen, um die Umsetzungsregeln auch in die interne Postfixdatenbank zu übernehmen und damit wirksam zu machen). Postfix ersetzt dann in allen ausgehenden Mails automatisch interne Adress- und Domainangaben in passende Angaben realer Mailaccounts, die im Internet verwendbar und überprüfbar sind.

Unter dem Reiter “Kryptografie” pflegt man ggf. seine PGP-/S-Mime-Schlüssel für Signaturen und verschlüsselte Mails ein. OpenPGP sowie KGpg sollten dafür installiert und gepflegt sein. Die Warnung, dass die Signatur für eine andere Emailadresse (nämlich die reale im Internet) ausgestellt wurde, kann man bei korrekten Umsetzungsregeln in Postfix – für externe wie interne Empfänger – ignorieren.

Der Reiter “Erweitert” erlaubt später die Einrichtung der Ordner für versendete Dateien, Entwürfe und Vorlagen zur angelegten “Identität”. Damit man dabei auch Ordner des IMAP-Servers auswählen kann, muss die Anbindung an den Server erst einmal stehen. Man holt diese Ordner-Konfiguration einfach später nach. Unter diesem Reiter legt man übrigens auch die “Antwort”-Mail-Adresse (“Reply to” – Adresse) für seine Mails fest.

Unter dem Reiter “Signatur” pflegt man seine Signatur-Angaben ein – also den Abspann für Mails. Ob dieser Abspann bei zitierten Mails vor oder nach dem Zitat-Bereich eingefügt werden soll, legt man übrigens unter “Einstellungen – Kmail einrichten – E-Mail-Editor – Reiter Allgemein” fest.

Festlegung des IMAP-Zugangs

Die Einstellungen für den Zugang zu einer Mailbox des IMAP-Servers (samt der untergeordneten Mail-Directory-Struktur) nimmt man unter dem Menüpunkt “Einstellungen – Kmail einrichten – Zugänge” vor. Danach geht man zum Reiter “Empfang”. Hier muss man sich grundsätzlich entscheiden, ob man einen replizierenden, sog. “disconnected Imap” – Zugang oder einen gewöhnlichen IMAP-Zugang anlegen will.

Hierzu folgender Hinweis: Ich habe bei früheren KDE 3.5-Versionen immer einen “disconnected IMAP” Zugang angelegt, obwohl die Replizierung der Mails bei mir enorm viel lokalen Speicherplatz auf der Platte verbrauchte (2 GB). Das verursachte auch länglich Abgleichzeiten mit intensivem Plattenzugriff. Diese Nachteile habe ich in Kauf genommen, um etliche Kmail-Fehler bei der Anwendung von lokalen Filterbefehlen (z.B. für eine Virusanalyse) über mehrere
100 Mails hinweg zu umschiffen. Das sukzessive und automatische Abarbeiten vieler mails hat mit normalen IMAP-Zugängen nie so richtig ohne Fehler und Abbrüche bis Abstürze funktioniert. Sehr wohl ging das aber fehlerfrei mit den replizierten (lokalen) Mails der disconnected-IMAP-Variante.

Unter KDE 4.2 habe ich bisher allerdings keine Probleme feststellen können. Daher verwende ich hier inzwischen einen normalen IMAP-Zugang.

Nach der Festlegung der IMAP-Zugangs-Art wählt man “Hinzufügen” und arbeitet dann der Reihe nach die Reiter für den neuen Zugang ab.
Die Zugangsdaten (IMAP-Account-Id und zugehöriges Passwort; diese Daten muss man natürlich kennen) zur eigenen Mailbox auf dem IMAP-Server werden unter dem Reiter “Allgemein” eingegeben. Kreuzt man dabei “IMAP-Passwort merken” an, so wird das Passwort nach Rückfrage in Kwallet hinterlegt.

Unter dem Reiter “Erweitert” bekommt man neben den typischen Einstell-Möglichkeiten für abonnierte und versteckten Ordner auch die Möglichkeit, die für diesen Zugang zu verwendende Identität festzulegen. In der Regel hat man nur eine, nämlich die, die man schon weiter oben angelegt hat. Festgelegt wird hier auch der Ordner für den Mülleimer.

Bei der Pfad-Angabe “Persönlich” trägt man das Inbox-verzeichnis auf dem IMAP-Server ein (meist “INBOX/”). Bei Namensräumen i.d.R.: “user/”
– das ist der Pfad unter /var/spool/imap, der zu den Verzeichnissen der einzelenen IMAP-Accounts (IMAP-User) führt. Den Punkt “Freigegeben” läßt man <Leer>.

Unter dem Reiter “Sicherheit” kann man Sicherheitsfeatures des IMAP-Servers testen. Ich habe auf unserem OX unter anderem TLS eingerichtet. Im internen Netzwerk benötige ich die verschlüsselte Übertragung zu meinem Arbeitsplatz aber zumeist nicht. Dies mag in anderen Firmen anders sein.

Sieve-Filtering kann man unter dem letzten Reiter angeben, wenn man den IMAP-Server entsprechend eingerichtet hat. (Die OX-Oberfläche hilft beim Festlegen von Sieve-Einstellungen).

Alle IMAP-Zugangs-Einstellungen sind einfach zu überblicken. Hat man alles richtig gemacht, so kann man nun bereits sein Postfach auf dem IMAP-Server sehen. (Wurde ein “disconnected Imap”-Zugang angelegt, so muss man im nächsten Schritt die erstmalige Replikation aller (abonnierten Ordner) vornehmen. Menü “Datei – nach Email sehen “; dann den IMAP-Zugang wählen, den man zuvor konfiguriert hat.)

Hinweis: Das Menü “Datei” enthält einen Punkt “Alte Nachrichten aus allen Ordnern löschen”. Nicht benutzen! Und bitte auch für keinen Ordner Verfallszeiten für Mails einrichten. Das Löschen geht so schnell – und wehe, man hat dann keine regelmäßige IMAP-Sicherung ! Ich würde es gerne sehen, dass dieser Befehl aus dem regulären Satz an Menü-Befehlen verschwindet.

Festlegung des SMTP-Versands

Die Einstellungen für den Mailversand per SMTP nimmt man unter dem Menüpunkt “Einstellungen – Kmail einrichten – Zugänge” vor. Danach geht man zum Reiter “Versand”. Auch dort sind die Einstellungen einfach vorzunehmen. Wieder kann man TLS oder SSL für eine verschlüsselte Übertragung der Mails zum Server einrichten. Der Reiter “Erweitert” erlaubt die Eingabe von Authentifizierungsdaten und die Wahl des Authentifizierungsverfahrens (SMTP-AUTH Mechanismus). Wir setzen CRAM-MD5 ein. Der OX Server mit Postfix muss natürlich bzgl. der SMTP-Auth Mechanismen entsprechend eingerichtet sein. Postfix bedient sich diesbzgl. der (Cyrus) SASL-Mechanismen. Wir benutzen bei uns als Authentification Backends sowohl “saslauthd” als auch “auxprop” plugins (mit sasldb(2)). Die Fähigkeiten des Servers kann man vor der Festlegung des Auth-Mechanismus testen.

Festlegung von Verzeichnissen

Unter Kmail werden die Einstellungen für bestimmte Verzeichnisse an folgenden Orten festgelegt:

  • Ordner für versendete Nachrichten : Einstellung unter Menü “Einstellungen – Kmail einrichten”, dann “Identitäten”, dort Reiter “Erweitert”
  • Ordner für Entwürfe : Einstellung unter Menü “Einstellungen – Kmail einrichten”, dann “Identitäten”, dort Reiter “Erweitert”
  • Ordner für Vorlagen : Einstellung unter Menü “Einstellungen – Kmail einrichten”, dann “Identitäten”, dort Reiter “Erweitert”
  • Mülleimer für gelöschte Mails: Einstellung unter Menü “Einstellungen – Kmail einrichten”, dann “Zugänge – Reiter Empfang”, dann IMAP-Konto wählen – Reiter “Erweitert”
  • Ordner, der beim Start von Kmail geöffnet werden soll: Menü “Einstellungen – Kmail einrichten”, dann “Diverses”

In allen Fällen können dort auch Verzeichnisse im Directory-Baum des IMAP_Servers angegeben oder ausgewählt werden, sobald der Zugang zum IMAP-Server etabliert wurde.

Hinweis:
Natürlich kann man neben dem IMAP-Zugang zum eigenen IMAP-Server auch weitere POP- und IMAP-Zugänge zu externen Servern im Internet einrichten. Für ganz besondere Konstellationen ist es dann im Menü “Einstellungen – Kmail einrichten – Identitäten – Reiter Erweitert” möglich, für jeden IMAP-Zugang einen eigenen SMTP-Versandweg einrichten, wenn dies erforderlich sein sollte.

Mehr ist für ein funktionierendes Zusammenspiel auf der Kmail Seite nicht zu tun. Dem Text kann man aber schon entnehmen, dass die eigentlichen Schwierigkeiten bei der Einrichtung eines funktionierenden Mailsystems im lokalen netzwerk eher auf der Seite des Servers – also bei der Postfix und Cyrus-Konfiguration liegen.

Wir werden uns einigen Details der Mailserver-Konfiguration vielleicht in späteren Beiträgen widmen.

OX5 – verlorener Ordner “Kontakte” nach Upgrade

Posted on by

Das letzte Update des OX5-Servers auf das SP4 U1 führte in unserer Umgebung leider zu folgendem Fehler:

Bei allen vorher existierenden User-Accounts waren plötzlich die privaten Adresseinträge nicht mehr zugänglich. So etwas ist trotz Sicherung mehr als ärgerlich. Nur die OX-Entwickler wissen vermutlich, wie es zu diesem Missstand kommen konnte. In einer Produktivumgebung ist sowas ein kleines Desaster.

Andererseits lieferte es in unserem Fall auch ein Beispiel dafür, dass man in einer Open Source-Umgebung solche Fehler mit ein wenig Geschick selbst beheben kann. Als nützlichen Nebeneffekt lernten wir dabei auch noch etwas über die Datenstrukturen von OX5, die auf unserem Server in einer Postgres-Datenbank mit der Bezeichnung “openexchange” abgelegt sind.

Der Fehler wurde auf unserem System dadurch sichtbar, dass ein Klick auf das Kontakt-Icon in der Bedienungsleiste des OX-Portals zur Meldung führte, dass man keine Berechtigung für den Zugriff besäße:

Kontakte
“Keine Berechtigung. Für den gewünschten Bereich fehlt Ihnen die Berechtigung.. “.

Daran änderte auch eine explizite neue Rechtevergabe für die betroffenen Accounts über die OX-Administrationsoberfläche leider gar nichts. Dann fiel uns auf, dass der bisher existente Default-Ordner “Kontakte” auch nicht mehr im persönlichen Ordnerbereich angezeigt wurde. Waren die privaten Adressdaten der verschiedenen User-Accounts also überhaupt noch vorhanden?

Kontakte Ordner, Datenbank und LDAP

Adressdaten werden im OX-System in sog. “Kontakte-Ordnern” abgelegt:

  • einem speziellen privaten Kontaktordner, der beim Anlegen eines Accounts automatisch erstellt wird (zusammen mit einem Kalender- und Aufgaben-Ordner)
  • selbst erstellten weiteren privaten Kontaktordnern,
  • einem “globalen Adressbuch”, das firmenweit gültige Adressen bereitstellt,
  • und in einem LDAP-Verzeichnisdienst.

Alle angelegten Kontakte tauchen dabei sowohl in der Openexchange Datenbank als auch im LDAP-Verzeichnis auf. Auf beide Quellen kann man unter KDE übrigens mit dem Informationsmanager “KDE Kontact” zugreifen.

In einem ersten Schritt bemühten wir den LDAP-Browser “gq”, um uns ein Bild davon zu verschaffen, welche Adresseinträge eigentlich auf dem LDAP-Server noch vorhanden waren. Mit Erleichterung konnte ich die Vollständigkeit privater Adresseinträge im Zweig

ou=addr,uid=MYSELF,ou=people,dc=MYDOMAIN,dc=de

des LDAP-Baumes feststellen. Meine eingepflegten Adressen war also zumindest dort noch vorhanden. Als nächsten Schritt legte ich dann einen neuen OX-Useraccount an, um herauszufinden, ob durch das Upgrade irgendwelche persönlichen Einstellungen verpfuscht worden waren. Zunächst konnte ich feststellen, dass der Vergleichsaccount
a) bis auf den Namen zu genau den gleichen Basiseinträge im LDAP führte, die auch mein Originalaccount aufwies,
b) und dass der Fehler mit dem Kontakte-Ordner für den neuen Account gar nicht auftauchte !

Die Ursachen für den Fehler waren also wirklich im Upgrade und irgendwelchen irregulären Datenbanktransaktionen für die vorhandenen Accounts zu verdanken.

Tabellen für Kontakte, Defaultordner und Zugriffsrechte in der Datenbank “openexchange”

Also: SSH-Zugriff auf den OX-Server. “su postgres” absetzen und danach mit “psql openexchange” auf die Postgres-Datenbank zugreifen. Ein “\dt” verschafft einem dann einen Überblick über die vorhandenen Tabellen. Nach etlichen Selects und ein wenig Kombinationsvermögen erkennt man schließlich Folgendes:

  1. Die “Standardordner” eines Benutzeraccounts sind u.a. in der Tabelle “oxfolder_standardfolders” über Referenzschlüssel eingetragen.
  2. Die eigentlichen Ordnereinträge findet man in der Tabelle oxfolder_tree. Der dortige Primary Key entspricht dann für die Defaultordner (u.a. ”
    Kontakte”) eines Users den Referenzschlüsseln in der Tabelle “oxfolder_standardfolders”.
  3. Adressdatensätze sind in der Tabelle “prg_contacts” eingetragen. Dort tauchen in entsprechenden Spalten dann natürlich auch Referenzschlüssel zum jeweiligen Ordner und zum User auf. (In dieser Tabelle fand ich dann in schöner Übereinstimmung zum LDAP auch meine privaten Adresseinträge wieder).
  4. Die Rechte zu den Ordnern sind in der Tabelle “oxfolder_permissions” eingetragen. (Details der numerischen Rechtekammstruktur lassen sich durch Beispieleinträge mit unterschiedlich vergebenen Rechten analysieren und ermitteln).

Durch Vergleich der Einträge zu meinem Originalaccount in den verschiedenen Tabellen mit entsprechenden Einträgen zu einem frisch angelegten Useraccount konnte ich dann folgende, durch das Upgrade entstandene Defizite ermitteln:

  • In der Tabelle “oxfolder_tree” fehlte in der Spalte “owner” der Eintrag des User-Kürzels. Dies war durchgängig für alle Accounts der Fall, die bereits vor dem Upgrade existierten.
  • In der Tabelle “oxfolder_permissions” fehlten die Einträge für die Default-Kontakteordner der User völlig.

Nach einem Vergleich mit den Daten eines neuen Accounts konnte wir mit Hilfe von Update- und Insert-Statements die erforderlichen Sätze letztlich recht einfach rekonstruieren. Und siehe da: Danach führte dann auch der Klick auf das “Kontakte”-Ordner-Icon wieder zum gewünschten Ergebnis!

Fazit:

Auch bei einem rel. umfassenden System wie “Open-Xchange” hat man im Fehlerfall (manchmal) eine Chance, diesen selbst zu beheben. Ein echter Vorteil von Open Source-Produkten! Das Auftreten des beschriebenen Problems im Zuge eines Upgrades ist aber dennoch in höchstem Maße ärgerlich!