JavaWS (Java im WebBrowser):
echo "deployment.javaws.jre.0.args=-Djava.net.preferIPv4Stack\=true" >> $HOME/.java/deployment/deployment.properties

Applikationen die direkt auf “/usr/bin/java” zurückgreifen:
cd /usr/bin
mv java java.orig
echo -e '#!/bin/bash\n/usr/bin/java.orig -Djava.net.preferIPv4Stack=true $*' > java
chmod 755 java

Applikationen die $JAVA_OPTS auslesen (z.B. josm):
echo 'export JAVA_OPTS="-Djava.net.preferIPv4Stack=true"' >> $HOME/.bashrc

Dieses Problem tritt wohl nicht auf, wenn man 32 Bit vom Prozessor (64 - 32 = 32) und 96 Bit der IP-Adresse (128 - 32 = 96) ungenutzt lässt.

Sobald ich aber die Suchanfragen genauer betrachtet wollte ist mir Iceweasel abgestürtzt. Die einzelnen Treffer liesen sich noch laden, sobald aber zu weit nach unten gescrollt wurde war es das mit dem Browser. Zuerst hatte ich die diversen installierten Extensions im Verdacht. Das Starten mittels iceweasel -safe-mode hatte leider keinen Erfolg.

Damit blieben ja nur noch die Plugins als Schuldige übrig. In der URL Zeile "about:plugins" eingegeben und alle installierten Plugins gelöscht.

Das Resultat war immer noch das gleiche. Die besagten Seiten liesen sich nicht zuende scrollen. Jetzt noch mal über die Menüführung Java und Java-Script ausschalten, allerdings ohne Erfolg. Aus lauter Verzweiflung noch den Seiten untersagt eigene Schriften zu nutzen. Damit sahen die Seiten zwar "etwas" unschön aus, aber der Crash blieb aus.

Ein Aufruf von strace -o iceweasel.strace icewease und nach dem Crash ein grep -i font iceweasel.strace brachte als letzte Zeile
open(”/var/lib/defoma/fontconfig.d/T/Tahoma.ttf”, O_RDONLY) = -1 ENOENT (No such file or directory)

Diese Datei Tahoma.ttf war ein Symlink der auf eine nicht mehr vorhandene Datei zeigte. Nun noch ein beherzter rm auf diesen Link und schon konnte es endlich mit der Festplattensuche weitergehen.

Ich hatte die Anforderung eine “gute” Verschlüsselung zu verwenden. Hierbei ist meine Wahl auf AES256 gefallen. Das Passwort für diese Verschlüsselung sollte etwas länger sein als die Passwörter die sich ein “normaler” Mensch merken kann. Am sinnigsten ist hier ein mehr oder minder zufälliges Passwort welches dann der bequemlichkeit halber mit einem Passwort abgesichert ist. PGP dürfte hierfür gute Dienste tun.

Das Programm losetup aus dem Debian Paket mount kann allerdings nicht mit Passwörtern aus einer pgp-geschützten Datei umgehen. Diese Fähigkeit besitzten die Programme aus dem Paket loop-aes-utils welche mit “apt-get install loop-aes-utils” schnell installiert sind.

Für die Verschlüsselung ist es notwendig, dass die Module cryptoloop und aes_i586 geladen sind. Falls diese nicht fest im Kernel eingebunden sind können diese mit den Befehlen “modprobe cryptoloop; modprobe aes_i586” nachgeladen werden. Damit das beim nächsten Start automatisch erfolgt bietet es sich an diese Information an die passende Datei mit dem Befehl “echo -e cryptoloop\\naes_i586 >> /etc/modules” anzuhängen.

Nun noch ein Zufallspasswort für die Verschlüsselung erstellen: “head -c 60 /dev/random | uuencode -m - | head -n 2 | tail -n 1 | gpg –symmetric -a >/etc/fskey.gpg“

Das Erstellen der neuen Partition ist nun mit wenigen Schritten zu erledigen:

• losetup -e AES256 -K /etc/fskey.gpg /dev/loop0 /dev/sda7
• mkfs -t ext3 /dev/loop0
• losetup -d /dev/loop0

Die Zeile “/dev/sda7 /crypted ext3 defaults,noauto,loop=/dev/loop0,encryption=AES256,gpgkey=/etc/fskey.gpg” in /etc/fstab genügt um dann die Partition mit dem Befehl “mount /crypted” einzubinden.

Zusätzlich zu einem Passwort als Schutz wollte ich noch einen weiteren Sicherheitsfaktor einfügen (Zwei-Faktor Authentifizierung). Hier befindet sich die Passwortdatei dann auf einem USB-Stick. Dank dem Tool usbmount wird der Speicher automatisch gemounted.

Ein sehr bequemes Hilfsmittel dafür ist die GParted Live-CD. Mit wenigen Mausklicks habe ich die die NTFS Partition um 10G beschnitten und die Swap- und boot-Partitionen nach vorne verschoben. Die root-Partition lies sich aber am keinen Preis verkleinern, auch nicht nach einem Verschieben und anderer Aktionen.

Der Blick in die Ergebnisse der Suchmaschine brachte schnell Klarheit. Aktuell wird wohl das Schrumpfen von XFS Partitionen nicht unterstützt. Um das Ganze doch noch irgendwie zu bewerkstelligen (ohne die Daten auf eine andere Platte via USB auslagern zu müssen) habe ich die neu gewonnenen 10G als ext3 Partition angelegt.

Mit “cp -rap” noch die Daten von der alten XFS Partition auf die neue ext3 Partition kopiert und den Eintrag im Boot-Menü von Grub angepasst und schon steht wieder Plattenplatz für die verschlüsselten Daten zur Verfügung.

Als dann wenige Tage später das erste Paket den Weg in meine Finger fand, war ich doch recht überrascht über dessen Größe und das Gewicht. In das Paket hätte bestimmt das Telefonbuch von Frankfurt hineingepasst was aber vom Gewicht nicht sein konnte. Das Ding hat fast nichts gewogen.

Nachdem ich das Paket mit dem Taschenmesser aufgeschlitzt habe war ich etwas verdutzt. Da ist ja nichts drin! Unter dem Zwischenboden habe ich dann die SD-Karte in ihrem Blister und den Lieferschein gefunden. 2GB sollten genügen um ein paar Photos und kleine Filmchen abzulegen.

Das zweite Paket das ein paar Tage später geliefert wurde war so wie ich es erwartet hatte. Hier wurde kein Platz verschenkt. Die Bücher waren so angeordnet, dass nur noch ganz wenig Freiraum im Paket zu finden war. Warum konnte man die SD-Karte nicht auch in einem passenden Karton bzw. Umschlag verschicken?