Dinge, Zeugs und Sachen - Linux

GPS-Tracks aufbereiten

nospam@example.com (namenlos) — Tue, 15 Jul 2008 09:31:47 +0200

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 i-Blue 747

nospam@example.com (namenlos) — Sat, 12 Jul 2008 00:26:15 +0200

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...

dm-crypt-Container Skripte

nospam@example.com (namenlos) — Thu, 24 Apr 2008 09:26:10 +0200

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.

mount_container.sh

#! /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:

umount_container.sh

#! /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.

Wenn der ejabberd nicht will...

nospam@example.com (namenlos) — Sun, 02 Dec 2007 00:42:34 +0100

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*

fetchmail für MS Exchange

nospam@example.com (namenlos) — Tue, 31 Jul 2007 15:48:17 +0200

Mein neuer Arbeitgeber hat ja seit neuestem einen Exchange-Server für die Mitarbeiter. Toll, toll, was für eine Begeisterung! Nun ja, wie das so ist, kommt man wohl leider nicht drumrum, also müssen Möglichkeiten her, sich an dieses Ding anzuklemmen. Evolution kann schon seit geraumer Zeit mit der Anbindung an ein Exchange (2000 und 2003) umgehen und stellt somit eine erste Variante dar. Dummerweise benutze ich schon ewig KMail um meine Mails zu verwalten und habe bis auf weiteres auch nicht vor das zu ändern. Was also tun?

Nun, zum Glück ist der Konnektor, mittels welchem sich Evolution an Exchange anhängt, Open Source und man kann einen kleinen Blick darauf werfen. Laut der beiligenden Doku arbeitet das Teil auf Basis des gefürchteten Outlook Web Access, einer Art Pseudo-Möchtegern-Mailapplikation, die im Browser läuft. Außer der Webseite (die oft genug als Feigenblatt herhalten muss in der Art: "Was du nur hast? Benutz doch einfach OWA in deinem Browser, wenn du kein Outlook willst!" Scherzkekse...) bietet OWA allerdings noch eine kleine Nettigkeit: den Zugriff auf die Mailbox via WebDAV. Diese HTTP-Abart stellt Kommandos zum Verwalten von Dateien und Verzeichnissen zur Verfügung und wird sonst beispielsweise für die Freigabe von Verzeichnissen etc. benutzt. Mit Hilfe von WebDAV ist Rettung vor der unheiligen Allianz Exchange-Outlook zumindest teilweise in Sicht...

Ziel ist es also, die Mails aus den Klauen von Exchange zu befreien und auf einen standardkonformen Mailserver zuzustellen (bspw. einen lokalen IMAP) oder sie in einem Maildir abzulegen (bspw. für Mozilla etc.). Für diese Aufgabe habe ich mir ein kleines Pythonskript geschrieben, welches zusammen mit einer angepassten davlib (Link zum Original. Bitte NICHT mit dem Skript verwenden!) seinen Dienst versieht. Im Kopf des Skriptes werden einige Konfigurationsvariablen gesetzt (Exchangeserver, SMTP-Server, Nutzernamen etc.). Besondere Beachtung verdient hier der MAILBOX_PATH: dieser gibt den Basispfad der Mailbox im OWA an. Meist hat er die Form /Exchange/Nutzername/Inbox oder /Exchange/Nutzername/Posteingang. Den genauen Pfad bekommt man, indem man sich den Link zu einer Mail im OWA anschaut und nach dem entsprechenden Muster sucht. Das Skript stellt die Mails auf die angegebene Adresse zu und benutzt dabei den angegebenen SMTP-Server. Prinzipiell könnte man aber auch an der Stelle die Mail in eine Datei speichern oder irgendwas anderes damit machen.

Ein Detail noch zum Versenden der Mails: die Funktion sendMail geht davon aus, daß der SMTP-Server STARTTLS beherrsch und sie sich dort mit Nutzernamen und Passwort anmelden muss. Wenn das nicht zutrifft (bspw. weil der Server auf derselben Maschine wie das Skript läuft) kann man die betreffenden Zeilen einfach auskommentieren.

Insgesamt ein übler Hack, aber wenigstens bekomme ich so meine Mails sauber auf meine Linux-Maschine. Fehlen ja nur noch die Termine, aber das ist eine andere Geschichte...

fetch-exchange.tar.gz – das Skript zusammen mit davlib und qp_xml. Einfach in ein Verzeichnis entpacken und mittels ./fetch-exchange.py starten.

Fehler beim X-Forwarding

nospam@example.com (namenlos) — Fri, 20 Jul 2007 09:45:22 +0200

Weil ich grad ne Weile dran hing: wenn ein X-Forwarding via ssh nicht funktionieren will, obwohl alles korrekt konfiguriert ist und der sshd im logfile folgendes meldet:

Jul 21 09:41:05 kiste sshd[6311]: error: Failed to allocate internet-domain X11 display socket.

dann sollte man mal nach seinem loopback-Device schauen. Ist selbiges nämlich in der Standardkonfiguration nicht aktiv, so wird der sshd mit eben jener Fehlermeldung auf die Nase fallen. Wie auch einige andere Programme.

Vielen Dank an http://giray.devlet.cc/Linux/Laptop/HiGradeNotino3400s/#redhat für den Tritt in die richtige Richtung.

OpenVPN 2.1 mit IPv6-Patch

nospam@example.com (namenlos) — Sun, 01 Jul 2007 16:42:22 +0200

OpenVPN ist für alles was Tunnel quer durch's Netz benötigt ne schicke Sache. Für einen bestimmten Anwendungsfall benötigte ich nun die Möglichkeit, einen Tunnel zu einem nur via IPv6 erreichbaren Server aufzubauen. Leider ist das im Upstream-Code noch nicht drin. Allerdings gibt es bereits seit einiger Zeit einen Patch von JuanJo Ciarlante, der das nachrüstet. Leider passt der gegen die aktuelle 2.1rc4 nur mit händischen Anpassungen (einige Probleme in socket.h). Ich hab daher für alle geneigten Spielkinder ein Debianpaket gebaut. Sollte unter Testing und Ubuntu Feisty Fawn laufen. Andere Systeme sind ungetestet.

mape2k hat ein passendes Paket für OpenWRT im Angebot und außerdem einen Einbau in das Gentoo-Paket veranlasst. Die Gentoo-Entwickler versuchen grad eine Integration in den Upstream-Code hinzubekommen.

Der gepatchte OpenVPN-Daemon versteht nun einige zusätzliche Konfigurationsdirektiven für den Aufbau eines Tunnels über IPv6. Details hält mape2k in seinem Wiki-Eintrag vor.

Download: openvpn_2.1rc4-1_i386.deb (Debian Testing/Ubuntu Feisty Fawn)

Hatschek unter Linux

nospam@example.com (namenlos) — Mon, 25 Jun 2007 20:03:07 +0200

Weil ich's grad gebraucht hab: wenn man das Wort Škoda unter Linux mit einer deutschen Tastatur richtig schreiben will, dann drückt man: AltGr+Shift+ä S. Das AltGr+Shift+ä ergibt den sogenannten Hatschek, der im Tschechischen oder Esperanto vorkommt. Der kommt dann über den danach folgenden Buchstaben.

So, wofür benutz ich das jetzt? Ach ja: um "Škoda" zu schreiben. Merkt man, dass ich grad nach nem neuen Auto suche?

Installation von Cheetah auf Ubuntu

nospam@example.com (namenlos) — Sun, 04 Mar 2007 11:29:59 +0100

Installiert man Pylons nach Anleitung mittels easy_install auf einem Ubuntu Feisty Fawn, dann bricht der Compilerlauf von Cheetah (welches als Abhängigkeit mit installiert wird) unter Umständen irgendwann mit folgender Meldung ab:

src/_namemapper.c:15:58: error: Python.h: No such file or directory

Das liegt daran, daß die passenden Headerfiles nicht in /usr/include/ liegen, sondern in /usr/include/python2.5 (bspw.), wo sie natürlich vom Compiler erstmal nicht gefunden werden. Ein

CFLAGS='-I/usr/include/python2.5' easy_install Pylons

behebt das Problem.

Hintergrundbildchen für KDE

nospam@example.com (namenlos) — Sun, 11 Feb 2007 19:24:48 +0100

Ich schau mir seit einigen Tagen Inkscape an, ein recht schickes Vektorzeichenprogramm, welches Wert darauf legt, standardkonformes SVG zu erzeugen. Nun hab ich mir mal eins der bekannten KDE-Hintergrundbilder genommen und es ein wenig auf Comic-Stil umgearbeitet. Vielleicht gefällt es ja jemandem:

Das Bild gibt es in verschiedenen Größen und natürlich auch im SVG-Original. Sämtliche Dateien stehen unter der Creative Commons Attribution-Share Alike 2.5 Lizenz.

Download: [1024x768] [1280x960] [1400x1050] [1600x1200] [SVG]

Hinweis: Das SVG sinnvollerweise in Inkscape oder ähnlichem öffnen. Leider kommt noch keiner der Browser mit allen eingesetzten Effekten klar. (Hauptsächlich Transparenz und Weichzeichner machen Schwierigkeiten)

Dumm, dümmer, am dümmsten

nospam@example.com (namenlos) — Tue, 15 Aug 2006 11:30:07 +0200

Dumm: Ein Verzeichnis namens ~ versehentlich anlegen.
Dümmer: rm -rf ~ um es zu löschen.
Am dümmsten: Kein Backup haben. *gnaaa*

Glücklicherweise ist es nicht meine private Maschine...

Wenn's mal wieder länger dauert...

nospam@example.com (namenlos) — Sun, 23 Jul 2006 21:11:03 +0200

...mit dem öffnen eines Verzeichnisses im Konqueror, dann kann das unter Umständen daran liegen, daß sich kio_file nicht auf /tmp/fam-<username> verbinden kann. Sieht man sehr schön im strace, wenn als letzte Meldungen da steht:

socket(PF_FILE, SOCK_STREAM, 0)         = 16
connect(16, {sa_family=AF_FILE, path=@/tmp/fam-<username>-}, 110 <unfinished ...>

Abhilfe schafft ein Neustart des fam-Daemon (unter Ubuntu heißt der gam_server. Den einfach killen, der wird neu gestartet). Danach rennt wieder alles wie gewohnt. Jetzt muss ich nur noch rausfinden, wieso der blöde gam_server alle paar Wochen mal abschmiert...

logrotate auf Debian

nospam@example.com (namenlos) — Thu, 13 Apr 2006 23:37:18 +0200

Wenn logrotate scheinbar nicht mehr läuft und die Logfiles daher ins unendliche wachsen, dann sollte man mal nachschauen, ob alle Konfigurationen in Ordnung sind. In meinem Fall war es ein installiertes zope2.7-Paket ohne entsprechende Instanz unter /var/lib/zope2.7/instance/. Da ich meine Zope-Instanzen woanders installiert habe, gibt es dort keine Unterverzeichnisse. Leider erwartet logrotate aufgrund des konfigurierten Jobs dort welche. Die Fehlermeldung sieht dann wie folgt aus:

error: error accessing /var/lib/zope2.7/instance/*/log: No such file or directory
error: zope2.7:24 glob failed for /var/lib/zope2.7/instance/*/log/*.log
run-parts: /etc/cron.daily/logrotate exited with return code 1

Dummerweise bricht damit das Logrotate gänzlich ab und die Logfiles bleiben liegen. Löschen des entsprechenden Jobs in /etc/logrotate.d hilft. Wahlweise natürlich auch das anlegen einer Defaultinstanz für Zope oder die Änderung des Jobs auf das richtige Verzeichnis.

IMP und Cyrus IMAP

nospam@example.com (namenlos) — Sun, 19 Feb 2006 12:06:40 +0100

Der Webmailer IMP ist ein umfassendes Tool zum Zugriff auf einen IMAP-Server mit dem Browser. Sehr praktisch, wenn man mal unterwegs an einem fremden Rechner kurz Mails checken will. Verwendet man nun den Cyrus IMAPd als IMAP-Server, dann kann man in ein paar Probleme laufen. In der IMAP-Spezifikation ist die Verwaltung von Unterordnern direkt in der Mailbox vorgesehen. Grundsätzlich liegen dabei alle Unterordner im Posteingang. Im Cyrus hat man standardmäßig also immer INBOX. (man beachte den Punkt) vorn dran hängen. Davon geht der IMP aus. Desweiteren nimmt er an, daß er den Pfadtrenner selbstständig entdecken kann (der ist normalerweise eben ein Punkt). Hat man nun den Cyrus so eingerichtet, daß der Punkt als ganz normaler Bestandteil des Ordnernamens vorkommen darf, so verwendet der Server nun /als Pfadtrenner. Demnach hätte man nun auch INBOX/ als Präfix für alle Pfadnamen. Leider merkt der IMP das nicht selbst, sondern man muss es ihm sagen. Typisches Fehlerbild ist ein Fehlen der Unterordner von INBOX in der Ordnerliste und in der Horde-Sidebar links im Webmail. Man sieht dann dort bloss den Posteingang, aber keine Unterordner.

Um das zu ändern, muss man in der Datei $IMP_BASE/config/servers.php ($IMP_BASE ist das Installationsverzeichnis der IMP-Installation) etwas anpassen. Dort sucht man den entsprechenden Server raus und ändert die Zeile 'namespace' => 'INBOX.', zu 'namespace' => 'INBOX/',. Außerdem kann man noch die Zeile 'delimiter' => '/', einfügen (aber man sollte sich vorher im klaren sein, was das tut und daß es effektiv die automatische Erkennung des Pfadtrenners abschaltet!). Danach sollte die komplette Ordnerliste an den entsprechenden Stellen sichtbar werden.

Ein weiteres Problem kann entstehen, weil IMP standardmäßig darauf beharrt, zu sendende Mails in INBOX/sent-mail zu speichern (das ist unabhängig von dem Problem oben). Nun legen bspw. der Thunderbird und KMail als Ordner standardmäßig INBOX/Sent an, was effektiv dazu führt, daß man bei wechselseitiger Verwendung eines Mailprogramms und IMPs die gesendeten Nachrichten auf zwei Ordner verteilt. Nun kann man im IMP den entsprechenden Ordner umstellen (unter "Einstellungen"->"Persönliche Einstellungen"->"Ordner für gesendete Nachrichten" [ganz unten irgendwo bei der entsprechenden Identität]). Muss man allerdings für alle Identitäten einzeln machen. Möchte man den Vorgabewert ändern (bspw. auf "Sent"), dann öffnet man die Datei $IMP_BASE/config/prefs.php und sucht folgenden Block:

// sent mail folder
$_prefs['sent_mail_folder'] = array(
    'value' => 'sent-mail',
// For Exchange server uncomment the line below and delete the line above
//    'value' => 'Sent Items',
    'locked' => false,
    'shared' => false,
    'type' => 'implicit');

Wie man schon ahnen kann, ändert man 'value' einfach auf den Namen den Unterordners, in dem die Mails landen sollen (OHNE INBOX/ vorn dran!). Danach neu ins Horde einloggen und schon geht's.

Wenn der Apache plötzlich kein SSL mehr spricht...

nospam@example.com (namenlos) — Wed, 18 Jan 2006 23:51:06 +0100

Da ich gerade meinen Webserver umziehe, bin ich auf ein eher unnettes Problem gestoßen: Wenn man einen SSL-gesicherten Virtual Host von einem Server auf den anderen umzieht, dann sollte man daran denken, in der <VirtualHost IP:443>-Deklaration auch die IP zu ändern. Tut man das nicht, so fängt der Apache nämlich kommentarlos an, auf Port 443 Plaintext zu sprechen, da er kein Interface mit der alten IP findet, auf das er diesen Virtual Host packen kann. Es greift also die eventuell vorhandene Definition ohne Port. Fehlermeldungen oder ähnliches sind leider auch nicht vorhanden, so daß die Suche einigermaßen kompliziert wird...