Ich bin dann so vorgegangen:

1. Beide Platten mit einem SATA2USB-Adapter an den Linux-Desktop-Rechner angeschlossen

2. Mit
   dd if=/dev/sdx of=/dev/sdy bs=1M
   die alte (sdx) auf die neue (sdy) Platte geklont

3. Mit
   gdisk /dev/sdy
   die Platte im GPT-Partitionierungstool geöffnet und eine Partition vom Typ 0700 auf dem Rest der Platte angelegt, mit w bestätigt – das korrigiert die Position der Backup-GPT

4. Die Platte abgestöpselt und in den Mac eingebaut

5. Den Mac gebootet und dort im Festplattendienstprogramm die leere Partition gelöscht und die OS X Partition etwas gestreckt

Klappte prima und erspart mir eine Neuinstallation von OS X. Ich habe jetzt noch Platz, um demnächst Ubuntu drauf unterzubringen.

The content of this blog entry is partially based on the “semi official tutorial” how to cross compile BusyBox and partially on my experience with Linux from Scratch, especially Chapter 5 – Constructing a temporary system. At the time of this being written, I tried to make sure that very few patches are necessary – this will not always be the way, maybe GCC 4.7 will need more patches or BusyBox 1.19 does. uClibc 0.9.32 does not yet build cleanly on x86, thus I stay with uClibc 0.9.31.1 for this time:

Needed files

Sources and patches:

• GNU Binutils 2.21

• GCC 4.6.0 plus gcc-4.6.0-cross_compile-1.patch
• Linux sources 2.6.39.2
• uClibc 0.9.31.1
• BusyBox 1.18.5
• Gmp 5.0.2
• Mpfr 3.0.1
• Mpc 0.9

Configuration files:

• busybox-1.18.5.config
• uClibc-0.9.31.1.config

1. Setting up the environment

Very few modifications to the environment are necessary. We just need three variables:

    export TGTARCH=i486
    export INSTDIR=/usr/local/crosstools
    export PATH=${INSTDIR}/bin:${PATH}

$TGTARCH is the targeted architecture, it should be either i486, i586, i686 or x86_64. Of course it is possible to build for several ARM or MIPS targets if you need a statically linked BusyBox for a rooted Android device or a DSL router. There is one drawback however: My configs for uClibc and BusyBox are very x86 specific. For the first build I recommend using the same target architecture as the machine you are building:

    export TGTARCH=` uname -m `

$INSTDIR is the location of the resulting toolchain. When building for different target architectures, you might also include the name of the target arch into the path. This makes deinstallation easier – you just have to delete a branch in the file system. For example:

    export TGTARCH=i486
    export INSTDIR=/usr/local/uclibc-crosstools-${TGTARCH}
    export PATH=${INSTDIR}/bin:${PATH}

2. Building binutils

Unpack the binutils and create a directory binutils-build on the same level of the file system, then configure binutils:

    tar xvjf binutils-2.21.tar.bz2
    mkdir binutils-build
    cd binutils-build
    ../binutils-2.21/configure \
        --target=${TGTARCH}-linux-uclibc \
        --prefix=${INSTDIR} --disable-nls \
        --disable-werror

Now build and install binutils:

    make && make install

3. Building GCC

As far as I tested, GCC needs a small patch to result in a properly working cross compiler. Besides this, GMP, MPFR and MPC must be present:

    tar xvjf gcc-4.6.0.tar.bz2
    tar xvjf mpfr-3.0.1.tar.bz2
    tar xvjf gmp-5.0.2.tar.bz2
    tar xvzf mpc-0.9.tar.gz
    mv mpfr-3.0.1 gcc-4.6.0/mpfr
    mv gmp-5.0.2 gcc-4.6.0/gmp
    mv mpc-0.9 gcc-4.6.0/mpc
    mkdir gcc-build
    cd gcc-4.6.0
    cat ../gcc-4.6.0-cross_compile-1.patch | patch -p1
    cd ../gcc-build

Now configure, build and install GCC:

    ../gcc-4.6.0/configure \
        --target=${TGTARCH}-linux-uclibc \
        --prefix=${INSTDIR} \
	--disable-nls --disable-shared --disable-multilib \
        --disable-libmudflap --disable-libssp --disable-libgomp \
        --disable-libquadmath --disable-target-libiberty \
        --disable-target-zlib --disable-decimal-float \
        --disable-threads --enable-languages=c \
	--without-ppl --without-cloog
    make && make install

4. Installing kernel headers

The kernel headers used should ressemble the version you intend to run the BusyBox on. Unpack and install them – the sanitizing step is taken from Linux from Scratch:

    tar xvjf linux-2.6.39.2.tar.bz2
    cd linux-2.6.39.2
    make INSTALL_HDR_PATH=dest headers_install
    find dest/include \( -name .install -o -name ..install.cmd \) -delete
    mkdir -p ${INSTDIR}/${TGTARCH}-linux-uclibc/include
    cp -rv dest/include/* ${INSTDIR}/${TGTARCH}-linux-uclibc/include

In the next steps ${INSTDIR}/${TGTARCH}-linux-uclibc will become more populated with headers, libraries and other development files for our build target.

5. Installing uClibc

Unpack uClibc and copy the config into the resulting directory. Since uClibc uses the same configuration scheme as the Linux kernel, some parameters in the config have to be changed with sed, and a run of make oldconfig is needed if you do not run my exact version of uClibc:

    unxz -c uClibc-0.9.31.1.tar.xz | tar xvf -
    cp uClibc-0.9.31.1.config uClibc-0.9.31.1/.config
    cd uClibc-0.9.31.1
    # This fixes the path of the linux headers
    sed -i 's%/usr/local/crosstools/i486-linux-uclibc/include%'${INSTDIR}/${TGTARCH}-linux-uclibc/include'%g' .config
    # This fixes the path to GCC and binutils:
    sed -i 's%/usr/local/crosstools/bin/i486-linux-uclibc-%'${INSTDIR}/bin/${TGTARCH}-linux-uclibc-'%g' .config
    make oldconfig

When building for x86_64 instead of i486-i686, replace the target as well:

    sed -i 's%TARGET_i386=y%#TARGET_i386 is not set%g' .config
    sed -i 's%# TARGET_x86_64 is not set%TARGET_x86_64=y%g' .config
    make oldconfig

Now build and install uClibc:

    make
    make install PREFIX=${INSTDIR}/${TGTARCH}-linux-uclibc/

Everything is in place now. In the next step we are building the statically linked BusyBox:

6. Building BusyBox

Our BusyBox will be statically linked. Since BusyBox also uses the configuration scheme from the Linux kernel, configuration is done by copying the .config file:

    tar xvjf busybox-1.18.5.tar.bz2
    cp busybox-1.18.5.config busybox-1.18.5/.config
    cd busybox-1.18.5
    make oldconfig CROSS_COMPILE=${TGTARCH}-linux-uclibc-

Build BusyBox and install it to the subdirectory _install:

    make CROSS_COMPILE=${TGTARCH}-linux-uclibc-
    make install CROSS_COMPILE=${TGTARCH}-linux-uclibc-

If your build system is x86_64, any i486 to i686 or x86_64 can be directly run. There will be no hassle with libraries since our binary is statically linked:

    # Should result in: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
    file _install/bin/busybox
    # Should print the BusyBox applets contained
    ./_install/bin/busybox

That’s it. Have fun with your BusyBox. In a short time I will tell you how to configure and build a minimal Linux system that just consists of a kernel, BusyBox and Dropbear for SSH logins – that is just enough Linux to do imaging and restoring tasks.

Installation von Debootstrap

Zuerst muss debootstrap vorhanden sein, am einfachsten natürlich mit apt-get install debootstrap. Unter Ubuntu kann mit debootstrap auch die Folgeversion installiert werden. Debian-User können das Ubuntu-Debootstrap direkt von http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/ herunterladen und mit dpkg -i installieren. Nutzer von RPM-Distributionen sollten ein Konvertierungstool installieren oder Debootstrap direkt aus dem .tar.gz installieren.

Vorbereitung eines Images

Für Xen DomUs haben Sie die Möglichkeit, physikalische Festplatten oder deren Partitionen zu nutzen oder Festplattenimages zu verwenden. Bei den Images wiederum gibt es zwei Möglichkeiten: Tap-Disks, die wachsen können und beispielsweise VMware VMDK-Format unterstützen oder “Plain-Images”, die als Loopback-Device gemountet werden können. Ich empfehle bei Testkonfigurationen grundsätzlich und bei Produktivsystemen für die Systempartitionen Images von Partitionen. Die Gründe:

• Im Gegensatz zu partitionierten Festplattenimages kann ein Partitionsimage ohne Verrenkungen vergrößert werden
• Ein Mounten ist simpel mit mount -o loop ... möglich, es muss kein Offset errechnet und angegeben werden
• Im Gegensatz zu VMDK-Images benötigt der Mount auf einer Xen-losen Maschine keine zusätzlichen Werkzeuge

Images erstelle ich als Sparse-Images, das geht schnell und spart Plattenplatz, hat aber bei Maschinen mit vielen Xen-Instanzen deutlich spürbare Einbußen durch doppelte Fragmentierung zur Folge. Zunächst entsteht ein Image für die Systempartition. Da ich gerne auch Kernel in der Xen-Instanz baue, hier 8GB groß, das Swap-Image bekommt ein Gigabyte:

dd if=/dev/zero bs=$((1024**2)) count=1 seek=8191 of=xvda1.img
dd if=/dev/zero bs=$((1024**2)) count=1 seek=1023 of=swap.img

Als nächstes entsteht eine Swap-Signatur und ein Dateisystem auf dem Image xvda1.img. Das Dateisystem mounte ich gleich auf einen noch zu erstellenden Mountpoint /tmp/minibuntu:

mkswap -f swap.img
freeloop=` losetup -f `
losetup $freeloop xvda1.img
echo "loopdevice is $freeloop"
mkfs.ext3 $freeloop
mkdir /tmp/minibuntu
mount $freeloop /tmp/minibuntu

Installation des Basissystems

Die Installation des Basissystems geht innerhalb weniger Minuten mit dem Befehl debootstrap. Auf einem 64-Bit Hostsystem haben Sie die Wahl, 32- oder 64-Bit-Gäste zu installieren. Bei Gästen, die keine allzu große Prozessgröße erwarten lassen, sind 32-Bit-Gäste oft einen Tick flotter und kompakter:

debootstrap --arch i386 lucid /tmp/minibuntu http://archive.ubuntu.com/ubuntu

oder

debootstrap --arch amd64 lucid /tmp/minibuntu http://archive.ubuntu.com/ubuntu

Das so installierte Ubuntu würde sich mit dem Hostkernel schon booten, darüber hinaus jedoch kaum nutzen lassen. Setzen wir einige Einstellungen:

vim /tmp/minibuntu/etc/default/locale

# BEGIN /etc/default/locale
LANG="POSIX"
# oder
# LANG="de_DE.UTF-8"
# END /etc/default/locale

vim /tmp/minibuntu/etc/network/interfaces

# BEGIN /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
# END /etc/network/interfaces

echo '127.0.0.1 localhost' > /tmp/minibuntu/etc/hosts
echo 'lucid-domU.test' > /tmp/minibuntu/etc/hostname

Auch eine vollständige /etc/apt/sources.list wird benötigt:

vim /tmp/minibuntu/etc/apt/sources.list

# BEGIN /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu/ lucid main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid main restricted
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates main restricted
deb http://de.archive.ubuntu.com/ubuntu/ lucid universe
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid universe
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates universe
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates universe
deb http://de.archive.ubuntu.com/ubuntu/ lucid multiverse
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid multiverse
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates multiverse
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates multiverse
deb http://security.ubuntu.com/ubuntu lucid-security main restricted
deb-src http://security.ubuntu.com/ubuntu lucid-security main restricted
deb http://security.ubuntu.com/ubuntu lucid-security universe
deb-src http://security.ubuntu.com/ubuntu lucid-security universe
deb http://security.ubuntu.com/ubuntu lucid-security multiverse
deb-src http://security.ubuntu.com/ubuntu lucid-security multiverse
# END /etc/apt/sources.list

Ohne /etc/fstab geht wenig im domU-System, die Platten heissen nicht mehr wie bei den alten dom0- und domU-Kerneln /dev/sda, sondern /dev/xvda:

vim /tmp/minibuntu/etc/fstab

# BEGIN /etc/fstab
proc /proc proc defaults 0 0
/dev/xvda1 / ext3 defaults 0 1
/dev/xvda2 none swap sw 0 0
# END /etc/fstab

Eine Konsole für Xen. Xen nutzt /dev/hvc0 als Systemkonsole, diese muss noch mit einem getty versehen werden. Das erledigen Sie durch Kopieren der Definition von tty1 und entsprechende Anpassungen:

cp /tmp/minibuntu/etc/init/{tty1,hvc0}.conf
sed -i 's/tty1/hvc0/g' /tmp/minibuntu/etc/init/hvc0.conf

Chroot, Passwort und Kernel

Zum Abschluss der Installation und der Nachinstallation von Software müssen Sie per chroot in das frisch installierte Ubuntu wechseln. Zunächst benötigen Sie dafür einige spezielle Dateisysteme:

mount -t proc none /tmp/minibuntu/proc
mount -t devpts none /tmp/minibuntu/dev/pts 

Wenn Host und Gast die gleiche Architektur nutzen, klappt der Chroot klassisch:

LANG=C chroot /tmp/minibuntu /bin/bash

Ist der Host dagegen 64 bittig und der Gast 32 bittig, ist setarch zu verwenden:

LANG=C setarch i386 chroot /tmp/minibuntu /bin/bash

Zunächst aktivieren wir Shadow-Passwörter und setzen ein Root-Passwort:

shadowconfig on
passwd

Auf 32-Bit-Gästen muss zwingend ein PAE-Kernel installiert werden. Nur dieser enthält Unterstützung für pvops. Kernel ohne PAE laufen nur auf dem “nackten Metall”. Bei 64 Bit sollten alle Kernel pvops unterstützen:

apt-get install linux-image-generic-pae

Da ein Bootloader bei unserer Konfiguration keinen Sinn macht, sind entsprechende Nachfragen mit [No] zu beantworten.

Aufbau des Initramfs

Im Gegensatz zu gängigen Dateisystemtreibern enthält Ubuntus Kernel die Frontend-Treiber für Blockdevices und das Netz nur als Module. Diese sind entsprechend zu Initramfs-Konfiguration hinzuzufügen:

vim.tiny /etc/initramfs-tools/initramfs.conf

MODULES=list

Diese Liste ist entsprechend anzupassen:

vim.tiny /etc/initramfs-tools/modules

# BEGIN /etc/initramfs-tools/modules
xen-kbdfront
xen-netfront
xen-blkfront
# END /etc/initramfs-tools/modules

Und anschließend wird das Initramfs neu aufgebaut:

mkinitramfs -o /boot/initrd.img-2.6.32-24-generic-pae 2.6.32-24-generic-pae

Verlassen Sie nun den Chroot wieder und unmounten Sie die beiden speziellen Dateisysteme.

exit
umount /tmp/minibuntu/proc
umount /tmp/minibuntu/dev/pts

Kopieren der Kernel, Aufbau der domU-Konfiguration

Kopieren Sie nun Kernel und Initramfs von /tmp/minibuntu/boot in das Verzeichnis, welches Festplattenimages und später die Konfiguration enthält. Erstellen Sie dann eine Datei ubuntu.cfg mit folgendem Inhalt (selbstverständlich ist der Pfad zum Installationsverzeichnis anzupassen und Kernel sowie Initramfs umzubenennen oder zu verlinken):

kernel = "/usr/local/xendomains/lucid_test/vmlinuz"
ramdisk = "/usr/local/xendomains/lucid_test/initrd.gz"
memory = 512
name = "lucid-test"
vif = [ 'mac=00:16:00:00:42:23' ]
disk = [ 'file:/usr/local/xendomains/lucid_test/xvda1.img,xvda1,w',
         'file:/usr/local/xendomains/lucid_test/swap.img,xvda2,w' ]
root = '/dev/xvda1 ro'
extra = 'console=hvc0'

Jetzt nicht vergessen, das Loopback-Device zu unmounten und freizugeben:

umount /tmp/minibuntu
umount $freeloop
losetup -d $freeloop

Dann kann auch die neue domU gestartet werden:

xm create -c ubuntu.cfg

Melden Sie sich in der Konsole der domU an und installieren Sie die Xen-Version der C-Bibliothek, sowie OpenSSH nach:

apt-get install ssh libc6-xen

Beim nächsten Mal kann dann die Domain ohne -c gestartet und per SSH zugegriffen werden. Soll die virtuelle Festplatte vergrößert werden, kann dies nach dem Herunterfahren mit dd erfolgen:

dd if=/dev/zero bs=$((1024**2)) count=1 seek=16383 of=xvda1.img
freeloop=` losetup -f`
losetup $freeloop xvda1.img
fsck.ext3 -f $freeloop
resize2fs $freeloop
losetup -d $freeloop

That’s it! Soll die domU automatisch mit dem Xend des Hostes starten, die .cfg in /etc/xen/auto verlinken und darauf achten, dass das Startscript /etc/init.d/xendomains beim Systemstart unmittelbar nach xend gestartet wird. Die so erstellte Domain ist prinzipiell portabel, man sollte sich allerdings keine allzugroßen Hoffnungen auf einen Boot unter alten Xen-Versionen (vor 3.4) machen. Sind noch alte dom0s vorhanden, schafft möglicherweise Ubuntus ec2-Kernel für Amazons Elastic Computing Cloud Abhilfe.

Ich habe einmal testweise ein Setup auf einer AMD64-Maschine erstellt, auf 32-Bit-Systemen sind lediglich einige Kleinigkeiten anders: Der Kernel muss PAE-Support haben und es muss zwingend ein Prozessortyp ausgewählt werden, der über Virtualisierungserweiterungen verfügt. Da heutzutage kaum Rechner als Xen-Host zum Einsatz kommen dürften, die nicht 64-Bit-tauglich sind, sollte sich die Frage nach pvops-Dom0s auf 32-Bit-Hardware kaum stellen.

Die Vorbereitung

Fürs Bauen des Kernels müssen zuerst einige Debian-Pakete nachinstalliert werden. Meine Testmaschine war ein recht blankes Netinstall, so dass diese Liste hoffentlich vollständig ist:

apt-get install build-essential libncurses5-dev python-twisted \
        git-core zlib1g-dev gettext libX11-dev uuid-dev libssl-dev\
        bin86 bcc flex bison python-dev bridge-utils

Auf 64-Bit-Systemen außerdem:

apt-get install libc6-dev-i386

Neuere Xen-Versionen benötigen Intels ACPI-Compiler. Den habe ich noch nicht in den Ubuntu-Paketlisten gefunden, stattdessen habe ich ihn aus den Quellen gebaut und mittels install installiert. Da nur ein einziges Binary benötigt wird, ist es leicht möglich, das temporäre Build-Verzeichnis in den Pfad aufzunehmen und so das System nicht zu verschmutzen. Bitte prüft vor der ACPICA-Installation, ob unter http://www.acpica.org/downloads/ neuere Versionen bereitstehen:

cd /usr/src
wget http://acpica.org/download/acpica-unix-20100806.tar.gz
tar xvzf acpica-unix-20100806.tar.gz
cd acpica-unix-20100806/compiler
make
install -m 0755 iasl /usr/bin

Bau und Boot des pvops-Kernels

Wie eingangs erwähnt, ist Support für pvops-Dom0 noch nicht Teil des offiziellen Kernels. Es muss daher Jeremys 2.6.32er mit pvops-Patches ausgecheckt werden. Falls jemand abkürzen möchte, kann er hier die von mir verwendeten Sourcen herunterladen, diese beinhalten bereits eine .config.

cd /usr/src
git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen
cd linux-2.6-xen
git reset --hard
git checkout -b xen/stable-2.6.32.x origin/xen/stable-2.6.32.x

Beim Selbstbau dürfte es meist ganz gut passen, die Kernelconfig des Ubuntu als Basis zu verwenden und mit make oldconfig die Xen-spezifischen Punkte zu ergänzen. Wer dabei die richtigen Treiber statisch einbindet, braucht auch an der Initramfs-Konfiguration nichts zu modifizieren:

cd /usr/src
cd linux-2.6-xen
cp /boot/config-` uname -r ` .config
make oldconfig

Zum Vergleich hier meine Xen-spezifischen Optionen:

CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=32
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_SWIOTLB_XEN=y
CONFIG_MICROCODE_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_DOM0_PCI=y
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_KBDDEV_FRONTEND=m
CONFIG_HVC_XEN=y
CONFIG_XEN_FBDEV_FRONTEND=m
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_MCE=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_S3=y
CONFIG_ACPI_PROCESSOR_XEN=y
CONFIG_XEN_PLATFORM_PCI=m

Wer möchte, kann meine Konfiguration komplett oder als unified diff (gegen Ubuntus 2.6.32-24 Kernel) herunterladen und diese verwenden. Das Bauen geht dann wie gewohnt, ich strippe die Kernelmodule und erstelle gleich eine GRUB-Konfiguration:

make
make install
make modules_install
find /lib/modules/2.6.32.18-xen0-pvops/ -name '*.ko' -exec strip --strip-unneeded {} \;
mkinitramfs -o /boot/initrd.img-2.6.32.18-xen0-pvops 2.6.32.18-xen0-pvops
update-grub

Der erste Neustart

Rebooten Sie nun den Rechner und wählen Sie den neuen pvops-Kernel als Startkernel aus. Die Maschine sollte problemlos hochfahren, tut sie das nicht, stehen die Chancen schlecht, dass dieser Kernel auch auf Xen sauber startet.

Installation von Xen und den Xen-Tools

Als dieses Tutorial erstellt wurde, war mit Xen 4.0.1 gerade die erste Maintenance-Release der 4.0er-Reihe erhältlich. Falls Sie noch 3.4.x oder 4.0.0 verwenden (und damit zufrieden sind): Aktualisieren Sie auf jeden Fall auf 4.0.1, weil hier einige Bugs im Zusammenspiel von Xen und dom0-pvops-Kerneln beseitigt wurden:

cd /usr/src
wget http://bits.xensource.com/oss-xen/release/4.0.1/xen-4.0.1.tar.gz
tar xvzf xen-4.0.1.tar.gz
cd xen-4.0.1
make xen
make install-xen
make tools
make install-tools PYTHON_PREFIX_ARG=

Es folgt die Erstellung einer Bootloder-Konfiguration, bitte die UUID entsprechend anpassen:

vim.tiny /etc/grub.d/50_xen

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Ubuntu 10.04 - Xen 4.0.1 - 2.6.32.18 pvops" {
        insmod ext2
        set root=(hd0,1)
        search --no-floppy --fs-uuid --set dc50c3d6-787a-45d7-951b-20836d10443c
        multiboot /boot/xen-4.0.1.gz dummy=dummy
        module /boot/vmlinuz-2.6.32.18-xen0-pvops root=UUID=dc50c3d6-787a-45d7-951b-20836d10443c ro dummy=dummy
        module /boot/initrd.img-2.6.32.18-xen0-pvops
}

chmod a+x /etc/grub.d/50_xen
vim.tiny /etc/default/grub

GRUB_DEFAULT="Ubuntu 10.04 - Xen 4.0.1 - 2.6.32.18 pvops"
GRUB_HIDDEN_TIMEOUT=30
GRUB_HIDDEN_TIMEOUT_QUIET=false

Anschließend nicht vergessen, die Grub-Konfiguration noch einmal neu aufzubauen:

update-grub

Ein Dateisystem für Xen: Einige Scripte benäötigen das alte /proc/xen. Dieses wird durch einen Eintrag in der /etc/fstab beim nächsten Neustart gemountet:

xenfs /proc/xen xenfs defaults

Dann benötigen wir noch zwei Module und deren Devices – die Module sollten in die /etc/modules eingetragen werden:

modprobe -v xen-evtchn
modprobe -v xen-gntdev

mkdir /dev/xen
mknod -m 0660 /dev/xen/gntdev c 10 57
mknod -m 0660 /dev/xen/evtchn c 10 58

Das war es: Beim nächsten Neustart startet der eben gebootete pvops-Kernel nicht auf nacktem Metall, sondern auf dem Hypervisor. Mit pvops-Kernel sollte es auch möglich sein, die beschleunigten Grafiktreiber von AMD und nVidia zu nutzen, ausprobiert habe ich dies nicht, weil bei mir Xen nur auf dem Server eingesetzt wird.

Auf die Konfiguration von pvops-DomUs gehe ich in den nächsten Tagen ein: Für diese halten aktuelle Distributionen oft passende Kernel bereit, ich werde jedoch auch zeigen, wie man mit einem frischen Vanilla-Kernel 2.6.35.x ein wenig mehr herausholt.

Vielen Dank an…

• …das offizielle Xen-Blog, an dessen Anleitung ich mich grob orientiert habe
• …die Mitarbeiter des Xen-Wikis, die viele wertvolle Informationen zu pvops zusammengetragen haben

Update, 31. August 2010

• bridge-utils zur Paketliste hinzugefügt
• Ergänzung zu /proc/xen
• Ergänzung zu fehlenden Devices und Modulen

root@caesium:~#  dd if=/dev/sda bs=448 count=1 | strings
1+0 Datensätze ein
1+0 Datensätze aus
448 Bytes (448 B) kopiert, 4,2288e-05 s, 10,6 MB/s
ZRr=
`|f
\|f1
GRUB
Geom
Hard Disk
Read
 Error

Das ist wohl GRUB, beim Syslinux-MBR (Extlinux) sieht die Ausgabe so aus:

RPf1
Missing operating system.
f`f1
|fRfP
Ht[y9Y[
Multiple active partitions.
Operating system load error.

Beim Neuaufsetzen eines Servers ist es besser, gleich eine PointToPoint-Lösung mit 255.255.255.255-Maske aufzusetzen. Damit können bei einer 29-Bit-Maske (255.255.255.248) acht statt fünf IP-Adressen genutzt werden — satte 60% mehr (bei vier, fünf, oder sechs Bit Masken fällt der Gewinn natürlich kleiner aus). Die Änderungen gegenüber dem Setup von gestern sind, dass dummy0 in der /etc/network/interfaces der dom0 entfällt. In der /etc/xen/xend-config.sxp wird das extern erreichbare Interface eingetragen (in der Regel eth0):

(network-script 'network-route netdev=eth0')
(vif-script     'vif-route netdev=eth0')

Die Netzwerkkonfiguration der domU bekommt nun die primäre IP-Adresse der dom0 als Gateway eingetragen, dazu das Schlüsselwort pointopoint (nur ein ‘t’!) und die “dichte” Netzmaske:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 172.16.16.114
        netmask 255.255.255.255
        gateway 192.168.1.2
        pointopoint 192.168.1.2
        post-up ethtool -K eth0 tx off

Vielen Dank an…

• Umstellung Debian Etch mit XEN 3 auf routed …die fleissigen Dokumentatoren im Hetzner-Wiki
• …den Admin bei 1&1, dessen Default-Setup mit pointopoint auf der primären IP mich dazu anregte, hier nochmal nachzuforschen

Ziel waren zwei Server: Ein 64-Bit-System fürs Büro und ein 32-Bit-System für einen alten (AMD Athlon XP 2000, 512MB, 80GB) Hetzner Rootie (Presse-Testsystem). Beide Systeme wurden zunächst mit einem Ubuntu Minimalsystem ausgestattet. Bei Hetzner geschah dies aus dem Notfall-System per debootstrap (fertige OS-Images werden nur einmal am Tag aufgespielt, was stört, wenn man nach einer abgeschossenen Installation neu aufsetzen möchte) und der Server zuhause wurde per Debian-Installer per PXE-Netboot eingerichtet. Die zwei Möglichkeiten, einen Hetzner-Server mit Ubuntu oder Debian auszustatten — debootstrap und den Debian-Installer im SSH-Modus — erkläre ich bei Gelegenheit im Detail.

Benötigte Pakete

Mit dem folgenden Befehl sollten alle Abhängigkeiten aufgelöst werden, die zum Bau von Xen und dem Betrieb einer Dom0 benötigt werden:

apt-get install rsync screen build-essential bin86 bcc libssl-dev \
      gettext libncurses-dev python python-dev pciutils-dev libx11-dev \
      pkg-config python-twisted bridge-utils gawk

Unter 32 Bit-Systemen sollte man aus Performance-Gründen noch die angepasste C-Bibliothek installieren:

apt-get install libc6-xen

Kernel kompilieren

Ubuntu selbst bietet einen Kernel für Amazons EC2, der sollte einigermaßen gut auf aktuellen Xen-Versionen laufen. Getestet habe ich es nicht. Stattdessen habe ich selbst drei Kernel kompiliert: Einen für AMD64 mit vollem Dom0-Support und vielen Treibern, einen mit stark abgespeckten Treibern (für 64Bit-DomUs) und einen i686-Kernel mit vollem Dom0-Support und der Möglichkeit, auf älteren Xen-Versionen gestartet zu werden. Die für Xen benötigten Frontend- sowie Backend-Treiber habe ich statisch integriert, was den Vorteil hat, dass an der Konfiguration des Initramfs nichts geändert werden muss. Alle Konfigurationen bieten Verbesserungspotential, beispielsweise beim Abspecken um nicht benötigte Treiber. Hier sei allerdings darauf verwiesen, dass das Entfernen vermeintlich nicht benötigter Funktionen Unresolved Symbols und damit Kompilationsabbrüche zur Folge haben kann.

Als Kernel kommt hier Gentoos 2.6.31.12 — konkret das Patchset xen-patches-2.6.31-12.tar.bz2 — zum Einsatz. Die verwendeten Patches stammen größtenteils von openSUSEs Xen-Kernel, wurden aber von SuSE-Spezifika befreit. Das macht das Bauen und die Installation einfacher. Gepflegt werden die Patches als eigenes Projekt bei Google Code.

Meine Konfigurationsdateien:

• config-2.6.31.12-mfs002-xen0-compat-i586
• config-2.6.31.12-mfs001-xen0-amd64
• config-2.6.31.12-mfs006-xenU-minimal-amd64

Und nun zum Bauen des Kernels, hier für AMD64:

mkdir xen-patches-2.6.31-12
cd xen-patches-2.6.31-12
tar xvjf ../xen-patches-2.6.31-12.tar.bz2
cd ../linux-2.6.31
for i in ../xen-patches-2.6.31-12/*.patch1 ; do patch -p1 < $i ; done
wget -O .config http://cdprojekte.mattiasschlenker.de/Public/Xen-Kernel/config-2.6.31.12-mfs001-xen0-amd64
make oldconfig
make
make install
make modules_install

Der Kernel braucht noch ein passendes Initramfs, dieses entsteht mit:

mkinitramfs -o /boot/initrd.img-2.6.31.12-mfs001-xen0-amd64 2.6.31.12-mfs001-xen0-amd64

Falls Sie Xen Frontend- oder Backend-Treiber in Module ausgelagert haben, müssen Sie ggf. die Modulliste des Initramfs anpassen!

Xen Hypervisor installieren

Ohne Xen nützt der schönste Kernel nichts, also bauen und installieren wir Xen 3.4.2 aus dem offiziellen Tarball von www.xen.org:

tar xvzf xen-3.4.2.tar.gz
cd xen-3.4.2
make xen
make install-xen

Bootloader konfigurieren

Der einfachste Weg ist die Erstellung eines simplen Scriptes /etc/grub.d/50_xen, welches hart kodiert Kernelnamen, Xen-Version und Pfade (Root-Device ist hier /dev/sda4) enthält. Zweimal root=... ist kein Tippfehler, sondern als Workaround für einen kleinen Bug in den Scripten des Initramfs gedacht:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Ubuntu 9.10 - Xen 3.4.2 + Linux 2.6.31" {
        insmod ext2
        set root=(hd0,4)
        multiboot /boot/xen-3.4.2.gz
        module /boot/vmlinuz-2.6.31.12-mfs001-xen0-amd64 root=/dev/sda4 ro root=/dev/sda4
        module /boot/initrd.img-2.6.31.12-mfs001-xen0-amd64
}

Das Script muss nun noch ausführbar gesetzt werden, sonst wird der neue Eintrag nicht in die GRUB-Konfiguration übernommen!

chmod a+x /etc/grub.d/50_xen

In der Datei /etc/default/grub sollten Sie den Standard-Booteintrag auf den neuen Kernel setzen:

GRUB_DEFAULT="Ubuntu 9.10 - Xen 3.4.2 + Linux 2.6.31"

Danach rufen Sie update-grub auf um die Bootloader-Konfiguration neu aufzubauen. Rebooten Sie jetzt den Rechner mit Xen und dem neuen Kernel.

Installation der Xen-Tools

Die Xen-Tools habe ich in einem frisch entpackten Xen-Tarball kompiliert. Die bei der Installation angegebene Variable ist wichtig, damit die Python-Module in den bei Ubuntu üblichen Pfaden landen. Gibt man diese Variable nicht an, ist es ggf. erforderlich eine Umgebunsvariable PYTHONPATH zu setzen und diese ggf. in das Script /etc/init.d/xend einzubauen:

rm -rf xen-3.4.2
tar xvzf xen-3.4.2.tar.gz
cd xen-3.4.2
make tools
make install-tools PYTHON_PREFIX_ARG=

Wenn alles geklappt hat, lässt sich der Xend starten. Läuft dieser, können die Bootmeldungen des Hypervisors ausgelesen werden.

/etc/init.d/xend start
xm dmesg

Xend in den Runleveln verlinken

Ich habe Xend vor dem SSH-Server verlinkt, den Start der domU-Instanzen danach. Grund waren Probleme mit dem SSH-Server: Upstart (oder der Xend?) versucht diesen neu zu starten, wenn neue Interfaces auftauchen. Das gelingt nicht immer, so dass ich während meiner Tests häufiger ohne SSH da stand. Auf einem Root-Server ist so etwas natürlich ganz bescheiden.

update-rc.d xend start 14 2 3 4 5 . stop 80 0 1 6 .
update-rc.d xendomains start 21 2 3 4 5 . stop 79 0 1 6 .

Vorbereitung für Routing-Setup

Achtung: Siehe auch den Nachtrag vom 19. März für ein besseres Setup!

Provider wie Hetzner oder Strato routen einem Server zugewiesene Subnetze auf dessen primäre IP-Adresse. Deshalb muss bei diesen Servern das Xen-Netzwerk von bridged auf routed umgestellt werden. Achtung: Einige Provider klemmen Server gnadenlos ab, wenn hinter einem Port des Routers bislang unbekannte MAC-Adressen auftauchen. Wer den Xend bei so einem Provider startet, ohne vorher auf routed umgestellt zu haben, fliegt aus der SSH-Verbindung raus und darf mit dem Support telefonieren!

Zuerst wird die Datei /etc/modules um eine Zeile

dummy

für den Dummy-Netzwerk-Adapter erweitert.

Es folgt die statische Konfiguration der primären IP-Adresse auf eth0 und der ersten nutzbaren IP-Adresse auf dummy. In diesem Fall haben wir das Subnetz 172.16.16.112/ 255.255.255.248 (acht Adressen von .112 bis .119) zugewiesen bekommen, .112 ist hier die Adresse des Netzes, .113 wird auf dummy0 gelegt, .114 bis .118 (fünf von acht Adressen) sind für die domUs nutzbar und .119 ist die Broadcast-Adresse:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        gateway 192.168.1.1

auto dummy0
iface dummy0 inet static
        address 172.16.16.113
        netmask 255.255.255.248

In der Konfigurationsdatei /etc/xen/xend-config.sxp des Xend muss die Einstellung von bridged auf routed umgestellt werden. Das zu routende Device muss explizit angegeben werden:

# (network-script network-bridge)
# (vif-script     vif-bridge)
(network-script 'network-route netdev=dummy0')
(vif-script     'vif-route netdev=dummy0')

An dieser Stelle ist ein Neustart des Xend, besser ein Reboot erforderlich. Anschließend können die domUs konfiguriert werden. Die Routing-Informationen werden hierfür in der Client-Config eingetragen:

kernel = "/boot/vmlinuz-2.6.31.12-mfs006-xenU-minimal-amd64"
ramdisk = "/boot/initrd.img-2.6.31.12-mfs006-xenU-minimal-amd64"
memory = 256
name = "ubuntu-amd64-minimal"
vif = [ 'ip=172.16.16.114' , 'mac=00:16:00:00:00:27' ]
disk = [ 'file:/usr/local/xendomains/test01_64/sda1.img,sda1,w' ]
root = "/dev/sda1 ro"
extras = "console=hvc0 xencons=tty"

Daneben ist es erforderlich, die IP-Konfiguration in der /etc/network/interfaces der domU einzutragen -- DHCP möchte ich an dieser Stelle nicht erklären, das würde den Rahmen sprengen.

Vielen Dank an...

• Installing Xen on Ubuntu 9.10 -- Brandon's Blog ...für die Idee mit dem Gentoo-Kernel und die GRUB-Konfiguration
• An introduction to custom Xen networking -- Debian Administration ...für die Hinweise zum Routed-Setup

Anmerkungen:

• Nie erst Ubuntus Xen-Tools 3.3 installieren und dann diese Anleitung durchführen. Das resultierende Versionsmischmasch wird garantiert kein funktionierendes Netzwerk zur Folge haben!

• Details zur domU-Konfiguration bei Hetzner folgen

• Details zur Ubuntu-/Debian-Installation aus Hetzners Rettungssystem folgen

Erster Bootversuch

Meinen ersten Bootversuch unternahm ich mit der aktuellen Testversion der Computerbild-Notfall-CD 2.1. Diese basiert auf “LessLinux“, meiner eigenen LFS basierten Distribution. Da Kernel 2.6.33 einen stabilen JME-Treiber mitbringt (JMicron Gigabit Ethernet) und Unterstützung für viele Atheros-WLAN-Chips hinzufügt war ich neugierig, wie sich diese CD schlagen würde. Das Ergebnis war gar nicht schlecht:

• Ethernet: nutzbar, flott, stabil
• WLAN: nutzbar, stabil, moderate Systemlast
• Grafik: VESA 1024×768 statt nativer 1366×768

Installation von Ubuntu 9.10

Da Ubuntus 2.6.31er-Installationskernel den JME-Treiber nicht kennt, schlug die favorisierte Netzwerkinstallation über unseren “Plug&Install-Server” leider fehl. Ich brannte also eine Xubuntu Alternate Install CD und installierte von dieser. Das folgende Update und die Nachinstallation von build-essential, m4 und libncurses-dev erfolgte über einen Ralink 2561 802.11g USB-Stick.

Kernelkompilierung und Segfaults

Den Kernel 2.6.33 entpackte ich unter /usr/src und kopierte Ubuntus Konfigurationsdatei nach .config. Ein anschließendes make oldconfig fragt nach den neuen Treibern, die aktiviert werden sollen. Als Faustregel gilt, dass Treiber, die als Modul bereitstehen, als Modul gebaut werden sollen und ansonsten der Vorschlag befolgt werden soll.

Seltsames passierte beim anschließenden Lauf von make: Ich hatte mehrere Segfaults. Da diese zunächst in eher exotischen Treibern auftauchten, vermutete ich Probleme im Zusammenspiel Compiler-Kernel-Architektur. Nach mehrfachen Reboots gelang es mir jedoch, den Kernel durchzukompilieren und zu installieren. Ich wählte den nicht ganz Debian konformen Ansatz mit

make
make install
make modules_install
find /lib/modules/2.6.33 -name '*.ko' -exec strip --strip-unneeded {} \;
update-initramfs -c -k 2.6.33
update-grub

Nach dem Reboot mit dem Kernel 2.6.33 lief der Rechner stabil, auch zwei gleichzeitige Kernel-Kompilierungen parallel konnten ihn nicht mehr aus dem Tritt bringen. Ich tendiere nun dazu anzunehmen, dass eher Probleme von Linux 2.6.31 dem Chipsatztreiber oder dem Core i3 ursächlich für das instabile System waren. wer sich den Ärger ersparen möchte, kompiliert den Kernel auf einer anderen Maschine, erstell mit make deb-pkg ein Debian-Paket und installiert dieses anschließend auf dem A52JR.

Teilerfolg und fehlende Grafiktreiber

Mit Kernel 2.6.33 lädt auch Ubuntu 9.10 korrekt jme für die Gigabit-Ethernetkarte und ath9k für die WLAN-Karte, Sound geht und die Webcam funktioniert mit Cheese (das Bild steht halt Kopf). Mein nächster Versuch galt also ATIs Catalyst-Treiber 10.2 vom 16. Februar 2010. Und da verließen sie ihn…

aticonfig: No supported adapters detected

Eine kurze Recherche auf Atis Website ergab, dass für die Mobility Radeon HD 5470 noch keine Treiber bereitstehen – weder für Linux noch für Windows. Da die Mobilversion andere PCI-IDs verwendet als die verwandte Desktopversion, kann diese erst seit Anfang des Jahres ausgelieferte Karte noch nicht zufriedenstellend genutzt werden. Geht die beigelegte Treiber-DVD verloren, schauen auch Windows-Nutzer in die Röhre. Zumindest bis zum nächsten Update der Catalyst-Treiber. Sollte ASUS sich an seinen bisherigen Zyklus halten, stehen um Mitte März die Treiber für Linux bereit, zehn Tage später Windows-Versionen. Solange muss ich wohl noch mit 1024×768 auskommen. Fortsetzung folgt…

Dateien

• Ausgabe von lspci -vv
• Ausgabe von lspci -nn
• Ausgabe von lsusb
• Ausgabe von dmesg (Kernel 2.6.33)
• Verwendete Kernelkonfiguration für Kernel 2.6.33 (benötigt noch Feinschliff)

Probleme bereitete die Installation und Nutzung des VMware-Players, den ich gerne als recht flexible Virtualisierungslösung einsetze.

Das Installationsproblem

Die Installation ist eigentlich simpel: Man setzt das *.bundle auf executable und startet das Paket dann mit Rootrechten. Doch ein Erfolg wollte sich nicht einstellen. Irgendwo auf halber Strecke hängt der Installer und bewegt sich weder vor noch zurück. Greppt man die Ausgabe von ps waux nach gcc-Prozessen durch, wird man schlafende oder wartende Kompilationsvorgänge finden.

Warum das? Die Kompilierung der VMware-Module verursacht viele Warnungen über fehlende Symbole. Daran verschluckt sich nun der umgebende Python-Prozess und nichts geht voran. Die Lösung hat das VMware-Forum parat:

• Man startet die Installation in zwei Fenstern (je mit Rootrechten)
• In einem der Fenster startet man das Bundle mit dem Parameter --ignore-errors
• Im zweiten Fenster tötet man gnadenlos alle Modul-Bauprozesse:
  while true; do killall -9 vmware-modconfig-console; sleep 1; done
  Die Schleife mit Strg+C abbrechen, wenn die Installation durch ist.
• Am Ende hat man zwar eine VMware, aber keine Kernelmodule, die baut man hinterher mit
  vmware-modconfig --console --install-all
• Nun noch den VMware-Dienst neu starten und der Player lässt sich nutzen

Das Mausproblem

Schnell werdet Ihr feststellen, dass die Maus in der VMware hüpft und immer wieder aus der VMware raus oder in sie rein wechselt. Ein vernünftiges Arbeiten ist so nicht möglich.

Die Lösung des Problems hat Rootloot.de herausgefunden: Eine Inkompatibilität, zwischen Ubuntus Gtk+ und dem Gtk, das die VMware erwartet. Der Trick: Einfach die VMware zwingen, das mitgelieferte Gtk+ zu nutzen, auch wenn die Darstellung nicht zu 100% mit dem Rest des Desktops kongruent sein sollte. Am besten per Export einer Umgebungsvariable. Da ich die VMware eh immer aus einer Shell starte, habe ich mich mit

export VMWARE_USE_SHIPPED_GTK=force

beholfen. Bingo, klappt alles!

• Starke Verschlüsselung: Das Backup muss sicherer sein als diese unsägliche ZIP-Verschlüsselung hinreichend sicher sein und ein statistischer Angriff soll keinen Erfolg versprechen.

• Gute Komprimierung: Ich möchte in kurzer Zeit das Backup klein eindampfen können und beim Zugriff effizient entpacken, also nur die Dateien, die ich benötige.

• Mountbares Backup: Ganz ohne vorheriges Entpacken soll ein sofortiger Zugriff auf alle Dateien im Backup möglich sein.

• Keine unverschlüsselten temporären Dateien: Weder beim Packen noch beim Entpacken sollen unverschlüsselte temporäre Dateien anfallen, einerseits aus Sicherheitsgründen, andererseits weil eine temporäre Datei auf einem zufällig verschlüsselten Dateisystem Prozessorlast erzeugt.

Bis vor kurzem habe ich einfach Archive mit Tarballs mit Twofish verschlüsselt (openssl bietet ein komfortables Subkommando) und diese auf DVD gebrannt. Neben den oben genannten Nachteilen kam das Problem dazu, dass auf einem ISO-9660-Dateisystem die Dateigrößengrenze bei 2GB lag.

Meine Lösung sah eine Kombination aus bekannten Technologien vor: Eine Containerdatei sollte per losetup zum blockorientierten Gerät mutieren, dort wiederum sollte mit cryptsetup ein verschlüsselter Datenträger entstehen, der wiederum ein komprimiertes Squashfs-Dateisystem aufnehmen sollte. Klingt kompliziert? Ist es aber nicht:

Benötigt werden die im Tutorial /home reisetauglich verschlüsselt erwähnten Pakete und die squashfs-tools sowie SquashFS-Module für den laufenden Kernel.

Anlegen des Containers und Befüllen mit Daten

Zuerst wird ein Container angelegt, verschlüsselt und dann mit Daten gefüllt

• Erstellen des Containers: Ein Sparse-File mit der maximal zulässigen Größe einer DVD5 (4700372992 Bytes oder 2295104 Blöcke — bei einer DVD9 müssten es 4150388 Blöcke sein) entsteht mit dem folgenden Befehl. Die Datei belegt am Anfang nur 2048 Byte, angezeigt wird dennoch die maximale Größe:

  dd if=/dev/zero bs=2048 count=1 seek=2295103 of=crypt_squash.data

• Erstellen eines Loop-Devices: Mittels losetup entsteht jetzt eine der Datei zugeordnete Blockdevice:

  losetup /dev/loop0 crypt_squash.data

  Sollte /dev/loop0 bereits besetzt sein, zeigt losetup -f freie Loop-Devices.

• Erstellen des Containers: Auf der Loop-Datei wird nun das verschlüsselte Blockgerät vorbereitet:

  cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 -y /dev/loop0

• Öffnen des verschlüsselten Gerätes: Nun wird die verschlüsselte Gerätedatei geöffnent. Das Resultat ist ein Blockdevide /dev/mapper/cryptdvd auf das geschrieben werden und von dem gelesen werden kann. Die Verschlüsselung erfogt hier komplett transparent:

  sudo cryptsetup luksOpen /dev/loop0 cryptdvd

• Erstellen des komprimierten Dateisystems: In /dev/mapper/cryptdvd entsteht nun das komprimierte Dateisystem SquashFS. Weil wir in eine Gerätedatei schreiben, muss explizit -noappend angegeben werden, um diese zu überschreiben. Die restlichen Parameter sind Kosmetik: Ich bevorzuge noch aus Kompatibilitätsgründen Komprimierung mit gzip und möchte nur einen Prozessor einspannen.

  mksquashfs Projekte WichtigeDaten /dev/mapper/cryptdvd  -nolzma -check_data -noappend -processors 1

Test des Containers

Nun ist der Test des Containers dran. Funktioniert das Backup so, wie wir es uns vorgestellt haben?

• Mounten des Containers: Das Cryptdevice existiert ja noch, mounten wir es einfach:

  mkdir /tmp/cryptdvd
  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

  Falls ein unbekanntes Dateisystem angegeben wird, sollten Sie sicherstellen, dass das SquashFS-Modul geladen ist und gegebenenfalls den Dateisystemtyp angeben:

  mount -t squashfs /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten:

  umount /dev/mapper/cryptdvd

• Auflösen des Cryptdevices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices: So stellen wir sicher, dass auch alle Daten im Container gelandet sind und wir gefahrlos brennen können:

  losetup -d /dev/loop0

Brennen der DVD

• Brennen der DVD: cdrecord ist es herzlich egal, was für Daten da gebrannt werden, es bannt unseren Container 1:1 auf den optischen Datenträger:

  cdrecord -v -speed=4 -dev=/dev/scd1 crypt_squash.data

Test der gebrannten DVD — Mounten und Unmounten des Backups

• Loop-Device erstellen: Zunächst entsteht ein Loopdevice auf der gebrannten DVD. Es könnte eigentlich auch ohne funktionieren:

  losetup /dev/loop1 /dev/scd1

• Öffnen des Crypt-Devices: Jetzt wird die Datei /dev/mapper/cryptdvd erzeugt, welche die Entschlüsselung transparent macht. Hier ist die Eingabe des Passwortes erforderlich:

  sudo cryptsetup luksOpen /dev/loop1 cryptdvd

• Mounten des Dateisystems: Möglicherweise ist die Angabe des Dateisystemtyps erforderlich:

  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten wie oben:

  umount /dev/mapper/cryptdvd

• Lösen des Crypt-Devices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices:

  losetup -d /dev/loop1

  Nun kann die DVD entnommen werden.

Die meisten der angegebenen Schritte lassen sich leicht automatisieren, so dass sichere Backups sehr einfach durchgeführt werden können und der Zugriff genauso einfach möglich ist. Ein Manko bleibt: Für das Hinzufügen neuer LUKS-Schlüssel muss der Container natürlich mit dd auf Festplatte transferiert und in ein Loop-Device überführt werden, bevor er neu gebrannt wird.

Nachtrag I: Ich stelle diesen Artikel hiermit unter BY-SA zur Verfügung. Wer möchte, kann ihn also per Copy und Paste ins UbuntuUsers-Wiki (oder andere Wikis) übernehmen und dort weiterbearbeiten, solange auf mich als Urheber verwiesen wird. Viel Spaß damit! creativecommons.org/licenses/by-sa/3.0/de/

Nachtrag II: Da einige Community-Wikis NC-BY-SA verwenden und BY-SA nicht nach NC-BY-SA überführt werden kann, zusätzliche Bereitstellung unter NC-BY-SA. Viel Spaß damit! creativecommons.org/licenses/by-nc-sa/3.0/de/