Linux

Manchmal regt mich meine NVidia-Karte im Notebook echt auf. Nicht nur, dass ich nur mit dem Binary-Treiber unter Linux Features wie 3D-Beschleunigung oder Suspend-to-RAM nutzen kann, nein, leider ist der auch noch nicht kompatibel mit der Standardarchitektur zum Setzen von Bildschirmauflösungen etc. Dafür braucht man ein spezielles Tool von NVidia, welches nur im Klicki-Bunti-Modus bedienbar ist. Nix mit Skripten und so (zumindest zum großen Teil). Macht alles nix, kann ich mich gerade noch dran gewöhnen. Was aber wirklich nervig ist, ist die Weigerung des Tools einen Wechsel des externen Monitors zu erkennen. Wenn man nach dem Booten einmal einen Monitor erkannt hat, dann lässt es sich durch nichts und niemanden davon überzeugen einen Wechsel desselben zur Kenntnis zu nehmen. Das ist normalerweise kein Problem: ich arbeite mit einem 1680x1050-Monitor, welche üblicherweise als erster erkannt wird und wenn ich dann mal zu einem Beamer wechsele, dann muss die Auflösung eben von Hand runtergestellt werden (sowieso sinnvoll, da viele Beamer interessanterweise eine höhere Auflösung melden, als sie nativ darstellen). Wenn ich jetzt allerdings mal ausnahmsweise einen Beamer nach dem Booten ranhänge und dann später zum großen Monitor wechseln will, dann hängt man mit der niedrigeren Auflösung fest. Nach einiger Rumprobiererei hab ich jetzt eine Methode, die das ohne X-Server-Neustart zu beheben scheint:

1. nvidia-settings starten ohne externen Monitor dran. Das Programm wird unter "X Server Display Configuration" das bereits früher erkannte Gerät (bspw. den Beamer) zeigen. Dort auf "Detect Displays" klicken. Das Programm wird sich beschweren, dass der externe Monitor entfernt wurde und fragen ob der auch aus der Liste der verfügbaren Displays entfernt werden soll. Soll er. Auf "Apply" klicken, bestätigen und das Programm beenden.
2. Monitor anstecken und nvidia-settings wieder starten. Wenn man jetzt unter "X Server Display Configuration" (wo definitiv nur ein Display zu sehen sein sollte, nämlich das interne!) auf "Detect Displays" klickt, dann sollte der richtige externe Monitor sichtbar werden (und damit auch die passenden Auflösungen zur Auswahl vorliegen).

Warum das so kompliziert ist fehlt mir im Moment jegliche Idee. Evtl. sitzt hier das Problem auch einfach mal wieder vor dem Monitor.

Interessante Erfahrung gerade: seit einem Neustart meines Jabber-Servers funktioniert der Kontakt dorthin nicht mehr aus meinem privaten Netz. Ein wenig Sucherei später stellt sich heraus, dass mein DSL-Router (bzw. der darauf laufende DNSMasq) DNS-Queries vom Typ SRV sperrt. Dazu muss man wissen, dass Jabberclients aus dem Domainpart der Jabber-ID mittels eines DNS-Queries ermitteln, auf welchem Server man sich einloggen muss. Sie fragen einfach nach _xmpp-client._tcp.domain.part mit RR-Type SRV und verbinden sich zu dem in der Antwort stehendem Server. Klappt das nicht lösen sie den Domainpart normal auf und verbinden sich dort hin. Nun hatte ich bisher nach einigen Umbauarbeiten immer noch eine Umleitung laufen, die ich aber im Zuge eines Systemupdates mal entfernt habe. Damit klappt das nicht mehr, dass man sich einfach auf die IP aus dem A-Record des Domainparts verbinden kann und den Jabberserver erreicht. In der Welt draußen kein Problem, gibt es doch einen passenden SRV-Record, der verrät, wie's geht. Dummerweise war mein DNSMasq hier mit der Option filterwin2k konfiguriert, was ihn dazu veranlasst (unter anderem) SRV-Records wegzufiltern. Nimmt man die raus funktioniert alles. Wieder was gelernt...

Ich wollte aus verschiedenen Gründen meiner Linux-Installation mal einen kompletten Neustart gönnen und Kubuntu Karmic Koala frisch aufsetzen. Dabei wollte ich allerdings vorzugsweise darauf verzichten mein aktuell 83 GB schweres Home-Directory komplett aus dem Backup wieder einspielen zu müssen. Gedacht, ... fast getan. Backup wurde natürlich vorher gemacht (ich bin ja nicht wahnsinnig. Jedenfalls nicht wesentlich mehr, als üblich. Außerdem hatte jemand in der näheren Umgebung letztens erst den Fall, dass sämtliche Daten zwar noch da, aber dank Festplattenverschlüsselung mit kaputtem Keystore nicht mehr zugreifbar waren. Das wollte ich mir natürlich ersparen.

Erstmal dazu, wie meine Platte grob aussieht:

/dev/sda
  |
  +---sda1 (/boot)
  +---sda2 (dm-crypt-Volume)
       |
       +---ec_root (/)
       +---ec_swap (swap)
       +---ec_home (/home)

Soweit, so unpraktisch. Speziell /home sollte unbedingt erhalten bleiben. Erster Anlauf: ganz naiv den Installer gestartet und geschaut, was er so erkennt. Klappt natürlich nicht. Der sieht sda2 und interessiert sich kein bischen für die Innereien. Ok, zweiter Anlauf: Situation herstellen, die dem Installer erlaubt die Innereien zu erkennen:

cryptsetup luksOpen /dev/sda2 sda2_crypt
lvm vgchange -a y

Das erste öffnet das verschlüsselte Volume, das zweite aktiviert die darin enthaltene Volume Group und alle logischen Volumes innerhalb dieser. Das ganze macht man am besten in einer zweiten Konsole, während der Installer gerade auf Nutzereingaben wartet (bspw. wenn er sich grad aufregt, dass er kein Netz findet). Danach kann man die Installation gemütlich weiterlaufen lassen und der Installer wird beruhigt die Volumes erkennen, so dass man in der manuellen Partitionierung (alles andere wäre Unsinn) alles entsprechend wieder zuweisen kann, wie es sein soll.

Mir ist hier noch ne Kleinigkeit unangenehm aufgefallen: sda2 wird aus irgendeinem Grund als Swap eingestuft. Aus Sicherheitsgründen habe ich das komplett rausgenommen (also auch nicht als Crypto-Volume definiert), was zur Folge hatte, dass hinterher etwas Handarbeit angesagt war.

Wenn die Installation durchgelaufen ist (auch das kann ein Problem sein, wenn das CD-Laufwerk auf einmal I/O-Error wie Kekse verteilt...), dann muss man noch einige kleinere Anpassungen machen um das System bootfähig zu machen. Was ist das Problem? Dadurch, dass das Crypto-Volume von Hand geöffnet wurde und der Installer so nichts davon weiß, fehlt der entsprechende Eintrag in der /etc/crypttab des frisch installierten Systems. Das wiederum führt dazu, dass das initrd nichts über die Verschlüsselung weiß und nicht nach dem Passwort fragt, was wiederum den Bootprozess einfach stillstehen lässt. Blöd. Eine Lösung muss her...

Im Prinzip isses einfach: man macht das System von Hand bootfähig. Man mountet noch im laufenden Installersystem /dev und /proc mittels -o bind nach /target/dev und /target/proc (/target ist der Punkt, wo der Installer die Platte einhängt. Wenn nicht: einfach selbst machen), wechselt mittels chroot /target ins installierte System, passt die /etc/crypttab entsprechend an (sprich: man trägt in meinem Fall /dev/sda2 passend ein. Eventuell muss man die /etc/fstab auch noch anfassen, wenn man schonmal da ist.), ruft update-grub und update-initramfs auf, wechselt wieder raus, macht alle Mounts rückgängig und rebootet. Wenn man großes Glück hat, geht's danach. Wenn nicht, dann ist Fehlersuche angesagt.

Für diese Sucherei hab ich heute dann doch etwas gebraucht. Vor allem immer unter der Prämisse: bloß nüscht kaputtmachen, sonst musst du das doofe Backup zurückspielen. Mittlerweile läuft alles, nur eine Warnung beim Systemstart bzgl. des Einbindens von /home irritiert mich noch. Hat zwar keine Auswirkungen, aber das will ich auch noch rauskriegen. Später...

Kleine Nettigkeit über die ich gerade gestolpert bin. Mein PostgreSQL 8.3 weigert sich zu starten. Er meldet:

2009-08-16 16:12:55 UTC WARNING: could not create listen socket for "localhost"
2009-08-16 16:12:55 UTC FATAL: could not create any TCP/IP sockets

Die erste Zeile hat mich dann richtig raten lassen: wenn man mittels debootstrap ein Debian aufgesetzt hat, dann fehlt üblicherweise die /etc/hosts. Deswegen kann er localhost nicht auflösen und weigert sich, zu starten. Ergo: echo "127.0.0.1 localhost" >> /etc/hosts und schon sollte er wollen. Bei der Gelegenheit kann man auch gleich noch die IP des Servers auf den internen Namen mappen (bspw. echo "1.2.3.4 servername" >> /etc/hosts. Wenn man eh schonmal dran ist...

Man kann ja mittels OSMTracker während des Trackens Audioaufzeichnungen anfertigen um sich gewisse Sachen zu markieren (sehr praktisch zum Beispiel bei der Erfassung von Hausnummern). In JOSM geöffnet werden die Aufzeichnungen als kleine Icons in der Karte angezeigt und können via Klick abgespielt werden.

JOSM ist ja ein Java-Programm und will als solches in einer JVM laufen. Nun habe ich standardmäßig Suns JVM installiert (unter Kubuntu: sun-java6-jre). Die hat aus irgendwelchen Gründen Probleme mit der Audioausgabe (Meldung: "Audio device unavailable"). Längeres suchen und probieren brachte mich darauf, die OpenSource-Variante der VM zu installieren (wieder unter Kubuntu: openjdk-6-jre). Die kann Audio. Theoretisch. Praktisch besteht das Problem, dass sie den PulseAudio-Server mit installiert und damit die Audioausgabe endgültig kaputtspielt. Keine Ahnung, was genau das Problem ist. Der Effekt ist folgender: sobald die JVM (oder das Flash-Plugin im Browser. Die scheinen die gleiche Infrastruktur zu nutzen) eine Audio-Ausgabe machen will, startet im Hintergrund der PulseAudio-Server. Danach geht gar kein Sound mehr. Liest man ein wenig im Netz rum, dann hat dieses Programm den Ruf nur Probleme zu verursachen. Die übliche Empfehlung: deinstallieren. Hab ich gemacht. Hilft. Plötzlich geht sowohl in der JVM, als auch im Flash der Sound völlig problemlos. Wenn ich jetzt noch ne Ahnung hätte, wozu das Audioverhinderungsprogramm PulseAudio genau da ist...

Mit vereinten Kräften gerade rausgefunden: um auf die Dateien eines Windows-Mobile-Gerätes von Ubuntu (in dem Fall Karmic, sollte aber auch mit Jaunty gehen) aus zugreifen zu können ist das Paket synce-kio-rapip-kde4 notwendig. Dieses enthält den notwendigen KIO-Slave, der einem erlaubt auf das WM6-Gerät zuzugreifen. Dummerweise ist dieses Paket nicht in den Standardquellen vorhanden (weder bei Jaunty, noch beim kommenden Karmic). Man kann sich behelfen, indem man folgendes in der /etc/apt/sources.list nachträgt:

deb http://ppa.launchpad.net/synce/ubuntu jaunty main

Danach kann man das Paket installieren und durch die Eingabe von rapip:/ in die Adresszeile des Dolphin auf die Dateien des WM6-Gerätes zugreifen. Ja, auch unter Karmic muss man jaunty in der Zeile stehen haben. Für Karmic gibt es (noch?) kein eigenes Repository. Macht aber nix: die Version von Jaunty lässt sich problemlos installieren (zumindest im Moment. Jetzt bloss kein Update!).

So, jetzt aufgezeichnete GPS-Tracks von heute ziehen und wieder ein wenig was an OSM tun.

Uff, da hab ich mal wieder länger ringen müssen. Aus ominösen Gründen wollte ich mal wieder eine Instanz meiner bevorzugten Blogsoftware aufsetzen. Weil sich aber die Platte des Servers mittlerweile ganz gut mit Instanzen füllt, sollte diesmal eine Shared-Installation her, bei der sich früher oder später mal alle Instanzen eine Code-Basis teilen (weniger mangels Platz, sondern wegen des Pflegeaufwandes). Soweit der Plan...

Nun gibt es dafür eine Anleitung, über der dick und fett steht: "WARNING: THIS FEATURE IS EXPERIMENTAL!". Experimentell ist es in der Tat, vor allem wenn die Anleitung und meine Vorstellung davon, was gewisse Dinge bedeuten, aufeinander treffen. Wenn man dann noch zusätzlich mod_vhost mit in den Ring schmeißt, dann ist das Chaos fast perfekt. Aber von vorn.

Ziel der Aktion war folgendes: eine Subdomain blogs.example.com unter der man einfach und ohne Probleme neue Blogs anlegen kann. Dazu sollte nur eine Serendipity-Installation verwendet werden (kein Bock da mehrere zu pflegen). Gut, der Anfang ist einfach: mod_vhost ist schon aktiv, einen neuen VirtualHost im Apachen anlegen (ServerName blogs.example.com, ServerAlias *.blogs.example.com) und im DNS *.blogs.example.com auf die IP des VirtualHost zeigen lassen. In dem VirtualHost Ersetzt man nun noch DocumentRoot durch folgende Zeilen (vorausgesetzt die Bloginstallation liegt am Ende mal unter /home/blogs.example.com/:

UseCanonicalName Off
VirtualDocumentRoot /home/blogs.example.com/subdomains/%1

Nun kann man ganz einfach durch Anlegen eines neuen Verzeichnisses in /home/blogs.example.com/subdomains eine neue Subdomain anlegen. (Beispiel: test.blogs.example.com wird mit der Konfiguration auf /home/blogs.example.com/subdomains/test abgebildet). Ausprobieren, ob das Konstrukt funktioniert und dann weitermachen.

Nächster Schritt: die Installation von Serendipity. Man lädt das normale Package runter (die LITE-Installation bringt die Dateien nicht mit, die man für die Shared-Installation-Geschichte braucht) und entpackt es nach /home/blogs.example.com/s9y. WICHTIG: der Pfad MUSS als letzten Teil s9y haben. Entpackt man die Dateien standardgemäß, dann landen sie in einem neuen Verzeichnis namens serendipity. Dessen Inhalt muss man nach s9y verschieben. Der Pfad ist im Code hart verdrahtet. Wenn man das Verzeichnis anders benennt, dann darf man sich auf unerklärliche Internal Server Errors freuen.

Zuguterletzt muss man dem Apache noch sagen, wo er sich seine PHP-Dateien zusammensuchen soll. Tut man das nicht, dann findet der Deployment-Code (siehe unten) die Dateien der Shared Installation nicht. Dazu trägt man in den VirtualHost noch folgende Zeile ein (ob /usr/share/php und /usr/share/pear hier wirklich notwendig sind, weiß ich nicht. Eigentlich stehen die bei Debian im "Master Value" für include_path. Vielleicht weiß da jemand ja mehr...):

php_value include_path ".:/usr/share/php:/usr/share/pear:/home/blogs.example.com:/home/blogs.example.com/s9y:/home/blogs.example.com/s9y/bundled-libs"

Außerdem hilft es, wenn man dem Apache noch erlaubt die .htaccess-Dateien, die Serendipity so mitbringt auch zu interpretieren. Dazu muss man in den Block <Directory /home/blogs.example.com/subdomains>...<Directory> in der Apache-Config bei AllowOverride All eintragen. Damit darf die .htaccess innerhalb der Subdomain-Verzeichnisse alle möglichen Änderungen vornehmen. Wer das einschränken will muss rausfinden, was genau benötigt wird und das dann dort entsprechend angeben.

Nun kann man mit folgendem Skript recht einfach eine neue Bloginstanz anlegen:

#! /bin/sh

BASE_DIR=/home/blogs.example.com

if [ x$1 == x ]; then
        echo "Please supply a subdomain-name for the blog.";
        exit 1;
fi

mkdir /home/$BASE_DIR/subdomains/$1
$(
        cd /home/$BASE_DIR/subdomains/$1

        cp -r ../../s9y/deployment/* .

        ln -s ../../s9y/templates .
        ln -s ../../s9y/htmlarea .
)
chown -R www-data.www-data /home/$BASE_DIR/subdomains/$1

su - postgres -c "createdb $1blogsexamplecom"
su - postgres -c "createuser -S -D -R -P -E $1blogsexamplecom"

Das Skript tut eigentlich nicht viel: es legt ein passendes Verzeichnis an um die Subdomain zu aktivieren, kopiert die Deployment-Dateien von Serendipity (ein paar kleine PHP-Dateien, die am Ende mal dafür sorgen, dass aus der Shared-Installation die gemeinsamen Dateien angesprungen werden), verlinkt templates und WYSIWYG-Editor passend und überträgt die Rechte an den Webserver-User. Die letzten beiden Zeilen legen noch die Datenbank und den passenden User zum neuen Blog an (Passwort wird erfragt). Das ist natürlich nur für die bei mir verwendete PostgreSQL gültig. Wer was anderes verwendet muss hier entsprechend anpassen.

Tja, wenn das alles fehlerfrei durchgelaufen ist, dann kann man eigentlich schon die Domain http://<name>.blogs.example.com besuchen. Dort wird man vom Installationsskript von Serendipity begrüßt, welches den eben angelegten DB-Nutzer wissen will und dann seine Arbeit erledigt. Für das (doch eigentlich recht einfache) Vorgehen hab ich jetzt doch 2 Stunden gebraucht um's auszutüfteln..

P.S: Das in der Originalanleitung erwähnte open_basedir muss man leider weglassen, weil es nicht zusammen mit mod_vhost spielen mag. Speziell der Subdomain-spezifische Teil des Pfades würde hier Probleme machen.

Fürchterlich! Irgendwann kommt man mal auf die glorreiche Idee, seinen Server auf Debian Lenny bringen zu wollen. Warum auch nicht? Ist ja mittlerweile schon ein Stück stable und außerdem und überhaupt. Also gestern fix angekündigt und heute morgen begonnen. Paketquellen geändert, apt-get dist-upgrade angeworfen und los. Joar, alles kein Problem, wenn da nicht so ein kleines Problem wäre: seit einiger Zeit kann ich OpenVPN auf dem Server nicht mehr beenden. Das bleibt dann mit der (sich alle 10 Sekunden wiederholenden) Meldung: kernel: unregister_netdevice: waiting for tap1 to become free. Usage count = 1. Tja... das OpenSSL-Update wollte dann OpenVPN neu starten... Plöt. Mitten im Update bleibt das ganze also mal gepflegt hängen. Intelligenterweise kann man sich nachdem das begonnen hat nicht mehr einloggen. Ich hatte also nichtmal mehr ne Konsole um die Kiste hart neu zu starten und zu hoffen. *gnaaa* Ok, Hetzner anrufen, Rettungssystem etc.pp. Blöd zum Zweiten: der im chroot auf dem halbfertigen System weitergeführte Update-Prozess war dann irgendwie der Meinung Mailserver etc. neu zu starten, was dazu führte, dass plötzlich der Secondary MX mit der Einlieferung begann. Ich hätte nicht erwartet, dass das ein Problem darstellen würde. Irgendwie war dem aber offensichtlich so, jedenfalls verabschiedete sich das System bei der Konfiguration des Bootloaders (Hurra! Wenn es einen dämlichen Moment gibt, dann diesen!) Also nochmal Hetzner angerufen (der arme Kerl, der da heute Dienst hatte...), Rettungssystem zum zweiten, Bootloader konfiguriert und installiert, neu gestartet und bibbernd davor gesessen. Zu meiner Überraschung hatte das dann aber geklappt. Die üblichen Verdächtigen (ein paar Django-Programme) wollten mal wieder nicht mehr starten und PostgreSQL wollte gern ein pg_updatecluster haben, damit es wieder lieb mit mir ist, aber sonst war alles locker.

So, jetzt aber erstmal wieder 5 Jahre Ruhe... *grmpf*

Geilste OpenOffice.org-Erweiterung ever: Presenter Screen. Aus ominösen Gründen bin ich heute auf ein wenig Hirnunterstützung in Form von Notizen angewiesen und bin dabei über dieses Teil gestolpert. Nach dem Starten einer Präsentation im Impress präsentiert sich der Bildschirm zum Vortragenden (zwei Bildschirme natürlich vorausgesetzt) recht aufgeräumt:

Presenter Screen auf dem Bildschirm des Vortragenden

Alles da, was man braucht: Uhr, Folienübersicht, Notizen, nächste Folie etc.pp. Hoffentlich wird diese Extension mal standardmäßig in OpenOffice.org mit eingebaut.

BTW: Unter Ubuntu ist Presenter Screen als openoffice.org-presenter-console verfügbar. Aber wahrscheinlich weiß das außer mit eh schon wieder jeder.

So ein paar Geburtswehwechen hat mein frisch installiertes Kubuntu 9.04 dann doch. Nachdem ich etwas länger aus Google Earth einklopfen musste und auch ein Bug im Handling von USB-Sticks schon behoben werden wollte (wenn man einen, der in Benutzung ist, über den Device Notifier auswerfen will, dann friert der ein. Patch ist im Upstream bereits drin.), war nun nur noch das Problem mit dem KOrganizer zu beheben. In der Tages-, Wochen- und Arbeitswochenansicht war nix zu sehen (vgl. passender Bug im Launchpad). Blöd, wenn man wie ich das Teil eigentlich recht exzessiv nutzt (ehrlich mal: ich würde meine Seminare vergessen ohne das Ding). Der Übeltäter ist folgender Eintrag in der ~/.kde/share/config/korganizerrc:

Der gibt die Trennung zwischen der Zeittafel und den zeitunabhängigen Events in den entsprechenden Ansichten an. Deswegen ist das auch in der Monatsansicht kein Problem: dort gibt es diesen Trenner nicht. Wenn man statt 0,0 sinnvolle Werte einsetzt (ich hab bspw. 800,600 eingesetzt und dann im GUI das wieder zurechtgezogen), dann ist alles wieder wie gewohnt. Eigentlich sollte das Problem laut Bugreport in 4.2.2 gefixt sein (was ich hier installiert habe). Ist es wohl aber für mich nicht. Mal kommentieren...

Wenn's mal wieder länger dauert... Jetzt hab ich doch einige Zeit versucht auf meinem 64-Bit-Kubuntu 9.04 Google Earth ans Laufen zu kriegen. Blöderweise verabschiedet sich das Programm immer mit Error 29, wenn es startet und stellt dann nichts dar. Folgender Thread enthält die Lösung des Rätsels: Auf einem 64-Bit-System sind normalerweise nicht unbedingt alle Bibliotheken installiert, die GE so erwartet (es ist ja leider "nur" ein 32-Bit-Programm). In meinem Fall fehlte lib32nss-mdns. Nach einer Installation beschwert es sich wieder über das bekannte OpenSSL-Problem (die GE-eigene libcrypto im Programmverzeichnis ist der Übeltäter. Einfach löschen und schon geht's) und wenn man das auch noch behoben hat, dann läuft das ganze.

Einfacher geht's zumindest unter Ubuntu mit aptitude install googleearth-package. Danach kann man sich mit make-googleearth-package ein Debian-Paket bauen, welches die nötigen Dinge tut, damit alles funktioniert.

Wer öfter mit GPS-Tracks arbeitet – für OpenStreetMap, Geocaching [auch wenn man da neuerdings aufpassen muss, dass man nicht gleich als Terrorist abgestempelt wird] oder auch nur zur persönlichen Analyse beim Joggen/Radfahren) – der dürfte sich über ein Programm wie GPSBabel freuen. Zwar nur ein Kommandozeilentool (mit Frontends für Windows und MacOS), aber dafür sehr mächtig. Es konvertiert von und zu x Speicherformaten (und ebnet so nach eigener Darstellung den "GPS-Turm vom Babel" ein) und bietet einen Haufen Nachbearbeitungsmöglichkeiten für die Tracks, die so aus manchen Geräten rausfallen.

Ein Beispiel: ein Urlaubstrack aufgezeichnet mit Medion GoPal 4. Intervall 1 Sekunde (was anderes kann das Medion IMO nicht) bedeutet in diesem Fall (Fahrt nach Kroatien, 5 Tage Segeln) mehrere Tracks mit insgesamt ~6MB Größe. Ziel ist es, die Tracks zu einem zusammenzusetzen und deutlich zu vereinfachen.

gpsbabel -i gpx -f 1.gpx -i gpx -f 2.gpx -i gpx -f 3.gpx -i gpx -f 4.gpx -i gpx -f 5.gpx -x track,merge,title="Urlaub komplett" -x simplify,crosstrack,error=0.002k -o gpx -F urlaub.gpx

Dieses Kommando setzt die Dateien [1-5].gpx zu einem Track zusammen, versieht den mit dem Titel "Urlaub komplett" und vereinfacht den Gesamtweg so, dass die Form erhalten bleibt (bei einem maximalen Fehler von 2 Metern, d.h. der neue Track-Verlauf weicht maximal 2m vom alten ab, was sowieso unter der Toleranz des GPS-Gerätes liegt). Auf diese Weise werden aus 5 Dateien mit einer Gesamtgröße von ~6MB eine mit 833kB. Wenn man jetzt am Ende das -o gpx... noch ersetzt durch -o kml -F urlaub.kml, dann kann man sich den Track gleich direkt in Google Earth anschauen.

Das Programm läuft auf allen gängigen Betriebssystemen, auch wenn die Windows- und Mac-User wahrscheinlich ob der Kommandozeilenbedienung weinen. Aber die können sich ja mal die grafischen Frontends anschauen, die allerdings nicht komplett alle Möglichkeiten des zugrundeliegenden Programms bieten.

Transystem hat mit ihrem i-Blue 747 eine schnuckelige GPS-Empfänger/Logger-Kombination im Angebot. Nachdem ich bisher für OpenStreetMap immer mit einem GoPal getrackt habe, wollte ich mir endlich mal einen richtigen Tracker gönnen. Die Vorteile liegen auf der Hand: kleiner, leichter, weniger fehleranfällig. Mit dem GoPal lässt sich zwar im Auto etc. wunderbar tracken, aber wenn man es in die Jackentasche steckt, dann nervt es ein wenig, dass man den Bildschirm nicht ausschalten kann. Braucht unnötig Strom und macht das Gerät aufgrund der Touchscreenbedienung anfällig gegen Fehlbedienungen durch Berührung. Also für Wandern, Radfahren etc. ein eigener Tracker...

Ursprünglich hatte ich mich anhand der Hardwareliste von OpenStreetMap auf das Wintec WBT-201 eingeschossen, welches anscheinend genau meine Anforderungen erfüllt. Durch den Test bei kowoma.de kam ich zusätzlich noch auf den i-Blue als Alternative. Der hat(te) zwar wesentlich weniger Speicher (70k vs. 131k Datenpunkte), war allerdings auch ~30€ billiger. Nachdem sich der Kauf nun noch ein paar Wochen hinausgezögert hatte, hat Transtec das Rennen gemacht: sie haben den i-Blue in einer neuen Variante auf den Markt geworfen, die den doppelten Speicher hat und damit ~150k Datenpunkte speichern kann. Mehr als genug für meine Ansprüche und deutlich günstiger als der Wintec. Anfang der Woche bestellt, heute bekommen.

i-Blue 747

So sieht das gute Stück aus. Zum Größenvergleich ein 20-¢-Stück daneben. Recht übersichtlich also und mit knapp 70g auch nicht schwer. Die Bedienung ist absolut simpel: entweder man betreibt ihn im Modus NAV, dann ist er ein reiner NMEA-kompatibler Empfänger und reicht die Daten via USB oder Bluetooth an PC/PDA/etc. raus. Betreibt man ihn hingegen im Modus LOG, dann zeichnet er zusätzlich zum Weiterreichen die Daten auch noch auf seinem internen Speicher auf. Mit einer Software kann man vom PC aus einstellen, was er aufzeichnen soll (Längen- u. Breitengrad, Höhe, Geschwindigkeit etc.pp) und unter welchen Bedingungen (alle x Sekunden von, alle x Meter oder über x km/h). Der Knopf in der Mitte des Geräte dient zum Setzen von Wegpunkten: drückt man ihn, dann speichert das Gerät den aktuellen Datensatz mit einem Vermerk und man kann das später als Wegpunkt auslesen. Sehr praktisch, wenn man beim Tracken was interessantes sieht und sich merken will, wo's war. Das war's auch schon am Gerät selbst. Geladen wird via USB, wobei ein Verbindungskabel zum PC, ein Netzteil und ein Stecker für's Auto beiliegen.

Ein kleines Problem gibt es (wie üblich) für mich: Software zum Auslesen des Gerätes liefert der Hersteller nur für Windows. Wäre ja auch zu schön... Als NMEA-kompatibler Empfänger stellt er kein Problem dar. Steckt man das Gerät per USB an, hat man plötzlich eine neue serielle Schnittstelle /dev/ttyUSB0 (oder äquivalent), die der gpsd mit Freuden abfragt und die entsprechenden Daten generiert. Damit funktionieren sämtliche linux-basierten Navigations- und Trackingprogramme. Das ganze soll auch problemlos via Bluetooth funktionieren, was ich allerdings noch nicht probiert habe.

An die Logs ranzukommen ist schon schwerer. Das Gerät präsentiert sich leider wie alle anderen auch nicht als USB-Massenspeicher, sondern will via serieller Schnittstelle dazu gebracht werden, die Daten rauszurücken. Die kanonische Antwort auf dieses Problem lautet: bt747, ein Java-Programm zum Auslesen und Konfigurieren der Geräte. Dummerweise konnte ich das bisher nicht ans Laufen kriegen, weil mit javax.comm fehlt, von dem mir Sun erzählt, dass es grad nicht zu haben sei. Glücklichweise hat sich jemand hingesetzt und ein Perl-Skript geschrieben, was das gleiche tut: mtkbabel. Funktioniert ebenso, auch wenn es nicht ganz so einfach zu bedienen ist. Wichtigster Aufruf: alle Daten vom Gerät laden: ./mtkbabel -s 115200 -l off -f track -w -t -a legt drei Dateien an. Eine binäre, die direkt vom Gerät kommt, eine track_trk.gpx, die den aufgezeichneten Weg enthält und eine track_wpt.gpx, die die per Knopfdruck aufgezeichneten Wegpunkte enthält. In JOSM geladen sieht das dann so aus:

Daten im JOSM

Zu sehen sind hier zwei überlagerte Strecken (Hin- und Rückfahrt) und ein Wegpunkt (das kleine Kreuz mit der Nummer 001). Die Aufzeichnungsqualität ist gut, das Gerät findet seine Satelliten schnell und arbeitet zuverlässig. Nur das Standardaufzeichnungsintervall von 5 Sekunden sollte man evtl. etwas kürzer einstellen (bspw. per mtkbabel). Ich bin im Moment bei zwei Sekunden. Mal noch ein wenig testen, was da brauchbar ist.

Insgesamt ein sehr schickes Gerät. Mal schauen, was die Zeit bringt und ob es im Dauereinsatz hält, was es bisher versprochen hat. Es gibt ja noch einige Orte hier in der Umgebung die getrackt werden wollen...

Im Linux-Kernel eingebaut ist ja nun schon seit geraumer Zeit das Crypt-Target des Device-Mappers, mit dem sich transparent ganze Partitionen auf der Platte verschlüsseln lassen. Das verwende ich schon länger um mein Notebook komplett zu verschlüsseln und so im Falle eines Diebstahls/Verlustes wenigstens nicht gleich meine ganzen privaten Daten im Netz zu finden. Für ein Projekt brauche ich in Zukunft allerdings ein wenig mehr: einen Container, der im normalen Betrieb nicht offen ist, sondern nur wenn ich mit den Daten arbeite, die sich darin befinden (man weiß ja nie, ob nicht unter Umständen unter dem eigenen Nutzer mal was Amok läuft). Recht bequem löst man das mit TrueCrypt: Container anlegen, im TrueCrypt auf "Mounten" klicken, Passwort eingeben, fertig (so zumindest unter Windows. TrueCrypt unter Linux hab ich noch nicht benutzt). Nun will ich mir nicht noch ein Tool installieren, schließlich hab ich mit dm-crypt schon ein erprobtes zur Verfügung. Leider kann dieses nur Devices verwalten und keine Dateien als Container direkt ansprechen. Macht aber nichts, wozu gibt es loop-Devices?

Die Schritte sind also ganz einfach: loop-Device auf der Container-Datei anlegen, mittels cryptsetup öffnen lassen und unter einem Mountpoint einhängen. Weil mir das zuviel Tipperei ist, hab ich zwei einfache Skripte zusammengebaut, die den kompletten Ablauf übernehmen.

Skript #1 ist zum Öffnen eines Container da. Einfach: ./mount_container.sh <containerdatei> <mountpoint> als root (oder mittels sudo) ausführen, Passwort eingeben und schon hängt der Container unter dem angegebenen Mountpoint.

#! /bin/bash

if [ x$1 == x ]; then
        echo "Usage: $0 <imagefile> <mountpoint>"
        exit 1
fi

DIRECTORY=$(dirname $1)
IMAGENAME=$(basename $1)
CUR_DIR=$(pwd)
if [ ! "x$DIRECTORY" == x ]; then
        cd "$DIRECTORY"
fi
IMAGEPATH=$(pwd)/"$IMAGENAME"
MAPPERNAME=$(echo "$IMAGEPATH" | sha1sum | cut -d" " -f 1)  # we use the sha1sum of the image path as mapper device

echo "Mapping $IMAGEPATH to device /dev/mapper/$MAPPERNAME"

MP_TMP=$(losetup -a | grep "$IMAGEPATH" | cut -d':' -f 1)
if [ x$MP_TMP == x ]; then
        echo "Setting up loop device"
        losetup -f "$IMAGEPATH"
fi
DEVICE=$(losetup -a | grep "$IMAGEPATH" | cut -d':' -f 1)

C_TMP=$(cryptsetup status $MAPPERNAME | grep " active")
echo $C_TMP
if [ x$C_TMP == x ]; then
        echo "Opening LUKS device $DEVICE"
        cryptsetup luksOpen "$DEVICE" $MAPPERNAME
fi
mount /dev/mapper/$MAPPERNAME "$2"

Irgendwann ist die Arbeit im Container dann mal beendet und man möchte ihn wieder aushängen. Dazu gibt es das Skript umount_container.sh (ebenfalls wieder als root oder via sudo ausführen:

#! /bin/bash
#! /bin/bash

if [ x$1 == x ]; then
        echo "Usage: $0 <mount point>"
        exit 1
fi

MAPPER_DEVICE_NAME=$(mount | grep "$1" | cut -d' ' -f 1 | cut -d'/' -f 4)
if [ x$MAPPER_DEVICE_NAME == x ]; then
        echo "$1 is not a mounted device."
        exit 1
fi
if [ x"$(cryptsetup status $MAPPER_DEVICE_NAME | grep ' active')" == x ]; then
        echo "$1 does not seem to be a mounted dm-crypt device"
        exit 1
fi
umount "$1"

DEVICE=$(cryptsetup status $MAPPER_DEVICE_NAME | grep device: | cut -d ' ' -f 5)
cryptsetup luksClose $MAPPER_DEVICE_NAME
LO_TMP=$(losetup -a | grep "$DEVICE")
if [ ! x"$LO_TMP" == x ]; then
        losetup -d "$DEVICE"
fi

Angelegt wird der Container ganz klassisch als loop-Device: Anleitung aus dem Gentoo Linux Wiki. Danach kann man ihn ganz einfach mittels der Skripte benutzen.

Tipp: Wenn man den Container als normaler Benutzer verwenden will (also ohne root-Rechte), dann sollte man als root einmalig nach dem Anlegen und Einhängen ein chown -R <nutzer> auf den Mountpoint machen. Zugriffsrechte auf das Verzeichnis kann man natürlich auch gleich noch entsprechend setzen, damit nicht jeder drin rumwurschteln kann.

Weil ich grad nen halben Tag gesucht habe: wenn der ejabberd zwar startet, aber keinerlei Ports öffnet und irgendwie nicht mehr reagiert, dann sollte man mal checken, ob der an seine Config kommt. Bei mir war es ein verwürfelter Owner von /etc/ejabberd/, der verhindert hat, daß er sein Configfile einlesen konnte. Blöd ist: sonst loggt das Teil jeden Sch***, aber bei so nem gravierenden Fehler herrscht im Logfile Schweigen. *gnaaa*