Linux

Seit einer Weile hatten wir vor, anstelle von Bildern fürs Fotoalbum auch mal ein Fotobuch drucken zu lassen. Das scheiterte bisher immer daran, dass die üblichen Verdächtigen eine reine Windows-Software anbieten, die noch nicht mal unter Wine zum Laufen zu bewegen ist.

Vor etwa 2 Wochen fand ich allerdings einen Anbieter, der explizit mit der Unterstützung von Linux wirbt. Das hat mich gleich fasziniert und ich beschloss, dieses Angebot wahrzunehmen. Am Montag kam dann das fertige Buch an.

Da ich sehr zufrieden war, nenne ich gerne Namen: Es handelt sich um die Firma fotobuch-profi.de, die das Java-Programm Photux benutzt.

Die Java-Software läuft auf vielen Plattformen, ich konnte und wollte nur Linux/x86 und Linux/amd64 testen. :) Für den einfachen Anwender gibt es zwei Stolpersteine, die der Hersteller noch ausräumen sollte.

1. Die Speicher-Beschränkung von Java. Normalerweise hat unter Linux jedes Java-Programm nur 64 MB RAM zur Verfügung. Das mag im letzten Jahrtausend bei der Erfindung von Java eine sinnige Idee gewesen sein, heute ich das zumindest für eine Bildbearbeitung wesentlich zu knapp. Das Programm selbst kann das Limit logischerweise nicht verändern, man muss dies in der Start-Kommandozeile machen. Der Händler nennt zwar die passende Kommandozeile, liefert für Linux aber eine blanke JAR-Datei aus. Ein einfaches Script zum Starten der Anwendung mit den richtigen Parametern könnte hier echt weiter helfen.

2. Das Programm erlaubt die Verwendung diverser Bildformate. Bindet man jedoch ein PNG mit indizierten Farben ein (PNG kann beides, indizierte Farben und RGB), so schlägt die Übertragung zur Druckerei fehl ohne eine eindeutige Fehlermeldung. Es hat mich einige Stunden experimentieren gekostet um diesen Umstand herauszufinden. Wandelt man das PNG in RGB um, klappt es.

Abgesehen davon lief alles reibungslos, die Designer-Software ist akzeptabel in der Bedienung (was nicht heißt, dass ich nicht Verbesserungsvorschläge hätte) und das Druck-Ergebnis exzellent (im Gegensatz zu meinem Display sind die Bilder etwas dunkler gedruckt worden. Das macht aber mein Farblaser hier auch, vermutlich ist mein LCD einfach etwas zu hell eingestellt).

Der Preis ist zwar nicht grade Dumping, aber die Qualität des Buches stimmt. Die Produktionszeit von etwa einer Woche (zzgl. Versand) ist auf der Internetseite gut dokumentiert und stört mich nicht.

Mein Garmin eTrex Legend kann im Lieferzustand nur Kartendaten bis maximal 2 GB Größe nutzen. Da man aus OSM-Daten sehr umfangreiche Karten erzeugen kann, tangieren aktuelle Europa-Karten diese Grenze bereits. Es ist also zu erwarten, dass mit weiterer Erfassung von Daten die Dateien größer werden.

Im neuesten Firmware-Update ist das Limit aber aufgehoben.

Dieses Update wollte ich also auf jeden Fall einspielen. Da ich bekanntermaßen kein Windows in Betrieb habe, gestaltet sich das aber schwierig. Vermutlich wäre das Update-Programm auch über Wine lauffähig gewesen, das habe ich nicht probiert. Da ich aus anderen Gründen neulich schon einmal ein Windows XP (Lizenz in Form der Microsoft-Steuer war ja beim Computerkauf eh dabei) in einem QEmu-Image installiert habe, benutzte ich das für das Firmware-Update.

Dazu kann man (wenn man den Parameter -monitor stdio angibt) auf der QEmu-Konsole ein USB-Gerät an das Gast-System durch reichen.
In meinem Fall sorgt der Befehl usb_add host:091e:0003 dafür, dass der Garmin eTrex durchgeschleift wurde. Das Update-Programm auf dem Gast-System erkannte dann auch das Gerät und startete das Update.

Kritisch: Während des Update-Prozesses trennt das Gerät ab und zu die Verbindung. Das erkennt man an folgenden Meldungen in der QEmu-Konsole:
husb: device 1.11 disconnected

Dann sollte man umgehend den obigen Befehl wiederholen, damit das Update fortgeführt werden kann.

Ich möchte niemandem empfehlen, das auf diese Art zu machen, aber wenn man die USB-Durchreichung schnell genug wieder herstellt, klappt das ganz gut.

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.

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.

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.