Linux

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.

Wie vor einer Weile schon einmal schrieb, hat mein Handy (oder obexftp, keine Ahnung wer schuld ist) leider besondere Anforderungen, wie man Dateien für den OBEx-transfer spezifizieren muss.

Da ich ein Freund der Konsole bin und daher meine GPX-tracks immer mittels obexftp auf meinen Rechner kopiere, ist das doch etwas lästig.

Aber jetzt gibt es Abhilfe. ;-)

Um mir diese Aufgabe zu erleichtern, habe ich ein kleines Python-Programm erstellt, das zuerst obexftp aufruft um ein Verzeichnis-Listing zu erhalten und dann alle Dateien mittels obexftp -G herunterläd (-G bedeutet, Dateien werden auf dem Handy gelöscht).

Zur Verwendung muss zuerst das Python-Modul »ElementTree« installiert werden. Danach müssen die Bluetooth-Hardware-Adresse des Gegenüber und der OBEX-Datei-Pfad im Script eingetragen werden.

Download: obexget
Lizenz: GPL >= 3

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.

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 habe vor einiger Zeit mal versucht, meine Bankgeschäfte unter Linux zu machen und dazu ein Kartenlesegerät des Typs »Chipdrive micro USB« gekauft. Hanno hat das kurz vor mir gemacht und von guten Erfahrungen berichtet.

Leider hat es sich dann so ergeben, dass kurz vor dem Kauf meines Leser die Ansteuerung von einem eingebauten serial-Converter auf ein reines USB-Gerät umgestellt wurde. Und eben dieses war leider nicht mehr mit freien Treibern zum Laufen zu bewegen. An meinem System hatte sich das Gerät damals mit den IDs "0000" gemeldet, was weiteres Debugging erschwerte.

Über diese Erfahrungen hatte ich auf meiner Website berichtet.

Neulich wurde ich von einem netten Mitarbeiter der Firma SCM (Hersteller des besagten Lesegeräts) angesprochen, dass diese Information nicht mehr stimme und wenn ich zur Verifikation ein aktuelles Gerät haben möchte, könne er mir dieses zuschicken. Klar, habe ich nichts dagegen. :)

So kam es, dass ich am Freitag per Post ein solches Gerät bekam. Über's Wochenende habe ich damit etwas getestet und heute dann die Seite überarbeitet. Ich will nicht verleugnen, dass ich die Aktion mit dem stillschweigenden Relabeling des Geräts nicht toll fand, aber die Reaktion der Firma SCM war hier wirklich vorbildlich und da das Gerät jetzt mit einem freien generischen Treiber benutzt werden kann, habe ich die Passage auf meiner Website sehr gerne passend geändert.

Ich hatte vor einiger Zeit den Tipp erhalten, dass man mit »Disconnected IMAP« (oder auch »Cached-IMAP« genannt) bei KMail das Verhalten hin bekommt, das ich so lange gesucht habe: IMAP aber ein Cache, der mir erlaubt, zumindest die neuesten X Mails jederzeit schnell und ohne Netzverbindung verfügbar zu haben.

Gehört, getan, habe ich mein IMAP-Konto erstmal mit einem Rotations-script ausgestattet (alle Mails älter als 1 Monat wandert in eine andere Mailbox) und das was noch da geblieben ist dann per »Disconnected IMAP« eingerichtet. Erst einmal klang das alles recht gut, die Mailbox war extrem schnell da, man kann ständig jede Mailbox öffnen, auch wenn grade eine andere abgeholt wird.

Die erste Ernüchterung kam sehr schnell: Das Abrufen der Mailbox dauerte etwa 20 Mal so lange wie vorher. Jeder Ordner für sich dauerte fast so lange wie sonst der komplette Baum. Das liegt daran, dass KMail nicht nur nach neuen Mails schaut sondern auch lokale Änderungen (gelesen, ...) hochladen muss.

Ich habe als automatisches, periodisches Abholen eingestellt, sodass ich immer alle Mails sehe. Da man auch während des Abholens andere Ordner schon lesen kann, ist das kein Problem.
Was aber etwas störend war: KMail bzw. der ganze Rechner geriet etwas in Stocken, wenn der IMAP-Abruf-Vorgang lief. Erst fiel das gar nicht sonderlich auf, dann aber immer öfter (man erkennt irgendwann den Zusammenhang ;) ). Als ich bemerkt habe, dass man während des Abrufens keine Mail mehr vernünftig verfassen kann (das Fenster war oft für ~10 Sekunden reaktionslos), habe ich den Entschluss gefasst, wieder zurück auf normales IMAP zu stellen.

Da meine Mailbox jetzt sowieso relativ klein ist, geht auch da das Abrufen sehr flott.

Fazit: Disconnected-IMAP ist eine schöne Idee, funktioniert auch prinzipiell ganz gut, muss aber noch deutlich besser auf Nebenläufigkeit optimiert werden.