Die Verwaltung von IT-Landschaften wird immer komplexer - die explosionsartige Vermehrung mobiler Clients ist nur eine der vielen Erschwernisse. Zeit also für ... (mehr)

Per PXE-Boot zur Installation

Um Systeme neu zu installieren, verwendet Cobbler PXE-Boot, dessen Dienste DHCP und TFTP es auf Wunsch verwaltet. Alternativ arbeitet es auch mit einer vorhandenen PXE-Boot-Infrastruktur zusammen. Damit Cobbler die DHCP-Verwaltung übernimmt, muss der Administrator in der Cobbler-Konfiguration »/etc/cobbler/settings« den Wert “manage_dhcp” auf 1 setzen. Mit “restart_dhcp”, ebenfalls auf 1 gesetzt, startet Cobbler bei Bedarf den DHCP-Server neu. Wichtig ist außerdem der “next_server”, hinter dem sich die IP-Adresse des DHCP-Servers verbirgt.

Als DHCP-Software stehen zwei Pakete zur Auswahl: der ISC-DHCP-Server und DNSMasq. Welchen der beiden Cobbler verwendet, bestimmt der Eintrag “mo-dule” im Abschnitt “dhcp” der bereits erwähnten Datei »/etc/cobbler/modules.conf« , die wie alle anderen Cobbler-Konfigurationsdateien ausführlich dokumentiert ist. Die Konfiguration des TFTP-Diensts funktioniert analog.

Die Vorlage zur Konfiguration des DHCP-Servers ist das Template »/etc/cobbler/dhcp.template« . Ist es für die eigene Netzwerk-Umgebung angepasst (IP-Adressen, Nameserver und so weiter), kopiert Cobbler die Konfiguration mit der Eingabe von »cobbler sync« nach »/etc/dhcp/dhcpd.conf« . Beim TFTP-Template gibt es normalerweise nichts zu ändern. Auch das TFTP-Template kopiert Cobbler aber beim Syncen an den richtigen Ort. Je nach Konfiguration werden auch die Serverprozesse von Cobbler neu gestartet.

Die Konfiguration eines einzelnen Rechners wird, wie schon angesprochen, über Profile erledigt. Ein Profil enthält neben der zu verwendenden Distribution beispielsweise auch IP-Adresse und andere Netzwerkeinstellungen, die spezifisch für einen Host sind. Im Web-Interface ist der entsprechende Menüpunkt unter “Configuration / Systems” zu finden, auf der Kommandozeile übernimmt das Anlegen eines Systems ein Aufruf des Cobbler-Tools:

cobbler system add --name node3 --profile wheezy-x86_64 --netboot-enabled=true --mac 52:54:00:4e:0d:25

Obligatorisch sind nur der Name und das Profil, allerdings kommen wohl in vielen Fällen auch die beiden anderen Optionen zum Einsatz, von denen die erste bestimmt, dass der Rechner übers Netz bootet, während die zweite die MAC-Adresse der Netzwerkkarte bestimmt. Sie verwendet Cobbler wiederum, um per PXE die richtigen Informationen zum Netzwerk-Boot auszuliefern. Hier lassen sich noch viele weitere Angaben machen, etwa die Kernel-Optionen, die das Boot-Verhalten festlegen, und teilweise auch, was nach dem Booten im Installer passiert.

Wer zum Beispiel zwei Netzwerkkarten in dem zu installierenden Rechner stecken hat, kann mit --kopts=”interface=eth0” festlegen, dass der Installer die erste verwendet. Sonst wird es möglicherweise nichts mit der automatisierten Installation, weil der Installer den Anwender zur Auswahl auffordert. Mehrere Optionen werden durch Leerzeichen getrennt. Um zu verhindern, dass ein frisch installierter Rechner beim ersten Neustart mit der Installation wieder von vorne beginnt, schaltet Cobbler das Netboot-Enabled-Flag ab, wenn in der Cobbler-Konfiguration die Variable “pxe_just_once” mit 1 belegt ist. Funktioniert das nicht wie gewünscht, fehlt vermutlich in der Kickstart- beziehungsweise Preseed-Datei der Aufruf, der per Wget die entsprechende URL auf dem Cobbler-Server aufruft.

Auch diese Funktionen sind alle über das Web-Interface erreichbar (Bild 3). Leider stehen dort aber nicht alle Optionen zur Verfügung. Im Zweifelsfall sollte man sich also alle tatsächlich verwendeten Variablen auf der Kommandozeile ausgeben lassen, etwa mit

cobbler system dumpvars --name node3
Bild 3: Editieren eines Systems im Web-Interface. Hier legt man beispielsweise fest, ob der Rechner übers Netz bootet.

Dann werden Sie zum Beispiel feststellen, dass die Kernel-Boot-Optionen (hier “kernel_options”) mehr Einträge umfassen als die im Web-Interface aufgelisteten, diese aber auch nicht vom “Profil” oder der “Distro” ererbt sind – jedenfalls nicht von dem, was dort im Web-Interface zu finden ist, denn zum Teil stammen die Kernel-Boot-Optionen auch aus der globalen Konfiguration. Auf der Kommandozeile zeigt der folgende Aufruf die Variablen eines Systems, einschließlich der Kernel-Optionen:

cobbler profile dumpvars --name “wheezy-net-x86_64”

Wie eine automatisierte Installation im Einzelnen abläuft, bestimmen die Kickstart- beziehungsweise Preseed-Dateien. Erstere stammen aus der Red-Hat-Welt und funktionieren mit Red Hat, CentOS, Fedora und ihren Ablegern, Letztere mit allen Debian-Varianten enschließlich Ubuntu. Um die Sache noch weiter zu verkomplizieren, gibt es für Suse noch einmal eine eigene Ausführung, nämlich die Autoyast-Dateien. Für die meisten unterstützten Betriebssysteme bringt Cobbler schon passende Dateien mit, die zumindest als Grundlage für die eigenen Installations-Files dienen können, und die mehr oder weniger gut funktionieren.

Am schwierigsten ist wieder die Installation von Debian, was auch daran liegt, dass sich beim Debian- und Ubuntu-Installer immer wieder kleine Details der Preseed-Dateien geändert haben oder aus unerfindlichen Gründen nicht funktionieren wie dokumentiert. Manchmal ist es dann nötig oder zumindest der einfachere Weg, einzelne Optionen als Kernel-Boot-Parameter zu übergeben, zum Beispiel die Netzwerkkarte zur Installation oder die Keyboard-Konfiguration.

Damit Sie bei der Installation physischer Server nicht immer einen Fußmarsch hinter sich bringen müssen, bietet Cobbler eine Reihe von Remote-Power-Management-Funktionen durch sogenannte

Fence-Skripts. Hierbei unterstützt das Programm beispielsweise IPMI, aber auch spezielle Hardware wie Bladecenter, HP Integrity, DRAC und APC.

Anpassungen mit Templates

Mit den beschriebenen Mitteln ist es nun ein Leichtes, Rechner mit unterschiedlichen Betriebssystemen automatisiert zu installieren. So können Sie zum Beispiel spezielle Preseed-Dateien schreiben, die Server mit Ubuntu 14.10 aufsetzen und die Software für einen LAMP-Webserver installieren. Das kann über ein eigens angelegtes Profil geschehen, das die passende Preseed-Datei enthält und das man den zu installierenden Systemen zuweist. Trotzdem müssen nicht alle damit installierten Rechner unbedingt gleich konfiguriert sein. Üblicherweise sind sie es auch nicht, denn mindestens unterscheiden sich der Hostname und die IP-Adresse.

Ein Weg, bestimmte Installationsschritte für jeden Host individuell zu gestalten, besteht darin, die Kickstart-Dateien als Templates zu behandeln, die auch Variablen und rudimentären Code enthalten dürfen. Hier können die vorher beschriebenen Cobbler-Variablen oder selbstdefinierte Werte eingesetzt werden. Um zum Beispiel das Root-Passwort für ein System zu setzen, kann der Administrator im Web-Interface bei einem System im Feld “Kickstart Metadata” den Wert »rootpwd=supersecret« eintragen. In einer Kickstart- oder Preseed-Datei kann dann die Variable »rootpwd« verwendet werden, bei Ubuntu/Debian etwa so:

d-i passwd/root-password password $rootpwd
d-i passwd/root-password-again password $rootpwd

Aus Sicherheitsgründen ist diese Methode nicht unbedingt empfehlenswert, da das Root-Passwort dann im Klartext in Cobbler gespeichert wird, sie verdeutlicht aber die Verwendung von Template-Variablen. Übrigens bieten Cobbler und die Preseeding/Kickstart-Systeme für den konkreten Zweck sonst die Möglichkeit, statt des Passworts einen Hash zu übergeben, was zumindest ansatzweise für mehr Sicherheit sorgt. Setzen Sie kein Passwort, verwendet Cobbler übrigens das in “settings” unter “default_password_crypted” definierte.

Auf der Kommandozeile sind die Template-Variablen bei Distributionen, Profilen und Systemen über den Parameter “--ksmeta” zu verändern. Bei der Ausgabe der Variablen über das erwähnte

»--dumpvars« haben sich die Entwickler allerdings dazu entschlossen, die Kickstart-Variablen hinter dem Key “ks_meta” (mit Unterstrich) zu verstecken. Daran muss man denken, wenn man etwa mit Grep danach sucht.

Wer sich im Web-Interface mit dem entsprechenden Button die Kickstart-Datei ansieht, bekommt das Resultat mit bereits eingesetzten Werten zu sehen. Das ist praktisch zur Kontrolle und Fehlersuche. Auf der Kommandozeile lässt sich das Gleiche mit »cobbler system getks --name node3« erreichen.

Bild 4: Koan listet die verfügbaren Installationsprofile auf und installiert auf Wunsch eine virtuelle Maschine.
comments powered by Disqus

Artikel der Woche

Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2018