Beinahe enzyklopädisch behandelt unser Schwerpunkt-Artikel über IPSEC verschlüsselte Verbindungen zwischen Linux, Windows, BSD, Solaris, Cisco- sowie ... (mehr)

Community-/Server-Version installieren

Die Installation der OX-Community-Version ist zwar nach wie vor mit einigem Aufwand verbunden, aber in der OX-Community für eine Reihe von Zielplattformen recht gut dokumentiert. Unser Workshop konzentriert sich im Folgenden auf die Schlüsselstellen, insbesondere weil die originale Doku hier in einigen Punkten Lücken aufweist. Für das Installieren der Open-Xchange Server-, Community- oder Hosting-Edition ist es ratsam, sich vorab mit Architektur und Arbeitsweise des OX-Servers vertraut zu machen und sich über die einzelnen Administrationsebenen, und in Verbindung damit über die Logik in der Zusammenarbeit der beteiligten Benutzerkonten im Klaren zu sein (Abbildung 2).

Abbildung 2: Für das erfolgreiche Installieren und Konfigurieren der Community-Version ist es hilfreich, sich Aufbau und Architektur des OX-Backends zu vergegenwärtigen. (Quelle: Open-Xchange)

Als Erstes benötigt Open-Xchange für den Installer und sämtliche administrativen Datenbankoperationen einen administrativen MySQL-Account »openexchange« . Dieser wird durch das Kommando »initdb« erzeugt und verschafft administrativen Zugang zur zentralen Datenbank »configdb« . Das Passwort übergibt der Admin als Parameter an das Skript. Im weiteren Verlauf der Installation begegnet dem Admin außerdem der sogenannte Open-Xchange Admin Master (User »oxadminmaster« ), der für die weitere Server-Konfiguration und das Verwalten der einzelnen Kontexte zuständig ist.

Ein Kontext ist im Open-Xchange-Sprachgebrauch eine geschlossene Benutzer-Gruppe mit einem eindeutigen Dateinamen. In der Praxis würde man je einen Kontext für eine Firma oder eine Abteilung anlegen. Die Lösung mit Kontexten rührt daher, dass Open-Exchange mandantenfähig ist. Deshalb müssen sich sämtliche Kontexte eindeutig voneinander trennen lassen. Open-Exchange stellt mit »defaultcontext« ein Kontext-Schema zur Verfügung, das sich als Template für eigene Kontexte nutzen lässt.

Der Benutzer »oxadmin« , der beim Erstellen eines Kontextes erzeugt wird, ist der Administrator des Kontextes und verfügt dazu über entsprechende erweiterte Rechte. Als Kontex-Admin hat er auch die Aufgabe und das Recht zum Anlegen neuer User in seinem Kontext und ist allgemein für das Verwalten von Benutzern, Gruppen und Ressourcen innerhalb eines Kontextes verantwortlich. Außerdem gibt es Unix/Linux-seitig einen Systembenutzer »open-xchange« , den der Installer im Laufe der Installation anlegt und mit dem er alle Dateisystemoperationen ausführt – außer es sind Root-Rechte erforderlich.

Die Open-Xchange-Community pflegt für alle wichtigen Distributionen eigene Repositories, sodass sich die benötigten Open-Xchange-Pakete problemlos über das jeweilige Paketmanagement einbinden lassen. Wir zeigen die wichtigsten Schritte der Installation exemplarisch für Debian 5 (Lenny). Der Open-Xchange-Installer schiebt die komplette Software in beiden Fällen vollständig nach »/opt/open-xchange« . Alle Binaries zu Open-Xchange sind dann unter »/opt/open-xchange/sbin« zu finden, während alle wichtigen Konfigurationsdateien in »/opt/openxchange/etc/groupware« liegen. Lediglich die initialen Startskripte, wie etwa »open-change-groupware« werden vom OX-Installer in »/etc/init.d« abgelegt. Auf jeden Fall ist es für den weiteren Verlauf der Installation und den späteren Administrationsbetrieb sehr sinnvoll, »/opt/open-xchange/sbin« in den Systempfad zu packen:

echo PATH=$PATH:/opt/open-xchange/sbin/>> ~/.bashrc && . ~/.bashrc

Debian-Nutzer fügen die Paketquelle mit

deb http://software.open-xchange.com/OX6/stable/DebianLenny/ /

in der Konfigurationsdatei »/etc/apt/sources.list.d/debian.list« hinzu. Sie können übrigens die angegebene Paketquelle durch Importieren des Keys

wget http://software.open-xchange.com/oxbuildkey.pub
apt-key add oxbuildkey.pub

verifizieren. Ein anschließender Blick ins Paketreservoir mit

sudo apt-cache search open-xchange

oder mithilfe von Synaptic offenbart eine stattliche Anzahl von Paketen. Frustration ist aber fehl am Platze, denn die Open-Xchange-Entwickler haben eine Reihe von Meta-Paketen gepackt, mit deren Hilfe das Installieren auch Nicht-Insidern gelingt. Die Suchergebnisse nach »open-exchange-meta« zu filtern, bringt bereits bessere Übersicht (Abbildung 3). Um einen Single-Server aufzusetzen, genügt es daher, MySQL (»mysql-server-5.1« ) sowie das Meta-Paket »open-xchange-meta-singleserver« zu installieren. Etwaige Connectoren (Outlook-Extender), Mobil- und Messaging-Clients lassen sich problemlos später in Betrieb nehmen. Außerdem braucht ein Applikationsserver wie Open-Xchange zwingend Java, das aber sofern nicht vorab installiert durch die Auswahl der Meta-Pakete auf die Platte gelangt. Das Installieren kann wahlweise via

Abbildung 3: Meta-Pakete erleichtern die Auswahl der zu installierenden Pakete. Im Idealfall genügt open-xchange-meta-singleserver.
apt-get install mysql-server open-xchange-meta-singleserver open-xchange-authentication-database open-xchange-spamhandler-default

oder auf einem Server mit grafischer Oberfläche via Synaptic erfolgen. Übrigens hat der Admin bezüglich der Authentication- und der Spamhandler-Pakete je nach Systemvoraussetzungen die Wahl zwischen mehreren Alternativen. Auf einem Ubuntu-System 10.10 mit Default-Paketquellen und allen aktuellen Patches stehen neben dem Paket »open-xchange-authentication-dababase« (Default) auch »open-xchange-authentication-ldap« und »open-xchange-authentication-imap« zur Verfügung, deren Installation jeweils ein Plugin zur Authentifizierung gegen ein IMAP-Konto oder einen LDAP-Server bereitstellt.

Beim IMAP-Plugin handelt es sich um ein Plugin, das die Anmeldung gegen ein IMAP-Konto regelt und nicht etwa um ein Plugin zur Benutzerverwaltung. So erhält der Benutzer Zugriff auf die Open-Xchange-Groupware, wenn er sich mit dem konfigurierten IMAP-Account anmelden kann. Es ersetzt nicht das Database-Paket. Alternativ ist die Authentifizierung über LDAP möglich. Auch beim zu verwendenden Spamhandler hat der Admin die Wahl zwischen dem Default-Paket und dem Paket »open-xchange-spamhandler-spamassassin« .

Die weitere Konfiguration erfordert eine laufende MySQL-Datenbank. Das Kommando »initconfigdb« initialisiert die Open-Xchange-Datenbank:

/opt/open-xchange/sbin/initconfigdb --configdb-pass=DB-Passwort -a

Der Parameter »-a« sorgt für das Anlegen eines administrativen Accounts »openexchange« in der MySQL-Datenbank, der zwingend erforderlich ist, um OX-Datenbanken registrieren zu können. Sollte bei der Installation vom MySQL ein Passwort für den MySQL-Root-Account vergeben worden sein, wird das »initconfigdb« -Kommando fehlschlagen.

In einem solchen Fall empfiehlt es sich, vorab das MySQL-Root-Passwort zu entfernen. Am einfachsten gelingt dies mit phpMyAdmin (Abbildung 4). Der versierte Admin kann aber auch zur MySQL-Kommandozeile greifen.

Abbildung 4: Das Anzeigen, Ändern oder Anlegen von Benutzern nebst deren Passwörter erfolgt im Reiter Rechte. Ist das Initialisieren der Open-Xchange-Datenbank gelungen, zeigt phpMyAdmin die zugehörige Datenbank configdb bereits an.

Datenbank-Hilfe

Die Eingabe von »initconfigdb« ohne Optionen zeigt zur Orientierung die im MySQL-Kontext vorhandenen Benutzernamen an. Das gilt übrigens für alle administrativen OX-Kommandos. So liefert zum Beispiel »/opt/open-xchange/sbin/oxinstaller« ohne Parameter ebenfalls sämtliche Defaultwerte. Jetzt sind alle Vorbereitungen so weit getroffen, dass das mitgelieferte »oxinstaller« -Skript zufriedenstellend seinen Dienst verrichten sollte. Es erwartet allerdings einige Parameter, neben dem gewünschten Open-Xchange-Servernamen auch das Passwort für den eben beschriebenen Admin-Master-Account sowie das eben gesetzte Configdb-Datenbank-Passwort. Der Admin-Master wird übrigens vom Skript selbst erzeugt. Die Option »--add-license« erwartet einen von Open-Xchange erworbenen Lizenz-Key. Wer nicht lizensieren, also die Community-Version verwenden möchte, benutzt dazu die Option »--no-license« .

/opt/open-xchange/sbin/oxinstaller --no-license -servername=Server --configdb-pass=DB-Passwort --master-pass=Master-Passwort --ajp-bind-port=localhost

Der Parameter »--ajp-bind-port« ist für Singleserver-Szenarien auf Localhost zu belassen und wird nur für Cluster-Setups benötigt. Im Anschluss an das Initialisieren der Konfiguration startet

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

das Administrations-Backend. Anschließend meldet der folgende Befehl den OX-Server an der »configdb« -Datenbank an:

/opt/open-xchange/sbin/registerserver -n Oxmaster -A oxadminmaster -P Master-Passwort

Hier ist unbedingt darauf zu achten, dass die Servernamen beim Aufruf von »oxinstaller« und »registerserver« übereinstimmen. Übrigens schreibt »oxinstaller« den Servernamen auch in die Konfigurationsdatei »/opt/open-xchange/etc/groupware/system.properties« , was ein schnelles Überprüfen der Übereinstimmung ermöglicht (siehe Abbildung 5).

Abbildung 5: Das erfolgreiche Registrieren des Servers lässt sich in phpMyAdmin kontrollieren. In der Tabelle server steht dann der eben vergebene OX-Servername nebst server_id.

Im nächsten Schritt ist ein lokales Verzeichnis auf dem Server anzulegen, in dem Open-Xchange sämtliche Groupware- und Infostore-Dokumente ablegt. Anschließend muss der System-Benutzer »open-xchange« die entsprechenden Zugriffsrechte auf dieses Verzeichnis erhalten.

mkdir /var/opt/filestore
chown open-xchange /var/opt/filestore

Auch dieses Verzeichnis muss der Administrator anschließend datenbankseitig beim Open-Xchange-Server als Filestore registrieren. Dazu dient das Kommando »/opt/open-xchange/sbin/registerfilestore«

/opt/open-xchange/sbin/registerfilestore-A oxadminmaster -P Admin-Master-Passwort-t file:/var/opt/filestore

Danach kann der Admin die Groupware-Datenbank beim Server anmelden:

/opt/open-xchange/sbin/registerdatabase -A oxadminmaster -P Admin-Master-Passwort-n OX-Datenbank-p DB-Passwort -m true

Laufen Open-Xchange-Server und Datenbank, muss der Admin den Apache-Webserver konfigurieren, insbesondere das Modul »mod-proxy-ajp« . Erst dann ist ein Zugriff auf den Server über das Webinterface möglich. Die Original-Dokumentation empfiehlt außerdem die Module »mod_expires« und »mode_defalte« , was die Performance deutlich verbessern soll. Das Laden und Aktivieren von Modulen für Apache 2 erfolgt wie üblich mit »a2enmod« .

a2enmod proxy proxy_ajp proxy_balancer expires deflate headers rewrite

Anschließend ist ein Neustart des Webservers erforderlich.

Zur Konfiguration des Apache-Moduls »proxy_ajp« muss der Administrator zunächst das zugehöriges Konfigurationsfile »/etc/apache2/conf.d/proxy_ajp.conf« anlegen. Zur Anzeige des Open-Xchange-Webinterface ist es erforderlich, die Einstellungen des Default-VHosts zu ergänzen. Beispiele für beides finden sich auf der Website des ADMIN-Magazins. Insbesondere beim Installieren von Open-Xchange auf Web- oder Root-Servern muss der Administrator dafür sorgen, dass sich das Open-Xchange-GUI an die richtige Domain-Adresse bindet (Name-Based Virtual Hosts).

Nach einem Neustart des Webservers sollte die Open-Xchange-Groupware sich wie folgt starten lassen:

sudo /etc/init.de/open-xchange-groupware start

Ab jetzt sollte sich unter der Standard-Adresse des Webservers ein Open-Xchange-Login-Screen melden (Abbildung 6).

Abbildung 6: Das Web-GUI läuft. Jetzt fehlt noch das Anlegen von Open-Xchange-Kontexten und -Benutzern.

Die Anmeldung ist allerdings noch nicht möglich, weil der Admin zunächst die erforderlichen Kontexte und Groupware-Benutzer generieren muss. Beim Erzeugen eines Kontextes mit »createcontext« muss der Parameter »context id« (-c) stets eindeutig sein. Mit dem Parameter »--access-combination-name« lassen sich dem jeweiligen Nutzer jedes Kontextes Open-Xchange-Module und Funktionen zuordnen, im Idealfall alle mit »all« (Listing 1).

Listing 1

Kontext anlegen

 

Der Username des Context-Admins ist hier »oxadmin« . Jetzt ist es lediglich noch erforderlich, im neuen Kontext den oder die gewünschten Groupware-User anzulegen, was der eben erzeugte Context-Admin tut (Listing 2). Die Context-ID bezieht sich auf den oder die mit »createcontext« erzeugten Kontext(e), im Normalfall 1.

Listing 2

User anlegen

 

Nun kann sich der neu angelegte User am Webinterface anmelden. Eine Besonderheit beim Anlegen eines Users besteht darin, dass der Kontext-Admin seinem User via Parameter »--imaplogin« , »--imapserver« und »--smtpserver« unmittelbar den vom ihm zu verwendenden externen oder lokalen (127.0.0.1) Mailserver mitgeben kann.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021