Bernds Blog

Seit langem sind mir Besucher-Tracker ein Dorn im Auge. Daher sind Domains wie www.etracker.de und google-analytics.com seit einiger Zeit bei mir im lokalen DNS-Server gesperrt, so dass diese aus meinem lokalen Netz nicht mehr aufgerufen werden können.

Leider wird grade etracker oftmals so penetrant eingesetzt, dann man einfache Unterseiten oder Downloads nicht mehr aufrufen kann, wenn deren Seite nicht mehr erreichbar ist.

Daher habe ich mir jetzt einen lokalen "Proxy" für dieses Problem erstellt. Das Setup ist simpel:

• Ein lokaler DNS-Resolver wird so konfiguriert, dass er für den betreffenden Host die Adresse eines eigenen Webservers zurückliefert.


• Der Webserver erhält einen neuen VHost, der für die Hostnames der betreffenden Websites verantwortlich ist.


• Ein CGI-Script liest die URL aus dem Aufruf-Parameter und sendet eine Weiterleitung an die betreffende Adresse ohne dass irgendwelche Statistiken zentral gespeichert werden.

Nachfolgend meine dafür verwendeten Konfigurationen und Scripte.

Seit geraumer Zeit haben sich bei uns neben einer beachtlichen DVD-Sammlung auch einige Filme angesammelt, die z.B. vom Fernsehen aufgezeichnet wurden.

Ich bin dagegen, für solche Filme krampfhaft ein Original-Cover zu suchen bzw. die DVD kaum vom Original unterscheibar zu machen. Im Gegenteil, ich möchte die Chance nutzen, die Filme dann einheitlich, sachlich und erkennbar zu positioniren.

In unserer lokalen Installation von VideoDB haben wir alle Filme erfasst. Sowohl die Kauf-DVDs als auch die selbst aufgezeichneten.

Um aus den dort hinterlegten Daten automatisch Cover zu erzeugen, habe ich mir gestern ein kleines Script zusammengebastelt.
Teile des Sourcecodes stammen aus einem anderen Projekt, daher auch die unsinnige Aufteilung auf zwei Dateien. Das Script ist aus der Not entstanden und so sieht es auch aus. Aber es dürfte leicht sein, daraus was eigenes zu erstellen.

Python-Code ist zugänglich unter https://svn.bwurst.org/software/dvdcover/, Lizenz: Public Domain.

Als Dateneingabe fungiert ein XML-Export (von phpMyAdmin) der "videodata"-Tabelle aus der VideoDB-Datenbank.
Ausgabe sind einzelne PDF-Dateien für die einzelnen Cover.

Nachdem ich jetzt doch von einigen Leuten weiß, die meinen greylisting-Filter bei sich einsetzen, kann ich das auch grade mal hier announcen... ;-)

Es gibt davon eine neue Version. Es gibt einen ziemlichen Bruch, es wird jetzt MySQL anstelle von SQLite als Backend benutzt. Das liegt daran, dass ich vor habe, eine selektive Whitelist (»Mails an diese Adresse bitte in den nächsten 10 Minuten nicht greylisten«) für unsere Kunden zu ermöglichen. Dazu muss es eine gemeinsame Datenbank für das webinterface und das greylisting geben, was hiermit geschehen ist.

Die offizielle Release-Seite enthält auch ein detaillierteres Change-Log.

Peinlicherweise habe ich erst ein paar Minuten nach dem Release festgestellt, dass die neue Version von courier, für die ich grade ein ebuild erstellt habe, eine kleine API-Änderung hat. ich habe mit einem Bugfix-Release der Version 2.0.1 darauf reagiert.

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

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.

Gestern hat mir Hanno mitgeteilt, dass er beim Aufräumen einige »ältere Backups« gefunden habe, die auch Daten von mir enthalten.

Es geht um meine alten, damals in Turbo-Pascal programmierten Programme. Ich habe vor einigen Jahren mein eigenes Backup dieser Daten gefunden, allerdings feststellen müssen, dass der CD-Rohling wohl defekt ist und daher das (»solid«) RAR-Archiv etwa die Hälfte der Daten komplett versemmelt hat. Es gibt de facto keine source-codes mehr von diesen Programmen und die Binaries ließen sich auch nicht starten.

Jetzt, Dank Hannos Backups habe ich immerhin wieder lauffähige Binaries und kann voll Stolz screenshots meiner damaligen Killerapplikation »geb« präsentieren. :)
Interessant dabei: Ich habe die Programme vor Bekanntwerden des Turbo-Pascal-Bug geschrieben und kompiliert, sie sollten auf aktuellen Rechnern also nicht mehr laufen. Unter dosbox tun sie aber ohne Probleme.


Dazu gab es auch noch ein grafisches Frontend:


Leider gibt es keine funktionierende Version von geb 2.0, das hatte nicht nur ein grafisches Frontend sondern einen grafik-Modus, da war dann alles grafisch bedienbar.

Heute habe ich beschlossen, dass ich dem Gästebuch unserer Ferienwohnung mal dringend einen Spamfilter verpassen muss.
Die letzten Tage hab ich insgesamt mindestens 5 Einträge gelöscht, die nur aus Links zu Sex- oder Viagra-Seiten bestanden.

Also habe ich (im Gegensatz zu Chris) einfach einen Link-Zähler eingebaut. Einträge mit mehr als 2 Links im Text werden als Spam eingestuft und abgelehnt.

Ich hoffe damit jetzt erstmal wieder Ruhe zu haben. Natürlich ist die Funktion "spamfilter($text)" schön ausgelagert und kann jederzeit um weitere Erkennungen erweitert werden.