Bernds Blog

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.

Als ich mein Nokia-handy 6230i gekauft habe, konnte ich sofort und ohne die von Hanno mehrfach beklagten Probleme mit dem Programm obexftp auf Handy-Speicher und die mitgelieferte 32-MB-MMC-Karte zugreifen.

Mit Erwerb einer neuen Karte mit 1 GB (Da Nokia denkt, das Handy kann mit solchen Karten gar nicht, bieten die solche Karten erst gar nicht an), trat bei mir aber das selbe Problem auf: Ich konnte auf Daten auf der Speicherkarte nicht mehr per obexftp zugreifen.

Gestern habe ich durch Zufall die Lösung gefunden: Aus irgendwelchen Gründen schafft es das Handy mit dieser Karte nicht, den Verzeichnistrenner semantisch zu verstehen sondern will da unbedingt einen Backslash (\) haben. mit der Nokia-Karte ging auch ein normaler Slash (/).

Ich lade jetzt also mit dieser Kommandozeile meine Daten herunter:

obexftp -b 00:17:E3:8E:FA:BC -o stream_20071207_1638.gpx -G 'Speicherkarte\Tracks\stream_20071207_1638.gpx'

directory-listing geht mit

obexftp -b 00:17:E3:8E:FA:BC -l 'Speicherkarte\Tracks'

Die Besonderheit dabei: obexftp versteht den Backslash nicht als Verzeichnistrenner. So geht z.B. das da nicht:
obexftp -b 00:17:E3:8E:FA:BC -c 'Speicherkarte\Tracks' -G stream_20071207_1638.gpx

Daher das Konstrukt mit -o, da sonst die Backslashes in den Dateinamen der Zieldatei übertragen werden.

Leider beziehen sich gefühlte 99,9% aller Bluetooth-unter-Linux-Anleitungen zur Zeit auf BlueZ 2. Gentoo bietet aber im unstable-Bereich seit langem BlueZ-3-Pakete.

Da dieser Versionssprung sehr umfangreiche Änderungen mit sich bringt, funktioniert das koppeln nicht mehr anhand der bisherigen Anleitungen. Insbesondere das Eingeben der PIN ist nicht ganz trivial unter BlueZ 3.

Daher hier der entscheidende Tipp:
Zuerst wie gehabt mit hcitool scan die Hardware-Adresse des Gegenüber herausfinden. Dann mit passkey-agent 1234 00:17:E3:8E:FA:BC die PIN in Stellung bringen (1234 ist die PIN, das dahinter die Hardware-Adresse des Gegenüber).

Sobald dieses Programm wartet, kann man mit dem anderen Gerät (z.B. Handy) die Kopplung einleiten. Nach Erfolgreicher Kopplung beendet sich passkey-agent von selbst und die PIN ist für das gekoppelte Gerät gespeichert.

(Ja, es gibt 2 oder 3 Gnome-Tools, die die PIN live abfragen, aber warum sollte man Gnome-Programme installieren wenn es auch ohne geht.)

Eigentlich ein alter Hut, aber heute gebraucht und nicht sofort ne passende Doku gefunden: Wie richte ich mein Hotplug/Udev/HAL so ein, dass ein bestimmtes Gerät immer am selben Mountpoint gemountet wird.

In meinem Fall eine externe Festplatte.

Vorbereitung: Erstmal sollte man wissen, wie man das Gerät identifizieren kann. Mit lsusb -v sollte sowas in der Art heraus kommen:

Bus 004 Device 011: ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter

Device Descriptor:

  bLength                18

  bDescriptorType         1

  bcdUSB               2.00

  bDeviceClass            0 (Defined at Interface level)

  bDeviceSubClass         0

  bDeviceProtocol         0

  bMaxPacketSize0        64

  idVendor           0x04b4 Cypress Semiconductor Corp.

  idProduct          0x6830 USB-2.0 IDE Adapter

  bcdDevice            0.01

  iManufacturer          56 Cypress Semiconductor

  iProduct               78 USB2.0 Storage Device

  iSerial               100 DEF107679C83

[...]

Besonders gut ist die "iSerial" geeignet, die Kombination aus idVendor und idProduct ist aber meist auch ausreichend (es sei denn man besitzt zwei baugleiche Geräte).

Beim Einstecken der Platte kommt udev zum Zug und erwartet eine Regel was er mit dem Gerät machen soll. Also habe ich eine neue Datei /etc/udev/rules.d/00_local.rules erstellt, die folgenden Inhalt hat:

BUS=="usb", KERNEL=="sd?1", SYSFS{serial}=="DEF107679C83", NAME="wechselplatte"

Bedenke: Ich möchte nur die Partition (sda1) ändern, die Platte selbst ist mir egal. Die Partition mit den Daten wird damit /dev/wechselplatte genannt.

Der nächste Schritt ist, HAL zu sagen, dass diese Partition bitte auch immer nach /media/wechselplatte gemountet werden soll. Dazu ändere ich die Datei /etc/hal/fdi/policy/preferences.fdi und füge kurz vor Ende diesen Block ein:

  <device>

    <match key="block.device" string="/dev/wechselplatte">

       <merge key="volume.policy.should_mount" type="bool">true</merge>

       <merge key="volume.policy.desired_mount_point" type="string">wechselplatte</merge>

    </match>

  </device>

Das war's, ab dann mountet z.B. KDE diese Platte automatisch nach /media/wechselplatte. Und ich kann digikam so einrichten, dass die Bilder dort gespeichert werden.

Ich nehme an, jeder, der unter Gentoo mal eine Netzwerkkonfiguration eingerichtet hat, die über den Trivialfall hinaus geht, stolpert über das irgendwie krude aber leistungsfähige Konzept des Netzwerk-Init-Scripts.

Leider ist die Doku dazu etwas mangelhaft und beschränkt sich nur auf einzelne Spezialfälle anstatt systematisch alle Möglichkeiten zu dokumentieren.

Heute habe ich eine lange Zeit damit verbracht, einen IPv6-Tunnel zu SixXS einzurichten. Bisher hatte ich das über ein eigenes init-script gelöst, aber das ist ja auch nicht das gelbe vom Ei.

Nach etwas herumprobieren kam ich dann auf eine funktionierende Konfiguration, deren Nennung ich auf den erweiterten Eintrag lege, damit das Layout durch preformatted text nicht zu sehr zerlegt wird.

Letzte Woche ist mir im Server meiner Eltern (Fax- und Dateiserver sowie Router und noch ein bisschen Kleinkram) die Festplatte gestorben und hat alle Daten darauf in die ewigen Festplatten-Jagdgründe genommen (Ja, ein nicht topaktuelles Backup war vorhanden).

Da ich also dann sehr schnell ein neues System gebraucht. Vorher war Gentoo installiert, aber da habe ich mich schon seit geraumer Zeit daran gestört, denn die Upgrades waren immer so heikel, da ich keinen physikalischen Zugriff darauf habe. Also wurde als Feldversuch der Server mit der Serverversion von Ubuntu-Linux eingerichtet. Installation war Ubuntu-Typisch in wenigen Minuten vorbei.

Die kranke Installationsprozedur von DJBdns war mir bekannt und hat mich folglich auch nicht so sehr schockiert. :)

Größtes Problem war, dass beim Aufstellen am späteren Einsatzort das NFS sich ganz komisch verhalten hat. Mozilla-Firefox und -Thunderbird ließen sich nicht starten weil sie angeblich schon laufen (nein, an den Lock-Files lag es nicht), KMail brachte wahllos Zugriffsfehler beim IMAP-Cache und ein sofort eingerichtetes Backup per rsync auf einen anderen Rechner führte oft zu der Meldung »stale NFS handles« und danach gab es nurnoch »permission denied« in dem Verzeichnis. Ein heraus und wieder hineinwechseln behebt das Problem kurzfristig.

Nach etwa einem Tag erfolgloser Suche und vielen Fragen an viele andere ratlose Leute, bin ich zufällig an diesen Bugreport herangestolpert.

Der dort vorgeschlagene Workaround hat bei mir funktioniert: Die Option »no_subtree_check« in alle exports-Einträge aufnehmen.
Bisher traten bei mir keine derartigen Probleme mehr auf.

Neulich erst mit Kubuntu erstmal ausprobiert, hatte ich auch gleich versucht, das auf meinem Gentoo-Desktop-Rechner laufen zu lassen.

Leider ist mir dabei nach dem Starten von compiz immer das System eingefroren. Warum weiß ich noch immer nicht, aber ich habe heute aufgrund mehrerer Anregungen einfach mal beryl ausprobiert. Und damit geht's!

Und von Beryl bin ich auch ansonsten sehr angetan. Das gconf-Feature von compiz hatte ich noch nicht getestet (da ich nicht erst das ganze gconf-Zeug installieren will), daher kann ich nur mit der Basiskonfiguration von compiz vergleichen. Aber man kann bei Beryl das einstellen, was ich wollte: Wobbeln nur bei Fenstern, nicht bei Tooltips, Passwort-Dialogen und so weiter.

Jetzt habe ich mal beryl als default-Window-Manager eingetragen, mal sehen ob ich das dauerhaft so lasse. :)

Neulich hat Hanno bei uns das MediaWiki auf eine neue Version geupdatet. Es war von 1.4.15 auf 1.6.8. Daraufhin war die Datenbasis mysteriös kaputt. Genauer gesagt haben manche Seiten gefehlt, manche waren steinalt und manche noch aktuell.

Zur Sicherheit habe ich dann von neuem die Update-Prozedur nochmal mit einem alten Backup der Datenbank nachgestellt und kam zu exakt demselben Ergebnis.

Nach einiger Zeit an Recherche in den Untiefen der Datenbank von MediaWiki habe ich festegstellt, dass sich einiges am Datenbank-Schema geändert hat. Bisher waren die Tabellen 'old' und 'cur' für die Inhalte zuständig, dort wurden die alten resp. die aktuellste Version jeder Seite aufbewahrt.

Im neuen Schema gibt es jetzt (eigentlich logischer) die Tabellen 'page', 'revision' und 'text', die Informationen zu den Unterschiedlichen Seiten, deren Versionen und den entsprechenden Texten speichern. 'page' verlinkt dabei immer auf die aktuelle Revision einer Seite.

Das Debugging hat nun ergeben, dass der update-Wizzard von MediaWiki aus irgendwelchen unerfindlichen Gründen die Datenbank nicht korrekt konvertiert hat. Es wurden Seiten vergessen oder alte Versionen als aktuell markiert.

Als Lösung habe ich ein Programm geschrieben, das die alte 'cur'-Tabelle ausliest und im neuen Datenbank-Schema eine neue Version jeder Seite mit dem Inhalt aus der alten Tabelle erstellt.

Der Einfachkeit halber konvertiere ich nur Artikel im Namespace 0, also normale Artikel.

Ich habe einen LaserJet 5M, wie schon irgendwann mal hier erwähnt. Der gute ist per PostScript an mein Netzwerk angeschlossen und wird per CUPS benutzt.
Schon seit kurz nach dem Kauf habe ich das Problem, dass der Drucker manchmal und, wie ich fand, nicht reproduzierbar, den Job einfach abgebrochen hat ohne, dass im CUPS-Logfile oder am Druckerdisplay irgend ein Grund zu finden war. Ein kurzes "Processing Job" und dann der Rücksprung auf "Ready".

Wenn ich die Postscript- oder PDF-Datei dann auf den Server kopiert habe und dort ein "lpr" getätigt habe, hat es geklappt. Vielleicht war dies der Grund warum ich der Sache nicht so eifrig nachgegangen bin. Heute jedoch hat das Phänomen bei Nici auch Einzug gehalten als die Datei vom Server gedruckt werden sollte.

Einige Debug-Sessions später hatte ich (mit dem selben Postscript-Ausgangsmaterial) im Cups plötzlich einen Unterschied, der die Misere erklären konnte. Und zwar wurde bei Nici immer die PostScript-Option "Duplex=None" mitgegeben, bei mir nicht.
Die Frage war nun, warum ist das so und wer setzt diese Option. Per User!?

Antwort: ~/.lpoptions
Dort stand Duplex=None hinter dem Drucker-Eintrag. Hat KDE gesetzt.

Leider scheint der Drucker ohne Duplex-Einheit mit allem außer "Duplex=Notcapable" Probleme zu haben. Vielleicht verwirft er es, da die Duplex-Einheit diese Befehle auswerten müsste.

Jedenfalls lag es daran und ich hoffe, dass ich in diesem Eintrag genug Suchbegriffe eingestreut habe, sodass andere mit diesem Problem meine Lösung finden.