Monthly Archives: August 2012

Kmail 4.9 – Datenverlust durch Spamfilterung

Posted on by

Bin letzte Woche unter Opensuse 12.1 auf KDE 4.9 umgestiegen, was mir generell ganz gut gefällt. Besonderes Augenmerk habe ich jedoch wieder mal auf KMail im Zusammenspiel mit IMAP-Servern und (OX-) Adressbüchern gelegt.

Hierzu erste Eindrücke:

Zuerst das Positive:

Mit etwas Mühe und viel Geduld kann man Kmail 4.9 im Gegensatz zu Kmail 4.8.2 – 4.8.4 x nun sogar davon überzeugen, dass die automatische Adress-Suche und -Vervollständigung beim Erstellen neuer Mails halbwegs funktioniert. (Als Linux Fan einen solchen Satz schreiben zu müssen, ist eigentlich peinlich!) Zur “address autocompletion” etwas mehr in einem späteren, separaten Beitrag.

An die Mängel bei der Adress-Autocompletion hatte man sich als Anwender ja schon seit einiger Zeit gewöhnt (siehe https://bugs.kde.org/show_bug.cgi?id=259949 ). Damit und zugehörigen Workarounds kann man leben

Nun aber das Negative:

Der Suchdialog funktioniert nach wie vor nicht:
Der Kmail-Suchdialog zum Suchen von Mails ist nach wie vor nicht benutzbar. Bei mir werden nun gar keine Treffer mehr angezeigt. Das ist fast besser als das, was früher am Schirm erschien. Also: Das Einzige, was bzgl. der Suche von Mails wirklich funktioniert, ist unter Kmail die Schnellsuchleiste oberhalb der Anzeige der Mailliste. Alles andere funktioniert nicht oder nicht richtig. Dieser Punkt allein disqualifiziert Kmail im Moment für den professionellen Einsatz.

Leider, leider, leider … Viel schlimmer ist aber noch Folgendes: Im Moment besteht die Gefahr eines (ggf. umfänglichen) Datenverlustes durch Spamfilterung an KDE’s E-Mail-Client.

Spamfilter eliminieren Mailinhalte:
Meine Frau hat gestern Abend Bogofilter für die Spam-Elimination auf ihrem Kmail eingerichtet. Hauptgrund ist, dass sie auch Mailkonten auf externen IMAP-Servern und nicht nur unserem eigenen benutzt. (Auf unserem eigenen Server werkelt Spamassassin und macht dort einen guten Job). Der Einsatz von Bogofilter unter Kmail sah anfänglich auch gut aus. Mails, die bereits als gelesen markiert waren und danach der Spamfilterung unterzogen wurden, wurden richtig und wie in den Filtereinstellungen vorgesehen behandelt. Die große Überraschung kam jedoch am nächsten Morgen:

Aus allen neuen Mails, die von Bogofilter als Spam eingestuft wurden, wurde der Mail-Body entfernt. Sprich: Diese Mails waren danach leer!

Dies betraf alle neuen ungelesen Mails – egal aus welcher IMAP-Quelle. Das ist keineswegs nur ein Darstellungsproblem am (K-)Mail-Client: Die Mails werden über Akonadi als leere Mails mit den jeweiligen IMAP-Server “abgeglichen”. Ein kurzer Test zeigte übrigens, dass das gleiche Problem unter Kmail auch bei Einsatz des Perl-basierten Spamassassin auftritt.

Irgendwie führt die Modifikation des Mailheaders durch Bogofilter/Spamassassin am Kmail-Client dazu, dass im Zusammenspiel von KMail – Akonadi – IMAP-Server die Mailinhalte von Mails gelöscht werden, die noch nicht als gelesen markiert wurden.

Nebenbei: Ein weiterer Bug ist der, dass diese derart malträtierten Mails nicht – wie in den Filterregeln vorgesehen – in einen SPAM-Ordner verschoben wurden. Und Spamassassin braucht beim Durchkämmen von größeren Verzeichnissen unglaublich viel CPU. Aber was solls … ich rege mich nicht mehr auf – sonst kommt gleich wieder ein Entwickler und macht mich mit Nachdruck darauf aufmerksam, dass seine Arbeit freiwillig ist und nicht bezahlt wird. (Das finde ich auch schlimm, meine aber trotzdem, dass SW-Qualität primär etwas mit vernünftigen Change Management und Release-Prozessen zu tun hat …)

Jedenfalls finde ich: Das Entfernen des Mailinhalts macht nicht nur keinen Spaß – das ist ein echtes Problem ! Und es ist keineswegs neu – wie ich nach ein wenig Recherche lesen musste:
https://bugs.kde.org/show_bug.cgi?id=295484

Ich habe die Spamfilterung bei meiner Frau jedenfalls vorläufig abgestellt. Sie hofft jetzt auf bessere Zeiten und sucht mal wieder nach Alternativen …

Um böse Überraschungen zu vermeiden, kann ich jedem Kmail-Anwender im Moment nur raten, Spam-Filter vor einem Einsatz wirklich ausführlich zu testen und auf umfängliche Trainingsläufe mit produktiven Mailfoldern zu verzichten – bis man sicher ist, dass nichts passiert.

Fazit:
Seit der Einführung von Akonadi, Nepomuk, Strigi reißen die Probleme mit Kmail für die Anwender leider immer noch nicht ab.

PDT 3.0./3.1 unter Eclipse 4.2 “Juno” langsam

Posted on by

Im Zuge eines neuen PHP-Projektes habe ich mal die neue Eclipse-Version 4.2 Juno zusammen mit den verfügbaren PDT-Modulen ausprobiert.

Sowohl mit dem alten PDT-Modul, das für Indigo bereitsgestellt wurde, als auch mit einer “Nightly Build”-Variante in der Version 3.1.X. Siehe http://wiki.eclipse.org/PDT/Installation_3.1.x. Leider gibt es ja im Moment noch keine offizielle neue PDT-Version für Juno (obwohl laut Release-Plan eigentlich vorgesehen). Daran arbeitet wohl noch das ZEND-Team.

Ich habe bei dem Experiment mit Juno meine PHP-Projekte nicht neu aufgebaut, sondern den entsprechenden Workspace statt unter Indigo einfach unter Juno geöffnet. Das führte erwartungsgemäß zu einem vollständigen Neuaufbau des Workspace sowie einer vollständigen Neuvalidierung aller Projekte.

Beim Arbeiten in der “PHP-Perspective” sind mir dann vor allem zwei Dinge aufgefallen:

1) Träge Reaktionen der Oberfläche beim Arbeiten mit Reitern: Die Reaktionen des Eclipse-UI auf Tab/Reiter-basierte Aktionen zu Dateien, die im PHP-Editor geöffnet wurden, sind im Vergleich zu Indigo sehr langsam. Dies gilt im Besonderen dann, wenn man bereits mehrere Sub-Windows für die gleichzeitige Ansicht mehrerer Dateien geöffnet hat. Auch der Aufbau neuer Subfenster ist trotz der nun farbigen Anzeige der Umrisse während der Aktion viel zu träge.

2) Extrem langsame PHP-Editor-Reaktionen bei gleichzeitig geöffnetem “Outline-View”: Vor allem aber gibt es unakzeptabel große Zeitverzüge, wenn man Zeilen in einer Datei markiert, für die gleichzeitig der Outline-View geöffnet ist. Beim Arbeiten mit Dateien zu Klassen, die viele Methoden aufweisen, ist das eine Standard-Situation. Irgendwie fühlt sich das Arbeiten mit der Eclipse-GUI dann jedoch leider so an, als ob Eclipse beim Markieren jeder Zeile eine vollständige Validierung der gesamten Datei vornimmt. Es dauert ewig, bis der Editor der Mausbewegung folgt.

Trotz vieler schöner Dinge scheint mir Eclipse Juno mit den aktuellen PDT-Varianten also noch nicht für die tägliche Entwicklungsarbeit einsetzbar.

Ich entwickle jetzt übergangsweise wieder mit Eclipse Indigo – und nach der Erfahrung mit Juno kommt mir die “alte” Umgebung wirklich wie ein Schnellzug vor.

Aber ich bin optimistisch und warte ein wenig ab – sicher sehe ich mir Eclipse Juno bald wieder mal an, sobald PDT in einer neuen Version bereitsteht.

Opensuse – Fehlermeldung zu ata_piix

Posted on by

Auf meinem Laptop fiel mir nach ein paar Updates auf, dass folgende Botschaft gleich am Anfang des Bootvorgangs erscheint:

FATAL: Module ata_piix not found
FATAL: Error running install command for ata_piix

Faktisch geschieht dies bereits während des ersten Ladens der Module von der “initrd”.

Die Meldung hört sich beunruhigend an, sie es in meinem Fall aber nicht. Denn trotz der Meldung läuft auf meinem Laptop, den ich nun schon ein paar Jahre unter Opensuse betreibe, alles ganz normal. Was also ist der Hintergrund der Fehlermeldung?

Checkt man auf dem gebooteten System die geladenen Module, so findet man, dass ein Modul “ata_piix” tatsächlich nicht geladen ist.

lap3lux64:~ # lsmod | grep ata_piix
lap3lux64:~ #

Dennoch zeigt ein Blick in die System-Konfiguration mittels “hwinfo” oder Yast2’s “Hardware-Information” sehr schnell, dass für die Harddisk und auch ein an Bord befindliches DVD-Laufwerk der benötigte Treiber “ata_piix” eingesetzt wird:

lap3lux64:~ # hwinfo | grep ata_piix

   0170-0177 : ata_piix
   01f0-01f7 : ata_piix
   0376-0376 : ata_piix
   03f6-03f6 : ata_piix
   bfa0-bfaf : ata_piix
   14:   244245    0    IO-APIC-edge    ata_piix
   15:   223066    0    IO-APIC-edge    ata_piix
   ata_piix: /devices/pci0000:00/0000:00:1f.2
   ata_piix: module = ata_piix
i/o:0 0x0170 – 0x0177 (0x08) “ata_piix”
i/o:0 0x01f0 – 0x01f7 (0x08) “ata_piix”
i/o:0 0x0376 – 0x0376 (0x01) “ata_piix”
i/o:0 0x03f6 – 0x03f6 (0x01) “ata_piix”
i/o:0 0xbfa0 – 0xbfaf (0x10) “ata_piix”
irq:0 14 ( 244245) “ata_piix”
irq:0 15 ( 223066) “ata_piix”
   ata_piix: /devices/pci0000:00/0000:00:1f.2
   ata_piix: module = ata_piix
   E: DRIVER=ata_piix
<7>[ 0.846528] ata_piix 0000:00:1f.2: version 2.13
<6>[ 0.846545] ata_piix 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
<6>[ 0.846551] ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
<7>[ 0.846596] ata_piix 0000:00:1f.2: setting latency timer to 64
<6>[ 0.846951] scsi0 : ata_piix
<6>[ 0.847068] scsi1 : ata_piix
Driver: “ata_piix”
Driver Modules: “ata_piix”
Driver: “ata_piix”, “sd”
Driver Modules: “ata_piix”
Driver: “ata_piix”, “sr”
Driver Modules: “ata_piix”
lap3lux64:~ #

Die Ursache dafür ist, dass man bei dem aktuellen Kernel 3.1.10-1.16, den Opensuse anbietet, das benötigte “ata_piix”-Modul nicht mehr extra laden muss. Es ist bereits in den Kernel einkompiliert. Dies erkennt man an der Konfigurationsübersicht für den aktuellen Kernel. Unter Opensuse findet man die entsprechende Datei unter dem Verzeichnis “/boot” :

Die Datei “boot/config-KERNELVERSION” – in meinem Fall “/boot/config-3.1.10-1.16-default” – enthält Informationen zur aktuellen Kernelkonfiguration, die die Opensuse-Leute für das System vorgesehen haben. U.a. findet man:

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_SVW=m
nCONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m

Der Treiber ist also bereits in den Kernel intergriert und nicht als nachzuladendes Modul vorgesehen.

Zur Beseitigung der ata_piix-Fehlermeldung genügt es deshalb, das Treibermodul aus der Datei

/etc/sysconfig/kernel

zu entfernen. Betroffen ist die Zeile:

INITRD_MODULES=”ata_generic processor fan ata_piix”

aus der man den Eintrag “ata_piix” schlicht löscht.

Am besten macht man das unter Opensuse allerdings mit YasT2’s “Editor für /etc/sysconfig”, da dabei gleich auch noch die “initrd” neu erstellt wird. Siehe im sysconfig-Editor die Einstellungen unter

“System >> Kernel >> INITRD_MODULES”

.
Ansonsten muss man den Befehl “SuSEconfig” ausführen und “auch noch den Befehl mkinitrd” absetzen.

Bei den anschließenden Bootvorgängen ist die Meldung dann verschwunden.

Ich denke, das ganze “Problem” ist dadurch entstanden, dass das Linux-System auf dem Laptop mehrere Male auf die neueste Opensuse-Version upgegradet wurde. Die ursprünglichen Einstellungen zur “initrd” aus einer Zeit, als das ata_piix-Modul noch separat nachgeladen wurde, bleiben dabei offenbar unverändert.

Also keine Panik, wenn die obige Meldung auftaucht !