Kai's Kram

Ich konnts dann doch nicht lassen. Bei näherer Betrachtung wars dann auch nur mittelschwer, Claws crypto beizubiegen. Und dann gehts auch ganz gut. Nur ehrlich, Leute: Otto Normal hat keine Lust 5-7 config-Dateien zu basteln, statt einfach auf zwei Knöpfe zu drücken.

Das Geheimnis von gpg lag übrigens in den Konto-Einstellungen, in die ich nach dem Aktivieren der Plugins nicht mehr rein gekuckt hatte.

Jetzt fehlt mir nur noch die „Edit as new“-Funktion aus den TB, dann könnte ich mal ernsthaft damit arbeiten. Wobei die sich zur Not dadurch darstellen lässt, dass man die betreffende Mail in die Entwürfe kopiert. Nicht sehr komfortabel, aber geht.

Nach den warmen Empfehlungen meiner Kommentatoren habe ich heute Claws noch mal etwas gründlicher getestet. Dabei habe ich das Problem der Identitäten mal außen vor gelassen – es ist ein reines Bequemlichkeitsproblem – und den zweiten Knackpunkt untersucht, der den Thunderbird- Konkurrenten bisher das Genick gebrochen hat: Kryptografie.

Und da gings dann leider steil bergab. Wären die reine Einrichtung des Kontos benutzerfreundlich und klar war, ist die Unterstützung für GPG und SMIME genau so rudimentär wie die von Kmail. SMIME bedarf zur Einrichtung noch größerer Verrenkungen als KMail und PGP war zwar schnell eingerichtet, ist aber unbenutzbar. Das Plugin ist nicht einmal in der Lage, aus mehreren secret keys den korrekten auszuwählen und lässt auch keine manuelle Auswahl zu.

Ich kenne ja das alte Unix-Mantra, das es besser ist, viele kleine Programme zu haben, die jeweils eine Sache richtig können, als ein großes, das alle Sachen nur halb kann. Aber eine signierte EMail zu verschicken ist nur ein Task und den sollte mein Mailer können, ohne das ich noch 10 andere Programme umständlich nach schlechten bis gar keinen Anleitungen konfigurieren muss. Dafür hab ich einfach mal keine Zeit.

Und da ich die fehlende Kryptografie-Unterstützung anderer Mailer unter anderen Systemen kenne, muss ich feststellen, dass das größte Hindernis für eine sinnvoll verschlüsselte und signierte Email-Kommunikation zwischen Frau Mustermann und Herrn Normal die mangelnde Umsetzung kryptografischer Standards in den entsprechenden Clients ist. Hier dann mal ein großes Lob an die Programmierer von Thunderbird und Enigmail. Ihr mögt in mancher Hinsicht grandios an meinen Wünschen vorbei programmieren, aber wenigstens das ist optimal gelöst. War ja damals schon der Grund, warum ich von KMail zu Thunderbird gewechselt bin.

Jedenfalls Sind meine Abwanderungsgelüste mal wieder etwas abgestumpft. TB ist scheinbar doch der am wenigsten schlimme Mail-Client, jedenfalls für meine Bedürfnisse. Claws kuck ich mir dann mal in ein zwei Jahren noch mal an. Da es offensichtlich sehr aktiv weiterentwickelt wird und in vieler Hinsicht einen durchdachten und sympathischen Eindruck macht baut ja vielleicht noch jemand die Kryptografie zu Ende.

Da Debian Squeeze nun endlich (fast) fertig ist, hab ich heute mal dem ersten halbwegs produktiven Server geupdatet, um schon mal zu kucken, ob auch ein etwas komplexeres Setup (lenny-xen-dom0 mit zwei squeeze-domUs) sauber durchläuft. Tat es natürlich nicht, was aber auch meiner noch etwas unzureichenden Erfahrung mit Xen geschuldet seien dürfte.

Damit nicht andere Leute in die Fallen tappen, die ich mitgenommen habe, hier mal ein kurzer Überblick:

Erster und wichtigster Punkt bei allen upgrades auf squeeze: Achtet auf Meldungen, das Firmware fehlen könnte! Der neue Debian-Kernel ist frei von proprietären Firmware-Blobs, was ich ideologisch gut aber teilweise unpraktikabel finde. Beim upgrade ist es aber ein lösbares Problem. Es müssen eben die entsprechenden Pakete aus non-free installiert werden. Bei einer Neuinstallation ist das erheblich ekliger, da es eben auch Netzwerkkarten betrifft, was es etwas schwierig macht, an die benötigte Firmware zu kommen.

Das zweite potentiell verhängnissvolle Problem ist, dass der neue Kernel nicht mit xen-3.2 kann. Beim normalen upgrade bleiben aber die 3.2er Pakete installiert und das erste boot-setup, das update-grub kreiert hat war natürlich eine Kombi aus Kernel 2.6.32 und Xen 3.2, die beim starten hängen blieb. Da freut man sich dann über das vorhanden sein einer Rescue Disc oder einer seriellen Konsole.

Nach dem das bare metal wieder tat ging es an das Kernel-Upgrade für die domUs. Hier lauert dann die nächste Falle: Der neue Kernel findet kein /dev/sd* mehr. Hier müssen in allen configs für die domUs die /dev/sd’s durch /dev/xvd’s (also z.B. /dev/sda1 durch /dev/xvda1) ersetzt werden und in der domU muss die fstab korrigiert werden.

Ab da gabs nur noch Kleinigkeiten. In den domUs müssen die Module für den neuen Kernel nachinstalliert werden, grub kann nicht installiert werden, weil er mit /dev/xvda nix anfangen kann (bootet aber trotzdem), es gibt kein /dev/rtc mehr (gabs das vorher?), und die Uhr ging gruselig vor. Letzteres lag an dem fix für die noch viel schlimmer falsch gehende Uhr unter Xen 3.2, der unter anderem darin bestand, in der domU.cfg „extra=“clocksource=jiffies““ einzutragen, was jetzt dazu führte, dass die Uhr pro Minute 5 Minuten vor ging.

Alles in allem lösbare Probleme, die allerdings ohne Rescue System mit einer Fahrt ins Rechenzentrum geendet hätten.  Aber gut, alle anderen Systeme sind domU oder bare metal. Da wird mir das nicht mehr passieren.

Ich wünsche jedenfalls allen viel Spaß mit Squeeze und herzlichen Dank an alle Beteiligten für das am wenigsten bekloppte Betriebssystem der Welt.