Bernds Blog

Heute durfte ich die jüngste schwiegerelterliche Investition ausprobieren, das neue Navigationsgerät Medion GoPal 4425.

Erster Eindruck: So ein langsames Gerät habe ich schon lange nicht mehr gesehen. Knopf drücken ... sofort ein unüberhörbar lautes klacker ... warten ... nach belieben noch ein paar mal auf den Touchscreen hacken, es klackert jedes Mal ganz doll ... noch ein bisschen warten ... irgendwann tut sich was.

Zweiter Eindruck: Dennoch kann man damit leben.

Ich würde mir deutlich mehr Einstellmöglichkeiten wünschen. Z.B. gibt es beim "Tastenton" (das nervige klackern) nur die Entscheidung: aus, laut oder ganz laut. Man will den Ton nicht ausschalten, weil man dann gar nicht mehr weiß ob das Navi jetzt noch nachdenkt oder ob der Touchscreen den Finger oder Stift nicht bemerkt hat.

Zum Routing an sich kann ich wenig sagen, da ich nirgends hin gefahren bin wo es Kreuzungen gibt.

Die Linux-Kompatibilität ist schlecht. Eigentlich sogar unerwartet schlecht. Dank Windows-CE meldet sich das Gerät als undefinierbares irgendwas beim Linux-Kernel. Der weiß damit nichts anzufangen. In meinem Test hat das Gerät auch gleich alle 3 Sekunden neu verbunden, was im dmesg eine etwas unschöne Liste an Meldungen erzeugt.


Erfreulich in diesem Zusammenhang: Aufgezeichnete Tracks werden als GPX auf der SD-Card gespeichert. Die zu erhalten ist also sehr unproblematisch.
Ebenso mit den Kartendaten. Also ja, es sind schon alle auf der SD-Card installiert, aber die Installation besteht auch nur darin, normale Dateien auf eine normale SD-Card zu kopieren. Das ist erfreulich einfach und funktioniert unter jedem OS.

Heute habe ich einen weiteren Linux-PC an eine Kundin ausgeliefert. Hier wurde ich letzte Woche gerufen, da der PC beim hochfahren immer Scandisk angeworfen hatte und das sich in einer Endlosschleife festgefressen hatte.

Ergebnis einer schnellen Diagnose mit der System-Rescue-CD: Auch hier war die Festplatte schlicht und einfach kaputt. Die Geräuschkulisse war zwar nicht besonders beängstigend, aber deutet auch in diese Richtung.

Da nach Austausch der Festplatte sowieso eine Neuinstallation ins Haus stand, habe ich auch hier die obligatorische Frage gestellt: "Für was brauchst du denn den Computer alles?" Da sich auch da schnell abzeichnete, dass die offensichtlichen Vorteile eines Linux-Systems (Kinder machen nicht versehentlich das System kaputt, keine ernsthaften Viren-Probleme) durch kein haltbares Argument zu entkräften waren, konnte ich auch hier deutlich machen, dass die Kundin mit einem Linux-System besser beraten ist.

Vor einigen Tagen wurde ich zu einem Kunden gerufen, der Probleme mit seinem "Server" hatte. In anführungszeichen deshalb, weil es sich um einen Arbeitsplatz-Rechner handelte, der in der Ecke stand und ein paar Freigaben im Netz publiziert hat.

Die Probleme des Servers waren schnell erkennbar, die ersten Sektoren der Festplatte waren komplett hinüber. Da sowieso eine neue Festplatte und damit eine Neuinstallation nötig war, habe ich gleich vorgeschlagen, das bisher eingesetzte Windows durch einen einfachen Linux-Server zu ersetzen. Windows-Dateifreigaben sind damit auch kein Problem und die Backups auf den im "Server" verbauten DVD-Brenner zu sichern dürfte mit K3B keine Probleme bereiten.

Ich entschied mich für Ubuntu 6.06 LTS. Das ist zwar schon etwas älter, wird aber noch eine Weile supported. Ich denke mal, in einigen Tagen kann ich dann gleich auf die neue 8.04 LTS aktualisieren. ich warte noch, weil ich denke dass es bestimmt noch Migrations-Probleme geben kann.

Dort arbeitet jetzt also seit etwa einer Woche ein Ubuntu-Server mit Samba und KDE/K3B zum Brennen von DVDs. Die Festplatte wurde durch einen Software-RAID-1-Verbund ersetzt, damit ein Platten-Ausfall erstens schneller bemerkt werden kann und zweitens vielleicht reparabel bleibt.

Der Kunde hat jetzt noch ein wenig Spaß, die knapp 40.000 Dateien, die von der Datenrettungs-Software des PC-Fachhändlers knallhart durchnummeriert zurück kamen inhaltlich zu bewerten und zu sortieren.

Mit dem Linux-PC ist der Kunde allerdings zufrieden, auch wenn es in seinem Tagesablauf keinen nennenswerten Unterschied zu vorher gibt.

Hatte neulich bei einem Desktop-PC versehentlich die Tastatur in den Maus-PS/2-Port eingesteckt. Dank USB-Maus hab ich das Versehen nicht bemerkt.

Linux bootete auch ganz normal und es hat alles funktioniert.

Dann ist mir aufgefallen, dass das BIOS vor dem boot recht lange wartet und dann sagt "No keyboard found".

Linux hat die Tastatur aber trotzdem benutzen können. Als ob nichts wäre. Das find ich mal cool. :)

Hier mal kurz eine Erfahrung von heute, auf dass dies vielleicht andere finden, die sich in der selben Situation wiederfinden.

Gestern Abend teilten mir meine Eltern mit, dass ihr Rechner keinen Login mehr macht. Egal welcher Benutzer sich anmeldet, es bleibt immer sofort nach Verschwinden der Login-Maske alles stehen.

Nach einigem Debugging habe ich erstmal aufgegeben (es war spät) und heute früh weiter gemacht. Im Netz habe ich auch nicht wirklich was gefunden was passend war.

Der Lösung näher kam ich als ich ein simples xterm (mittels xinit bzw. .xinitrc) gestartet habe und dort dann "strace kwin" aufgerufen habe. Damit zeigte sich, dass der Prozess beim Locking auf die ~/.qt/.qtrc.lock stehen blieb. Da das NFS-Homedir schon manchmal beim Locking Probleme hatte, habe ich also getippt, es kann daran liegen. Laut rpcinfo -p war aber der nfslockd aktiv.

Über einiges trial und error und den entscheidenden Fund im Netz, dass das Locking Probleme macht, wenn der Server die IP-Adresse des Clients nicht auflösen kann, bin ich dann darauf gestoßen, dass der bind auf dem Server aus mir unerklärlichen Gründen sich nicht für die lokale reverse-Zone zuständig gefühlt hat. Ein einfaches Restart des bind hat genau das behoben, ab dann waren auch lokale reverse-lookups wieder möglich.

Der NFS-Server hat die Situation aber nicht verkraftet, einen restart-Versuch hat er immer mit einem Segmentation fault verweigert. Als ich dann aber den Server-Rechner neu gestartet habe, hat wieder alles wunderbar funktioniert. ohne das ich irgend etwas ändern musste.

Gestern habe ich vom neuen CAcert Assurer Test gelesen:

To meet the increased demands on quality assurance due to the CAcert Systems Audit, which is needed to be included in Mozilla’s browsers, CAcert has decided to initiate a Challenge for all for Assurers.
To be an Assurer, you will need to reach 100 assurance points, and you will have to pass the Assurer Challenge. The assurer challenge and training system called CATS is so now avaliable. Under http://wiki.cacert.org/wiki/AssurerChallenge you can find the infos how to join and participate.

Natürlich war ich gleich neugierig und habe den Test absolviert. Da ich schon mehrfach auf Fachmessen für das CAcert-Projekt am Stand tätig war, war der Test inhaltlich machbar. Zeitbedarf: deutlich unter 10 Minuten.

Das Problem an der Sache begann danach. Um das Zertifikat »Certified CAcert Assurer« als PDF ausgestellt zu bekommen, muss man eine möglichst verschlüsselte und zwingend mit seinem X.509-Client-Zertifikat signierte E-Mail an CAcert senden.
Und eben das ist mit KMail zur Zeit eine völlige Katastrophe. Zeitbedarf für mich: 1 Tag. ;-)

Der Reihe nach:
KMail benutzt gpgsm zur Verarbeitung von S/MIME. Das Frontend Kleopatra erlaubt das halbwegs komfortable Einfügen meines Zertifikats in gpgsm. Damit gpgsm überhaupt irgendwelche Zertifikate benutzt, will es eine CRL konsultieren:

gpgsm[12626]: can't connect server: `ERR 50331917 can't exec `/usr/bin/dirmngr': Datei oder Verzeichnis nicht gefunden'
gpgsm: can't connect to the dirmngr: IPC "connect" Aufruf fehlgeschlagen
gpgsm: certificate #04BD1F/1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: Die CRL konnte nicht geprüft werden: Kein Dirmngr
gpgsm: error creating signature: Kein Dirmngr <GPGSM>

CRLs sind eigentlich grundsätzlich sinnvoll, aber nicht bei gpgsm. Um nämlich bei gpgsm eine CRL zu benutzen, braucht man dirmngr. dirmngr braucht dazu aber auch OpenLDAP und man muss beide Kollegen manuell konfigurieren. Es gibt zumindest bei Gentoo keine dafür brauchbare Standard-Konfiguration.

Also will man bei gpgsm lieber auf eine CRL verzichten. Dazu muss man die Option disable-crl-checks in die Datei ~/.gnupg/gpgsm.conf eintragen.

Das nächste Problem sieht so aus:

gpgsm: Fingerprint=13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
gpgsm: DBG: BEGIN Certificate `issuer':
gpgsm: DBG: serial: 00
gpgsm: DBG: notBefore: 2003-03-30 12:29:49
gpgsm: DBG: notAfter: 2033-03-29 12:29:49
gpgsm: DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.4
gpgsm: DBG: SHA1 Fingerprint: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
gpgsm: DBG: END Certificate
gpgsm: after checking the fingerprint, you may want to add it manually to the list of trusted certificates.
gpgsm: Interaktives vertrauenswürdig-Markieren ist in gpg-agent ausgeschaltet
gpgsm: error creating signature: Nicht vertrauenswürdig <GPG Agent>

Der hervorgehobene Teil führt zum Ziel; man muss in der Datei ~/.gnupg/gpg-agent.conf die Zeile allow-mark-trusted eintragen.

Damit der gpg-agent das auch weiß, muss er neu gestartet werden. Überflüssig zu erwähnen, dass natürlich alle Programme, die den gpg-agent verwenden möchten auch neu gestartet werden sollten. Insbesondere gilt das bei KDE und KMail so, dass KDE neu gestartet werden muss.

Nach dieser Prozedur fragt gpg-agent bei Bedarf in kaputtem UTF-8 nach, ob das Zertifikat okay ist. Bestätigt man das, stürzt er erst einmal ab:

** glibc detected ** gpg-agent: free(): invalid next size (fast): 0x000000000065d190 ***
======= Backtrace: =========
/lib/libc.so.6[0x2ac27fb11b7d]
/lib/libc.so.6(cfree+0x76)[0x2ac27fb13896]
gpg-agent[0x415452]
gpg-agent[0x409649]
gpg-agent[0x428a38]
gpg-agent[0x40867c]
gpg-agent[0x407851]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2ac27fac01f4]
gpg-agent(realloc+0x1e1)[0x4053c9]
======= Memory map: ========
[...]

Beim nächsten Versuch sollte aber alles soweit klappen.


Damit konnte ich dann eine X.509-signierte und -verschlüsselte E-Mail senden.

Am nächsten Morgen ...

Heute war dann die Antwort von CAcert da, eine E-Mail mit ~140 KB. KMail sagt dazu:

Verschlüsselte Nachricht (keine Entschlüsselung möglich)
Grund: Nicht unterstütztes Verfahren
smime.p7m
S/MIME Encrypted Message

Ende der verschlüsselten Nachricht

Um dieses Problem weiter einzugrenzen habe ich die Datei smime.p7m gespeichert und mit gpgsm auf der Konsole versucht, weitere Infos einzuholen:

$ gpgsm -v --decrypt smime.p7m
gpgsm: unsupported algorithm `1.2.840.113549.3.2'
gpgsm: (Dies ist der RC-2 Algorithmus)
gpgsm: message decryption failed: Nicht unterstütztes Verfahren <GPGSM>

Eine kleine Internet-Such-Aktion später war klar: gpgsm unterstützt den alten RC2-Algorthmus schlicht und einfach nicht mehr. Thunderbird meint aber leider viel zu oft, diesen benutzen zu müssen.

Einzige mir sinnvoll erscheinende Lösung: Ich habe Mozilla Thunderbird installiert, dort meinen IMAP-Zugang konfiguriert, mein X.509-Zertifikat importiert und mit diesem die E-Mail geöffnet und das angehängte PDF gespeichert.


Nach knapp 10 Minuten Assurer-Prüfung und etwa einem Tag Kampf mit S/MIME bin ich nun also offiziell Certified CAcert Assurer Nummer 78. ;-)

Wer einen Account auf einem Server hat, dem kommt ab und zu das Verlangen, sich in der Fremde einfach mal dort einzuloggen um eine vertraute Umgebung vorzufinden. Seit es um den perfekt konfigurierten »mutt« zu benutzen, schnell im »screen« dem laufenden »irssi« zu zu schauen oder einfach um eine vorher dort hinterlegte Datei zu lesen.

Praktisch ist es natürlich gefährlich, sich von einem nicht vertrauenswürdigen Rechner auf einem Server einzuloggen. Bei der Eingabe des Passwortes auf einem fremden Rechner besteht immer die Gefahr, dass ein böswilliger Admin, ein Schäuble oder die Werbeindustrie einfach alle Tastendrücke aufzeichnet und damit sehr einfach das Passwort für den sicher geglaubten Account erhält.

Um diesem Problem generisch, also für alle fremden Rechner brauchbar zu begegnen, gibt es Einmalpasswörter. Mit diesem Verfahren (das in etwa den TANs vom PIN/TAN-Onlinebanking nahe kommt), gibt es eine Liste von Passwörtern, die jeweils nur einmal gültig sind. Sind die verbraucht, sind sie ungültig.

Unter unixoiden Systemen hat sich dafür das S/Key-System einen Namen gemacht. Es läuft auf den meisten Plattformen und lässt sich sauber z.B. mit PAM einbinden. Das Verfahren ist sehr transparent und die Einmalpasswörter lassen sich mit dem challenge, das vom Server beim Login genannt wird auch extern berechnen. So braucht man keine Papier-Liste mitnehmen sondern kann z.B. mit einem Java-fähigen Handy die Einmalpasswörter (auf einem vertrauenwürdigen Gerät) errechnen lassen.

Sehr edel das ganze, daher haben wir das auch gleich auf schokokeks.org eingebaut. Als Anleitung verweise ich hier mal auf unseren Wiki-Artikel zu Einmalpasswörtern.

Sei noch erwähnt, dass es mehrere Möglichkeiten gibt, S/Key unter SSH zu benutzen. SSH bringt eine solche Funktionalität selbst mit (Gentoo-USE-Flag skey) und es gibt alternativ dazu das PAM-Modul pam_skey.

Wir haben uns für letztere Variante entschieden, da die SSH-Lösung für den Benutzer weniger transparent ist. Bei SSH wird erst nach dem normalen Passwort gefragt und wenn dies leer oder falsch ist, dann wird nach dem S/Key-Einmalpasswort gefragt.

Bei pam_skey dagegen wird, sofern der Benutzer skey für sich aktiviert hat, gleich nach »S/Key response or system password« gefragt. Ist skey für den Benutzer nicht aktiviert, wird das PAM-Modul einfach übergangen und das normale Passwort abgefragt.

Gestern habe ich für die LUG Backnang einen Vortrag "Einführung in MySQL" gehalten.

Slides: PDF | ODP

Seit einiger Zeit habe ich ein Nokia 6230i und kann das auch per Bluetooth nutzen. Seit wenigen Tagen merke ich, dass gammu mit der Konfigurationsdatei die ich hier geklaut habe elendig langsam funktioniert. Jede Aktion dauert erstmal 2 Minuten für den Verbindungsaufbau.

Anhand der Gammu-Doku habe ich jetzt gesehen, dass mittlerweile offenbar ganz andere Namen für die selben Optionen eingeführt wurden. Nach einigen ausprobieren kam ich auf folgende Konfiguration:

[gammu]
model=6230i
port=00:17:E3:8E:FA:BC
connection=bluerfphonet
synchronizetime=no
use_locking=no
startinfo=no

Ergebnis: Der Verbindungsaufbau dauert jetzt ca. 3-4 Sekunden. nicht vollkommen perfekt aber erträglich.

Für die besserwissenden Hacker: Das Einschalten von use_locking erzeugt als User einen »permission denied«-Fehler. Das Einschalten von synchronizetime verstellt jedes mal die Uhr, da es nur Stunden und Minuten synchronisiert, nicht aber die Sekunden. Sekunden werden immer auf Null gesetzt. Nein, ich habe den Bug nicht reported.

Neulich konnt eich mich endlichmal aufraffen, mich um automatisiertes Onlinebanking zu kümmern um nicht immer alle Lastschriften für schokokeks.org manuell machen zu müssen.

Die gute Nachricht zuerst: Es geht einfacher als ich vermutet hatte. Ich benutze jetzt diese Kommandozeile:

aqbanking-tool debitnote --bank=60291120 --account=671279017 --rbank=12345678 --raccount=192837465 --rname="Kundenname" --value="123,00:EUR" --purpose="schokokeks.org" --purpose="Re-Nr. 1234, Kd-Nr. 05" --purpose="vom 2007-12-01" --force-check --exec

Diese Zeilen lasse ich mir von einem Script zusammen bauen, das die Daten der aktuell offenen Rechnungen aus der Datenbank liest.


Aber nun zum Ernst der Lage:
Ich hatte vor einiger Zeit in einem Blog-Posting dazu aufgerufen, dass man an das AqBanking-Projekt spenden sollte, damit der Entwickler die Spezifikationen für die neuen Volksbank-Karten kaufen kann.

Ich hatte diesen Aufruf nicht gelöscht oder geändert, weil ich der Meinung war, auch wenn diese Spezifikationen jetzt beschafft wurden, sollte der Autor einen Anreiz haben, den Code auch zu schreiben.

Jetzt allerdings muss ich diesen Aufruf entschieden zurücknehmen. Der Grund dafür ist hier zu finden:
http://www.aquamaniac.de/sites/aqbanking/user.php#aqbanking-cli

Eben dieses Kommandozeilen-Programm, mit dem ich obigen Kurztipp durchführe, wird aber der kommenden Generation der AqBanking-Schnittstelle kommerzielle Software werden und nicht mehr frei zur Verfügung stehen.

Natürlich ist das keine komplette Katastrophe, man kann (vermutlich) eines der auf AqBanking aufbauenden Programme als Vorlage für ein relativ minimalistisches, neues Kommandozeilen-Programm benutzen. Aber alleine das Vorgehen, dieses Programm ohne Erklärung, mit der fadenscheinigen Begründung "Da dieses Tool hauptsächlich professionell benutzt wurde, ist es nun nicht mehr frei verfügbar", kommerziell zu machen, finde ich sehr bedenklich.

Kombiniert mit der Erkenntnis, dass dieses Projekt nur Code annimmt, wenn die vollständigen und uneingeschränkten Verwertungsrechte an Martin Preuss übertragen werden, finde ich dieses Projekt ab sofort nicht mehr unterstützenswert. Trotz der unbestrittenen Leistung, die Martin Preuss in dieses Programm investiert, finde ich diesen Umgang mit Code-Beiträgen Dritter nicht angemessen für ein freies Projekt.