Kontact 4.7 und OX 6 unter Opensuse 11.4 – Teil II

Einleitung und Inhalte dieses 2-ten Beitrags zu einer OX 6 Testinstallation

Im ersten Teil dieses Beitrages zu einer OX6-Testinstallation haben wir eine OX6-Grundinstallation auf einem “Opensuse 11.4”-Server vorgenommen. Siehe auch:
https://linux-blog.anracom.com/2011/08/21/kontact-47-und-ox-6-unter-opensuse-114-teil-i/ .

Es stand noch aus, einen ersten OX-Kontext und zugehörige OX6-User anzulegen.

Letztere sollen unter der OX-eigenen Web-Oberfläche auf den externen IMAP-Server zugreifen können. Der IMAP-Server, mit dem der OX6-Server kooperieren soll, läuft in unserer Testkonfiguration auf einem separaten Server. Wir werden uns nachfolgend daher damit auseinander müssen, wie sich diese Trennung der Serversysteme auf die Einrichtung von OX6-Usern auswirkt.

In einem nachfolgenden dritten Blog-Beitrag wollen wir abschließend testen, ob und wie der Zugriff von Kontact auf den OX6-Server funktioniert.

Anlegen eines Default-Kontextes

Im ersten Teil sind wir bereits auf Kontexte eingegangen. Wir legen nun als “oxadminmaster” den sog. Default-Kontext an und kreieren dabei gleichzeitig den zugehörigen Default-Kontext-Administrator, dem wir hier willkürlich den Usernamen “oxadmin” geben. Das Ganze geschieht wieder durch ein Skript:

#   /opt/open-xchange/sbin/createcontext  −oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 1  −u oxadmin  −d “Context Admin”  −g Admin  −s User  −p MY_OX_CONTEXT_ADMIN_PWD  −L defaultcontext  −e oxadmin@mydomain.de  −q 1024  −−access-combination-name=all

Ein paar Hinweise zu den Optionen (s. auch die Befehlsbeschreibung im OX6-Manual “OX6-Provisioning.pdf”):

  • Das “-c 1” definiert die Kontext-Id,
  • das “-u” die User-ID,
  • das “-d” den Displaynamen für den Kontext-Admin,
  • das “-g” den “Given Name” (Vorname),
  • das “-s” den Nachnamen,
  • das “-L” das sog. Login-Mapping (hier eben auf den Defaultkontext),
  • das “-e” die E-Mail-Adresse des Kontext-Admins,
  • das “-q” den kontext-weiten Quota-Betrag in MByte (!),
  • ein “-N” einen Kontext-Namen.

Ein Kontext kann auch einen Namen erhalten – hierzu ist der Parameter “-N” einzusetzen. Dieser Name kann z.B. beim Login-Mapping verwendet werden (s.u.).

Als Email-Adresse sind wir von einem IMAP-Account “oxadmin@mydomain.de” ausgegangen, der über unseren IMAP-Server versorgt wird. Unser IMAP-Server ist dabei wie gesagt nicht identisch mit dem Server des OX6-Systems.

Obwohl die Kommandos für die spätere Anlage normaler OX6-Anwender ähnlich sind, ist die Anlage des “Kontext-Administrators” ein besonderer Akt, der initial die Berechtigung des OX6-Adminmasters erfordert.

Hinweis zu mehreren Kontexten und zum kontextspezifischen Login-Namen eines Users

Legt man später mehrere Kontexte an, so geschieht dies für den zweiten Kontext etwa über

#   /opt/open-xchange/sbin/
createcontext  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 2  −u oxadmin  −d “Context Admin”  −g Admin  −s User  −p MY_OX_CONTEXT_ADMIN_PWD  −e oxadmin@mydomain.de  −q 1024  −−access-combination-name=all

Man beachte 2 Dinge:

  • Für das Anlegen des Kontextes und gleichzeitig des Kontext Admin ist die Autorisierung als “oxadminmaster” erforderlich. Die weitere Gestaltung des jeweiligen Kontextes und auch die Pflege der zugehörigen User obliegt danach aber dem jeweiligen Kontext-Admin!
  • Jeder User-Account ist kontextspezifisch. Auch der “oxadmin”-User für den Kontext 2 ist keineswegs identisch mit dem “oxadmin”-user für den Kontext 1 !
  • In der Praxis sollten die Kontext-Administratoren natürlich besser unterschiedliche Bezeichnungen bekommen.

Der Login in einen spezifischen Kontext durch Angabe der Kontextnummer nach dem Usernamen, also z.B. durch “oxadmin@1” für den Kontext mit der Nummer 1 oder “oxadmin@2” für den Kontext 2, falls – wie im obigen Beispiel – in jedem Kontext ein User “oxadmin” angelegt wurde. Möchte man statt mit Kontext-ID-Nummern lieber mit “Kontextnamen” operieren, so kann man ein entsprechendes “Login-Mapping” durch folgende “Kontextänderung” bewirken:

#   /opt/open-xchange/sbin/changecontext  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 2  −N verwaltung  −L 2,verwaltung

Dieser Befehl ordnet dem Kontext 2 den Namen “verwaltung” zu. Ein Login in diesen Kontext würde für den User “oxadmin” danach also auch mit der Eingabe der Userbezeichnung “oxadmin@verwaltung” in einer Login-Maske möglich sein.

Hinweis zu einem typischen Fehler aufgrund bestimmter anfänglich zu viel installierter OX6-Pakete

Bei mir schlug das Kommando zur Kontextanlage trotz Variationsversuchen zunächst zig-fach fehl, weil ich unvorsichtigerweise das Paket “open-xchange-admin-plugin-autocontextid” installiert hatte (s. hierzu auch die Warnung in Teil 1).

Ich wurde dann mit Fehlermeldungen der Art

Error: Unrecognized options on the command line: Unknown option “-c’

oder

com.openexchange.admin.plugins.PluginException: com.openexchange.admin.rmi.exceptions.StorageException: Table ‘configdb.sequence_context’ doesn’t exist

konfrontiert. Letzteres wenn ich testweise das “-c” weggelassen habe. Das Paket “open-xchange-admin-plugin-autocontextid” setzt nämlich Zusatztabellen voraus, die bei unserer Grundinstallation nicht implementiert wurden.

Siehe zu diesen Fehlern
https://forum.open-xchange.com/showthread.php?5935-Error-option-c-not-recognized-when-running-createcontext

Ich habe in meinem Fall dann eine Neuinstallation mit genau den Paketen durchgeführt, die in der Referenz-Installationsanleitung (s. Teil 1) aufgeführt sind. Danach lief das Kommando einwandfrei durch.

Unzureichende Default-Einträge für den IMAP-Mail-Account des Kontext-Administrators

An dieser Stelle lohnt sich nun ein Blick mit PhpMyAdmin in das lokale MySQL-RDBMS, Datenbank “oxdatabase_{ID}”, Tabelle “user“. Es zeigt sich, dass nun für den Kontext 1, der bislang auch unser
Defaultkontext ist, ein Eintrag mit folgender Feldbelegung existiert:

  • cid = 1
  • id = 2
  • imapServer = imap://localhost:143
  • mail = oxadmin@anracona.de
  • smtpServer = smtp://localhost:25
  • etc.

Einen korrespondierenden Eintrag findet man in der Tabelle “user_mail_account“. Man beachte dort auch das Feld “default-flag”, das für diesen ersten Maileintrag zum User “oxadmin” auf “1” gesetzt ist. Für weitere Maileinträge, die man später über die Web-Oberfläche des OX6-Systems erzeugen kann, ist das nicht der Fall. Dort findet man dann eine “0”.

Das obige Kommando für die Kontexterzeugung geht für den User “oxadmin” im jeweiligen Kontext also von der Existenz eines Default-Email-Accounts auf dem lokalen OX6-Server nach dem Muster “imap://localhost:143” aus.

Der würde in unserem Fall aber unglücklicherweise nicht funktionieren, da unser IMAP-System ja auf einem anderen Server vorausgesetzt wurde. Login-Versuche des eben angelegten Users “oxadmin” über die Web-Oberfläche des OX6 würden mit nachaltigen Fehlermeldungen und einer Abschaltung des E-Mail-Subsystems für diesen User quittiert werden. Also müssen wir die Angaben für den User ändern (s.u.).

Dabei gilt es zu beachten, dass dem Default-Email-Account eines OX6-Users eine besondere Bedeutung zukommt.

Behandlung des Default-Mail-Accounts für OX6-User auf einem separaten IMAP-Server

Durch etwas Lesen und Herumprobieren findet man folgenden, eigentlich logischen Punkt heraus:

Jeder User auf dem OX-Server erhält eine Default-Mail-Adresse zugeordnet. Die implizite Annahme ist dabei wohl die, dass dieser Default-Mailaccount ein fester Bestandteil der OX6-Einrichtung ist und auf dem gleichen Server wie das OX-System selbst eingerichtet sein sollte. Alle anderen IMAP-Accounts eines Users sind davon externe unabhängige Dinge. Aber der Anspruch einer OX6-Einrichtung ist der, dass das OX6-System jedem seiner User einen eigenen Mail-Account anbietet. Nun habe ich aber bereits einen separaten IMAP-Server im Netz. Und dort will ich natürlich auch die Default-Accounts des OX6-Systems betreiben!

Wichtig für das erfolgreiche Zusammenspiel des OX-Servers mit unserem separaten IMAP-Server im Netz ist nun, dass der User-Name z.B. des “oxadmin”-Users auf dem OX6-Server identisch mit dem Login-Namen des Useraccounts auf dem Linux-IMAP-Server ist – auf Betriebssystemebene wie auf IMAP-Ebene.

Auch das verwendete Passwort muss auf beiden Servern (zunächst) identisch sein ( – wiederum auf Betriebssystemebene wie auf IMAP-Ebene).

Das gilt nicht nur für den “oxadmin”-Account sondern auch für alle anderen OX6-User-Accounts, die problemfrei auf ihren jeweiligen Default-IMAP-Account zugreifen sollen. Man sollte also einen eigenen, im Netz vorhandenen IMAP-Server von vornherein als eine dem OX6-System fest zugeordnete Einheit begreifen.

Das halte ich nebenbei gesagt für einen kleinen Nachteil der OX 6 Grund-Installation. Denn dies setzt vorab eine aufgeräumte Netzwerkumgebung mit “Single Sign On”-Charakteristik voraus. Was ja keineswegs verkehrt ist, aber dennoch nicht überall gegeben ist. Das Dumme ist dann, dass der OX6-Anwender bei Problemen mit der Default-Mail-Account-Einrichtung spürbare Schwierigkeiten beim Öffnen seiner OX6-Weboberfläche bekommt. Er erhält dann regelmäßig Fehlermeldungen, die das Abschalten des Email-Moduls der Groupware-Oberfläche ankündigen. Und dann ist man als Admin gefordert.

Ich habe übrigens nicht explizit geprüft, ob die Linux UID-Nummern auf den unterschiedlichen Servern auch identisch sein müssen; ich gleiche die aus anderen
Gründen aber sowieso immer ab. Hier hilft natürlich ein zentrales LDAP-System als universales Backend enorm, aber dessen Einrichtung würde hier wirklich zu weit führen.

Nebenbei:
Man kann durch Eingriffe jenseits der verfügbaren OX6-Verwaltungskommandos auch unterschiedliche Passwörter auf dem IMAP-Server und dem OX6-System verwenden. Dazu muss man das abweichende IMAP-Passwort direkt in die Tabelle “user_mail_account” eintragen. Natürlich ist das Passwort verschlüsselt – also ist die spezifische Hash-Methode Crypt in der Tabelle “user_mail_account” zu beachten! (In der Tabelle “users” wird für das OX6-Passwort dagegen SHA1 als Hashverfahren verwendet). Da mir dabei das von OX6 verwendete Salt zur Crypt-Hash-Generierung nicht bekannt ist, behelfe ich mir hier regelmäßig, indem ich gezielt Dummy-User mit dem von mir gewünschten Mail-Passwort anlege, den erzeugten Hash dann in den zu ändernden User-Record kopiere und danach den Dummy-User mit “deleteuser” wieder entferne.

Weitere IMAP-Accounts jenseits des Default-Accounts?

Nach diesen Hinweisen zum Default-Mail-Account eines OX6-Users stellt sich die Frage, wie es um weitere IMAP- oder POP-Accounts bestellt ist und ob man die in der OX6-Web-Oberfläche auch nutzen und die zugehörigen Mailordner einsehen kann.

Ja, das geht natürlich! Jeder User kann später auf beliebige weitere IMAP- oder POP-Accounts auf externen Mail-Servern zugreifen – selbst dann, wenn es mit dem Default-Account des OX6-Systems Probleme geben sollte. Für das Anlegen von Mail-Accounts gibt es in der OX6-Web-Oberfläche einen entsprechenden Menüpunkt unter

“Einstellungen >> E-Mail >> Accounts”.

Nur seinen Default-Account kann der User dort weder löschen noch in seinen Grunddaten ändern. Dies kann nur der Kontext Administrator. Das unterstreicht die besondere Rolle des Default-Mail-Accounts als Teil der OX6-Services.

Beim Anlegen weiterer Accounts kann man die auf dem jeweiligen IMAP-Server gültigen Login-Daten anstandslos verwenden – und die müssen dann natürlich auch nicht identisch mit den Account-Daten auf dem OX-Server sein. Die zusätzlichen Mail-Accounts werden nahtlos in die Struktur der Web-Oberfläche integriert; man kann auf die entsprechenden Mail-Ordner-Inhalte zugreifen sowie eigene Mails mit spezifischen SMTP-Einstellungen versenden. Siehe hierzu auch die Abbildungen weiter unten.

Anpassen der Einträge auf dem OX6-Server für einen Default-Email-Account auf einem separaten IMAP-Server

Nehmen wir an, der von uns betriebene IMAP-Server habe die IP-Adresse “192.168.0.10”. Gehen wir weiter davon aus, dass es auf dem IMAP-Server 192.168.0.10 in unserem Netz einen Account und Postfach für den User “oxadmin” gibt. Dieser soll per E-Mail unter der Adresse “oxadmin@mydomain.de” erreichbar sei. Dann können wir unseren OX6 “oxadmin”-Account für den Kontext 1 wie folgt abändern, damit er mit diesem Postfach verbunden wird:

#   /opt/open-xchange/sbin/changeuser  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u oxadmin  −e oxadmin@mydomain.de  −−imaplogin oxadmin  −−imapserver 192.168.0.10  −−smtpserver 192.168.0.10

Man beachte, dass wir uns hier bzgl. der Authorisierung auf den “Kontext Administrator” und nicht auf den OX6-Admin-Master “oxadminmaster” beziehen !!! Innerhalb eines Kontextes ist es – wie gesagt – der Kontext Administrator, der die Useraccounts ändert – auch seinen eigenen! Wir überprüfen das Ergebnis der Maildatenänderung wieder durch einen Blick in die Datenbank.

Hinweis: Der Zugriff auf den Default-Email-Account per OX6-GUI
muss für Kontext Administratoren explizit freigeben werden !

Theoretisch könnten wir uns als User “oxadmin” nun über einen Browser bereits auf unserem OX6-Server einloggen. Das würde aber immer noch zu Fehlermeldungen führen, denn aus Sicherheitsgründen ist der Zugriff der Kontextadministratoren auf ihre IMAP-Default-Postfächer per OX6-Browser-Oberfläche defaultmäßig abgeschaltet. Diesen Umstand kann man aber durch Änderung eines Eintrags in den Konfigurationsdateien unter “/opt/open-xchange” ändern:

In der Datei “/opt/open-xchange/etc/groupware/mail.properties” muss man dazu den Wert des Parameters “com.openexchange.mail.adminMailLoginEnabled=true” auf true statt false setzen.

Man sollte das Flag in der Konfigurationsdatei wirklich kennen. Sonst wundert man sich – wie ich – evtl. stundenlang, warum die E-Mail-Anzeige in der OX6-Oberfläche für alle normalen User auf Anhieb funktioniert, nur nicht für den Kontext-Administrator – und das obwohl man über Kmail auf den E-Mail-Account des Kontextadmin ebenfalls problemlos zugreifen kann. Noch verwirrender wird die Angelegenheit, wenn man für den “oxadmin” über den Default-Mailaccount hinaus testweise weitere IMAP-Mailaccounts anlegt und sich mit denen auch sofort verbinden kann! Die Ursache für evtl. Probleme mit dem Default-Mail-Account des Kontext-Administrators liegt nur in besagtem Konfigurations-Flag!

Nebenbei:

Als Admin (root) des OX 6 Servers wird man sich neben dem Zugang zu seinem ureigenen Mail-Account ggf. auch einen Zugang zu dem “oxadmin”-IMAP-Account z.B. unter Kontact/Kmail/Akonadi anlegen, falls man die Groupware-Verwaltung nicht deligieren kann. Hierbei sollte man wie immer natürlich wegen des serverseitigen Abonnements von weiteren Ordnern als den Account-Standardordnern des IMAP-Servers aufpassen. Man will ja als Admin nicht alle möglichen Ordner des IMAP-Servers doppelt und dreifach synchronisiert bekommen.

Anlegen eines ersten normalen Users im Kontext 1

Wir legen nun einen ersten “normalen” User im Kontext 1 an. Dieser User muss natürlich bereits einen passenden E-Mail-Account auf dem IMAP-Server besitzen – mit auf beiden Servern gleicher UID und Passwort. Das Passwort heiße USER_PWD. Auf meinem Cyrus-Server sind die IMAP-User-Namen identisch mit den Linux-User-Namen – unser erster User habe den Login-Namen “rlu” (Ralf Lustig). Sein Mailaccount sei “rlu@mydomain.de”.

#   /opt/open-xchange/sbin/createuser c 1  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u rlu  −d “RLU”  −g Ralf  −s Lustig  −p USER_PWD  −e rlu@mydomain.de  −−imaplogin rlu  −−imapserver 192.168.0.10  −−smtpserver 192.168.0.10

Änderungen an diesen Daten führt man im nachinein wieder mit Hilfe des Scripts “changeuser” durch, wie wir das bereits weiter oben für den “oxadmin” vorgeführt haben. Will man dem User z.B. den Zugriff auf das Adressbuch des OX6-Systems gestatten ( in dem die User des OX6-Systems aufgeführt sind), so erreicht man dies durch :

#   /opt/open-xchange/sbin/changeuser  −c 1  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u rlu  −−access-global-address-book-disabled true

Spätestens jetzt sollte man sich als Admin für weitere Optionen und Einstellungen mit dem Dokument OX6-Manual “OX6-Provisioning.pdf”
https://linux-blog.anracom.com/category/open-xchange/ox6/(http://software.open-xchange.com/OX6/doc/OX6-Provisioning.pdf]
vertraut machen.

Login in die Web-Oberfläche des OX6-Servers

Hat man den OX6-Server wie im ersten Teil dieser Serie beschrieben angelegt, so wäre er jetzt im eigenen Netz unter der Adresse “http://oxs3” erreichbar. Wir probieren dies zum Abschluss unserer Anstrenugungen nun abschließend für den User “oxadmin” aus.

OX6 Login-Maske

Danach erhalten wir – wenn wir alles richtig gemacht haben – die aufgeräumte Web-Anwender-Oberfläche für das OX6-System:

OX6 Benutzer Oberflaeche

Man erkennt hier – etwas mühsam – dass neben dem geöffneten Default-Email-Account noch ein zweiter IMAP-Account auf einem IMAP-Server “oxs2” eingerichtet worden ist. Man kann einen solchen Account einrichten, indem man auf das Zahnradsysmbol in der Icon-Leiste oben links klickt. Man erreicht dann das Menü “Einstellungen” und seine Unterpunkte. Hiermit sollte man sich auch als Admin vertraut machen.

ox6 Menue Einstellungen

Die Einstellung eines zusätzlichen Email-Accounts erfolgt dann über den Menüpunkt “Einstellungen >> E-Mail >> Accounts”:

Ox6 zusaetzlicher Mail Account

Nach diesem ersten Erfolg wünsche ich viel Spass beim Einrichten weiterer User und beim Vertrautmachen mit den Möglichkeiten der OX6 GUI! Man lese hierzu auch das User-Manual

http://software.open-xchange.com/OX6/doc/OX6-User-Guide-German.pdf

Im nächsten Beitrag zum OX6 sehen wir uns dann den Zugriff auf den OX6-Server von KDE Kontact aus an.

Kontact 4.7 und OX 6 unter Opensuse 11.4 – Teil I

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.