Cobbler ist ein Provisioning-, Update- und Boot-Server, mit dessen Hilfe automatisierte Neu- und Re-Installationen durchgeführt werden können. Als Teil der Produktfamilie "Emerging Technologies" der Firma Redhat ist Cobbler bisher kein Bestandteil offizieller System Management-Werkzeuge, was seine Eignung für den hier angedachten Einsatzzweck aber keineswegs schmälert. Cobbler stellt ein Lösungsportfolio dar, dass sowohl für eine vollautomatische Neu- und Re-Installation von physischen sowie virtuellen Systemen wie auch für Bare Metal Provisioning geeignet ist. Hierbei kommen folgende Komponenten in einer wirkungsvollen Kombination zum Einsatz:

• DHCP-Server (und Management durch Cobbler)
• PXE-Boot (Templating und Management durch Cobbler)
• TFTP-Server
• Webserver (Apache)
• Kickstart Tracking (Remote Syslog)
• Kickstart-Autoinstall (Templating und Management durch Cobbler)
• Repository-Management
• Profile Management
• System Management

Dabei liegt der erhöhte Nutzwert von Cobbler vor allem in der erheblichen Arbeitserleichterung durch Konsolidierung von zusammengehörigen Informationen sowie der enormen Flexibilität und Anpassbarkeit auf individuelle Bedürnisse. Letztere wird massgeblich unterstützt durch die den Einsatz der flexiblen Template-Engine (basierend auf Cheetah-Templating-Engine. Die Verknüpfung zahlreicher, bestehender, aber i.d.R. nicht einfach zu bedienenden Technologien (PXE, DHCP, Kickstart, Yum) in einem schlüssigen, extrem flexiblen und erweiterbarem Gesamtkonzept reduziert hierbei sowohl den Aufwand (damit auch die Kosten) als auch die Anforderungen an die Administratoren in erheblichem Masse). Dabei lässt sich Cobbler auch in bereits bestehende Umgebungen (vorhandenes DHCP-Setup, DNS mit DNSmasq, Verwendung bestehender Kickstart-Files, z.B. aus Satellite-Server, etc.) integrieren.

Dadurch bedarf es zum Beispiel zu einer vollständigen Implementierung eines Desaster Recovery Systems mit Cobbler, unabhängig von der Anzahl der im Cluster befindlichen Nodes, lediglich folgender Voraussetzungen:

• eine vorhandene Installationsquelle (ggf. ergänzt um mind. ein Repository mit Updates)
• ein Kickstart-File, das wiederum die Unterschiede durch Einsatz
• einer Variable dynamisch ersetzt.

Das Cobblersystem in einer absoluten Minimalkonfiguration bzw. dessen Konfiguration besteht daraufhin aus folgenden Schritten:

1. Installation Cobbler
2. Grundkonfiguration Cobbler
3. Hinzufügen eines Repositories
4. ggf. Hinzufügen des Update-Repositories
5. Erstellen eines Profiles, das die o.g. Kickstart-Datei verwendet
6. Hinzufügen jeweils mind. einer MAC-Adresse aller Clusternodes

Selbstverständlich lassen sich mit Cobbler auch wesentlich komplexere Setups konfigurieren, deren Implementierung dann sicherlich auch mehr als 10 Minuten in Anspruch nehmen dürfte.

Mit diesen wenigen Arbeitsschritten (Dauer ca. 10 Minuten!) lässt sich ein vollständiges DisRec-System mit Hilfe von Cobbler betreiben, das folgende Features beinhaltet:

• Möglichkeit des Bootens aller Nodes über PXE,
• netzwerkweite Konfiguration während des Bootvorgangs möglich (PXE-Templating)
• Zuweisen temporärer oder dauerhafter IP-Adressen (DHCP inklusive Mehrfach-Subnets)
• Integration der DHCP-Informationen in DNS (DNSmasq)
• Dynamische Anpassung der Bootparameter (Kernel-Opts, Runlevel, Boot-Params, …)
• Neuinstallation des Systems inklusive:
  • Dynamische, äusserst flexible Installationsroutine (Kickstart + Templating)
  • Überwachen des gesamten Installationsvorganges per Syslog und ggf. VNC
  • Verwendung eigener Repositories
  • Dauerhafte Bereitstellung der Repositories auf den Zielmaschinen (/etc/yumrepos.d/)
• Gruppieren von Systemen inklusive Vererbung von Eigenschaften
• Anmeldung in Service-Discovery-Engine (avahi-daemon)
• Verwendung sowohl für phyische als auch für virtuelle (Para- und Full-Virtualized) Systeme
• Bereitstellung alternativer Boot-Mechanismen für Nicht-PXE-fähige NICs (Koan)
• nahezu unbegrenzte Erweiterbarkeit durch:
  • Trigger
  • Snippets
  • Template-Engine
  • Schnittstellen
  • API (Python und XMLRPC)
  • (skriptbasiert) editierbare Config-Files (Textfiles in /var/lib/cobbler)
• aufgrund o.g. Eigenschaften Eignung von kleinen bis sehr grossen IT-Infrastrukturen
• einfache Konfiguration¹⁾ über CLI und/oder GUI möglich

Somit ist Cobbler ein äusserst flexibles, einfach bedienbares, skalierbares und auch für Enterprise-Umgebungen geeignetes Disaser Recovery Tool, das mit den Informationen des Configuration Managements die MTTR ²⁾ als Teil des IT Service Continuity Managements auf ein Minimum³⁾ reduzieren kann.

Dabei kommt ein hierarchisches Konzept von:

• Distributionen (Kernel, initrd, Kernel- und Boot-Params, Metadata)
• Repositories (Yum Mirror Informationen, Custom Repos)
• Profiles (Verknüpfung Distribution mit Kickstart-File, Metadata)
• Systems (Verknüpfung von MACP, IP, Hostname mit Distribution, Metadata) und

zum Einsatz. Selbstverständlich lassen sich alle Objekte / Klassen:

• erzeugen (cobbler cobbler distro|profile|system|repo add)
• anzeigen (cobbler cobbler distro|profile|system|repo list|report)
• löschen (cobbler cobbler distro|profile|system|repo remove)
• editieren (cobbler cobbler distro|profile|system|repo edit)
• umbenennen (cobbler cobbler distro|profile|system|repo rename)
• kopieren (cobbler cobbler distro|profile|system|repo copy)

Zielstellung des Configuration Management sollte es sein, diese Hierarchie-Ebenen ebenfalls in seiner Klassifikation verwenden zu können.

Distributionen stellen in Cobbler die oberste Hierarchie-Ebene dar. Sie müssen daher auch zuerst erstellt werden. Dabei können neben Template-Variablen (Metadata) folgende Informationen hinzugefügt werden:

• Name der Distribution (Identifier im Cobbler-System)
• Kernel (zu verwendender Boot-Kernel)
• Initrd (zu verwendende Boot-Initrd)
• Kernel-Options
• Architecture
• KS-Metadate (Template-Variablen, die später ersetzt werden)
• Breed (Unterscheidung Install-Routine,derzeit nur Redhat/Fedora/CentOS-Systeme)

In Cobbler integriert ist ein flexibles Repository-Management, mit dessen Hilfe sich:

• vorhandene Repositories spiegeln lassen (Mirroring)
• eigene Repositories erstellen und verwalten lassen (Custom Repo)

um

• auch ohne Internetanbindung Installationsquellen netzwerkweit anbieten zu können
• die intern verfügbare Bandbreite effizient nutzen zu können (GigaBit vs. DSL o.ä.)
• Bandbreite der Internetanbindung zu sparen
• Repositories individuell gestalten (Ein-/Ausschluss einzelner Pakete) zu können.

Selbstverständlich können Sie die entstehenden Repos auch ausserhalb von Cobbler (z.B. mit yum) benutzen, da sie in der Webroot des Cobbler-Servers per HTTP den Clients zur Verfügung gestellt werden. Die dazu erforderlichen Repo-Files (für Verzeichnis /etc/yum.repos.d/ stellt Cobbler automatisch bereit (File „config.repo“ im jeweiligen Repository-Dir).

Mit folgendem Kommando fügen Sie Ihre vorhandenen Installationsmedien zu den verfügbaren Repositories hinzu:

 
cobbler import --name="Fedora8" --mirror=/media/dvdrom

Die Befehle

 
cobbler repo add --mirror=http://mirrors.kernel.org/fedora/core/updates/6/i386/ --name=fc6i386updates
cobbler repo add --mirror=http://mirrors.kernel.org/fedora/extras/6/i386/ --name=fc6i386extras

erzeugen eine lokale Kopie der angegebenen Repositories als lokaler Mirror und stellen diese Repos zur Verwendung nach und während der Kickstart-Installationsroutine bereit.

Mit folgendem Befehl werden das entfernte und das lokale Repository gesynct und die lokale Kopie in Cobbler integriert:

 
cobbler reposync

Durch die Auswahl der Option „keep updated“ in Verbindung mit erneutem Aufruf des o.g. Befehls (z.B. per Crontab) halten Sie Ihre Repos ständig auf dem aktuellsten Stand.

Wenn Sie später mit folgendem Befehl⁴⁾ (Beispiel) Profile anlegen,die diese Repos verwenden sollen,

 
cobbler profile add --name=fc6i386special --repos="fc6i386updates fc6i386extras" --distro=FC6-i386 --kickstart=/etc/cobbler/kickstart_fc6.ks

werden automatisch im Kickstart-Template folgende Zeilen generiert:

 
# If any cobbler repo definitions were referenced in the kickstart profile, include them here.
 
$yum_repo_stanza
 
[...]
 
%post
$yum_config_stanza

Daraus generiert Cobbler automatisch im erzeugten Kickstart-File dann folgende Zeilen:

# If any cobbler repo definitions were referenced in the kickstart profile, include them here.
repo --name=fc6i386updates --baseurl=170.100.1.250/cblr/repo_mirror/fc6i386updates
repo --name=fc6i386extras --baseurl=170.100.1.250/cblr/repo_mirror/fc6i386extras
 
[...]
 
%post
wget http://170.100.1.250/cblr/repo_mirror/fc6i386updates/config.repo --output-document=/etc/yum.repos.d/fc6i386updates.repo
wget http://170.100.1.250/cblr/repo_mirror/fc6i386extras/config.repo --output-document=/etc/yum.repos.d/fc6i386extras.repo

Damit werden neben der Bereitstellung der Repos zur Verwendung während und nach der Installationsroutine diese Repos auch dauerhaft im System verfügbar gemacht durch das Herunterladen der dazugehörigen Repo-Dateien mit wget und Speicherung der Files im Yum-Repo-Dir (/etc/yum.repos.d/).

Mit Cobbler und createrepo lassen sich einfach und schnell individuelle Repos erzeugen und verwalten:

 
# Erstellen des Verzeichnisses für unser Custom Repo
mkdir -p /path/to/repos/myownrepo
cd /path/to/repos/myownrepo
 
# Kopieren unserer eigenen RPMs in das Verzeichnis
cp /pyour/path/myfavouriterpm.rpm .
cp /pyour/path/myfavouriterpm2.rpm .
cp /pyour/path/myotherrpm.rpm .
 
# Erzeugen des Verzeichnisses 'repodata' (Repo-Meta-Info)
createrepo .
 
# Hinzufügen des Repos unter Cobbler-Verwaltung
cobbler repo-add --name="mycustomrepo" --mirror="/path/to/repos/myownrepo"

Dadurch lassen sich individuelle Konfigurationen per RPM deployen und in die Installations- und DisRec-Routine einbinden.

Alternativ dazu können Sie auch in bestehenden Repos (lokal im Cobbler-Verzeichnis) RPMs durch eigene ersetzen oder bestehende löschen (z.B. Entfernen sicherheitskritischer Werkzeuge wie z.B. Nessus, Nmap, etc.). Der anschliessende Aufruf von.

 
createrepo /path/to/repo
cobbler reposync

stellt Ihnen Ihr modifiziertes Repo zur Verwendung mit Yum, Cobbler, etc. bereit.

Profile stellen die Verknüpfung zwischen den vorher erzeugten Distribution einerseits und den Kickstart-Files inklusive dazugehöriger Metadata dar. Damit sind Profile das Kernelement im Sinne der zentralen Hierarchie-Ebene von Cobbler. Mit Hilfe der Profile lassen sich die Systeme Ihrer IT-Umgebung sinnvoll gruppieren (z.B. Webserver, DB-Server, Desktop-PCs, Cluster A, …).

Dabei können folgende Informationen zu einem Profile hinzugefügt werden:

• Name des Profiles (Identifier im Cobbler-System)
• Distro (Verknüpfung zur vorab erzeugten Distribution)
• Kickstart-File (Verknüpfung zum KS-File)
• Repositories (vom System während und nach der Installation einzubindende Repositories)
• Vererbung (Hierarchische Vererbung von Profilen möglich)

Zusätzliche Parameter für Virtuelle Maschinen:

• Virt-File-Size (Grösse des Disk-Images in GB)
• Virt-Ram (Grösse RAM in VM)
• Virt-Type (Xen-Paravirtualized, QEMU/KVM, auto)
• Virt-CPUs (Anzahl virtueller CPUs)
• Virt-Path (Pfad zum VM-Image)
• Virt-Brigde (Verwendete Bridge)

Systeme stellen in Cobbler die unterste Hierarchie-Ebene dar. Hier werden phyische oder virtuelle Systeme mit einem Profile verknüpft. Dabei können neben Template-Variablen (Metadata) folgende Informationen hinzugefügt werden:

• Name des Systems (Identifier im Cobbler-System)
• MAC-Adresse (für DHCP-IP-Vergabe)
• IP-Adresse (sofern statisch)
• Hostname (optional, kann auch im KS-File definiert
• Gateway und Subnet (nicht bei DHCP, nur bei statischen IPs)
• Kickstart-File (sofern Single-KS-File nur für das System, keine Zuordnung zu Profil)
• Netboot (Booten über PXE (yes) oder Koan (no))
• DHCP-Tag (bei verschiedenen Subnets)

Zusätzlicher Parameter für Virtuelle Maschinen:

• Virt-Brigde (Verwendete Bridge)

Für Cobbler stehen fertige RPMs unter http://cobbler.et.redhat.com/download.php zur Auswahl. Damit beschränkt sich die Installation auf

yum install cobbler

Rufen Sie anschliessend als User root

cobbler check

auf, um die Voraussetzungen zu prüfen. Bei unveränderter Konfiguration des Original-RPMs weist Sie die Fehlermeldung auf notwendige Anpassungen (“Server“ und “next-server“ in /var/lib/cobbler/settings hin. Wenn Sie DHCP verwenden wollen, aktivieren Sie es, indem Sie die Zeile “manage_dhcp=0“ in /var/lib/cobbler/settings ändern in “manage_dhcp=1“.

Das war`s.

Im folgenden Text werden die zugrundeliegenden Technologien und deren Implementierung im Cobbler-System beschrieben.

Cobbler kann (optional) die Verwaltung der Netzwerkinfrastruktur mit DHCP und DNS für die zu verwaltenden Systeme managen. Damit wird Cobbler zur zentralen Verwaltungsinstanz Ihrer Systeme und bietet damit einen Single Point of Control (SPoC).

Standardmässig ist die Verwaltung des DHCP-Servers deaktiviert. Bei der Aktivierung im Configfile /var/lib/cobbler/settings haben Sie die Wahl zwischen ISC dhcpd und DNSmasq. Ein Wechsel zwischen beiden ist jederzeit (auch später) möglich. Als initiale Grundlage verwendet Cobbler hierbei die Datei /etc/cobbler/dhcpd.template (bei Verwendung ISC) oder /etc/cobbler/dnsmasq.template (bei Verwendung DNSmasq).

Bei der Aktivierung des DCHP-Managements durch Cobbler werden folgende Features automatisch aktiviert:

• Verknüpfung zwischen DHCP-Hostnamen und MAC-Adressen
• Mixen von Itanium und x86/x86_64-Systemen möglich (ISC)
• Verknüpfung zwischen DHCP-Hostnamen und MAC-Adressen mit Hilfe von DNS (DNSmasq)

Hierzu werden beim Erstellen des Systems folgende Übergabeparameter zusätzlich spezifiziert:

• “–hostname= “
• “–mac= “
• “–ip= “

Zusätzlich lassen sich hierbei ebenfalls aus den gewonnen Informationen des Inventories weitere Informationen ergänzen:

• “–profile=“ (für vordefinierte Profile, z.B. Gruppierung / Klassifikation aus dem CM)
• “–kopts=“ (für diverse Kernel-/Boot-Options, wie zum Beispiel:)
  • „ksdevice=“ (NIC, die beim Kickstart-Prozess benutzt wird, z.B. um das Client-LAN zu entlasten)
  • “–ksmeta=\“foo=bar\“ (Variablen, die beim Generieren des Kickstart-Files ersetzt werden durch Cheetah)
• “–dhcp-tag=\“Client-LAN\““ (für Auswahl bestimmter Subnets in dhcpd.conf)

Somit kann aus den beim Inventory eingesammelten Daten direkt die Cobbler-Netzwerkverwaltung aktiviert werden. Eine Möglichkeit des Auslesens mit system-config-network und der Cobbler-Integration demonstriert folgender Code:

Dadurch werden automatisch MAC-Adressen, ihre Verknüpfungen zur IP-Adresse und im obigen Beispiel der von Kickstart benutzte Eth-Device (kann auch davon abweichend konfiguriert werden, z.B. immer auf das selbe Netzwerksegment) an Cobbler übergeben und von Cobbler in das DHCP-Management integriert. Hier finden Sie eine Anleitung zum Verfahren bei Vorhandensein mehrerer NICs in einem Server, die jeweils in unterschiedliche Netzwerksegmente zeigen. Beachten Sie dabei, dass erst nach dem Aufruf von „cobbler sync“ dies auch wirksam wird (Restart dhcpd).

Das Preboot Execution Environment (PXE) ermöglicht das Booten eines Systems über dessen Netzwerkkarten (NIC).

• Funktions- und Wirkungsweise:
  • DHCP + TFTP + BIOS Magic + bootloader (PXELinux)
• „Generally a pain to setup up and maintain. Not well documented“
• In Kombination mit inventarisierten MAC-Adressen Bare Metal Provisioning möglich
• MAC-Adresse = einzig notwendige Information für Re-Installation oder Neu-Installation (in Verbindung mit Kickstart-Template)
• Deployment PXE-Bootfähige Kernel + Initrd (z.B. von ISO-CD)
• Nachteil: Management des DHCP-Servers notwendig, PXE-fähige NICs notwendig, Dauer des Bootvorganges
• PXE-Boot-Loop-Prevention (netboot-enabled, pxe_just_once)
• Alternativen: Koan

Cobbler erzeugt dabei das PXE-Menü automatisch, wobei sich dieses individuell anpassen lässt (PXE-Templating).

Nicht-PXE-fähige Systeme sowie virtuelle Maschinen (XEN-Hosts) können mit Hilfe von KOAN („Kickstart Over A Network“) ebenfalls durch das Cobbler-System reinstalliert werden. Hierzu wird ein Helferprogramm auf dem Zielsystem ausgeführt, das daraufhin mit dem Cobbler-Boot-Server kommuniziert und den Bootprozess initiiert. KOAN kommt demzufolge in folgenden Szenarien zum Einsatz:

• wenn die Hardware des Zielsystems kein PXE unterstützt
• wenn es sich bei dem Zielsystem um eine Virtual Machine handelt
• wenn DHCP aus organisatorischen oder technischen Gründen nicht eingesetzt werden kann

Bei Redhat Kickstart handelt es sich um eine Installationsbeschreibungssprache, die den standardmässig interaktiven Installationsprozess mit Redhats Installationstool „Anaconda“ automatisiert. Dabei lässt sich das zu installierende System neben lokalen Variationen (Floppy, CD, DVD, Hard Disk) auch über das Netzwerk booten und installieren. Auf der Remote-Seite muss sich neben den eigentlichen Installationsquellen vor allem das Kickstart-File befinden, in dem alle Konfigurationsoptionen des Zielsystems enthalten sind.

Die Konfiguration des Installationsprozesses über das Kickstart-File bietet nahezu unbegrenzte Möglichkeiten, da neben den vordefinierten Parametern in Kickstart sowohl vor als auch nach dem Installationsprozess Kommandos und Skripte ausgeführt werden können. Während die Pre-Section dabei noch Einschränkungen unterliegt aufgrund des verwendeten Minimalsystems, können in der Post-Section alle notwendigen Konfigurationen des Zielsystems vorgenommen werden. In beiden Sections steht dabei das Netzwerk und damit netzwerkweit verfügbare Informationen und Daten zur Verfügung. Auch dynamisch variierende Interaktionen zwischen dem Zielsystem und einer hierfür konfigurierten Gegenstelle lassen sich hierbei integrieren.

Das Kickstart-File lässt sich sowohl manuell als auch mit Hilfe der dafür bereitgestellten GUI (system-config-kickstart) erzeugen. Im letzteren Fall werden bereits Teile der aktuellen Konfiguration automatisch ausgelesen und in ein von Kickstart lesbares Format umgewandelt. Kritische Abschnitte werden dabei deaktiviert und können durch den Administrator manuell aktiviert werden (z.B. Partitionierung). Aber auch der manuellen Erstellung der Kickstart-Files steht aufgrund der hervorragenden und umfangreichen Dokumentation nichts im Weg.

Da es sich bei dem Kickstart-File um ein skripting-fähiges Textfile handelt, lässt sich dieses auch automatisiert erzeugen und / oder bearbeiten. So lassen sich aus dem Inventory bekannte Informationen automatisch in ein von Redhat Kickstart verwertbares Format umwandeln. Cobbler nutzt diese Fähigkeit aus und verstärkt deren Wirkungsgrad noch zusätzlich durch den Einsatz der Template-Engine Cheetah.

Einziger Wermutstropfen dabei: Kickstart konfiguriert den Installationsprozess des Zielsystems. Für eine Konfiguration bzw. Konfigurationsänderung eines bestehenden System ist es nicht geeignet. Führt man sich jedoch die Grundsätze des Configuration Managements nach ITIL vor Augen, wird mit der Definition des SOLL-Zustandes und des Herstellens dieses mit einer Installationsroutine wie Kickstart sichergestellt, dass der SOLL-Zustand auch dem IST-Zustand entspricht. Änderungen am System, die nicht vom Configuration Management erfasst sind, würden in im Fehlerfall auch nicht wiederhergestellt werden können. Somit ist der Ansatz einer zyklischen automatisierten Wiederherstellung von Systemen und dabei ggf. stattfindenden Anpassung der Wiederherstellungsroutinen ein gangbarer Weg⁵⁾.

Um die Wiederverwendbarkeit zu steigern und Anpassungen an den Kickstart-Files global vornehmen zu können, lassen sich sogenannte „Snippets“ integrieren. Hierzu werden die Snippets im Verzeichnis /var/lib/cobbler/snippets/ abgelegt und können an jeder beliebigen (passenden) Stelle im Kickstartfile eingebunden werden mit:

 
SNIPPET::name_of_your_snippet

Selbstverständlich können alle Template-Variablen im Snippet verwendet werden. Diese werden dann dynamisch über dei Verknüpfung zum Profil und / oder System ersetzt.

Eine Übersicht über verschiedene Möglichkeiten des Kickstart-Templatings mit Cobbler finden Sie hier, Kickstart-Snipplets hier.Informationen zur Template-Engine, die auch für das Kickstart-Templating verwendet werden kann (Cheetah), finden Sie hier.

Um potentielle Fehler im Kickstartfile zu vermeiden, kann das KS-File mit dem Kommando

 
cobbler validateks

auf bekannte Syntax-Fehler untersucht werden. Die Überprüfung wird dabei auf dem entgültigen (Template-Variablen sind bereits ersetzt) KS-File durchgeführt.

Durch die Verwendung eines separaten Syslog-Servers (Port: 25150, konfigurierbar) kann der gesamte Kickstart-Prozess vom Cobbler-Server aus überwacht werden, sofern Anaconda mit der Fähigkeit „syslog forward“ verwendet wird (> FC6 / RHEL5). Alternativ bzw. ergänzend dazu kann manuell mit VNC die Installation auf dem Zielsystem ebenfalls überwacht werden.