OX 5 – LDAP Restaurierung nach Fehler

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

Opensuse 11.4 – Kontact/Kmail 4.7.0 – Probleme

Mutig (oder dumm?) wie ich bin, habe ich am Wochenende gewagt, eine unser Linux-Arbeitsstationen unter Opensuse 11.4 von KDE 4.6 auf KDE 4.7 umzustellen. Dabei nutzte ich – wie bei früheren KDE Updates auch – das Opensuse KDE Factory Repository.

Leider hatte ich es versäumt, mir den neuen Inhalt des KDE Factory Repositories genauer anzusehen. Dabei wäre mir nämlich folgendes aufgefallen:

Suse hatte die KDE PIM-Pakete und Akonadi bislang auf dem Stand der KDE 4.4 ausgeliefert (also z.B. Kmail 1.13. statt Kmail 2.x). Gründe hierfür waren sicher die vielen Probleme mit den neuen Versionen und deren Zusammenspiel mit Akonadi – siehe hierzu meine eigenen Beiträge in diesem Blog. (U.a. gab es Probleme mit dem enormen CPU-Verbrauch von Nepomuk und virtuso-t.) Nun hat aber auch SUSE die neuen Versionen Kontact 4.7, Kmail 4.7 und weitere Programme sowie die zugehörigen Akonadi-Versionen ins KDE Factory Repository aufgenommen.

Das hatte ich nach meinem Urlaub nicht mitbekommen – und das blieb leider nicht ohne Folgen:

Problem 1: Kmail und Kontact 4.7.0 ließen sich nicht starteten

Das erste Problem war, dass sich Kontact wegen Kmail nicht mehr starten ließ bzw. wegen eines “schweren Fehlers”

“In KMail ist ein schwerwiegender Fehler aufgetreten. Das Programm wird beendet.
Die Fehlermeldung lautet: Fehler beim Einholen der Ressourcen-Sammlung. … ”

immer wieder geschlossen wurde. Siehe hierzu auch:


https://bugzilla.novell.com/show_bug.cgi?id=708977

http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/463408-kde-4-7-out-2.html
http://www.kde-forum.de/post/13239/kontact-4-7-0-und-akonadi-funktionieren-nicht.html#post13239
http://www.linuxforen.de/forums/showthread.php?p=1779066

Ziemlich sarkastische – aber aus meiner Sicht auch angemessene Kommentare findet man hier:
https://bbs.archlinux.de/viewtopic.php?id=19453


Problembehebung:

Mich hat die Behebung dieses Problems alles in allem etwa 2 Stunden gekostet. Zunächst habe ich mit einem jungfräulichen Benutzeraccount versucht, Kontact/Kmail 4.7 zum Laufen zu bewegen. Dieser Test ist bei KDE-Updates immer nützlich, denn nach dem Aufsetzen eines jungfräulichen Users gibt es keine alten Konfigurationsdateien unter ~/.kde4/share und den dortigen Subverzeichnissen. Da es dann mit dem jungfräulichen User ging, war klar, wo ich weitermachen musste.

Ich musste letztlich “alle” alten Dateien zu Kmail und Akonadi in meinen eigenen Subverzeichnissen von “~/.kde” eliminieren sowie den Akonadi-Server und die Akonadi-Ressourcen komplett neu einrichten.

Es reichte übrigens nicht, die “kmail*rc”-Dateien in “~/.kde/share/config” zu eliminieren/umzubenennen. Ich musste auch Dateien unter dem Subverzeichnis “~/.kde/share/apps” entfernen. Dabei muss KDE immer mal wieder neu gestartet werden (z.B. mit init 3 – init 5).

Schließlich habe ich es so nach mehreren Anläufen geschafft, Kmail 4.7 zum Laufen zu bringen und auch an einen IMAP-Server in unserem Netz anzubinden.

Problem 2: In Kmail macht die initiale Einrichtung von Spam-Filtern das Weiterarbeiten unmöglich

Naiv wie ich bin, habe ich dann versucht, Spam-Filter einzurichten. Dies hat sich als sehr schlechte Idee erwiesen, da diese Filter beim initialen Lauf über große Mailordner (und davon habe ich viele) ein Bedienen der Kontact-
Oberfläche völlig unmöglich machten. Man sieht den “Fortschritt” der Mail-Analyse – das lief doch unglaublich langsam ab. Ich habe Kontact schließlich gewaltsam beendet und die Filter-Einstellungen (Bogo-Filter und/oder Spam-Assassin) wieder aus den Kmail-Konfigurationsdateien entfernt.

Spam-Filter werde ich deshalb erst wieder bei der Version KDE 4.7.1 wieder ausprobieren. Frühestens ….

Problem 3: Das manuelle Einstellen der Reihenfolge der Mailordner funktioniert unter Kmail 4.7 nicht mehr

In der Ansicht der Mailfolder konnte man bislang die Reihenfolge der angezeigten Mailordner nicht nur alphabetisch oder nach anderen Anzeigespalten sortieren lassen, sondern die Darstellung der Reihenfolge auch manuell festlegen. Das funktioniert unter Kmail 4.7 im Moment schlicht nicht mehr. Bei unserer doch umfänglichen Ordnerlandschaft ist das einfach ärgerlich.

Problem 4: Keine Kontact-Verbindungen zu einem OX 5 Server – nur zu OX6

Leider nutzt einem Kmail alleine auch nicht viel, wenn man nicht mehr an einen Teil seiner Kontakte und Adressdaten herankommt und auch seine Kalender-Einträge nicht mehr öffnen kann. Bei uns liegen Kontakte und Kalender zu einem größeren Teil nämlich immer noch auf einem Open-Xchange Server der Version 5. Wir betreiben zwar auch einen Open-Xchange Server der Version 6 (aus Kostengründen in der Community Edition) auf einem Opensuse 11.0-System. Aber die Migration aller alten OX5 Daten – insbesondere auch der umfänglichen Wissenseinträge oder des Dokumentenarchivs vom OX 5 zum neueren OX 6 System hatten wir bislang nie vollständig vollzogen. Warum auch, wenn man zwei fehlerfrei laufende Serversysteme hat.

Die schlechte Nachricht ist nun die:

Die Akonadi-Konnektoren zu OpenXchange Ressourcen funktionieren bei KDE/Kontact 4.7.0 im Gegensatz zu älteren Versionen (z.B. unter KDE 4.4) nur noch für den OpenXchange Server 6 aber nicht mehr für den OX 5. Ob sich das bei künftigen Versionen noch ändern wir, weiß ich nicht.

Schade eigentlich, dass die KDE-Entwickler die bis KDE 4.4 anstandslos funktionierenden Schnittstellen zu OX5 nicht auch in die neuen Kontact/Korganizer/Kontakt-Versionen übernommen haben. Das ist für mich nicht nachvollziehbar.

Jedenfalls kann ich im Moment den Zugriff von meinem KDE 4.7 System auf den alten OX 5 Server vergessen – und damit auch den direkten Zugriff unter Kontakt auf die dort liegenden Informationen. Das ist schon ziemlich blöd, wenn einem plötzlich in der täglichen Arbeit einige Adressbücher und E-Mail-Adressen fehlen.

Wer also produktiv mit einem OX 5 Server arbeiten will oder muss, sollte von einem KDE Update auf KDE 4.7 unter Opensuse besser die Finger lassen.

Gott sei Dank habe ich Zugriff auf mehrere Opensuse 11.4-Systeme, auf denen noch eine 14 Tage alte KDE 4.6-Version mit den KDEPIM-Komponenten von KDE 4.4 läuft..

Was Positives

Nun aber auch ein paar gute Nachrichten:

a) Ich habe dann am Sonntag mal testhalber einen OX 6 Server unter Opensuse 11.4 aufgesetzt. Hierzu mehr in einem anderen Beitrag. Dies ist praktisch genauso einfach oder schwierig wie unter Opensuse 11.0.

b) Die Anbindung des Gespanns Kontact/Akonadi von KDE 4.7 an die Ressourcen (Adressbücher, Kalender, Tasks) der OX 6 Server unter Opensuse 11.0 und Opensuse 11.4 funktioniert doch sehr ordentlich. Ich konnte beim ersten Rumspielen zumindest keine echten Probleme erkennen.

c) In Kmail wurde ein alter, ärgerlicher Regressions-Fehler von Anfang 2009 nun endlich behoben: Beim Ziehen von Mails aus der Mailliste über die Ordner im Ordnerbereich öffnet sich die Ordnerhierarchie nun wieder. Das erleichtert die Mailverschieberei in der komplexen Ordnerstruktur eines Unternehmens doch erheblich.

r
d) Die in einem früheren Beitrag zu Kmail 2 und unter https://bugs.kde.org/show_bug.cgi?id=246678 kritisierten Problemen mit dem hohen CPU-Verbrauch von Nepomuk und Virtuoso beim Indizieren neuer Mails scheinen behoben zu sein. Nepomuk läuft jedenfalls bei mir und ich kann die früheren extremen Ausschläge in der CPU-Belastung nicht mehr sehen.

Fazit

Der Schritt auf KDE/Kontact 4.7 ist mit Kinderkrankheiten verbunden. OX 5 Nutzer sollten den Schritt auf KDE 4.7 unter Opensuse lieber bleiben lassen oder vorab ernsthaft eine Migration auf OX 6 in Angriff nehmen.

KDE 4.6 Beta, K3b, Kmail, Akonadi, virtuoso-t, OX5

No risk no fun ! Dachte ich und habe mir mal KDE 4.6 Beta auf einem meiner Opensuse 11.3 Systeme installiert. Aus drei Gründen war das für mich ein interessantes Experiment :

  1. Weil unter KDE 4.5.2, KDE 4.5.3 K3b nicht mehr funktionierte und ich gemäß der Einträge bei den entsprechenden KDE-Bugs aber die Hoffnung bekam, es könne nun wieder laufen.
  2. Weil unter KDE 4.6 das Akonadi-Subsystem nicht mehr nur für das Adressbuch sondern auch für die Verwaltung der Mailordner zuständig wird. Hier ist das Wechselspiel mit IMAP-Systemen interessant.
  3. Weil Akonadi auch mit den Kalender-Ressourcen eines Open-Xchange 5 Servers zusammenarbeiten sollte.

Um es vorweg deutlich zu sagen: Solche Experimente mit Beta-Systemen wie zu Punkt 2 sollten keine produktiven IMAP- oder OX-Server einbeziehen, sondern nur Server, die Kopien der eigentlichen IMAP-Mail-Ordner und Kalenderdaten beinhalten! Zur Not richtet man sich einen IMAP-Testserver halt auf einem Laptop oder einem virtuellen System ein. Bei OX5 oder OX6 ist das zugegebenermaßen schon schwieriger.

Zu Punkt 1 – K3b:

K3b läuft unter Opensuse 11.3 und KDE 4.6 wieder – allerdings nur mit den letzten K3b RPM-Paketen 2.0.1-44.1 im Opensuse Factory Repository. Eine CD habe ich mal testweise gebrannt – das lief ohne Probleme. Genauer getestet habe ich das Brennen von unterschiedlichen Medien (DVD+-R, DVD+RW, etc. aber noch nicht. Das Rippen von CDs läuft mit der aktuellen Version aber wie gewohnt. Anzumerken bleibt: Die aktuellen RPMs von Packman 2.0.1.pm.2.26 laufen nicht. (Vermutlich wegen der erfolgten Änderungen im HAL-Bereich)

Zu Punkt 2 – Kmail, Akonadi, IMAP – und die problematische Wirkung von Filtern :

Die Verwaltung von Mailordnern durch Akonadi stelle ich mir persönlich als eine komplexe Angelegenheit vor. Im Besonderen dann, wenn die Mailordner auf einem IMAP-Server liegen und die Filterung von Mails (Spam und andere Filter) aber lokal unter KDE’s Kmail erfolgt. Ich habe auf meinem Desktop-System eine ganze Reihe von Filtern eingestellt. Nicht nur zum zusätzlichen Filtern von Spam, der auf dem Server nicht erkannt oder zu vorsichtig behandelt wurde, sondern auch themen- und kundenbezogene Filter.

Für mich als Anwender stellt sich doch die Frage, wie der mindestens zweistufige Weg der Filterung von Kmail über die Akonadi-Maschinerie hin zum IMAP-Server abläuft. Kmail als Frontend zu Akonadi initiiert die Filterung und als Reaktion werden dann ggf. Verschiebungen von Mails aus dem Posteingangsordner hin zu anderen Ordnern durchgeführt. Das Ergebnis muss sich zunächst auf dem lokalen Akonadi-System und dessen Abbildung der Mailordner niederschlagen. Die vorgenommenen Ergebnisse der Filteraktionen wie Löschungen im Ursprungsordner und entsprechende Neuzugang in definierten Zielordnern müssen ja aber auch periodisch zwischen Akonadi und dem IMAP-Server abgeglichen werden. In einer solchen Verarbeitungskette – MUA-Client <> Akonadi (als zwischengeschobenes zentraler Puffer) <> IMAP-Server – eröffnen sich zahlreiche Möglichkeiten für Fehler.

Meine Erfahrungen waren entsprechend :
Die Migration der vorhandenen Mail-Ordner aus dem alten Kmail hin zu Akonadi ging grundsätzlich ohne Probleme vonstatten. Es dauerte allerdings etliche Minuten, da unsere Mailordner mehrere Gigabyte umfassen. Die Zeitdauer für die Migration war aus meiner Sicht absolut OK. Probleme verursachten dann aber die bereits konfigurierten Mail-Filter aus meiner KDE 4.5.3-Kmail-Version. Diese fingen nämlich beim Füllen meiner doch zahlreichen Mailordner an zu wirken – und zwar nicht in der gewohnten Weise. Es wurde in andere lokale Ordner verschoben, die begonnen Filtervorgänge schluckten
enorm viel CPU-Zeit, die Kmail-Oberfläche kam letztlich zum Stillstand und war nicht mehr bedienbar …. Ursache war hier vermutlich, dass viele Mailordner im Zuge der Migration gleichzeitig neu befüllt wurden.

Kurzum:
Die Filter verursachten zeitversetzt und im Nachgang zum eigentlichen Migrationslauf zunächst ein ziemliches Chaos und ungewohnte Verschiebungen in lokale (!) Spam- und Trash-Ordner. Offenabr war ein teil der alten Konfiguration – nämlich die Festlegung der Zielordner – verloren gegangen. Nun ließen sich die laufenden Filterprozesse wegen des Stillstands der Kmail-Oberfläche leider auf konventionellem Wege auch nicht mehr aufhalten. Ein Killen der entsprechenden Prozesse, ein Löschen der Konfigurationsdatei kmail2rc und ein Neustart verhalfen mir schließlich zu der Möglichkeit, meine Filter zu entfernen und komplett neu anzulegen. Danach verhielt sich Kmail ruhiger und ließ sich fast (s.u.) normal bedienen. Die fälschlich verschobenen Mails habe ich dann wieder in ihre Ursprungsordner einstellen können.

Ich kann daher jedem, der größere Mailordner sein eigen nennt, nur raten, vor einem Umstieg auf das neue KDE und sein Kmail alle eingerichteten Filter zunächst mindestens zu deaktivieren, wenn nicht gar zu löschen – und sie erst im Nachheinein neu einzurichten.

Aber auch dann bereiten die lokalen Filter in Kmail noch weitere Probleme:

Im Gegensatz zu früheren Kmail-Varianten werden nämlich alle auf dem IMAP-Server für das Löschen markierte – aber im IMAP-System aus den Ursprungsordnern physikalisch noch nicht gelöschte Mails – erneut in den Mail-Ordnern von Kmail angezeigt (in grauer Schriftfarbe). Regeln zur Kompaktifizierung der IMAP-Ordner – sprich zu einem sofortigen Löschen von Mails in den IMAP-Ordnern auf dem Server – sind bei mir deaktiviert. Mails werden daher auf dem IMAP-Server bei Lösch- oder Verschiebe-Vorgängen in ihrem Ursprungsordner nur zum Löschen markiert. Die eigentlichen Löschungen laufen dann am IMAP-Server zwar periodisch, aber mit deutlichem zeitlichem Abstand. Das ist eine reine Vorsichtsmaßnahme, von der die User an ihren Clients (wie dem alten Kmail) normalerweise gar nichts mitbekommen.

Aus der Anzeige der zum Löschen markierten Mails in Kmail lässt sich schließen, dass Akonadi beim Filtern und Verschieben der Mails in neue Ordner also mitbekommt, dass die verschobenen Mails auf dem IMAP-Server noch im Ursprungsordner vorhanden sind – wenn auch mit geändertem Status. Nun wirkt sich das leider negativ auf die Filter in Kmail aus. Die Filter bewerten die markierten Mails offenbar als neu eingegangene (möglicherweise wegen der Statusänderung) und filtern sie deshalb auch erneut. Obwohl sie ja schon früher behandelt und in andere Ordner verschoben wurden. Und das setzt sich dann so fort ….

Ergebnis:
Nach einigen periodischen Abgleichen zwischen Akonadi und dem Imap-Server wächst der Inhalt in Trash oder Spam-Ordnern linear an. Mit immer den gleichen Dateien. Das ist im Produktivbetrieb ein Desaster. Als Anwender kann man hier das Gesamtsystem nur so einstellen, dass bei der Löschung/Verschiebung einer Mail aus einem Ordner durch eine Kmail-Aktion auch eine sofortige Löschung der Mail in ihrem Ursprungsordner auf dem IMAP-Server vorgenommen wird. Das ist zumindest riskant. Oder man muss die Filter um sehr spezielle Einstellungen und Kriterien erweitern – was man vom normalen User nicht verlangen kann.

Die Lösung aus meiner Sicht wäre eine andere Behandlung von Mails, die auf dem IMAP-Server zum Löschen markiert sind, in Akonadi wie in der Anzeige und den Filter-Routinen von Kmail.

In der jetzigen Form ist das Kmail/Akonadi-Verhalten im Zusammenspiel mit IMAP-Servern zwar schon erstaunlich stabil und auch die Migration der Mailordner zu Akonadi-Ressourcen funktioniert im Kern schon richtig. Aber die Behandlung von Mails, die aufgrund von Client-Aktionen auf den IMAP-Servern zum Löschen vormarkiert werden, muss für den produktiven Einsatz geändert werden.

Hinzu
kommt ein weiteres Problem, dessen Ende ich auf meinem Versuchssystem noch nicht absehen kann. Mindestens am ersten Tag der Umstellung fraß der “virtuoso-d”-Prozess mit führendem Abstand die allermeiste CPU-Zeit auf meinem System (in Form von nice-Last). Ursache ist die Indizierung von Mails durch Nepomuk mit Virtuoso als Backend (virtuoso-t ist wohl ein zugehöriger Datenbank-Prozess).

Dabei war die Konkurrenz um die Prozessorzeit keineswegs gering – auf zwei von 4 CPU-Cores habe ich andauernd unter VMware auf einem virtuellen Windows-System gearbeitet. Normalerweise würde VMware die meiste CPU-Zeit beanspruchen. Bei KDE 4.6 Beta war es bislang aber der Prozess “virtuoso-d”. Er verbrauchte doppelt soviel CPU-Zeit wie VMware – und zwar im bereich mehrerer Stunden. Das ist wirklich viel!

Ob das daran liegt, dass ich Gigabytes an Mails habe, vermag ich im Moment nicht zu sagen. Ich hoffe jedenfalls noch, dass “virtuoso-t” nach vielleicht weiteren 12 Stunden endlich Ruhe gibt. Im Moment ist er immer noch fleißig am Werkeln. Fairerweise muss ich sagen, dass vituoso-t sich auf einen Prozessor-Core beschränkt und nach ersten Eindrücken auch nur dann so richtig aktiv wird, wenn tatsächlich noch CPU-Zeit verfügbar ist. Na ja, wir werden sehen, ob die Nepomuk- Indizierung auch mal zu einem Ende kommt. Insgesamt ist das Ganze aber in Indiz dafür, dass man Virtuoso oder aber das Zusammenspiel von Akonadi und Virtuoso ggf. noch effizienter machen muss.

Im Moment würde ich wegen der geschilderten Erfahrungen noch niemanden raten, auf produktiven Systemen auf das neue Kmail umzusteigen.

Zu Punkt 3 – Korganizer, Kadressbuch, OX5:

Das funktioniert im Moment schlicht und einfach nicht. Die Einrichtung von Kalendern als Teil einer OX5-Verbindung zu Kontakt scheitert. Einen entsprechenden Bug habe ich eingestellt. Das ist für mich im Moment übrigens der Hauptgrund, bei KDE 4.5.3 zu bleiben.

Auf einige Ungereimtheiten beim Umgang mit dem OX5-Adressbuch mag ich hier nicht mehr eingehen. Das läuft zwar als Relikt aus 4.5.3 zwar irgendwie, aber dennoch habe ich den Eindruck, dass die zugehörige Akonadi-Ressource nicht wirklich migriert wurde. Denn wenn ich auf die Eigenschaften der entsprechenden Akonadi-Resource zum OX5-Adressbuch gehe, öffnet sich ein Dialog zur Migration – in dem leider Open-Xchange gar nicht als Alternative erscheint. Womöglich arbeitet das “übernommene” Adressbuch also auf einer alten, nicht upgedateten Akonadi-Resource, die keine Verbindung zum OX-Server mehr aufweist. Bin im Moment aber zu faul, mir das genauer anzusehen.

Fazit:

Interessant war es schon, Akonadi nun mal im breiten Einsatz für Gigabytes an Mail zu sehen und nicht nur als Quelle für simple und in der Anzahl überschaubare Adressbuch-Daten. Im Kern funktioniert das schon. Bis auf “Kleinigkeiten” wie die Anzeige von zum Löschen markierten Mails des IMAP-Server und die Behandlung von Filteraktionen für solche Mails.

Ich bin daher sehr gespannt, wie sich KDE 4.6.Beta 2 bzw. der Release-Kandidat präsentieren werden. Im Moment ist Kontact KDE 4.6 in unserem Arbeits-Umfeld jedenfalls noch nicht reif für den produktiven Einsatz. Was ich bei einer ersten Beta-Version auch keinesfalls überbewerten will, sondern als normal ansehe.

Nachtrag: Problem mit der FROM-Adresse

Gerade macht mich meine Frau darauf aufmerksam, dass Mails, die ich von meiner Testinstallation verschicke, eine leere FROM-Envelope-Adresse aufweisen. Dies geschieht seit der Installation der letzten Kmail-RPM-Variante 4.5.80-261.2 vom Opensuse Factory-Repository unter KDE 4.6 Beta. Obwohl alle notwendigen Daten in der Kmail-“Identität” gepflegt sind. Na ja, Beta halt ……