Category Archives: Open-Xchange

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

Bye, bye Open-Xchange

Posted on by

Habe vor kurzem ein laufendes Opensuse 12.3-System auf Opensuse 13.1 upgegradet. Das ging bis auf einige Schwierigkeiten mit der neuen Apache 2.4 Version relativ problemfrei – nur ein lokaler Open-Xchange 6.22 Server hat das nicht überlebt. Na ja, ganz stimmt das so nicht – eigentlich überlebte nur das vom Server bereitgestellte Web-Interface nicht. Aus welchen Gründen auch immer – das für OX6 reservierte Verzeichnis im Bereich “/srv/www/htdocs” war nach dem Update und einem Neustart von OX6 von allen relevanten Dateien befreit, obwohl die Verzeichnisstruktur erhalten geblieben war.

Ich konnte den ursprünglichen Zustand aus Backups zwar wieder restaurieren. Da das Problem mit Open-Xchange und Opensuse-Upgrades aber nicht zum ersten Mal aufetreten, freunde ich mich gerade mit dem Gedanken an, ganz auf diese Groupware-Lösung zu verzichten. Das hat neben der Anfälligkeit gegenüber System-Updates noch mehrere andere Gründe:

Grund 1: Keine Lizenz-Variante für SLES unter 25 User
Ich habe nicht vergessen, wie uneinsichtig sich OX bzgl. eines Upgrades von einer 5-User-Lösung unter SLES beim Wechsel von OX 5 auf OX 6 zeigte. Damals bekam ich klar Bescheid, dass ich entweder auf einen UC-Server umsteigen oder eben eine 25 User-Lizenz erwerben müsse. Dabei war mir der Umstieg auf eine 5-User-Lizenz von einer ursprünglichen 25 User umfassenden SLOX-Lösung von OX selbst empfohlen worden. OK, die Botschaft kam an – OX wollte ab den ersten Erfolgen mit 1&1 offenbar nur noch hinreichend große Kunden haben und entsprechend Geld verdienen. Das auch kleine Unternehmen einen SLES oder RHEL einsetzen, war den Strategen in den USA wohl egal. Als Konsequenz habe ich mit der Community-Version von OX6 dann sehr gut ein paar Jahre unter Opensuse und ohne jede Lizenzgebühr gelebt. Jetzt ist auch damit Schluss.

Grund 2: Verschwindender Support für die Community Edition
Wie wenig die Community Edition noch Bedeutung hat, kann man auch dem Inhalt und Aufbau der aktuellen OX-Website entnehmen. Eine spezielle Seite für die CE gibt es nicht mehr. Die Anzahl der CE-Forenbeiträge pro Zeiteinheit wird auch immer dünner. Am schlimmsten ist aber der aus meiner Sicht katastrophale Zustand der OX-Repositories für Opensuse. Dafür scheint sich wirklich niemand mehr zu interessieren.

Grund 3: Ausrichtung auf soziale Medien und weiter zunehmende Kommerzialisierung
Mir passt die zum Programm erhobene Ausrichtung von OX ≥ V7 auf die sogenannten “sozialen” Medien nicht. Das hat aus meiner Sicht in einer Firmen-Groupware schon aus Sicherheitsgründen wenig bis gar nichts zu suchen. Nicht alles, was populär ist und dem Kommerz – speziell von SaaS-Anbietern – dient, ist auch gut.

Grund 4: Unübersichtliches Backend
Technisch wirkt auch das Java/OSGI-Backend-Konstrukt zunehmend zu komplex bis unübersichtlich, um damit weiter in einer nicht kommerziellen Server-Umgebung herumzudoktern. Ich verstehe, dass man hochgradig skalierbare Lösungen für den Einsatz in großen Unternehmen und speziell für SaaS benötigt. Aber irgendwie wirkt der Einsatz einer vollen Java-Architektur wie ein Overkill für die Ansprüche kleiner, mittelständischer Firmen an eine Groupware.

Grund 5: Einarbeitungszeit
Die Zeit, die man typischerweise in eine funktionierende Installation unter Opensuse 12.3 für die 7-er Version des Open-Xchange-Servers stecken muss, ist nach meinem Gefühl genauso groß wie die, sich in Alternativen einzuarbeiten.

Grund 6: Fehlende Replikationsmöglichkeiten
Meine erste eingesetzte Groupware war Lotus Notes 5/6 unter Linux. Ein Riesenvorteil von Lotus war die Server-Replikationsfähigkeit. Etwas Entsprechendes habe ich bei Open-Xchange immer vermisst.

Vor kurzem ist Opensuse 13.1 erschienen. Diese soll einen deutlich längeren Support erhalten als andere Opensuse-Versionen. Ein Umstieg auf eine neue opensource-basierte
Groupware-Lösung, die unter OS 13.1 funktioniert, erscheint mir daher als ein vernünftiger Schritt.

Was werde ich an OX vermissen ? Vielleicht Info-Store, vielleicht auch das gut organisierte Web-Interface …. aber bzgl. der Organization und Versionierung von wichtigen Dokumenten setzen wir seit ca. einem Jahr mit gutem Erfolg SVN und ein Wiki ein. Und als Groupware-Interface haben wir meist Kontact und nicht das Web-Interface benutzt ….. Und Ajax können auch andere Groupware-Hersteller ….

Vermissen werde ich vielleicht auch die kritischen Kommentare vom aktuellen OX CEO Rafael Laguna zur zunehmenden Kontrolle des Internets – durch staatliche Institutionen, aber nicht zuletzt auch durch und mit Hilfe der zugehörigen großen Monopol-Firmen des Internets ….. Wie schreibt er so schön:

“Before you blame the government for the filthy roads, clean your own yard! ”

Stimmt ! Aber warum sollte ausgerechnet eine Firma, die ihre Entwicklungskapazitäten zunehmend genau an den Vorgaben der kritisierten Giganten ausgerichtet hat und vor allem große und landesweit bis länderübergreifende SaaS-Partner umwirbt, besonders glaubwürdig dafür sein, die Rechte und Interessen der am meisten betroffenen normalen Nutzer und kleiner Firmen zu vertreten ?

Opensuse 12.3 – OX 6.22 lässt sich mit systemd nicht starten

Posted on by

Nach dem Upgrade von Opensuse 12.2 auf Opensuse 12.3 musste ich leider feststellen, dass der Dienst “/etc/init.d/open-xchange” nicht mehr automatisch gestartet werden kann. Im Gegensatz zu Opensuse 12.2 führt ein "systemctl start open-xchange" nun leider ins Nirwana:

mysystem:/etc/init.d # systemctl status open-xchange.service
open-xchange.service – LSB: Open Xchange Daemon
Loaded: loaded (/etc/init.d/open-xchange)
Active: inactive (dead) since Wed, 2013-03-27 12:30:19 CET; 5min ago
Process: 13365 ExecStop=/etc/init.d/open-xchange stop (code=exited, status=0/SUCCESS)
Process: 13349 ExecStart=/etc/init.d/open-xchange start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/open-xchange.service
Mar 27 12:30:19 mysystem.mydomain.de systemd[1]: Starting LSB: Open Xchange Daemon…
Mar 27 12:30:19 mysystem.mydomain.de open-xchange[13349]: Starting open-xchange ..done
Mar 27 12:30:19 mysystem.mydomain.de systemd[1]: Started LSB: Open Xchange Daemon.
Mar 27 12:30:19 mysystem.mydomain.de su[13360]: (to open-xchange) root on none
Mar 27 12:30:19 mysystem.mydomain.de open-xchange[13365]: Shutting down open-xchange ..done

Jeder Start mit systemd führt also auch zu einem sofortigen Stop. Und der Service ist danach regelmäßig "dead".Was dem User beim Versuch, sich in OX 6 einzuloggen mit 503-Fehlermeldungen quittiert wird.

Na da freuen wir uns doch mal wieder herzlich über die "wunderbare" Welt von systemd! Was für OX 6.22 unter Opensuse 12.2 anstandslos lief, läuft unter Opensuse 12.3 nicht mehr. Und die Fehleranalyse ist für systend so kompliziert und unüberschaubar, dass ich im Moment keinerlei Lust verspüre, auf Fehlersuche zu gehen.

Workaround
Netterweise geht aber nach wie vor ein direkter Start über das Skript:

mysystem:/etc/init.d # ./open-xchange start
redirecting to systemctl start
Starting open-xchange done
mysystem:/etc/init.d # ./open-xchange status
Checking for service open-xchange running
Checking for service open-xchange running
mysystem:/etc/init.d # systemctl status open-xchange
open-xchange.service – LSB: Open Xchange Daemon
Loaded: loaded (/etc/init.d/open-xchange)
Active: inactive (dead) since Wed, 2013-03-27 12:57:05 CET; 1min 39s ago
Process: 15646 ExecStop=/etc/init.d/open-xchange stop (code=exited, status=0/SUCCESS)
Process: 15636 ExecStart=/etc/init.d/open-xchange start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/open-xchange.service
Mar 27 12:57:05 mysystem.mydomain.de systemd[1]: Starting LSB: Open Xchange Daemon…
Mar 27 12:57:05 mysystem.mydomain.de open-xchange[15636]: Starting open-xchange ..done
Mar 27 12:57:05 mysystem.mydomain.de open-xchange[15646]: Shutting down open-xchange ..done
Mar 27 12:57:05 mysystem.mydomain.de systemd[1]: Started LSB: Open Xchange Daemon.
mysystem:/etc/init.d #

Man beachte die Kleinigkeiten und erfreue sich an dieser berauschenden Logik: Das Startscript wird angeblich an systemctl redirected. Open-Xchange wird danach auch erfolgreich gestartet. Der Status ist bei normaler Abfrage per Script auch running. Man kann sich regulär per Browser in seinen OX6-Account einloggen. Aber systemd kann mit dem erfolgreichen Start offenbar gar nichts anfangen und sieht nicht mal, dass der Service läuft! Was für ein grandioses Chaos!

Jedenfalls läuft der Dienst nur nach einem normalen Start – also über /etc/init.d/open-xchange start regulär. Nicht aber das Rauf- und Runterfahren über systemd. Damit kann man den inzwischen auf ein Minimum reduzierten “Runlevel-Editor” von YaST für eine Aktivierung von OX 6.22 schlicht vergessen. Runlevels gibt es dort nicht mehr – und für OX funktioniert das Starten beim
Hochfahren in das Systemd-Default-Target mit systemd nicht.

Also gilt bis auf weiteres unter Opensuse 12.3: OX 6.22 händisch starten und vor dem Runterfahren auch wieder stoppen.
Schöne neue Welt …. Seufz ….

Nachtrag 08.06.2013 und Lösung:
Die Opensuse-Leute haben mir inzwischen wirklich geholfen, das Problem analysiert und ein service-file für den “open-xchange”-Service zusammengestellt. Dadurch ist nun ein Hochfahren von open-xchange beim Systemstart möglich.
Siehe
https://bugzilla.novell.com/show_bug.cgi?id=813767
Man beachte auch die gute Erklärung der Problem-Ursache.

Vielen Dank an Frederic Crozat !!

OX 6 – Upgrade von OX 6.20.7 auf OX 6.22.1 unter OS 12.2

Posted on by

Habe mich seit längerem nicht mehr um Upgrades des bei mir unter Opensuse 12.2 laufenden OX 6 kümmern können. Mein letzter Schritt war im letzten Jahr ein Update auf die Version 6.20.7 gewesen. Seitdem hat sich doch einiges geändert und demnächst steht auch die OX 7 App Suite vor der Tür.

Mögliche Upgrade-Pfade

Laut den Infos auf den einschlägigen Open-Xchange Webseiten sind folgende Upgrade-Pfade vorgesehen:

  • v6.20.7 auf v6.22.0 (man beachte die 0 bei der 6.22-er version!)
  • v6.22.x auf OX App Suite 7

Siehe hierzu:
http://oxpedia.org/wiki/index.php?title=Update_to_6_22
http://oxpedia.org/wiki/index.php?title=AppSuite:Upgrade_from_6.22_for_SLES11

Alle Wege führen also zwingend über die Version 6.22.0 !

Version 6.22 klingt harmlos. Diese Applikation bringt allerdings gegenüber den Versionen 6.20.X wesentliche Neuerungen mit sich. Insbesondere die Aufsplittung der Repositories für Server-Komponenten und das Ajax-Frontend. Zudem werden die bisher 2 Dämonen zum Starten des OX6-Systems zu einem zusammengefasst. Es verschwinden auch etliche der vielen bisherigen Pakete. Offenbar werden hier Änderungen vorgenommen, die in eine noch stärkere Rollenaufteilung zwischen einem komponentenbasierten Backend und mehreren unterschiedlich ausgeprägten Frontends in der App Suite münden werden.

Das machte mir dann doch ein wenig Angst vor einem Update des OX6 unter Opensuse 12.2. Die zugehörigen Infos in den OX-Webseiten entsprechen mehr denen eines echten Upgrades als eines kleineren Updates. Aber die nachfolgende Abbildung beweist, dass alles am Schluss glatt lief. Gezeigt wird der Blick von Kontact/Korganizer auf Kalender-Einträge auf meinem OX6 v6.22.1.

ox622_cal_600

Dennoch gab es ein paar kleinere Hürden zu überwinden, auf die ich nachfolgend eingehe.

Fehlendes Opensuse 12.2 Repository für die als Zwischenschritt erforderliche OX-Version 6.22.0

Unter den Repositories für Opensuse 12.2 findet man zwar bereits ein Verzeichnis für die App Suite. Das enthält aber noch keine Dateien. Also wollte ich auf meinem Opensuse 12.2-System zunächst nur das sowieso erforderliche Upgrade auf die Version v6.22 vornehmen.

Nun drohte dieses Vorhaben daran zu scheitern, dass sich im Moment kein Opensuse 12.2 Repository mit RPMs zur OX Version 6.22.0 mehr finden lässt. Vorhanden ist nur ein Repository zur Version v6.22.1. Dorthin führt aber z.B. von OX 6 V6.20.7 kein direkter Weg !

Umweg über ein 6.22.0 Repository für den SLES 11

Ich habe dann notgedrungen das Experiment gewagt, ein Repository für den SLES 11 zu benutzen. Ein solches Vorgehen ist nicht risikofrei. Bevor andere das nachmachen, empfehle ich unbedingt ein Backup der OX6 Datenbank auf seinem MySQL-Server, ein Backup der OX6-Verzeichnisse auf dem Apache-Server und ein Backup der OX6-Dateien – bei mir unter “/opt/open-xchange”.

Das von mir genutzten SLES11-Repositories findet man unter:
OX 6.22.0 Backend: http://software.open-xchange.com/OX6/6.22/6.22.0/backend/SLES11/
OX 6.22.0 Frontend: http://software.open-xchange.com/OX6/6.22/6.22.0/
frontend/SLES11/

Diese Repositories bindet man in die Paket-Verwaltung unter YaST2 ein. Unter YaST2’s Software-Update-Modul wechselt man dann am besten in die Ansicht für die “Installationsquellen”. Dort prüfe man für das Repository zum OX6-Backend und im Repository zum Frontend, welche Pakete als update-fähig angezeigt werden und hake die Einträge entsprechend ab. (Weiter unten findet man 2 Listen zu den erforderlichen Paketen). Man wundere sich beim Auflösen der Paketabhängigkeiten durch YaST2 nicht, dass dann sehr viele alte Pakete für als zu löschen markiert werden. Das hat tatsächlich seine Richtigkeit!

Ändern des OX6-Daemon-Starts über den Run-Level-Editor

Nachdem der Update gelaufen ist, muss man den Start des OX6-Daemons ändern. Die ursprünglich 2 Dämonen für die OX6-Groupware und die OX6-Administration sind nun zu einem Dämon zusammengezogen worden. Man nimmt die Änderungen am schnellsten über den YaST2-Runlevel-Editor vor. Ja, das geht auch unter den neuen systemd-Verhältnissen. YaST2 übersetzt die alten sysvinit-Angaben für diese konventionellen LSB-Applikationen unter systemd schon passend:

update_ox622_daemon_600

Nach dem Update funktioniert der OX6-Login über die Web-Oberfläche erstmal nicht – 503-Fehler

Hat man den OX6-Groupware-Server dann erneut gestartet, darf man sich ein kleines Frustrationserlebnis abholen. Versucht man sich nach den bisherigen Operationen auf dem OX6-Server über die OX6-Weboberfläche einzuloggen, so geht das schief. Egal, welchen User man probiert, man erhält eine “503-Meldung”: “Service temporarily not available”.

Zusätzlich tauchen in den OX6-Logs Fehlermeldungen zu fehlenden Sprachfiles auf.

Bevor du nun das Fluchen anfängt:
Prüfe erstmal, ob die Anbindung der Kalender-Clients unter OX6 funktioniert! Von dort klappt nämlich die Anbindung zum backend anstandslos, wie ich überrascht feststellen musste. So schlimm konnte der Fehler also nicht sein. Einige Minuten später stellte sich nach einem Blick auf den Webserver folgendes heraus:

Der Fehlschlag mit der OX6-Web-GUI liegt daran, dass für das 6.22-Frontend neue Pakete installiert werden müssen! Sieht man sich unter den OX6-Verzeichnissen seines Apache-Servers mal die Datumsangaben der installierten OX6-Files an, so wird man feststellen, dass der bisherige, oben beschriebene Update-Prozess die HTML- und Javascript-Files der früheren 6.20-Installation nicht angetastet hat. Der alte Client passt aber schlicht nicht zum neuen Backend! Wir korrigieren dieses Problem gleich im Zuge eines Upgrades auf die Version 6.22.1!

Upgrade auf die Version OX 6.22.1

Wir deaktivieren unter YaST2’s Paketverwaltung nun die OX 6.22.0-Repositories. Zusätzlich binden wir die aktuellen OX6-Repositories für OS 12.2 ein:

http://download.opensuse.org/repositories/server:/OX:/ox6.22:/frontend/openSUSE_12.2/
http://download.opensuse.org/repositories/server:/OX:/ox6.22:/backend/openSUSE_12.2/

Und nun stellen wir folgende Listen an Paketen für den Upgrade zusammen:

OX6-Backend (V6.22.1)
update_ox622_backend_600

Hier kommt zu den bisherigen Paketen eines für
die “de_DE”-Sprachunterstützung des Backends hinzu: open-xchange-l10n-de-de.

OX6-Frontend (V6.22.1)
update_ox622_frontend_600

Dies sind etliche Pakete mehr als beim Upgrade zu v6.22.0 ! Am wichtigsten ist das Paket “open-xchange-gui” ! Hinzu kommen Pakete zur deutschen Sprachunterstützung sowie zu Hilfe-Funktionen. Benötigt werden außerdem separate Pakete für die E-Mail-Account-Verwaltung und Plugin-Wizards:

open-xchange-gui-help-plugin, open-xchange-gui-help-plugin-gui, open-xchange-gui-l10n, open-xchange-gui-l10n-de-de, open-xchange-online-help-de-de, open-xchange-gui-themes-default, open-xchange-gui-loading-theme-default, open-xchange-gui-login-theme-default, open-xchange-gui-mail-accounts-plugin, open-xchange-gui-wizard-plugin, open-xchange-gui-wizard-plugin-gui

Man führe dann per YaST2 den Update zu diesen Paketen durch. Ein kurzer Blick auf den Webserver zeigt danach, dass dort jetzt aktuelle OX6-Web-GUI-Files mit einem neueren Datum vorliegen. Ferner ist jetzt auch das Verzeichnis “/opt/open-xchange/i18n” gefüllt.

Und jetzt klappt endlich auch der Web-Login für den OX6!

ox622_mail_600

Das Bild zeigt den Zugriff auf einen (separaten) IMAP-Server über den OX6! Der WE-GUI-Zugriff auf die im OX6 selbst verwalteten Kalender-Einträge, Aufgaben, den Infostrore, etc. funktionierten bei mir ebenso völlig anstandslos wie der Rest der upgedateten Web-GUI!

Ich musste nur bei einem einzigen User in die Datenbank eingreifen und dort den Email-Account für die Unified Mail (“unifiedinbox”) löschen. Bevor ich das tat, verweigerte OX6.22 für diesen speziellen Account jegliche Mail-Anzeige und deaktivierte das Mail-Modul. Die Ursache blieb unklar; aber das war mir auch egal, da dieser lokale Account sowieso nicht benutzt wurde. Bei keinem anderen User trat ein solches Problem auf!

Erfolgreicher Check des OX6-Zugriffs mit Kontact-Komponenten von KDE 4.10

Bleibt abschließend nur, den Zugriff von Kontakt/Organizer und vom Kontact/Addressbook (eiens aktuellen KDE 4.10) auf den OX6.22 zu prüfen. Der Zugriff läuft über Akonadi und da ist man bekanntlich nie vor Überraschungen gefeit.
Aber: Alles funktionierte auf Anhieb und ohne jede Änderungen oder Eingriffe. Der OX6-Konnektor von Akonadi funktioniert also auch mit OX 6.22.1 ! Interessant, dass auch die “Address Auto Completion” von Kmail 4.10 beim Zugriff auf das OX6-Adressbuch keine größeren Zicken machte. Soweit ich sehen kann, werden die vorhandenen Adressen genauso gut (oder schlecht) wie zuvor angezeigt. Sehr gut funktionierte CUH der Web-Dav-Zugriff auf die Verzeichnisse des InfoStore über Dolphin!

Geht doch !

OX 5 – LDAP Restaurierung nach Fehler

Posted on by

Gestern hatte ich nach 6 Jahren erstmals ein größeres LDAP-Problem mit unserem alten OX5-Server.

Meine Kollegin hatte versucht, eine neue Mail-Adresse auf dem OX 5 Server von Kontakt/Kmail eines Client-Rechners aus zu speichern. Dabei wird ein neuer Kontakt angelegt, dessen Daten bei meinem OX 5 sowohl in der Postgres-Datenbank als auch in einer LDAP-Datenbank hinterlegt werden.

Leider hatte die Kollegin die Mail von einem Outlook-Benutzer erhalten, der seine Adressangaben recht chaotisch gepflegt hatte. Seine “von”-Adresse wies eine Angabe der Form “mailto:xxx@yyy.com” auf. Unvorsichtigerweise hat meine Kollegin zur Übernahme der Mailadresse in das Kmail-Adressbuch (das eigentlich ein OX-Adressbuch ist) wie gewohnt mit der rechten Maustaste auf diesen “mailto-Link” im Adressbereich der an sie weitergeleiteten Mail geklickt. Dies hatte schlimme Folgen:

Der Speichervorgang für den neu anzulegenden “Kontakt” in den Kontakte- und Adressen-Verzeichnissen des OX5 Servers wurde leider nicht korrekt abgearbeitet. Als resultierende Symptome musste ich nach einiger Analyse von Log-Dateien des Servers leider einen traurigen Zustand feststellen:

  • Absturz von Tomcat
  • Korrumpierte LDAP-Datenbank
  • Massive Performancereduktion des OX-Servers wegen hängendem LDAP

Für die, die hier evtl. schlimmere Dinge vermuten: Ein Virenscan der Mail mit unterschiedlichen Scannern hat nichts erbracht.

Wegen der korrupten LDAP-Datenbank war auf dem OX5-server natürlich auch keinerlei Login mehr für die OX-User möglich, da diese alle über LDAP verwaltet und über “pam-ldap” authentisiert werden. User auf externen Servern konnten daher weder Dienste des OX-IMAP-Servers, noch Samba- und NFS-Dienste nutzen. Hier war schnelle Abhilfe von Nöten.

Die Lösung brachte hier (SUSE-SLES-System) folgende Kommandosequenz :

cd /var/lib/ldap
rcldap stop
db_recover -v
slapindex
rcldap start

LDAP unter Opensuse und auf SLES-Systemen nutzt defaultmäßig die Berkely DB als Backend zur Datenhaltung. Damit ist das Kommando “db_recover” angesagt. ( Unter Red Hat ist übrigens statt “db_recover -v” das Kommando “/usr/sbin/slapd_db_recover -h /var/lib/ldap ” einzusetzen.)

Für “katastrophale” Fälle kann man auch – nach weiteren Sicherungsmaßnahmen (! siehe die Links unten !) – die Variante

db_recover -v -c

verwenden. “-c” steht hier für “catastrophic”.

Will man das Kommando von einem anderen Ort als dem Verzeichnis “/var/lib/ldap” ausführen, so ist die Option “-h” nützlich.

Weitere Informationen – auch für hartnäckige Fälle der Restaurierung der LDAP Backend Datenbank – liefert die Artikel unter folgenden Links:

http://sdb.open-xchange.com/node/29
http://blog.mydream.com.hk/howto/linux/openldap-recovery-howto

Zu den Optionen von “db_rcover” für die BDB siehe :

http://www.manpagez.com/man/1/db_recover/

Weitere Informationen zur Fehlerbehebung findet man unter:

http://techarold.blogspot.com/2006/07/more-openldap-recovery.html
http://www.prestonlee.com/2009/07/08/recovering-a-corrupt-openldap-database-on-osx-server/
http://serverfault.com/questions/87889/ldap-database-recovery-after-server-crash
http://
web.archiveorange.com/archive/v/TDuKz11zCkpKFJNjBppH
http://www.bynari.net/support/users/kb.php?id=236

Generelle LDAP-Admin-Informationen findet man unter :

http://www.openldap.org/doc/admin24/

Zum Einsatz der BDB als LDAP-Backen siehe:

http://www.zytrax.com/books/ldap/ch6/bdb.html

Kontact 4.7 und OX 6 unter Opensuse 11.4 – Teil II

Posted on by

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.