Monthly Archives: October 2008

Kontact – disconnected IMAP – lokale Virenscans

Posted on by

Disconnected IMAP

Da es bei Operationen mit größeren Mailmengen in der Vergangenheit immer wieder Probleme mit einer direkten IMAP-Verbindung von Kmail gab, setzen wir im produktiven Alltag Kontact/Kmail mit einer sogenannten “disconnected imap” – Verbindung ein.

Operationen über viele Mails sind z.B. Suchvorgänge oder Aktionen, die mit konfigurierten Mailfiltern im System zusammenhängen. Klassische Beispiele für Kmail-Filter ergeben sich aus der Einbindung lokaler Virenscanner und von Spamfiltern auf dem Mail-Client.

Die disconnected Imap-Struktur führt zu Replikationen zwischen Server und Client.

  • Vorteil: Operationen auf vielen Dateien (wie z.B. Virus Scans) laufen absturzfrei. Es gibt eine lokale Kopie der Inhalte abonnierter Folder. man kann auch “disconnected” arbeiten.
  • Nachteil: Lange Ladezeiten und intensive Plattenzugriffe beim Start von Kmail, um unsere vielen Mailverzeichnisse zu aktivieren und in temp. Zwischenspeiche rzu laden. Das ist aber ein einmaliger Vorgang – danach geht das Arbeiten flüssig.

Wo liegen die replizierten Mails lokal auf dem Client ?

Ein Systemadministrator wird regelmäßig auch die Mails in Replikationsverzeichnissen der Clients nach Mails untersuchen lassen wollen – und zwar ohne, dass er Kontact/Kmail überhaupt startet. Ferner ist er evtl. an speziellen und ausführlichen Scans ganz bestimmter Verzeichnisse interessiert und möchte für solche Verzeichnisse also “clamscan” oder andere Werkzeuge mit spezifischen Optionen starten. Für ihn ergibt sich dann die interessante Frage:

Wo legt Kmail eigentlich die Kopien der abonnierten Mailverzeichnisse ab? Antwort:
Unter

  • /home/USER/.kde/share/apps/kmail/dimap
  • /home/USER/.kde4/share/apps/kmail/dimap

Wie sieht die Verzeichnisstruktur aus ?

In diesen Verzeichnissen findet man (versteckte) “.”-Ordner für sämtliche “disconnected” IMAP-Verbindungen und deren abonnierte Ordner und Subordner. Die Namensgebung der Folder auf dem IMAP-Server spiegelt sich hierbei in der lokalen Namensgebung trotz bestimmter Zusätze von Kmail wieder. Zu Subordnern führen jeweils die Dot-Verzeichnisse, also die mit dem vorangestellten “.”. Der direkte Mail-Inhalt eines Ordners liegt jedoch immer in den dreigliedrigen Subverzeichnissen des Folders ohne (!) den Dot.

Beispiel: Der Ordner “Ralph” sei unter dem Ordner “Freunde” eingehängt. Zum Mailinhalt von “Ralph” führen dann beispielsweise die Pfade:

  • /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/cur
  • /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/new
  • /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/tmp

Trotz der kryptischen Namensgebung für die Mailfiles kann man dort die einzelnen Mails gezielt mit Kmail öffnen. Warum es diese komplizierte Struktur gibt und wozu sie verwendet wird, kann man leicht erraten. Wir gehen hierauf an dieser Stelle nicht weiter ein.

Wichtiger aber ist, dass man mit dieser Verzeichnisstruktur im Kopf lokale Virenscanner regelmäßig und gezielt auf bestimmte Ordner dieses Baums loslassen kann, ohne Kmail überhaupt zu aktivieren und dessen interne Klamav/Clamav-Filter zu bemühen.

Viel Spaß bei der periodischen Mail-Hygiene!

KDE 4.1 und Nvidia: Fehler bei GTK-Applikationen

Posted on by

Beim Arbeiten mit Openoffice (aber auch mit anderen GTK-Applikationen) treten immer wieder seltsame Artefakte auf, wenn der Input-Cursor im Office-Dokument aktiv ist und man die Maus aus dem Fenster der Applikation hinausbewegt:

Der Controlbar wird bei der Mausbewegung nicht schnell genug upgedated – im Ergebnis treten Verfälschungen der Icon-Farben oder schwarze Rechtecke auf. Manchmal wird das aktive Bild des Desktop im Hintergrund für einen Augenblick schwarz.

Andere User habend den Bug bestätigt. Er scheint generell bei GTK-Applikationen aufzutreten. Ferner scheint er spezifisch für Nvidia Karten und deren proprietäre Treiber zu sein.

Schade eigentlich – das ist manchmal schon störend. Speziell, wenn Entwickler mit Eclipse (auch GTK abhängig) arbeiten, irritiert so was schon gewaltig …..

KDE 4.1 – digitales Problemchen mit KsCD

Posted on by

Beim Ausprobieren von KDE 4.1.2 und seiner Komponenten stößt man schnell auf das Problem, dass die digitale Extraktion von Audio CDs nicht funktioniert.

Fehlermeldung: Keine CD
Das Programm meldet nach Umstellung des Flags “Digitale Wiedergabe nutzen” unter dem Konfigurationspunkt “Extras”, dass keine CD vorhanden sei. Und dies obwohl einen Augenblick zuvor die CD bei analoger Wiedergabe im gleichen Laufwerk noch erkannt worden war! Man stellt sich unwillkürlich die Frage, ob man überhaupt Audio CDs mit digitaler Datenübertragung abspielen kann.

Beruhigt werde ich dadurch, dass ich man einfach mal “xmms”, “amorak” oder “kaffeine” ausprobiere – dort funktioniert die Wiedergabe nämlich, wenn als zugehöriges Backend “xine” eingestellt ist. (Das ist mein persönlicher Default.)

Lösung: Xine als Backend für KDE 4.1 “Phonon”
Also interessiere ich mich dafür, welches Backend eigentlich für den Sound unter dem aktuellen KDE4.1 verwendet wird. Die zugehörige Info finde ich nach etwas Forschungsarbeit unter dem KDE-Hauptmenüpunkt:

“Configure Desktop->Systemverwaltung->Sound->Backend”.

Dort ist das aktuelle Backend für das vielgerühmte “Phonon”-System eingetragen. Phonon wird standardmäßig von allen KDE-Applikationen – so auch KsCD – genutzt. Das Default-Backend ist “Gstreamer”. Leider hat das aktuelle Gstreamer ein Problem mit der digitalen Extraktion, wie einem eine entspr. Recherche im Internet zeigt.

Auf der Suche nach anderen Backends wird man aber schnell fündig: Es gibt bereits ein “phonon-xine”-Backend ! Das zugehörige rpm ist bei Opensuse schon dabei. Nach der Installation taucht dann tatsächlich “Xine” in der Liste der mögl. Backends für Phonon auf.

Wählt man nun “Xine”, so funktioniert danach auch die die digitale Extraktion aus Audio CDs mit KsCD ! Ich wünsche viel Spaß beim Musikhören unter Linux und KDE 4.1!

P.S.: Ich verwende dazu in der Regel “amarok” – auch für Audio CDs ! Das Erlebnis mit KsCD kam nur vom Herumprobieren !

kscd41_1

KDE 4.1.2 – erster Eindruck zur Einsetzbarkeit

Posted on by

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

Posted on by

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!