© blende 10, Fotolia.com

Mit Kiwi lassen sich im Handumdrehen Suse-Images unterschiedlichster Art erzeugen. Dank eines angepassten Yast-Pakets klappt das nun auch von der grafischen Oberfläche aus .

Der chinesische Strahlengriffel (Actinidia Deliciosa oder Chinensis, [1]) lässt für den Open-Suse-Freund kaum Wünsche offen. Neben CD-, DVD- oder USB-Stick-Images erzeugt Kiwi auch für die gängigen Virtualisierungslösungen Xen und VMware direkt bootbare Abbilder per Mausklick. Bei Bedarf stellt der Benutzer Images per PXE zum Netzwerkboot bereit oder flasht mit dem OEM/Raw-Format Thin Clients direkt per »dd« oder »dd_rescue«. Soweit die Theorie. Doch gerade das Zusammenspiel mit Yast sorgt immer wieder für Magenprobleme.

Kiwi-Enterprise und -Vorlagen

Dabei ist Kiwi nicht auf Open Suse beschränkt, sondern bietet ebenfalls die Möglichkeit, zusammen mit SLES eine eigens angepasste Enterprise-Distribution zu erzeugen. Das Paket »kiwi-templates« liefert sogar generische Vorlagen, zum Beispiel als Basis für ein “Just enough Operating System” (JEOS), also eine abgespeckte, für den geplanten Einsatzzweck maßgeschneiderte Minimalausgabe der jeweiligen Distribution.

In der Theorie nutzt der Admin den Yast2 Image Creator (Abbildung 1), in der deutschen Version etwas gewöhnungsbedürftig “Bildersteller” genannt, um bequem über die grafische Oberfläche ein Suse-Image zu erstellen. Aber das Yast-Modul, in der Rubrik »Andere« zu finden, kann zurzeit nicht mit der schnellen Entwicklung von Kiwi selbst mithalten.

Abbildung 1: Auch ein USB-Stick lässt sich mit Kiwi und dem Yast2 Image Creator per Mausklick zusammenbauen, darüber hinaus aber auch CDs, DVDs und Images für virtuelle Systeme.

Unter Open Suse 11.1 ist es gar nicht mit der aktuellen Version der Beerenfrucht kompatibel. Das Problem liegt beim Zusammenspiel zwischen Kiwi und dem durch Yast erzeugten XML-Schema in Version 2.0 statt in der erwarteten 2.4, woraus Kiwi sogar Version 3.5 macht. Die Erzeugung des Image schlägt deshalb komplett fehl.

Der Autor dieses Artikels hat eine um den Fehler bereinigte Version von Image Creator erstellt, die RPM-Datei findet sich auf der DELUG-DVD und online unter [2]. Die Installation ist einfach: Listing 1 zeigt, wie sich der Strahlengriffel samt Bildersteller in vier Schritten an der Befehlszeile erfolgreich einrichten lässt. Zypper fügt das passende Repository dem System hinzu, dann installiert der Admin die Pakete und das gefixte RPM-File. In diesem Beispiel nimmt der Admin einfach alle verfügbaren Kiwi-Module zur Installation mit (Abbildung 2). Damit lässt sich später jeder unterstützte Image-Typ erzeugen.

01 zypper ar http://download.opensuse.org/repositories/Virtualization:/Appliances/openSUSE_11.1/Virtualization: Appliances.repo
04 zypper ref
05 zypper in kiwi-*
06 rpm -Uvh http://medozas.de/yast2-product-creator-2.18.9-11.23.noarch.rpm

Abbildung 2: Umfangreich: Mit den richtigen Repositories gibt’s auch in der Yast-Softwareverwaltung eine stattliche Auswahl an Kiwi-Software.

Gefixt: Image Creator

Mit der bereinigten Version lässt sich die Distribution im Image mit nur wenigen Mausklicks vielfältig anpassen. Zunächst wählt der Benutzer Repository, Ausgabeverzeichnis, Abbildtyp und Abbildname. Für Kiwi-Einsteiger bietet es sich an, das unkomplizierte Hinzufügen und Entfernen von Paketen oder ganzen Paketgruppen zunächst mit einem USB-Stick auszuprobieren.

Die Templates aus dem mit Kiwi mitgelieferten Paket »kiwi-templates« lassen sich ebenso mit dem Image Creator importieren und nachträglich anpassen. Sie liegen unter »/usr/share/kiwi/image/«. Damit im Image Creator der Import über das Optionsfeld »Basierend auf bestehender Konfiguration« einfacher funktioniert, sollte der Admin die gewünschten Verzeichnisse mit den XML-Vorlagen von »/usr/share/kiwi/image/« nach »/var/lib/YaST2/product-creator/images« kopieren.

Für das neugeschaffene Abbild kann er auf den weiteren Registerkarten des Yast-Moduls Benutzer vorgeben und eigene Skripte oder Verzeichnisse einbinden (Abbildung 3). Wer schnell und effektiv immer wieder neue Versionen von Images erzeugen will, muss die aktuellen Suse-Repositories natürlich auf dem gewünschten Image-Build-System lokal vorhalten. Die üblichen Verdächtigen unter den Suse-Repositories (also OSS und Update) lassen sich mit Rsync schnell und bandbreiteneffizient als lokaler Mirror anlegen.

Abbildung 3: Für die Benutzerverwaltung verwendet der Admin nahezu die gleichen Dialoge wie in den bekannten Yast-Modulen.

Lokale Repositories mit Reposync

Das Synchronisations-Skript »suse-reposync« (Listing 2; ebenfalls auf der DVD und unter [3]) vereinfacht dies noch etwas: Mit ihm lassen sich die aktuellen Repositories herunterladen und als Basis einer eigenen Suse-Fabrik mittels Kiwi verwenden. Welche Verzeichnisse dabei eine Rolle spielen, zeigt der Rsync-Code im Listing: »+« schließt das genannte Directory ein, »-« exkludiert Deltas und Patches.

01 #!/bin/bash
02 #export RSYNC_PROXY="proxy:3128"
03 RSYNC_FLAGS="-4HPSav --delete-after --delete-excluded";
04 rsync $RSYNC_FLAGS 
05  rsync://ftp5.gwdg.de/pub/opensuse/distribution/11.1/repo/oss/ 
06  /repo/suse111/ 
07  --filter=merge <(cat <<-EOF
08   + /content*
09   + /gpg*
10   + /control.xml
11   + /directory.yast
12   + /license.tar.gz
13   + /media.1/***
14   + /suse
15   + /suse/i586/***
16   + /suse/noarch/***
17   + /suse/repodata/***
18   + /suse/setup/***
19   + /suse/x86_64/***
20   - *
21   EOF
22  );
23 rsync $RSYNC_FLAGS 
24  rsync://ftp5.gwdg.de/pub/opensuse/update/11.1/ 
25  /repo/suse111u/ --filter=merge <(cat <<-EOF
26   - *.delta.rpm
27   - *.patch.rpm
28   - *-debuginfo-*.rpm
29   + /repodata/***
30   + /rpm
31   + /rpm/i586/***
32   + /rpm/noarch/***
33   + /rpm/x86_64/***
34   - *
35   EOF
36  );
37 exit 0;

Zwar besteht grundsätzlich die Möglichkeit, direkt von den Online-Repositories hinweg zu installieren, doch nimmt dieses Verfahren wesentlich mehr Zeit in Anspruch und belastet die Bandbreite bei jedem Build.

Aufbau eines Kiwi-Build

Kiwi lässt sich aber auch von der Befehlszeile bedienen. Das folgende Beispiel nimmt den Aufbau eines OEM/Raw-Image zum Vorbild, das auf der Suse-11.1-JEOS-Vorlage basiert, in KVM-Gästen lauffähig sein soll und darüber hinaus zur Installation auf Thin Clients dient:

cd /usr/share/kiwi/image/suse-11.1-JeOS
kiwi --prepare . --root /tmp/myraw --type oem --logfile terminal
kiwi --create /tmp/myraw --type oem -d /tmp/myraw-result --logfile terminal

Auf der Kommandozeile führt der Benutzer zunächst ein »kiwi –prepare« durch, danach folgt der eigentliche Buildprozess mit »kiwi –create«. Tabelle 1 zeigt alle für die Kiwi-Konfiguration relevanten Dateien. Zur Installation des Image legt Kiwi im definierten »–root« ein Chroot an. In »config.xml« definierte Pakete installiert Zypper, die notwendigen Repositories (ebenfalls aus »config.xml«) bindet Kiwi in das Chroot ein. Das neu erzeugte Image lässt sich nun per KVM mit

qemu-kvm /tmp/myraw-result/LimeJeOS-openSUSE-11.1.x86_64-1.11.1.raw -m 512

starten oder bei Bedarf auch per Dd auf eine Compact-Flash-Karte eines Thin Clients übertragen:

dd /tmp/myraw-result/LimeJeOS-openSUSE-11.1.x86_64-1.11.1.raw /dev/sdX bs=32k

Darüber hinaus birgt Kiwi eine beachtliche Anzahl an Modifikationsmöglichkeiten. Die Manpages »kiwi::config.sh« und »kiwi::images.sh« erläutern alle Direktiven und Funktionsaufrufe zur Build-Zeit. Hier sind auch sehr spezielle Aktionen möglich: Unter anderem kann Kiwi dank Funktionen wie »baseStripMans« oder »baseStripDocs« automatisiert Manuals oder überflüssige Dokumentation aus dem Image entfernen.

Automatische Inkrementierung der Versionsnummer

Wer häufig neue Imageversionen erstellt, wird eine automatische Inkrementierung der Versionsnummer sinnvoll finden. Mit einem Skript wie

VERSION="`sed -e '/<version>/!d' -e 's/[t]*<[^>]*>//g' config.xml`"
NEW_VERSION=$( echo $VERSION | awk -F. '{ print $1"."$2"."$3+1 }' )
sed -i "s#.*<version>.*</version>.*#tt<version>${NEW_VERSION}</version>#g" config.xml

übernimmt Kiwi auch die Versionsnummer in den Namen der Zieldatei, sodass der Admin auch im Nachhinein jederzeit unkompliziert feststellen kann, um welche Version es sich bei einem vorliegenden Image handelt.

Wem das nicht reicht, der kann weitergehende Möglichkeiten zur Modifikation eines Kiwi-Build wahrnehmen, indem er die Profile unter »/usr/share/kiwi/image/« nutzt. Auch die Steuerung des Image bereits in der Initrd ist möglich: Weil dabei das Root-Filesystem noch nicht gemountet ist, können Kiwi-Benutzer beim ersten Bootvorgang über geskriptete Anweisungen auch Programme wie Fdisk zum Partitionieren aufrufen.

Die Zukunft der Kiwi

Kiwi liegt voll im Trend. Vertreter der Cloud-Computing-Fraktion freuen sich über die neue Möglichkeit, direkt Amazon-EC2-Images zu erzeugen, und der Entwickler Markus Schäfer sorgt immer wieder für neue Releases und eine sehr gute Dokumentation [4].

Die Möglichkeiten sind nahezu unerschöpflich, außerdem lässt das modulare Design viele Erweiterungen zu. Davon können sich interessierte Anwender auch online auf Suse Studio [5] überzeugen. Dort kommt nämlich auch Kiwi als Backend zum Einsatz. (mfe)