Computer

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.