Das letzte Update des OX5-Servers auf das SP4 U1 führte in unserer Umgebung leider zu folgendem Fehler:
Bei allen vorher existierenden User-Accounts waren plötzlich die privaten Adresseinträge nicht mehr zugänglich. So etwas ist trotz Sicherung mehr als ärgerlich. Nur die OX-Entwickler wissen vermutlich, wie es zu diesem Missstand kommen konnte. In einer Produktivumgebung ist sowas ein kleines Desaster.
Andererseits lieferte es in unserem Fall auch ein Beispiel dafür, dass man in einer Open Source-Umgebung solche Fehler mit ein wenig Geschick selbst beheben kann. Als nützlichen Nebeneffekt lernten wir dabei auch noch etwas über die Datenstrukturen von OX5, die auf unserem Server in einer Postgres-Datenbank mit der Bezeichnung “openexchange” abgelegt sind.
Der Fehler wurde auf unserem System dadurch sichtbar, dass ein Klick auf das Kontakt-Icon in der Bedienungsleiste des OX-Portals zur Meldung führte, dass man keine Berechtigung für den Zugriff besäße:
Kontakte
“Keine Berechtigung. Für den gewünschten Bereich fehlt Ihnen die Berechtigung.. “.
Daran änderte auch eine explizite neue Rechtevergabe für die betroffenen Accounts über die OX-Administrationsoberfläche leider gar nichts. Dann fiel uns auf, dass der bisher existente Default-Ordner “Kontakte” auch nicht mehr im persönlichen Ordnerbereich angezeigt wurde. Waren die privaten Adressdaten der verschiedenen User-Accounts also überhaupt noch vorhanden?
Kontakte Ordner, Datenbank und LDAP
Adressdaten werden im OX-System in sog. “Kontakte-Ordnern” abgelegt:
- einem speziellen privaten Kontaktordner, der beim Anlegen eines Accounts automatisch erstellt wird (zusammen mit einem Kalender- und Aufgaben-Ordner)
- selbst erstellten weiteren privaten Kontaktordnern,
- einem “globalen Adressbuch”, das firmenweit gültige Adressen bereitstellt,
- und in einem LDAP-Verzeichnisdienst.
Alle angelegten Kontakte tauchen dabei sowohl in der Openexchange Datenbank als auch im LDAP-Verzeichnis auf. Auf beide Quellen kann man unter KDE übrigens mit dem Informationsmanager “KDE Kontact” zugreifen.
In einem ersten Schritt bemühten wir den LDAP-Browser “gq”, um uns ein Bild davon zu verschaffen, welche Adresseinträge eigentlich auf dem LDAP-Server noch vorhanden waren. Mit Erleichterung konnte ich die Vollständigkeit privater Adresseinträge im Zweig
ou=addr,uid=MYSELF,ou=people,dc=MYDOMAIN,dc=de
des LDAP-Baumes feststellen. Meine eingepflegten Adressen war also zumindest dort noch vorhanden. Als nächsten Schritt legte ich dann einen neuen OX-Useraccount an, um herauszufinden, ob durch das Upgrade irgendwelche persönlichen Einstellungen verpfuscht worden waren. Zunächst konnte ich feststellen, dass der Vergleichsaccount
a) bis auf den Namen zu genau den gleichen Basiseinträge im LDAP führte, die auch mein Originalaccount aufwies,
b) und dass der Fehler mit dem Kontakte-Ordner für den neuen Account gar nicht auftauchte !
Die Ursachen für den Fehler waren also wirklich im Upgrade und irgendwelchen irregulären Datenbanktransaktionen für die vorhandenen Accounts zu verdanken.
Tabellen für Kontakte, Defaultordner und Zugriffsrechte in der Datenbank “openexchange”
Also: SSH-Zugriff auf den OX-Server. “su postgres” absetzen und danach mit “psql openexchange” auf die Postgres-Datenbank zugreifen. Ein “\dt” verschafft einem dann einen Überblick über die vorhandenen Tabellen. Nach etlichen Selects und ein wenig Kombinationsvermögen erkennt man schließlich Folgendes:
- Die “Standardordner” eines Benutzeraccounts sind u.a. in der Tabelle “oxfolder_standardfolders” über Referenzschlüssel eingetragen.
- Die eigentlichen Ordnereinträge findet man in der Tabelle oxfolder_tree. Der dortige Primary Key entspricht dann für die Defaultordner (u.a. ”
Kontakte”) eines Users den Referenzschlüsseln in der Tabelle “oxfolder_standardfolders”. - Adressdatensätze sind in der Tabelle “prg_contacts” eingetragen. Dort tauchen in entsprechenden Spalten dann natürlich auch Referenzschlüssel zum jeweiligen Ordner und zum User auf. (In dieser Tabelle fand ich dann in schöner Übereinstimmung zum LDAP auch meine privaten Adresseinträge wieder).
- Die Rechte zu den Ordnern sind in der Tabelle “oxfolder_permissions” eingetragen. (Details der numerischen Rechtekammstruktur lassen sich durch Beispieleinträge mit unterschiedlich vergebenen Rechten analysieren und ermitteln).
Durch Vergleich der Einträge zu meinem Originalaccount in den verschiedenen Tabellen mit entsprechenden Einträgen zu einem frisch angelegten Useraccount konnte ich dann folgende, durch das Upgrade entstandene Defizite ermitteln:
- In der Tabelle “oxfolder_tree” fehlte in der Spalte “owner” der Eintrag des User-Kürzels. Dies war durchgängig für alle Accounts der Fall, die bereits vor dem Upgrade existierten.
- In der Tabelle “oxfolder_permissions” fehlten die Einträge für die Default-Kontakteordner der User völlig.
Nach einem Vergleich mit den Daten eines neuen Accounts konnte wir mit Hilfe von Update- und Insert-Statements die erforderlichen Sätze letztlich recht einfach rekonstruieren. Und siehe da: Danach führte dann auch der Klick auf das “Kontakte”-Ordner-Icon wieder zum gewünschten Ergebnis!
Fazit:
Auch bei einem rel. umfassenden System wie “Open-Xchange” hat man im Fehlerfall (manchmal) eine Chance, diesen selbst zu beheben. Ein echter Vorteil von Open Source-Produkten! Das Auftreten des beschriebenen Problems im Zuge eines Upgrades ist aber dennoch in höchstem Maße ärgerlich!