Mein Zweithirn

Neben all dem anderen Kram hier, gab es die Tage auch noch eine Speichererweiterung für Javalon. 2 SAS Platten. Die Installation geht recht einfach: Blende rausnehmen und Platten einschieben. Fertig. Danach wurde ein RAID1 auf dem LSI MegaRAID Controller konfiguriert. Dazu verwenden wir das Kommandozeileninterface vom Hersteller: MegaCli von LSI [1]

MegaCli -CfgLdAdd -r1[8:4,8:5] WT RA Direct -a0 MegaCli -LdSetProp -Name sdc -L2 -a0

wobei die zweite optional ist. Eine schöne Befehlsübersicht zu MegaCli gibt es unter [2]. Ein MegaCli-Ebuild unter [3]. Lieder bemerkt der Kernel nicht automatisch, dass es ein neues Device gibt. Es gibt im Internet dazu einige Hinweise wie echo "scsi add-single-device a b c d" > /proc/scsi/scsi, welche aber entweder mit Invalid Argument endeten oder wirkungslos waren. Gefunden hab ich die Lösung in einer IBM Wiki [4]:

echo "- - -" > /sys/class/scsi_host/host0/scan

Danach meldete der Kernel:

sd 0:2:2:0: [sdc] XXXX 512-byte hardware sectors (XXX MB) sd 0:2:2:0: [sdc] Write Protect is off sd 0:2:2:0: [sdc] Mode Sense: 1f 00 10 08 sd 0:2:2:0: [sdc] Write cache: disabled, read cache: disabled, supports DPO and FUA sd 0:2:2:0: [sdc] Attached SCSI disk ...

Quellen: [1] http://www.lsi.com/storage_home/products_home/internal_raid/megaraid_sas/megaraid_sas_8480e/index.html [2] http://tools.rapidsoft.de/perc/perc-cheat-sheet.html [3] https://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/sys-fs/MegaCli/MegaCli-1.01.39.ebuild [4] http://www.ibm.com/developerworks/wikis/display/LinuxP/SCSI+-+Hot+add,+remove,+rescan+of+SCSI+devices

Manchmal nervt mich sowas echt. Im stable Portagetree sind grade e2fsprogs-1.41.2 und e2fsprogs-libs-1.41.2 als stable markiert worden, blockieren aber einige installierte Programme:

pegro ~ # emerge e2fsprogs -1av These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE="nls (-static%)" 4,263 kB [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 479 kB [blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9) Total: 2 packages (1 upgrade, 1 new, 4 blocks), Size of downloads: 4,741 kB !!! Error: The above package list contains packages which cannot be installed !!! at the same time on the same system. For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

Dazu muss man wissen, das com_err und ss nun in e2fsprogs-libs enthalten sind, daher das Blockieren. Leider kann die aktuelle Portageversion mit solchen Fällen noch nicht umgehen (in kommenden Versionen soll das behoben sein). Theoretisch reicht in solchen Fällen, die betroffenen Pakete von Hand zu deinstallieren. Also versucht man dann ein

emerge -C com_err ss

was jedoch nur ein Teil des Problems löst:

pegro ~ # emerge e2fsprogs -1av These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE="nls (-static%)" 4,263 kB [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 479 kB [blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2) Total: 2 packages (1 upgrade, 1 new, 1 block), Size of downloads: 4,741 kB !!! Error: The above package list contains packages which cannot be installed !!! at the same time on the same system. For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

[Update] Bevor man ss und com_err deinstalliert, sollte man ein

emerge -f e2fsprogs

machen, damit die Sourcen geladen werden, denn auf manchen Systemen funktioniert wget nach dem unmerge nicht mehr und so lässt sich auch e2fsprogs nicht mehr so einfach installieren. [/Update] Als hässlicher Workaround funktioniert

emerge -C e2fsprogs && emerge e2fsprogs

was ich aber für normale Gentoo-User echt unzumutbar halte. Ich hoffe, man findet eine bessere Lösung. Unter [1] wird darüber diskutiert. Dort gibt es noch ein paar Hinweise, was man tun muss, falls man noch Ebuilds hat, die direkt von com_err oder ss abhängen. [Update2] Portage in der Version ab 2.1.6.4 ist in der Lage, das Problem zu erkennen und selbstständig zu beheben. Die 2.1.6.4 ist seit dem 29.12.2008 als stable markiert. [/Update2] [1] http://bugs.gentoo.org/show_bug.cgi?id=234907#c7

Niemals ein und denselben Artikel auf 2 Rechnern zum Entwurf geöffnet haben UND Autosave aktiviert lassen.

*ARG* Ich hasse es: nun schreib ich den Artikel zum dritten Mal...

Ein oft gewünschtes, meist ignoriertes Feature für Psi ist OTR, also Off-the-Record Messaging [1]. Mittlerweile hat sich Timo Engel mal daran gemacht, dies für Psi 0.12 zu implementieren [2]. Dazu muss extra eine Pluginschnittstelle in Psi gepatcht werden. Die Patches und das Plugin findet man auf seiner Homepage. Für Gentoo findet man passende Ebuilds im Bugtracker [3]. Da die aktuelle Version 0.4 des Plugins von libotr-0.3.1 abhängt, das mittlerweile im Portagetree enthaltene kopete-4.1.2 mit dem Useflag otr jedoch von libotr-0.3.2, meckerte Portage:

!!! Multiple versions within a single package slot have been !!! pulled into the dependency graph

usw. Mit einem kleinen Patch [4] für das Plugin compiliert das Ganze auch mit libotr-0.3.2 und Portage ist zufrieden. Jedoch finde ich das Plugin in seiner jetzigen Form noch nicht wirklich benutzbar. Zuviele Metanachrichten, die einem die History vollmüllen, Einstellungen mühsam über ein Kontextmenü einstellbar und komisches Verhalten, wenn eine Seite die OTR-Session beendet. Außerdem fehlt die Authenfizierung über ein "shared secret", was ich für unkomplizierter als das Fingerprintverfahren halte. Quellen: [1] http://www.cypherpunks.ca/otr/ [2] http://public.tfh-berlin.de/~s30935/ [3] http://bugs.gentoo.org/show_bug.cgi?id=238596 [4] http://bugs.gentoo.org/attachment.cgi?id=169973

http://thedoor.ch/mainpage/content/view/35/76/

Subversion 1.5 ist nun schon eine Weile stable und nun auch im Portage als Stable markiert worden. Die wichtigste Änderung auf Clientseite ist wohl, dass sich das Workspaceformat geändert hat. Sobald man z.B. svn up auf einer Workingcopy anwendet, wird diese automatisch auf das neue Format aktualisiert und ist dann nicht mehr nutzbar für ältere Subversionversionen. Auf Serverseite hat sich auch einiges geändert, u.a. auch das Repositoryformat, welches jedoch von Hand auf die neue Version gebracht werden muss. Dazu führt man für jedes Repository

svnadmin upgrade

aus. Danach ist es ebenfalls nur noch mit Subversion >= 1.5 nutzbar. Dies betrifft aber nur die Tools und Programme, die lokal auf Workingcopys oder Repositories arbeiten. Das auf DAV aufsetzende SVN Protokoll hat sich nicht geändert, sodass verschiedene SVN Versionen immer noch interagieren können, auch wenn sich dann nicht alle Features nutzen lassen. Näheres zu der neuen Version steht in den Release Notes [1]. Quelle: [1] http://subversion.tigris.org/svn_1.5_releasenotes.html

Bisher mache ich immer

layman -S && eix-sync

um die Ebuilds auf den neusten Stand zu bringen. Layman ist aber bei eix nicht unbekannt. So reicht es, in die Datei /etc/eix-sync.conf folgendes einzufügen:

*

Fertig. Dann werden alle durch layman hinzugefügten Overlays ebenfalls gesynct. Manchmal kann es so einfach sein... Update: Früher wurde beim eix-sync die etwas längliche Ausgabe von emerge --sync unterdrückt. Das ist in neueren Versionen nicht mehr der Fall. Um das alte Verhalten wieder zu erzwingen, kann man in die /etc/eix-sync.conf noch eine Zeile

-C --quiet

hinzufügen. Danach sollte Ruhe sein. Quelle: [0] man eix

Lang ist's her, dass ich mal ein Software-RAID erstellt habe. Da vergisst man so manchen Schritt. Daher hier nochmal kurz zwei Gedanken:

mdadm --create /dev/md0 --level 1 --raid-devices 2 /dev/sdd /dev/sde

sollte eigentlich das gewünschte Device erstellen, jedoch sah ich nur eine Meldung:

mdadm: error opening /dev/md0: No such device or address

Auch cat /proc/mdstat lieferte einen Fehler. Die Ursache ist ganz simpel: keinen RAID-Support im Kernel Also RAID Support aktiviert, Kernel neu gebacken und rebootet, geht.

"Wo ein Wille ist, ist ein Weg. Wo zwei Villen sind, ist er verbaut."

Marco Tschirpke

Auf den MemorySticks für meine Digitalkamera befindet sind jeweils ein FAT32 Dateisystem. Als ich heute die Kamera ansteckte, hat sie der ivman gleich unter /media/digicam eingehangen. Jedoch waren dann alle Dateinamen kleingeschrieben, also lowercase. Zumindest bei allen Dateien mit Dateinamen, die in das Schema FILENAME.END passen. Das muss einen nicht stören, mich aber stört's. Es liegt an den Shortnames des FAT-Dateisystems. In der Manpage von mount [1] findet sich im Abschnitt vfat dazu eine kurze Erklärung und der Lösung des Problems: Beim mouten die Option

-o shortname=winnt

setzen. [1] http://linux.die.net/man/8/mount

Update: Dieser Artikel behandelt KDE 4.1. Für das kürzlich erschienende KDE 4.3 findet man u.a. hier nützliche Informationen.

Wer sich nicht an die KDE4 SVN-Ebuilds traut, sollte sich mal das Overlay des KDE-Teams von Gentoo ansehen. Eine gute Übersicht, welche Pakete bereits übernommen wurden, findet man hier:

http://skrypuch.com/kde4/

Das Overlay ist mittlerweile in der Remotelist [1] von layman [2]. Also reicht ein

layman -a kde-testing

Empfehlenswert ist es, vor dem Installieren das globale Useflag kdeprefix zu setzen, da sonst KDE4 nach /usr statt nach /usr/kde/4.1 installiert wird, was einen Parallelbetrieb von 3.5 und 4.1 verhindert. Nagut parallel geht es schon. Dann hat man einen 3.5 Windowmanager mit 3.5 Systemtray, aber 4.1 Plasma Desktop und 4.1 Taskleiste. Eine äußert unschöne Mischung. Globale Useflags setze ich meist mit euse aus dem gentoolkit-Paket.

euse -E kdeprefix

Von der Fehlermeldung

* Overlay eclasses override eclasses from PORTDIR: * * '/usr/local/portage/layman/kde-testing/eclass/kde4-base.eclass' * '/usr/local/portage/layman/kde-testing/eclass/kde4-functions.eclass' * '/usr/local/portage/layman/kde-testing/eclass/kde4-meta.eclass' * * It is best to avoid overridding eclasses from PORTDIR because it will * trigger invalidation of cached ebuild metadata that is distributed with * the portage tree. If you must override eclasses from PORTDIR then you * are advised to add FEATURES="metadata-transfer" to /etc/make.conf and to * run `emerge --regen` after each time that you run `emerge --sync`. Set * PORTAGE_ECLASS_WARNING_ENABLE="0" in /etc/make.conf if you would like to * disable this warning.

sollte man sich erstmal nicht aus der Ruhe bringen lassen. UPDATE KDE 4.1.2 ist mittlerweile im Portagetree enthalten, so dass man das Overlay nicht mehr braucht. Weitere Informationen findet man im Gentoo KDE 4 Guide [3]. Links: [1] http://www.gentoo.org/proj/en/overlays/layman-global.txt [2] http://layman.sourceforge.net [3] http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml

Man stelle sich vor, auf einem entfernten, per SSH erreichbaren Server liegen Dateien, die man gerne ins SVN einchecken möchte. Leider ist auf dem Zielsystem kein Subversion installiert. Also dachte ich mir, nutzt du die hier bereits öfter erwähnten Möglichkeiten von FUSE und seinen Dateisystemen. Hier SSHFS [1]:

sshfs user@entfernter.server.de: working-copy

funktioniert auch wunderbar, das entfernte Verzeichnis wird transparent gemountet und man kann mit allen Tools darauf arbeiten, bis auf Subversion.

svn: Can't move 'test/.svn/tmp/entries' to 'test/.svn/entries': Operation not permitted

lautet die trotzige Antwort. Bei der Recherche fand ich viele Blogs mit diesen Problemen, die aber meist eklige Hacks mit rm und cp vorschlugen. Schließlich fand ich auf der macfuse-devel Mailingliste einen Hinweis auf die FAQ [2] von SSHFS:

The reason is that SFTP protocol version 3 (which is implemented by OpenSSH's sftp-server) defines the rename operation slightly differently than POSIX. The difference is that renaming to an existing file or directory will fail instead of atomically replacing the old file. The -o workaround=rename option will try to emulate POSIX rename semantics, but it cannot guarantee atomicity. In most of the cases this doesn't matter, and things will work fine with this option.

Und siehe da: mit

sshfs -o workaround=rename user@entfernter.server.de: working-copy

funktioniert auch SVN wie gewünscht. Quellen: [1] http://fuse.sourceforge.net [2] http://fuse.sourceforge.net/wiki/index.php/SshfsFaq

Am Donnerstag abend wunderte ich mich über die extrem schnell wachsenden Logfiles des Gatling, den wir testweise als Ersatz für Apache und Proftpd auf dem Verteilserver der FeM e.V. für 2XC3-Videos verwenden. Innerhalb eines Tages sind über 140MB Log entstanden. Da musste was faul sein. Ein Blick in die Logfiles zeigte einen Client, der seit Stunden immer wieder eine Datei anfragte und diese auch brav ausgeliefert bekam. Weitere Ermittlungen mit tcpdump ergaben: Immer ein und dieselbe HTTP-GET Anfrage für eine bestimme wenige KB große Byterange. Da schien wohl ein Player in der Endlosschleife zu hängen. Auch nach dem Stoppen des Webserver traffen immer wieder Anfragen ein, die vom Kernel auf TCP-Ebene resetet wurden, da kein Programm auf dem gewünschten Port lauschte. Wie sich später herausstellte, war der Server am Vormittag mehere Stunden während Wartungsarbeiten runtergefahren, was den Client jedoch nicht zur Aufgabe überredete. Also wie geht man mit einem Client um, der sich weder durch Abarbeitung der gewünschten Anfrage, noch durch Ablehnung selbiger von seinem Vorhaben, mir meine Logfiles vollzuspammen, abbringen lässt. Eine Idee wäre gewesen die TCP-Verbindung zwar anzunehmen, aber nicht zu beantworten, sondern ins Timeout laufen zu lassen. Eine spontane Idee von cosrahn stellte sich aber als effektiver heraus:

cat /dev/zero | nc -p 80 -l

So würde die erste Anfrage auf Port 80 so lange mit Nullen beantwortet, bis die Gegenseite keine Lust mehr hat. Da 99,9% der Anfragen von diesem Client kamen, war die Wahrscheinlichkeit groß, den richtigen damit zu treffen. Wohl nicht groß genug, denn das erste Opfer war ein Suchmaschinencrawler. Aber schon beim zweiten Versuch bekam unsere Nervensäge einen Schwung Nullen. Und war scheinbar damit zufrieden, denn sie ward ab da nie wieder gesehen. Was es nicht alles für Software gibt... Ergebnise der Ursachenforschung: Alles fing am 2008-09-10 um 23:14:46.375373500 an:

2008-09-10 23:14:46.375376500 GET 73 /CCC/24C3/mp4/24c3-2276-en-space_communism-COMPATIBLE.mp4 141011139 AppleTV/2.1 [no_referrer]

Soweit so unspannend. Dieser Aufruf brach jedoch mit einer kaputten Röhre ab und eine knappe Sekunde später, kam die nächste Anfrage:

2008-09-10 23:14:46.692818500 socket_error 73 Broken pipe 2008-09-10 23:14:46.692821500 close/writefail 73 190 137076 2008-09-10 23:14:47.444218500 accept 73 $IP1 63950 29 2008-09-10 23:14:47.444220500 GET 73 /CCC/24C3/mp4/24c3-2276-en-space_communism-COMPATIBLE.mp4 141011139 CFNetwork/250 [no_referrer] 2008-09-10 23:14:47.515451500 socket_error 73 Broken pipe 2008-09-10 23:14:47.515454500 close/writefail 73 182 13236 2008-09-10 23:14:47.522374500 accept 73 $IP1 63951 29 2008-09-10 23:14:47.522375500 GET 73 /CCC/24C3/mp4/24c3-2276-en-space_communism-COMPATIBLE.mp4 141011638 CFNetwork/250 [no_referrer] 2008-09-10 23:16:35.661407500 request_done 73 189 141011912 2008-09-10 23:16:35.661410500 close/reqdone 73

Die dritte Antwort kam schließlich an. Knapp anderthalb Minuten später begann eine Requestorgie. Dieselbe IP fragte nun unentwegt ein kleines Häppchen dieses Videos an, und zwar teilweise 3 - 4 Mal IN DER SEKUNDE. 3 Minuten später war nach insgesamt 683 Anfragen wieder Ruhe.

2008-09-10 23:19:06.602376500 accept 19 $IP1 64644 38 2008-09-10 23:19:06.602380500 GET 19 /CCC/24C3/mp4/24c3-2276-en-space_communism-COMPATIBLE.mp4 43702 CFNetwork/250 [no_referrer] 2008-09-10 23:19:06.666856500 socket_error 19 Broken pipe 2008-09-10 23:19:06.666859500 close/writefail 19 197 13238

nur um 14 Sekunden später die nächste Datei zu versuchen:

2008-09-10 23:19:20.159584500 accept 54 $IP1 64648 38 2008-09-10 23:19:20.174916500 GET 54 /CCC/24C3/mp4/24c3-2254-en-freifunkerei-COMPATIBLE.mp4 141891401 AppleTV/2.1 [no_referrer] 2008-09-10 23:19:20.473401500 socket_error 54 Broken pipe 2008-09-10 23:19:20.473404500 close/writefail 54 187 183156 2008-09-10 23:19:21.179885500 accept 54 $IP1 64649 38 2008-09-10 23:19:21.179887500 GET 54 /CCC/24C3/mp4/24c3-2254-en-freifunkerei-COMPATIBLE.mp4 141891401 CFNetwork/250 [no_referrer] 2008-09-10 23:19:21.248104500 socket_error 54 Broken pipe 2008-09-10 23:19:21.248106500 close/writefail 54 179 13236 2008-09-10 23:19:21.253173500 accept 54 $IP1 64650 38 2008-09-10 23:19:21.253175500 GET 54 /CCC/24C3/mp4/24c3-2254-en-freifunkerei-COMPATIBLE.mp4 141891900 CFNetwork/250 [no_referrer] 2008-09-10 23:21:12.671895500 request_done 54 186 141892174 2008-09-10 23:21:12.671898500 close/reqdone 54

Wie zu erwarten war, ging die Orgie weiter:

2008-09-10 23:21:12.763754500 accept 44 $IP1 64670 31 2008-09-10 23:21:12.763756500 GET 44 /CCC/24C3/mp4/24c3-2254-en-freifunkerei-COMPATIBLE.mp4 6460 CFNetwork/250 [no_referrer] 2008-09-10 23:21:12.763758500 request_done 44 194 6737

Mit immerhin 2148 Anfragen in den folgenden 4 Minuten. Und die nächste Datei:

2008-09-10 23:25:16.899816500 accept 49 $IP1 62786 27 2008-09-10 23:25:16.899819500 GET 49 /CCC/24C3/mp4/24c3-2133-en-building_a_hacker_space-COMPATIBLE.mp4 86446445 AppleTV/2.1 [no_referrer] 2008-09-10 23:25:17.226411500 socket_error 49 Broken pipe 2008-09-10 23:25:17.226413500 close/writefail 49 198 186033 2008-09-10 23:25:17.889025500 accept 49 $IP1 62787 27 2008-09-10 23:25:17.889028500 GET 49 /CCC/24C3/mp4/24c3-2133-en-building_a_hacker_space-COMPATIBLE.mp4 86446445 CFNetwork/250 [no_referrer] 2008-09-10 23:25:17.926603500 socket_error 49 Broken pipe 2008-09-10 23:25:17.926606500 close/writefail 49 190 13233 2008-09-10 23:25:17.970382500 accept 49 $IP1 62788 27 2008-09-10 23:25:17.970386500 GET 49 /CCC/24C3/mp4/24c3-2133-en-building_a_hacker_space-COMPATIBLE.mp4 86446944 CFNetwork/250 [no_referrer] 2008-09-10 23:26:25.563879500 request_done 49 196 86447215 2008-09-10 23:26:25.563882500 close/reqdone 49 ... 2008-09-10 23:26:25.643619500 accept 7 $IP1 62796 17 2008-09-10 23:26:25.643621500 GET 7 /CCC/24C3/mp4/24c3-2133-en-building_a_hacker_space-COMPATIBLE.mp4 4960 CFNetwork/250 [no_referrer] 2008-09-10 23:26:25.643622500 request_done 7 203 5234

Diesmal war aber nicht nach 4 Minuten schluss. Auch nach 4,5 Stunden und über 155000 Anfragen war kein Ende in Sicht. Denn die Zwangstrennung um 4:09 sorgte nur für 18 Sekunden Ruhe und dann eine neue IP mit weiteren 180000 Anfragen bis 07:32:27. Dann unterbricht diese Kette, weil wegen Wartungsarbeiten der Server einige Stunden runtergefahren werden musste. Wer jetzt glaubte, eine mehrstündige Zwangspause würde den Client stoppen, liegt falsch.

2008-09-11 13:04:30.601335500 starting_up 0 :: 80 2008-09-11 13:04:30.601338500 start_ftp 0 :: 21 2008-09-11 13:04:30.652079500 accept 7 $IP2 62782 1 2008-09-11 13:04:30.722534500 GET 7 /CCC/24C3/mp4/24c3-2133-en-building_a_hacker_space-COMPATIBLE.mp4 4960 CFNetwork/250 [no_referrer] 2008-09-11 13:04:30.768665500 request_done 7 203 5234

Der Server ist grade 0,05 Sekunden gestartet, da treffen erneut dieselben Anfragen ein. Bis zur Problembeseitigung gegen 20.39 Uhr kamen weitere 205500 Anfragen seit der Serverdowntime hinzu. Macht in der Summe 488447 Anfragen in fast 21 Stunden, über 2,4GB Traffic, 144MB Logfile und einige strapazierte Nerven. Der hier auftauchende User-Agent "CFNetwork/250" kommt wohl aus dem Hause Apple. Dazu passt auch die zeitliche Nähe der jeweils ersten Anfrage mit dem User-Agent "AppleTV/2.1". Ich stelle an diesem Punkt keine weiteren Vermutungen an und bitte jeden, sich selbst eine Meinung über die Qualität dieser Software zu bilden.

"Wer mit der Herde geht, kann nur Ärschen folgen"

Autor (mir) unbekannt

Da ich nebenbei versuche alle Webseiten auf PostgreSQL umzuziehen, musste auch irgendwann dieses Blog dran glauben. Nach kurzem Googlen fand ich auch eine recht abenteuerlich aussehende, aber funktionierende Anleitung [1] zum portieren, da die Software das von Haus aus nicht anbietet. Das verlief dann auch recht problemlos. Wieder eine Seite weniger. Quellen: [1] http://she.geek.nz/archives/428-migrated-to-postgres.html