How to create encrypted loopback images with dm-crypt and LUKS + automatically mounting them after login with pam_mount

I recommend using debian squeeze for this scenario as lenny includes a very old version of libpam-mount and I had lots of problems when I tried using it.
Using only the libpam-mount package and its dependencies from squeeze maybe (I didn’t try it and I wouldn’t recommend it either) does the job too, but at least has a very bitter after taste if you take a closer look at the dependencies.

1. Make sure you have the required kernel modules loaded. If you use the stock debian kernel, this will be the case. if you don’t, make sure you’ve set the following options:

• CONFIG_BLK_DEV_DM=y or CONFIG_BLK_DEV_DM=M
• CONFIG_DM_CRYPT=y or CONFIG_DM_CRYPT=M
• CONFIG_CRYPTO_CBC=y

Additionally, you need to include support for at least one cipher.

In make menuconfig, you can find the required kernel modules at the following locations:

Device Drivers  --->
	Multi-device support (RAID and LVM)  --->
		<*> Device mapper support
		<*> Crypt target support

Cryptographic options  --->
	 SHA256 digest algorithm
	 AES cipher algorithms (x86_64)

To avoid a reboot, you can build all of these options as modules. If you chose to do so, you can later load the modules by using modprobe .

2. Install the required packages
apt-get install cryptsetup libpam-mount
…apt-get should take care of all dependencies

3. Generate a random key and assign it to a variable for later use

KEY=`tr -cd [:graph:] < /dev/urandom | head -c 79`

4. Encrypt the key and save it to a file

echo $KEY | openssl aes-256-cbc > container.key

5. Create the loopback file and fill it with random data

dd if=/dev/urandom of=~/container.img bs=1G count=10

This will create a 10GB file and fill it with random data taken from /dev/urandom.
Another option (which will be much faster especially on older hardware) is using /dev/zero to fill the loopback file with zeros:

dd if=/dev/zero of=~/container.img bs=1G count=10

6. Set up a loop device

losetup /dev/loop0 ~/container.img

7. LuksFormat it

echo $KEY | cryptsetup -v -c aes -s 256 luksFormat /dev/loop0

8. Open it

cryptsetup luksOpen /dev/loop0 container

9. Make a filesystem of your choice

mkfs.xfs /dev/mapper/container

10. Close it and delete loop

cryptsetup luksClose container && losetup -d /dev/loop0

11. Configure pam_mount
Open /etc/security/pam_mount.conf.xml in your favorite text editor and change it to the following:

<?xml version="1.0" encoding="utf-8" ?>

<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<pam_mount>
	<debug enable="1" />
	<mkmountpoint enable="1" remove="true" />

	<msg-sessionpw>reenter password for pam_mount:</msg-sessionpw>
	<volume user="foobar" path="/home/foobar/container.img" mountpoint="/home/foobar/containercontents"
		options="cipher=aes-cbc-essiv:sha256,hash=sha512,keysize=256" fstype="crypt" fskeycipher="aes-256-cbc"

		fskeypath="/home/foobar/container.key" fskeyhash="md5" />
</pam_mount>

Using this configuration the image /home/foobar/container.img will get mounted into /home/foobar/containercontents when the user foobar logs in.
Enabling debugging is pretty usefull if something isn't working as it should. In this case you can take a look at /var/log/auth.log.

12. Include /etc/pam.d/common-pammount in the PAM configuration files of the services that should use it (for example: SSHd)
Open /etc/security/sshd in your favorite text editor. Look for the line "@include common-session" and add a new line after it:

...
@include common-session
@include common-pammount
...

13. If needed, change the configuration of the relevant services (for example: SSHd)
Open /etc/ssh/sshd_config in your favority text editor and make sure you have the following lines in there:

# pam_mount
UsePAM yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePrivilegeSeparation no
PermitUserEnvironment yes

If you disable PasswordAuthentication and use keys instead you have to enter the users password after connecting via SSH.

14. Test if anything works as expected
Open a root session or use sudo and watch the auth log by using tail -f /var/log/auth.log. Then login as the user for which you have configured a volume earlier.
If the encrypted loopback image gets mounted, also test if it gets unmounted again, when the user logs out.
If anything works remove the debug line from /etc/security/pam_mount.conf.xml.

Many thanks go to the users tuxophil and pillgrim from the gentoo forums. Large parts of this howto were taken from their postings at http://forums.gentoo.org/viewtopic-t-274651.html.

When I was trying to automatically mount an encrypted image at login using pam_mount, I encountered a strange problem:
I wasn’t able to find any errors in my configuration (at least none connected to this behaviour), but mount.crypt was unable to mount the image.
Enabling debugging in pam_mount.conf.xml (<debug enable="1" />) revealed the command used for mounting:

pam_mount(misc.c:272) command: mount.crypt [-o loop] [/home/foobar/container] [/home/foobar/crypto]

In Debians libpam-mount 0.44-1+lenny3, /sbin/mount.crypt is a bash script that calls cryptsetup with parameters generated during its runtime.
Debugging it (set -x), I stumpled upon the following command:

cryptsetup -c aes -h ripemd160 -s 256 create _home_foobar_container /home/foobar/container

…which returned the following error message:

Command failed: BLKROGET failed on device: Inappropriate ioctl for device

So mount.crypt has been passed the loop option but cryptsetup was told to mount the encrypted image instead of the associated loopback device (normally mount.crypt executes losetup to create this association in its function _losetup, but this apparently has never been called).

Long story short:
There seems to be a bug in Debians libpam-mount 0.44-1+lenny3.
The case statement at line 110 in /sbin/mount.crypt doesn’t work as expected because the variable $KEY used for option comparison has an ordinary space at its values beginning.
To fix this, you can either change the way how passed options are saved in the OPTION variable (starting at line 60) or change line 110 to the following:

case ${KEY/ /} in

This will remove all spaces.

Eigentlich ist suPHP eine nette Sache. Das Apache Modul mod_suphp sorgt in Kombination mit einem SetUID Binary dafür, dass PHP-Skripte mit den Berechtigungen des Benutzers, dem sie gehören, ausgeführt werden. Damit das funktioniert muss man in Binär-Distributionen wie etwa Debian Linux nicht mehr tun, als dass Modul zu installieren, einen Blick auf dessen Konfiguration zu werfen und es anschließend zu aktivieren. Vielleicht ist es gerade diese Einfachheit (deren Preis die Starrheit ist), die es so beliebt macht.

Ein großes Problem tut sich aber dann auf, wenn man PHP-Caches wie APC, TurckMM oder eAccelerator verwenden möchte. Denn all diese Caches funktionieren nicht im Zusammenspiel mit suPHP. Zwar lässt sich eine solche Kombination verwenden, doch ist sie leider nutzlos, da nichts gecached wird.

Eine wundervolle Alternative zu der Verwendung von suPHP ist eine Kombination aus Apache, SuExec, FCGID und PHP-CGI. Mit dieser Kombination funktioniert auch das Caching problemlos. Eine Anleitung zum Aufsetzen dieser Kombination findet sich bei Hetzner.de.

Wer seine Websites nicht in dem von der jeweils genutzten Linux Distribution dafür vorgesehenen Verzeichnis ablegt sondern stattdessen beispielsweise in /home/*/public_html/ muss darauf achten, SuExec selbst zu kompilieren oder auf Debian-Systemen die gepatchte Version apache2-suexec-common zu verwenden. Aus Sicherheitsgründen erwartet SuExec bereits bei der Kompilierung den Pfad zum Docroot. Bei der Verwendung von apache2-suexec-common lässt sich das Docroot in der Datei /etc/apache2/suexec/www-data angeben.

Das Loop Disk Image einer XEN DomU ist zu klein geworden? Solang die Festplatte des Hypervisors noch genügend Platzreserven hat, ist das glücklicherweise kein unlösbares Problem. Loop Disk Images können mit Bordmitteln vergrößert werden. Zwei kleine Beispiele für die Vorgehensweise bei EXT2, EXT3 und XFS Dateisystem:

EXT2 / EXT3 Dateisystem
VM herunterfahren:

xm shutdown domu.blub.local

Image um 30GB vergrößern:

dd if=/dev/zero bs=1024k count=30720 >> disk.img

Fehler im Dateisystem korrigieren:

e2fsck -f disk.img

Dateisystem auf die Größe des Images vergrößern:

resize2fs disk.img

XFS Dateisystem
VM herunterfahren:

xm shutdown domu.blub.local

Image um 30GB vergrößern:

dd if=/dev/zero bs=1024k count=30720 >> disk.img

Fehler im Dateisystem korrigieren:

xfs_repair -f disk.img

Dateisystem auf die Größe des Images vergrößern:

mount disk.img /mnt/tmp/ -o loop
xfs_growfs -d /mnt/tmp/

Mir sind gerade fast die Augen rausgefallen als ich bei einem Blick ins Error-Log des Apache Webservers unter Debian Etch abertausende Zeilen mit der Fehlermeldung "PHP Warning: Module ‘json’ already loaded in Unknown on line 0" sah. Jeder Seitenaufruf erzeugte diesen Fehler. Die installierten Pakete (php5-cgi + Module sowie apache2 + Module) entstammen dem offiziellen Debian Etch Repository, das Problem betrifft also wahrscheinlich auch noch viele weitere Systeme, bei denen nicht ständig ins Error-Log geschaut wird. Wahrscheinlich wird beim Start des php-cgi Prozesses noch eine andere Konfigurationsdatei als /etc/php5/cgi/php.ini, mit der Anweisung das Modul zu laden, ausgelesen.

Beheben lässt sich das Problem durch das Editieren von /etc/php5/cgi/php.ini. Dort die Zeile, die das json-Modul lädt, einfach auskommentieren und den Apache neustarten.

Was ist Code ohne Dokumentation? Genau: total daneben.

Zum Glück gibt es ja praktische Helfer wie phpDocumentor, um aus Kommentaren eine richtig anständige Dokumentation zu zaubern. Aber das verdammte Ding nach jedem SVN commit anzustoßen ist auf Dauer ganz schön nervig…

Abhilfe verspricht der post-commit hook. In dem Wurzelverzeichnis jedes SVN Repositorys befindet sich ein Verzeichnis namens hooks. Dort können beliebige ausführbare Dateien hinterlegt werden, die je nach deren Dateinamen zu einem bestimmten Zeitpunkt ausgeführt werden (Beispiele / Templates sind bereits in dem Verzeichnis enthalten).
Um phpDocumentor nach einem erfolgreichen SVN commit zu starten kann man ein Bash-script verwenden, indem man diesem den Dateinamen post-commit verpasst und das Executebit setzt (chmod +x foo).

Der Ablauf im Script ist dann wie folgt:
1. SVN checkout anwerfen
2. phpdoc -d anwerfen
3. Quellcode löschen (bei Bedarf)

Das Script bekommt bei seinem Aufruf 2 Argumente: den absoluten Pfad zum betroffenen Repository sowie die Reversion nach dem commit.

Besonders praktisch finde ich daran die Möglichkeit den Quelltext zusammen mit der entsprechenden Dokumentation im Intranet zugänglich zu machen.

pdftk
pdftk ist eine Open Source Software, die es ermöglicht, PDF-Dateien per Kommandozeile zu bearbeiten. Zu den vielfältigen Features von pdftk gehört etwa die Möglichkeit PDFs übereinander zu legen.

pdftk statisch kompilieren

Einleitung
Möchte man pdftk statisch kompilieren, um es etwa auf einem Hetzner Managed Server betreiben zu können, müssen die mitgelieferten Java Bibliotheken statisch kompiliert werden. Um dies zu erreich genügt es sowohl bei pdftk 1.21 als auch bei pdftk 1.41, die Makefiles
anzupassen – von Änderungen am Quelltext bleibt man verschont. Es ist übrigens durchaus sinnvoll, pdftk als 32bit Applikation zu kompilieren, denn nur so läuft es auf nahezu jedem Linuxsystem – ohne dass man sich auch noch mit Cross-Compiling herumschlagen muss.

Makefiles anpassen
Nachdem man pdftk heruntergeladen hat, das Archiv entpackt hat und in das neue Verzeichnis gewechselt hat, gilt es die Dateien Makefile.Base und Makefile.DEINE-DISTRIBUTION bzw. Makefile.Generic anzupassen. Diese befinden sich im Unterverzeichnis pdftk.

Makefile.Generic / Makefile.DEINE-DISTRIBUTION
In der Datei Makefile.Generic (bzw. in der Datei, die make mit dem Parameter -f übergeben wird, z.B. make -f Makefile.RedHat) werden die Flags für den Gnu Java Compiler GCJ gesetzt:

# itext compiler flags
export GCJFLAGS=

Um GCJ anzuweisen, die (mitgelieferten) Java Bibliotheken statisch zu kompilieren, müssen die GCJFLAGS wie folgt geändert werden:
export GCJFLAGS= -static

In diesem Makefile werden auch die Flags für den C++-Compiler g++ gesetzt.
Default hat die Entsprechende Konstante in dem Makefile Makefile.RedHat folgenden Wert:
CXXFLAGS= -lrt -ldl -lgcj

Auch diese Flags müssen angepasst werden:
CXXFLAGS= -W1,-v -static -W1,-Bstatic -lgcj -lpthread -lm -lz -ldl -lrt -W1,-Bdynamic -lsupc++ -lstdc++ -lc

Die Flags, die mit “-W1,” beginnen, werden an den Linker ld übergeben. Abgesehen von libc, libsupc++ und libstdc++ werden alle Bibliotheken statisch gelinkt, um deren dynamische Versionen auf dem Zielsystem nicht erforderlich zu machen (auf den Managed Servern von
Hetzner ist beispielsweise keine (dynamische) libgcj installiert).

Makefile.Base
In der Datei Makefile.Base werden Konfigurationen vorgenommen, die weniger Distributionsabhängig sind, als jene in den anderen Makefiles. Der Entwickler von pdftk hielt sie offenbar sogar für komplett Distributionsabhängig, deshalb wird dieses Makefile von allen anderen
eingebunden. Für das Vorhaben pdftk statisch zu kompilieren ist sie eigentlich uninteressant – es sei denn man erhält (wie bei mir während des Linkens von pdftk 1.41 passiert) eine Fehlermeldung im Stil von “multiple definition of `convert’”.
pdftk liefert nämlich selbst alte Java Bibliotheken mit. Im Beispiel von Convert reicht es die betreffende Zeile im Makefile auszukommentieren, um das Problem zu beheben:

libgcj_local_libs = \
$(java_libs_root)/java_local/security/security.a \
$(java_libs_root)/gnu_local/java/security/provider/provider.a \
$(java_libs_root)/gnu_local/java/security/security.a# \
#$(java_libs_root)/gnu/gcj/convert/convert.a

Tücken
GCC Versionen
Die aktuelle Version von pdftk stammt vom 28. November 2006 – anders ausgedrückt: pdftk wird nicht mehr aktualisiert. Da sich die GNU Compiler Collection jedoch mit jeder neuen Version ändert und beispielsweise strikter wird, was Syntax angeht, lassen sich pdftk Version 1.21 sowie pdftk 1.41 am besten mit alten Compilern kompilieren. Ich habe pdftk 1.21 erfolgreich mit GCC 3.4.5 kompiliert sowie pdftk 1.41 mit GCC 4.0.4. Statt sein System hierfür vollzumüllen
kann ich die Installation von Fedora Core 2 in einer VM (z.B. der kostenlose VMWare Server) empfehlen.

Statische Libraries mit “falschen” (unerwarteten) Dateinamen
Während des Kompilierens von pdftk werden u.a. die statischen Bibliotheken libgcj.a und libgcc_s.a erwartet. Sind die entsprechenden Pakete (meist libgcc-devel, libgcj-devel o.ä.) installiert, kann es trotzdem sein, dass die entsprechenden Dateien nicht vom Linker ld
gefunden werden können. In meinem Fall hat sich libgcj.a unter dem Dateinamen libgcj_bc.so versteckt, libgcc_s.a hieß libgcc_s.so.1. Ein Symlink (ls -s) auf den richtigen Dateinamen behebt dieses Problem.
Die GCC Bibliotheken befinden sich bei Linuxdistributionen standardmäßig im Verzeichnis /usr/lib/gcc/*/.

GCC 4.0.4 auf Fedora Core 2 kompilieren
GCC 3.4 ist auf Fedora Core 2 bereits installiert. GCC 4.0.4 kann auf einem der zahlreichen GCC Mirrors heruntergeladen werden.

GCC 4.0.4 habe ich wie folgt konfiguriert / kompiliert / installiert:
tar jxf gcc*.tar.bz2
cd gcc-*
mkdir objdir && cd objdir
../configure --enable-languages=c,c++,java --prefix=/opt --enable-threads=posix && make && make -k check
make install

Wer sich ein frisches Ubuntu Linux installiert und anschließend wahllos ein Upgrade auf aktuelle Pakete fährt sollte damit rechnen, dass sein System anschließend nicht mehr einwandfrei funktionsfähig ist.
Dies wurde mir erst heute wieder bewusst, als ich auf meiner Workstation ein apt-get update && apt-get upgrade durchgeführt hatte. Anschließend hatte ich mit einem lästigen Fehler zu kämpfen: Viele Programme verweigerten ihren Dienst mit der Fehlermeldung Bus-Error. Ein Bus Error entsteht für gewöhnlich, wenn die CPU versucht auf Speicher zuzugreifen, den sie physikalisch nicht adressieren kann. Ein weiterer möglicher Grund ist ein Hardware-Fehler. Doch mein Rechner lief ansonsten einwandfrei und auch Windows machte keine Murren.

Der Grund für das Problem liegt in einem Fehler in den Ubuntu libc6 Paketen. Ein simples apt-get –reinstall install libc6 && apt-get –reinstall install libc6-i386 (als root! also vorher: sudo su) schafft Abhilfe.

Wer seinen Usern die Möglichkeit geben möchte Videos hochzuladen und beim Abspielen Kompabilitäts-Probleme vermeiden möchte kommt um FLV (Flash Video) nicht vorbei, denn den Flash-Player hat eigentlich jeder installiert und aktiviert. Der Download eines extra Players bzw. Codecs entfällt so auch bei exotischeren Betriebssystemen.

Mit FFmpeg lassen sich diverse Videotypen in das FLV Format konvertieren. Da man aus PHP Skripten heraus beliebige Prozesse mit den Rechten des Benutzers, der PHP ausführt, starten kann, lässt sich FFmpeg auch sehr gut in einem PHP Skript verwenden um Videos direkt nach dem Upload automatisch zu konvertieren.

1. Download, Kompilieren und Installation von LAME:
Auf Sourceforge gehen und aktuellste Version auswählen, Download URL kopieren und per wget auf dem Server herunterladen, also z.B. wget http://surfnet.dl.sourceforge.net/sourceforge/lame/lame-3.97.tar.gz
Nach dem Download den Tarball mit tar zxf lame-3.97.tar.gz entpacken und mit cd lame-3.97 in das Verzeichnis wechseln. Nun das Configure-Skript durchlaufen lassen, kompilieren und installieren: ./configure && make && sudo make install

2. Download, Kompilieren und Installation von FFmpeg:
FFmpeg Sources runterladen: wget http://ffmpeg.mplayerhq.hu/ffmpeg-export-snapshot.tar.bz2 , mit tar jxf ffmpeg-export* entpacken. Jetzt das Configure-Skript durchlaufen lassen, kompilieren und installieren: ./configure –enable-libmp3lame && make && sudo make install

3. FFmpeg von PHP aus starten:
<?php
system(”/usr/local/bin/ffmpeg -i input.mov -ar 22050 -ab 56 -aspect 4:3 -b 200 -r 12 -f flv -s 320×240 -acodec mp3 -ac 1 output.flv”);
?>

Tipp: Wenn FFmpeg den Start verweigert weil es libmp3lame.so.0 nicht finden konnte muss das Configure-Skript von LAME mit –prefix=/usr aufgerufen werden.