KDE 4.1.2 – erster Eindruck zur Einsetzbarkeit

Seit 3 Tagen aber ich nun produktiv unter KDE 4.1 auf einem Opensuse 10.3 System. Dabei habe ich regelmäßig Openoffice, den KDE4 PIM Kontact, Dolphin, Konqueror, SmB4K, K3b, Terminals und VMware mit Windows XP eingesetzt. Im Hintergrund werkeln je nach Lust und Laune Compiz/Emerald und Amarok.

Mein Fazit ist:

Trotz immer noch vorhandener Fehler, Ungereimtheiten und Unzulänglichkeiten können Neugierige den Umstieg langsam wagen. Funktional bringt es zwar nichts und spürbar schneller scheint mir KDE4 auch nicht zu sein. Aber das Design ist sehr ansprechend, und man spürt an allen Ecken und Enden, dass sich KDE 4 zu etwas Großem mausern wird – ganz im Gegensatz zu MS Vista.

Richtig gut finde ich die neue Version von Kontact und die erweiterten Möglicheiten bzgl. des Journals, der Notizbücher und der Popup Notes. Das Teil macht jetzt richtig Freude und die neuen Tools sind wirklich nützlich. Allein deswegen lohnt sich der Umstieg – zumal die aktuelle 3.5.10-Version richtige Bugs im Zusammenspiel mit OX5 hat.

Aber es läuft bei weiten noch nicht alles so oder vergleichbar, wie man das von KDE 3.5.10 gewohnt war.

Daher auch der Rat : Installiert KDE 4.1 lieber parallel zu KDE 3.5. Die SUSE RPMs machen einem das grundsätzlich leicht – auch wenn man bei der einen oder anderen Applikation dann auch unter KDE 4.1 letztlich doch wieder zur KDE 3-Version zurückgeht. Schön ist an KDE 4.1 nämlich auch, dass man bei vielen Applikationen die Möglichkeit hat, auch die alte Version von KDE 3.5 zu starten.

OX5 – verlorener Ordner “Kontakte” nach Upgrade

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:

  1. Die “Standardordner” eines Benutzeraccounts sind u.a. in der Tabelle “oxfolder_standardfolders” über Referenzschlüssel eingetragen.
  2. 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”.
  3. 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).
  4. 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!

Openoffice 3.0 unter MS Win mit Samba-Zugriff

Am 21.10.2008 habe ich in diesem Blog einen Fehler von OO 2.4 für MS Win beschrieben. Dabei ging es um erhebliche Verzögerungen beim Speichern von Dateien, welche auf Samba-Servern lagen und auf die direkt mit Openoffice zugegriffen wurde (also über die Windows-Netzwerkumgebung).

Inzwischen habe ich auf dem Windows Client OpenOffice in der Version 3.0 installiert. Der früher beschriebene Fehler tritt in dieser Version nicht mehr auf! Gut so!