Xenisierung eines Kernels für den Betrieb unter EFW2

Da ich EFW2 unter Debian einsetzen möchte, habe ich die Debian-Kernel-Quelltexte mit integrierten Xen-Patches als Ausgangspunkt genommen. Ich habe mir im SRPM des Original-Kernels des EFW2 die auf die Kernel-Quellen angewendeten Patches angesehen und im ersten Anlauf versucht, die auf den Debian-Kernel anzuwenden. Der Erfolg war nur mäßig, da der Debian-Kernel auf 2.6.16 aufbaut, EFW2 aber einen 2.6.9 verwendet. Ich habe dann Patch für Patch geprüft, ob es eine neuere Version gibt oder ob der Patch bereits überholt ist - durchaus möglich, dass ich dabei Details übersehen habe, also keine Gewähr ;-)

Zum Handwerklichen: Ich benutze derzeit die Xen-Kernel aus Debian-Testing (linux-image-2.6.<irgendwas>). Die weichen von den bisher unter Sarge verwendeten (kernel-image-2.6.<irgendwas>) stark darin ab, wie man mit den Quelltexten und Neuübersetzen umgeht. Früher gab es ein Quelltextpaket, dass die passend zu einem Kernel-Image bereitstellte und als Binärpaket zu installieren war, jetzt muss man tatsächlich ein Quellpaket holen und es mit den üblichen Debian-Paketbaumechanismen (debian/rules <bla>) zusammenbauen lassen. Eine grundlegende Anleitung dafür findet sich hier:  http://kernel-handbook.alioth.debian.org/ch-common-tasks.html Die entscheidende Information findet sich am Ende von Abschnitt 4.2:

a) Man bereitet die mit

apt-get source linux-2.6.16-xen-vserver-686

installierten Quellen zunächst

b) vor,

fakeroot debian/rules debian/build debian/stamps
fakeroot make -f debian/rules.gen setup-i386-none-686

c) kann dann die Patches auf den Quelltextbaum anwenden und ihn anschließend mit:

fakeroot make -f debian/rules.gen binary-arch-i386-none-686

übersetzen. <none-686> in b) und c) sollte man durch etwas Sinnvolles ersetzen ;-)

Wenn die Patches, die man in c) vor dem Übersetzen einspielt, Konfigurationsoptionen zum Kernel hinzufügen, ruft man am besten noch mal Schritt b) auf. Dann werden die neuen Optionen wie bei einem "make oldconfig"-Lauf abgefragt.

Zu den Patches - Vorsicht das ist ein Protokoll der Dinge, die ich getan habe. Ich habe es mangels Zeit nicht nachvollzogen, möglich, dass hier Klippen drin sind. Im EFW2-SRPM für den Kernel bin ich auf foldende Kernel-Patches gestoßen.

iptables-1.3.2-pptp-20050720-workaround.patch
iptables-1.3.2.tar.bz2
kernel-2.6.9-2.6.10-layer7-1.2.patch
linux-2.6.11-broken_conntrack_nf_fix.patch
linux-2.6.9-pom-20050720-CONNMARK.patch
openswan-2.4.0.kernel-2.6-natt.patch
patch-o-matic-ng-20050720.tar.bz2

Schon der Versuch, mit dieser Version der patch-o-matic-ng auf den Debian-Kernel loszugehen, scheiterte mit merkwürdigen Meldungen. Folgende Patches habe ich letztlich erfolgreich anwenden können:

iptables-layer7-2.3.patch
openswan-2.4.6.kernel-2.6-natt.patch
patch-o-matic-ng-20060823
iptables-1.3.5-20060823

Nach dem Anwenden dieser Patches ließ sich der Kernel übersetzen. Allerdings habe ich einige CONFIG-Optionen zurücknehmen müssen, die ich im ersten, von den Debian-Tools ausgelösten "make oldconfig"-Lauf mutig aktiviert hatte. Ich habe leider nur den "entscheidenden Teil" der Optionen notiert (müssten alle dem Iptables/Nat?-Lager entstammen): talk, rtsp, quake3, conntrack rpc (udp) ipv4options, ip6t_route).

An den Start bringen: Die herausfallenden Debian-Pakete lassen sich dann auf dem Host-System, das EFW2 unter Xen ausführen soll, installieren - vorausgesetzt sie kolidieren namensmäßig nicht mit dem schon vorhandenen Kernel. Die Kernel mit den Xen-Patches trägt Debian - anders als normale - nicht in den Boot-Loader ein. Auch erzeugt es keine Initrd dafür. Letzteres muss man für Xen zu Fuß machen. Dazu sollten die initramfs-tools installiert sein; mit den Alternativen hatte ich keinen Erfolg.

Ich bin von einem VMware-Image mit EFW2 ausgegangen, habe ein Abbild der Installation in ein tar.gz-Archiv angefertigt, dass auf einem leeren Dateisystem wieder ausgepackt und in Details angepasst (etwa Passwörter neu gesetzt, mount-Punkte auf ein Dateisystem gelenkt et cetera). Außerdem müssen die Module aus dem /lib/modules-Verzeichnis des Hosts in das Xen-DomU-Dateisystem hineinkopiert werden. Dann erstellt man eine Konfigurationsdatei für die DomU, die kann zum Beispiel so aussehen (ich verwende LVM für die Dateisysteme/Platten? der DomUs, es könnten aber auch Image-Dateien sein):

kernel="/boot/vmlinuz-2.6.16-2-xen-vserver-efw2-686"
ramdisk="/boot/initrd.img-2.6.16-2-xen-vserver-efw2-686"
name="efw2"
root="/dev/sda1 ro"
disk=['phy:xenvg/efw2lv,sda1,w']
memory=64
vif=['bridge=xenbr0','bridge=dsl','bridge=xenbr2' ]

Die Netzwerkschnittstellen kommen über Bridge-Interfaces in die DomU. Beim Starten kann man Xen anweisen, die Consolen-Ausgaben beim auszugeben (efw2 ist der Name der in /etc/xen angelegten Konfigurationsdatei für die DomU-Instanz):

xm start efw2 -c 

Bei einem unbehandelten Debian-Kernel in der DomU fallen dabei Meldungen über Module auf, die nicht geladen werden konnten:

ip_conntrack_mms
ip_nat_mms
ip_proto_gre
ip_nat_gre

Nach der Behandlung des Debian-Kernels mit o.g. Patches verschwinden die ersten beiden Warnungen zu den mms-Mdulen, die letzten beiden bleiben. Haben hier die Kernel-/Iptables-Entwickler womöglich etwas umbenannt, sodass die Module gar nicht oder unter einem anderen Namen existieren?

Anpassungen des VMware-Images/tar.gz-Archivs:

Sonstige Informationen:

/usr/sbin/ethconfig wirft eine Fehlermeldung, weil via lspci über die in die DomU gebridgten NICs nichts in Erfahrung zu bringen ist. Das lässt sich verhindern, indem in der Funktion die Variablen name und businfo initialisiert:

        # get card name
        name = "Unknown"
        businfo = "Unknown"

Beim Anwenden neuerer iptables-Patches ist es wichtig, dass auch die User-Land-Werkzeuge ausgetauscht werden (/sbin/iptables und die Dateien in /lib/iptables haben genügt). Bei EFW21 war zusätzlich in /usr/local/lib ein Link iptables auf /lib/iptables zu setzen (das fehlte für 20 in der Dokumentation, war aber wohl auch dort notwendig). Ansonsten scheitern schon simple iptables-Aufruf zum Einrichten von NAT-Regeln.

Auffälligkeiten beim Betrieb in einer Xen-Umgebung: Beim Datentransfer von DomU zu DomU (EFW und mailhost auf einer Maschine in mehreren Xen-Instanzen) "stimmt" etwas mit den tcp-Prüfsummen nicht. Es kommen keine TCP-Verbindungen zustande. Die Xen-Entwickler haben hier wohl irgendwas mit der Prüfsummenberechnung optimiert. Bisher hat es genügt, auf den anderen/nicht EFW-DomUs die Prüfsummenbildung mit ethtool abzuschalten, bei Debian eine ausführbare Datei fix-xen in /etc/network/if-up.d anzulegen:

#!/bin/bash
if [ $IFACE != "lo" ] ; then
        ethtool -K $IFACE tx off
fi

In den Xen-Mailinglistenarchiven (etwa auf  http://marc.theaimsgroup.com) finden sich diverse Diskussionen zu diesem Thema.

Zweiter Anlauf mit Community 2.1

Installiert per VMware und dort als tar.gz geerntet.

Hostnamen/IP-Adressen-Anpassung auch in /etc/hosts!

Irgendwas am Web-Interface war nach der Umstellung der IP-Adresse plötzlich kaputt.