Opensuse 11.4, samba, apparmor-Problem

Habe in der letzten Zeit auf meinem Opensuse 11.4 keine Samba CIFS-Shares mehr freigegeben. Heute musste ich das jedoch mal wieder tun.

Ergebnis: 1,5 Stunden ging erstmal gar gar nichts. Zwar werden die Shares in "smbtree" und "smbclient" angezeigt, aber ein Versuch, die Inhalte der Share-Verzeichnisse in "smbclient" aufzulisten, endete jedesmal mit

NT_STATUS_ACCESS_DENIED listing \*.

Ebenso schlug das Browsing in Dolphin oder von anderen Rechnern aus fehl.

Natürlich habe ich dann meine Konfiguration geprüft, Passwörter und Rechte gecheckt, meine Zugriffsdaten mehrfach über "smbpasswd" und "pdbedit" upgedated, die Fehlerfreiheit von smb.conf mit "testparm" gecheckt und Zeit in das Studium von Samba-logs investiert. Mein Problem war auch nicht das, dass "/etc/init.d/smb" oder "/etc/init.d/nmbd" nicht gelaufen wären, wie das lt. Internet bei anderen Opensuse 11.4-Usern schon vorgekommen sein muss. Siehe etwa:

http://www.hardwarecrash.de/index.php/faq/software/linux/opensuse/215-opensuse-114-nmbd-startet-nicht
http://forums.opensuse.org/english/get-technical-help-here/network-internet/456049-11-4-samba-wont-run.html
http://www.linux-club.de/viewtopic.php?f=6&t=112904
http://forums.opensuse.org/english/get-technical-help-here/network-internet/455677-mount-cifs-issue-opensuse-11-4-a-2.html

Mein Opensuse 11.4 ist zudem auf dem neuesten Stand. Ich war wirklich ratlos.

Dann habe ich meine SMB-Konfiguration auf einem anderen, nicht vollständig aktualisierten Opensuse 11.4-System nachgestellt. Dort lief die Sache anstandslos. Also mussten irgendwelche Paket-Updates bei mir etwas "verschlimmbessert" haben.

Über weitere Hinweise im Internet bin ich dann auf Apparmor als Ursache vieler Samba-Probleme unter Opensuse 11.4 gestoßen. Ich habe dann zunächst geprüft, ob Apparmor bei mir über das Kontrollpanel unter Yast deaktiviert war. Ja, das war es. Dennoch lag der Fehler im Apparmor-Bereich und zwar in irgendeiner perversen Weise, die man als Endverbraucher nicht mehr verstehen kann und will :

Es half nämlich auch nichts, SMB-bezogene Profile aus Apparmor per Yast zu löschen. Einzig und allein

  • ein (zweifaches) Anwenden des "Assistenten zum Aktualisieren von Profilen" unter Yast im Bereich Apparmor
  • und ein "Zulassen" bei den hochkommenden SMB-relatierten Profilfragen

brachte die Lösung.

Liebe Leute von Novell:

Solche Bugs sind so dermaßen kontraproduktiv und so dermaßen desillusionierend, das man nur noch müde abwinken kann. (Ich habe meiner Frau versprochen, mich über sowas nicht mehr aufzuregen.) So gewinnt man keine Freunde für Linux in Form der Opensuse Distribution und schon gar nicht für Apparmor. Es führt eher zu dem Reflex, dieses Tool gar nicht mehr zu installieren.

Es trägt übrigens wenig zu meiner Beruhigung bei, dass es unter Fedora mit SELinux mal ein ähnliches Problem gab. Siehe etwa die Diskussion und nachfolgenden Beiträge zu http://lists.samba.org/archive/samba/2007-April/130900.html

Ursache für diese Misere ist aus meiner Sicht mal wieder das aktuelle Kernproblem von Opensource: die mangelnde Qualitätssicherung. Man ist als User - und vor allem als Enduser - halt doch immer Beta-Tester. Nun halt mal in puncto Sicherheit. Na toll .....

Links:
http://www.linux-club.de/viewtopic.php?f=6&t=113044
http://forums.opensuse.org/deutsch-german/hilfe-und-helfen/installation-administration/458037-opensuse-11-4-samba-probleme-wegen-apparmor.html
http://web.archiveorange.com/archive/v/TDuKzixdvQtYbQQ6CLRH
http://www.linux-club.de/viewtopic.php?f=6&t=113221

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 "http://linux-blog.anracom.com/2009/01/29/kmail-kde-42-postfix-und-cyrus-imap-unter-ox/").

Wir 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 http://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 http://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 ...
   </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 http://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.

MySQL – Sortierung in UNION Statements

Heute sind meine Frau und ich über ein kleines My-SQL-Problem gestolpert. Wir hatten ein Statement der Art

( SELECT .... ORDER BY ...) UNION (SELECT ..... ORDER BY ... )

Wir waren beide der Meinung, dass das zusammengesetzte Ergebnis pro Einzelresultset die jeweils gewünschte Sortierung aufweisen würde. Das war aber leider nicht der Fall !

Dabei hatten wir bereits früher ähnliche Statements verwendet, in denen die Sortierung funktionierte! Wir hatten jedoch eine bedeutsame Kleinigkeit übersehen. Unsere früheren Statements waren nämlich von der Art:

( SELECT .... ORDER BY ... LIMIT .. ) UNION (SELECT ..... ORDER BY ... LIMIT .... )

Der Unterschied liegt in der Vorgabe von LIMIT, also der Begrenzung der jeweiligen Teil-Resultsets im UNION-Statement. Wir haben dann ein wenig herumprobiert und herausgefunden, dass eine LIMIT-Vorgabe tatsächlich erforderlich ist, wenn beide (oder mehrere) Resultsets separat sortiert und danach zum Union-Resultset zusammengefügt werden sollen.

Offenbar ignoriert der MySQL-Optimizer die ORDER-Statements der Teil-Selects, wenn die einzelnen Resultsets nicht explizit begrenzt werden.

Somit stehen einem wohl zwei Arten zur Verfügung, wei man ein UNION-Resultset ordnen kann:

  • Variante 1 - separate Sortierung der Einzel-Resultsets :

        ( SELECT .... ORDER BY ... LIMIT ... ) UNION (SELECT ..... ORDER BY ... LIMIT ... )

  • Variante 2 - Sortierung des Gesamt-Resultsets :

        ( SELECT .... ) UNION (SELECT .... ) ORDER BY ....

Hinweise:
Die Klammerung ist mindestens im zweiten Beispiel von ausschlaggebender Bedeutung.
Klar auch, dass dabei die Felder der Einzel-Selects identisch sein sollten.

Links:
In einigen MySQL-Foren findet man tatsächlich auch entsprechende Hinweise. Man sollte da doch öfter mal reinschauen:

http://www.mysqlfaqs.net/mysql-faqs/Funtions-and-Operators/How-does-union-work-in-MySQL
http://forums.mysql.com/read.php?10,412000,412000

Veröffentlicht unter MySQL