Bernds Blog

Ab und an hat man eine Idee, welche Anwendung der Menschheit noch gefehlt hat und will dieses Manko umgehend selbst beheben. Oft kommen dabei gute Ideen bzw. Anwendungen heraus.

Schlecht ist allerdings, wenn die Umsetzung dann doch genau das nicht macht was sie verspricht.

So gesehen beim einfachen Web-Service DownForEveryoneOrJustMe. Gibt man dort eine Adresse ein, die erreichbar ist, ist das eine nette Bestätigung, dass es funktioniert.

Gibt man aber eine Adresse ein, die einen Timeout verursacht (was ja ab und an vorkommt, wenn eine Seite wirklich down ist), dann erhält man nach einer entsprechenden Wartezeit einen Fehler von Google, dass auf der Website ein Fehler aufgetreten sei. Also der Timeout des bei Google betriebenen PHP-Scripts kommt früher als der HTTP-Timeout beim Versuch die Seite zu testen. :)

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.

Diese Woche erschien die neue Version der Handy-Java-Software »Mobile Trail Explorer«, Version 1.8.

Mit dieser Software und einem Bluetooth-GPS-Empfänger ist es möglich, GPS-Tracks aufzuzeichnen. Das größte manko der Vorversion war, dass die Software gelegentlich beim Speichern abstürzte (die berüchtigte "OutOfMemoryException") und damit der komplette Track weg war. man durfte also nicht vergessen, nach spätestens 500 Trackpoints zu speichern, da sonst die Datenmenge zu groß wurde.

Nicht so mit der neuen Version!!

Jetzt gibt es die Option "GPX-Stream". Dabei wird sofort begonnen, die Datei zu schreiben. Die Software schreibt Punkt für Punkt in die Datei und hält nicht einfach alles im Speicher. Dadurch gibt es keine Wartezeit und kein Speicherproblem nach Abschluß der Aufzeichnung.

Kurzanleitung:

• Menü
• Manage Trails
• Option
• New GPX stream
• Dann kommt die Frage des Telefons ob auf die Speicherkarte geschrieben werden darf
• Danach noch »Start/Stop recording«
• Nach Abschluß der Aufzeichnung (»Start/Stiop recording«) kommt der üblicher Speichern-Dialog, mit der zusätzlichen Option am Ende »Close GPX Stream«
• Der Name der resultierenden Datei beginnt mit »stream_«

Besonders erwähnenswert:
Wenn das Programm abstürzt oder versehentlich beendet wird, geht nichts verloren! Beim nächsten Start fragt das Programm ob der alte GPX-Stream fortgesetzt werden soll. tut man das nicht (»Forget about it«), hat man aber auch trotzdem noch eine Datei, bei der man nur das XML manuell schließen muss, die Punkte sind dennoch alle drin.

Noch nicht getestet habe ich, ob in diesem GPX-Stream auch die Waypoints drin sind.

Nach diesem ersten Eindruck der neuen Version: Prädikat »Absolut empfehlenswert!«

Ja, die wesentlichste Neuerung war, dass das Program OSM-Tiles als Hintergrund anzeigen kann und damit die eigene Route live visualisieren kann. Aber ohne vernünftige Daten-Flatrate und ohne schnellere Verbindung ist das für mich etwas sinnlos. Ich freu mich einfach über die neue GPX-Stream-Funktion.

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.

Mein kleines Gewerbe läuft jetzt seit zwei Jahren. Um möglichst wenig Probleme mit den Behörden zu bekommen, habe ich mich dazu entschlossen, auch ohne spezielle Schulung oder sowas einfach alles relevante aufzuschreiben. Das soll die Steuererklärung einfacher machen.

Im ersten Jahr habe ich dazu eine einfache Tabelle benutzt in die ich alle Daten eingetragen habe. Das war auch noch nicht viel Arbeit, einfach alles eintragen und immer wieder ein paar Zeilen zusammenzählen lassen um die Beträge zu ermitteln. Da die nach dem jahr fällige Steuererklärung mich vor enorme Probleme gestellt hat (was kommt denn jetzt eigentlich wo rein?), habe ich mir von Chris die Steuer-Software T@x von Buhl-Data empfehlen lassen. das ist eine Windows-Software, die im Wine-Bundle daherkommt und grade mit dem mitgelieferten Wine auch erstaunlich reibungslos funktioniert. Damit ging die Steuererklärung gut und das Finanzamt hat das von dem Programm ausgedruckte Formular anstandslos akzeptiert. Das fand ich klasse, hat mir alleine dafür mindestens einen Tag Arbeit erspart.

Über das Jahr weg konnte ich auch jeweils die Buchungen in das Programm eintragen, mit dem Ziel, jetzt im neuen Jahr noch nichtmal mehr die Beträge manuell eingeben zu müssen. Außerdem konnte ich so die monatliche USt-Voranmeldung bequem aus dem Programm heraus machen.

Leider ist die Produktstruktur dieser Software so, dass man nur jeweils einen Steuer-Jahrgang damit erledigen kann, für die nun fällige Erklärung 2006 braucht man die neue Version für 2007. Da das Programm grade bei der Steuererklärung gute Dienste geleistet hat, wollte ich also gleich die neue Version bestellen.
Doch dann die Enttäuschung. Es gibt keine Linux-Version. Schnell den Support angeschrieben und das da als Antwort bekommen:

vielen Dank für Ihr Schreiben. Sehr gerne werden Ihre Fragen zu dem
Programm "t@x 2007 Linux download" beantwortet.

Bisherige Ausgaben von tax waren mit dem Windows-Emulator Wine unter
Linux lauffähig. Mit den aktuellen Programmversionen von Wine gibt es
jedoch technische Schwierigkeiten, die im Quellcode von Wine zu beheben
sind. Alle bisherigen Anstrengungen, auch unter Einbeziehung der
Programmierer von Wine, waren jedoch vergebens.

Für das Veranlagungsjahr 2006 ist daher keine Linux-Ausgabe der Software
t@x erhältlich.

Vielen Dank für Ihr Verständnis.

Oha. Das ist deutlich.
Da lässt man sich einmal auf proprietäre Software ein und dann sowas!

Nun zur nächsten Frage: Was nun? Ich haben jetzt ein Jahr mit Tabellenkalkulation gemacht und das skaliert irgendwie nicht gut. Mit den damals ~2-3 Einträgen in Monat war das ok, aber jetzt kommen schon öfter mal 30 Einträge in Monat, da wird das auch mal umständlich.
Eine spezielle Software habe ich nicht gefunden (Komm mir keiner mit Gnucash, das benutze ich zum Banking, aber für eine so einfach Buchhaltung / EÜR ist es mir zu umfangreich. Wenn man damit richtig arbeiten will, muss man doppelte Buchführung machen).

Meine Lösung wäre jetzt eine eigene Datenbank zu machen. Oder kennt denn jemand ein geeignetes System, das eine einfache EÜR macht und ein paar Auswertungen bieten kann? Umsatzsteuer-Voranmeldung ist übrigens nicht mehr Pflicht, die fällt jetzt endlich weg weil meine Steuern beinahe weniger sind als die Bankgebühren. :)

Ich programmiere zur Zeit (schon lange immer so nebenbei) an meinen Python-Bibliotheken zur Datenbank-Ansteuerung. Nichts allgemeines sondern sehr speziell auf die Zwecke des Keks zugeschnitten.

Die letzten Tage bin ich richtig schön weitergekommen, habe meine Bibliotheken ausgebaut, meine Objekte so weit es geht abstrahiert und auch Schreibzugriff auf die Datenbank damit ermöglicht. Eigentlich hat alles geklappt. Nun wollte ich das Frontend noch schnell darauf umstellen. Eigentlich kein Problem, denn ich muss ja nur die Attribute des Objekts füllen und commit() aufrufen.

Nur war dann beim Speichern der Daten immer nur die Hälfte in der DB. Beim debuggen war alles da, beim Testen aller Klassen war alles da. Nur nach dem Erzeugen der Objekte und vor dem DB-Zugriff muss irgenwas schiefeglaufen sein.

Des Übels Wurzel: Ich habe einen kleinen aber feinen Teil in Pythons Dokumentation übersehen: Klassenvariablen. Eine Klassenvariable (die man in der Klassen-Definition einträgt, anstatt sie mit self.var in einer Methode zu setzen) gilt für alle Objekte der Klasse und ihrer Subklassen gemeinsam. D.h. solange man mit einem Objekt arbeitet gibt es kein Problem. Erst wenn man mehrere Objekte der selben Klasse hat und an einer solchen Variable was ändert, dann passieren merkwürdige Dinge.

Auch wieder was gelernt. ;-)

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.

Für ein System, das kein Netzwerk und nur kontrollierten physischen Zugriff hat, brauche ich ein Setup, das passwortlos arbeitet. Der User will das so und ich sehe bei den Rahmenbedingungen auch keinen Sinn in einem Passwort.

Also prinzipiell kann ich mit »passwd -d [user]« das Passwort löschen. Das klappt dann für den Login und auch für sudo. Mit »echo '[user]:' | chpasswd --md5« kann man das Passwort auch auf einen leeren String setzen, dann muss der User zwar noch ein Passwort eingeben, kann aber einfach Enter drücken.

Problem aber: Die KDE-Bildschirmsperre lässt sich mit leeren Passwort nicht beenden.

Da es sich um Kubuntu handelt, wollte ich das auf der Kubuntu-de-Liste ansprechen, in der Hoffnung, dass das Problem bekannt ist und es vielleicht einen Workaround gibt.

Ok, nach einigen Flamereien ("Wenn du ein Linux ohne Passwörter willst, nimm einfach Windows") habe ich das gesteckt und auf der gentoo-Liste nachgefragt. Eine wirkliche Lösung war auch nicht dabei, aber ein Denkanstoß. Zusammen mit dem KDE-Bugtracker bin ich darauf gestoßen, dass man »kcheckpass« SetUID root setzen muss. Normale Passwörter kann er auch so überprüfen, leere Passwörter allerdings nicht.
Bei Ubuntu war zudem noch das PAM-Modul pam_unix mit dem Parameter »nullok_secure« ausgestattet, sodass leere Passwörter nur von sicheren ttys (eingetrag in /etc/securetty) erlaubt werden. Das muss natürlich auch raus, da der X-Desktop kein sicheres tty ist. Ich habe einfach »nullok« stattdessen eingesetzt.

Ich mag meine Distri manchmal. Manchmal auch weniger. Heute ist so ein Fall von »weniger«.

Seit ein paar Tagen steht das upgrade von openldap auf einem meiner Server an. Es ist zugegeben nur ein Lern- und Test-Setup, wird aber produktiv für den System-Login meiner Eltern benutzt. Das ebuild spuckt beim kompilieren aus, dass ich bitte vorher die Daten sichern und löschen soll.
Ok, ich halte mich ja gelegentlich an Anleitungen, daher habe ich das getan. Nachdem der Kompiliervorgang etwa eine halbe Stunde gedauert hat, hat die neue Version mysteriöse Dinge gemacht und ließ sich nicht starten. Ich weiß nicht was vorgefallen ist, aber nachdem ich selbst nach einer Stunde noch keinen Schritt weiter war, habe ich beschlossen die alte Version wieder zu installieren um endlich wieder einen System-Login zu ermöglichen. Nach Installation der alten Version lies sich der daemon wieder hübsch starten, aber es war keine Verbindung von nirgendwo her möglich. Auch hier wieder etwa eine Stunde debugging, dann habe ich aufgegeben und die Login-Daten in die /etc/passwd und co eingetragen.

Vielleicht wäre es mit dem Hinweis im heute veröffentlichten GWN einfacher gewesen. Ich weiß es nicht.
Zumindest stören mich zwei wesentliche Dinge:

1. Der GWN, der mir versucht, einige Hürden zu zeigen kommt hinterher, nachdem das Paket schon als stable markiert wurde!
2. Die offizielle Anleitung im ebuild (und die einzige Möglichkeit es auf normalem Weg installiert zu bekommen) erfordert eine downtime von über einer halben Stunde!

Ungeachtet dessen, dass ich die alte Version vorher hätte mit quickpkg in ein binpackage verwandeln können, es kann doch nicht sein, dass das Herunterfahren eines Services und Löschen seiner Datenbank über die Dauer des Kompiliervorgangs der richtige Weg ist! Durch die Fehlersuche und das nochmalige Kompilieren kam ich so auf eine stolze downtime von 2-3 Stunden.

Ich muss nicht erwähnen, dass zudem nach dem upgrade elementare Systemkomponenten nicht mehr funktiniert haben weil die LDAP-library nun anders hieß? Ein revdep-rebuild hat ebenfalls nochmal ne Stunde gedauert.

In diesem Punkt erlaubt sich Gentoo leider immer wieder böse Patzer, so dass ich kaum widersprechen kann, wenn jemand behauptet, Gentoo sei nichts für einen Server. Ich werd es weiter betreiben, aber ich bin auch immer wieder entrüstet über die Leichtigkeit mit der hier laufende Systeme getötet werden...