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:

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:

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

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

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:

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.