Monthly Archives: February 2012

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

Kmail 4.8 – Suchfunktionalität weiterhin im Eimer

Posted on by

Seit der Umstellung auf das akonadi-basierte Kmail2 (unter Opensuse passierte das nach KDE 4.6.4) gibt es Probleme mit der Suche nach Mails unter Kmail. Diese Feststellung ist mehr als traurig, denn im täglichen professionellen Einsatz von Mail-Programmen benötigt man Suchfunktionen, die einen schnell mehrere Suchkriterien miteinander kombinieren lassen – z.B. für den Mail-Text und für das Absender-Feld.

Kmail 1.13.7 wies hierfür einen voll funktionsfähigen eigenen Such-Dialog auf. Auf einem unserer Rechner ist die alte Version noch unter KDE 4.6.4 installiert. Da läuft alles noch prima – auch im Zusammenspiel mit IMAP-Servern.

Wie ist der Zustand seit KDE 4.7 und auch jetzt noch unter KDE 4.8 ?

  • Weder unter Kmail 4.7.4 noch unter Kmail 4.8 gibt der Suchdialog einem eine Möglichkeit zur Eingabe eines Mailverzeichnisses, den man durchsuchen will.
  • Wenn gesucht wird, so wird (manchmal) in allen Mailverzeichnissen gesucht.
  • Unter KDE 4.7.4 liefern viele Suchvorgänge Ergebnislisten mit leeren Zeilen am Anfang.
  • Unter KDE 4.8 liefert eine Suche mit mehreren kombinierten Such-Kriterien leere Resultsets, obwohl es viele Mails gibt, die die Kriterien erfüllen.
  • Manche Suchen nach Begriffen im vollständigen Mailtext liefern Resultsets – aber auch die nicht immer zuverlässig. Die Suchergebnisse sind nicht immer vollständig.

Das Ganze ist so fehlerhaft, dass man den Suchdialog unter Kmail im Moment als nicht benutzbar ansehen muss. Im Grunde ein Desaster! Hingewiesen hat mich darauf übrigens Martin Lüchem. Ich wollte es ihm zunächst gar nicht glauben, aber leider hat er recht.

Die einzige Suche, die bei mir z.Z. noch funktioniert, ist die über die Eingabezeile im normalen Kmail-Fenster. Das ist eine Volltext-Suche. Die scheint zu klappen. Aber wie gesagt, das reicht für den professionellen Einsatz überhaupt nicht.

Da fragt sich der KDE-Anwender erneut: Wie kann es sein, dass sich solche Mängel über zwei größere Releases von KDE 4 hinweg halten können?

Update KDE 4.8 – Nepomuks hohe CPU-Last

Posted on by

Habe gerade unter Opensuse 12.1 auf KDE 4.8 upgegraded. Danach erzeugt Nepomuk samt virtuoso-t ähnlich wie früher bei KDE 4.6 eine enorm hohe CPU-Last, die sich leider nicht so ohne weiteres beseitigen lässt.

Bei mir hat folgendes geholfen:

  • Stoppen von Nepomuk über die KDE-Systemeinstellungen.
  • Stoppen von Akonadi (man benutze das Kommando “kcmshell4 kcm_akonadi”,
    gehe dann im sich öffenenden Fenster auf den 2-ten Reiter für die “Einrichtung des Akonadi-Servers”
    und stoppe dort den Akonadi-Server).
  • Zur Sicherheit : Herunterfahren in den Runlevel 3
  • Löschen des Verzeichnisses ~/.kde4/share/apps/nepomuk
  • Löschen aller Konfigurationsdateien der Form ~/.kde4/share/config/nepomuk*
  • Löschen aller Konfigurationsdateien der Form ~/.kde4/share/config/akonadi_nepomuk_*
  • Hochfahren in den Runlevel 5 und Log in in den KDE-Desktop.

Danach wurden bei mir neue Konfigurationsdateien angelegt und auch das Nepomuk-Verzeichnis wurde erneuert.

Nepomuk begann dann mit einer Reindizierung aller möglichen Ressourcen, aber beanspruchte die CPU dabei viel, viel weniger als zuvor. Ferner verhält sich Nepomuk jetzt bei mir sogar adaptiv und begrenzt die CPU-Belastung auf Zeiten, in denen ich mit anderen Programmen nicht so viel macht.

Siehe hierzu auch https://bugs.kde.org/show_bug.cgi?id=289932, Kommentar #3 und weitere Kommentare.

Schade, dass die KDE-Entwickler immer wieder solche Schnitzer produzieren. Es muss doch möglich sein, die Programme neuer Versionen so zu gestalten, dass es möglich wird KDE-Updates durchzuführen, ohne Konfigurationsdateien von Schlüsselkomponenten löschen und neu anlegen zu müssen.

Nachtrag 15.02.2012:

Ich habe ein anderes System, auf dem folgende Voraussetzungen gegeben waren:

1) Opensuse 12.1 wurde von scratch neu installiert – und zwar zunächst ohne KDE, aber mit XFCE.
2) Danach habe ich direkt KDE 4.8 aus dem Repository http://download.opensuse.org/repositories/KDE:/Release:/48/openSUSE_12.1/ installiert. Es gab also kein Update von KDE 4.7.2.

Nach der Anbindung an einen IMAP-Server begann der Nepomuk-Indexer zu arbeiten und zwar ziemlich lange. Als nach ca. 30 Minuten kein Ende absehbar war, bin ich in die KDE-Systemeinstellungen (“systemsettings”) gegangen und dort in die Einstellungen zur “Desktopsuche”. Dort habe ich in der angegebenen reihenfolge folgende schritte durchgeführt:

  • Deaktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”
  • Deaktivierung des Punktes “Nepomuk-Datei-Indexer aktivieren” -> Button “Anwenden”
  • Deaktivierung des Punktes “Nepomuk-Semantik-Dienste aktivieren” -> Button “Anwenden”

Danach geht die CPU-Belastung durch Nepomuk auf 0. U.a. ist der Email-Indexer gestoppt. Dann habe ich folgendes gemacht:

  • Aktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”
  • Aktivierung des Punktes “Nepomuk-Datei-Indexer aktivieren” -> Button “Anwenden” und Durchlaufen lassen ! Ggf. über “Erweiterte Einstellungen” den verzeichnisbereich, der indiziert wird, einschränken.
  • Aktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”

Danach war Ruhe und die hohe CPU-Belastung durch virtuoso-t / nepomuk ging auf fast 0! Vermutlich wurde der erstmalige Neuindizierungsprozess von Nepomuk (kontrolliert?) abgebrochen. Danach scheint es aber leider so, dass der Email-Indexer gar nicht mehr läuft – zumindest werden bei Suchvorgängen nach Begriffen
im Text von Emails keine Treffer mehr unter neuen Emails gefunden.

Posted in KDE