Linux

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*

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.

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

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?

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.

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

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

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.

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.

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

shfs ist ein Linux-Kernelmodul zum Mounten von Dateisystemen über SSH. Es ist nur für diese eine Aufgabe da und daher meiner Meinung nach wesentlich einfacher einzurichten als bspw. FUSE. Leider hat es so seine Probleme mit dem GCC 4.x. Dieser meldet nämlich beim kompilieren des letzten Releases shfs 0.35:

/usr/src/shfs-0.35/shfs/Linux-2.6/dir.c:491: error: static declaration of 'shfs_dentry_operations' follows non-static declaration
/usr/src/shfs-0.35/shfs/Linux-2.6/shfs_fs.h:53: error: previous declaration of 'shfs_dentry_operations' was here

(Das Beispiel ist hier für einen 2.6er Kernel.). Die Lösung ist so simpel, wie wirkungsvoll: man entferne in der dir.c in Zeile 491 das static vor struct. Ich bin mir im Moment nicht 100% sicher, was static an dieser Stelle bewirken sollte. Ich vermute, daß es die struct außerhalb der compile unit verfügbar machen soll. Das eledigt nun allerdings scheinbar schon das extern in shfs_fs.h:53. Falls ich mich irre: Kommentare gern erbeten!.