Workshop: Cobbler automatisiert die Linux-Installation

Server neu besohlen

Wer eine größere Anzahl von Servern installieren muss, ist mit der Installations-DVD in der Hand viel unterwegs. Oder er verwendet einen Provisioning-Server wie Cobbler, der als Open Source-Software eine ganze Reihe von Linux-Distributionen, aber auch Nexenta, FreeBSD und VMware ESX installieren kann. Was das Programm im Einzelnen leistet und wo seine Schwächen liegen, verrät dieser Workshop.
Die Verwaltung von IT-Landschaften wird immer komplexer - die explosionsartige Vermehrung mobiler Clients ist nur eine der vielen Erschwernisse. Zeit also für ... (mehr)

Open Source-Tools zum Konfigurationsmanagement gibt es mittlerweile schon recht viele, etwa das in vorangegangenen IT-Administrator-Ausgaben beschriebene Puppet. Bis sich damit allerdings Rechner managen lassen, muss darauf erst einmal ein Betriebssystem laufen und die Konfigurationsmanagement-Software installiert sein. Dafür gibt es in der Open Source-Welt die Software Cobbler (auf Deutsch: Schuster), die maßgeblich von Red Hat-Entwicklern geschrieben wurde. Ursprünglich war sie auf die Installation von Fedora und Red Hat Linux beschränkt, beherrscht aber in aktuellen Versionen auch Debian, Ubuntu, Suse und sogar FreeBSD, VMware, Xen und Nexenta. Allerdings variiert der Grad der Unterstützung sehr stark und ist bei Red Hat und seinen Ablegern immer noch am besten. Eine automatisierte Installation von Debian- und Ubuntu-Distributionen hinzubekommen, ist mit Cobbler aber kein Problem.

Die neueste Cobbler-Version zu installieren, bringt vor allem den Vorteil von hoffentlich weniger Bugs und den Support für die jeweils neuesten Betriebssysteme. Es ist aber auch möglich, eine ältere Cobbler-Version dahingehend zu aktualisieren, dass sie eine neuere Distribution unterstützt, indem man nur die Signatur-Datei austauscht – dazu später mehr. Wer die Pakete aus den distributionseigenen Repositories verwendet, muss zusätzlich zu “cobbler” noch das Paket “cobbler-web” installieren, um in den Genuss des optionalen Web-Interfaces zu kommen.

Übrigens erfüllt auch die Installation aus dem Distributions-Repository nicht unbedingt alle Abhängigkeiten. Wer auf Ubuntu eine RPM-basierte Distribution provisionieren möchte, muss zm Beispiel noch das Paket »createrepo« installieren. Auf CentOS 6.5 beispielsweise wird nach der Paketinstallation nicht automatisch der Webserver neu gestartet, was eigentlich nötig wäre. Wer die Installation aus dem Quellcode versuchen möchte, findet im Kasten “Für Cobbler benötigte Pakete” eine Liste von Paketen, die Cobbler voraussetzt.

Für Cobbler benötigte Pakete

python-yaml, python-cheetah, python-netaddr, python-simplejson, python-urlgrabber, libapache2-mod-wsgi, python-django, atftpd, createrepo, httpd (apache2 bei Debian/Ubuntu), mkisofs, mod_wsgi (libapache2-mod-wsgi bei Debian/Ubuntu), mod_ssl (libapache2-mod-ssl bei Debian/Ubuntu), python-cheetah, python-netaddr, python-simplejson, python-urlgrabber, PyYAML (python-yaml bei Debian/Ubuntu), rsync, syslinux, tftp-server (atftpd für Debian/Ubuntu), yum-utils, git, make, python-devel (python-dev bei Debian/Ubuntu), python-setuptools, python-cheetah, python-simplejson, Django (python-django in Debian/Ubuntu), debmirror (für den Import von Debian-Repositories), lsb-release, hardlink

Je nach verwendetem Init-System startet ein Aufruf von »systemctl start cobblerd.service« (systemd), »service cobblerd start« oder »/etc/init.d/cobblerd start« den Cobbler-Daemon. Die Konfiguration ist im Verzeichnis “/etc/cobbler” zu finden, in erster Linie in der Datei »settings« . Nach der Installation steht das Kommandozeilenprogramm “cobbler” zur Verfügung, das als Dreh- und Angelpunkt für alle Cobbler-Aufgaben dient. Einen Test der Cobbler-Installation übernimmt »cobbler check« , gegebenenfalls als Root oder bei Ubuntu mit »sudo« ausgeführt.

Fallstricke der Installation

Alle Details der Installation für jede mögliche Kombination von Betriebssystem und Installationsvariante zu beschreiben, wäre etwas zu ausufernd, daher hier nur ein paar allgemeine Hinweise: Cobbler verwendet den Apache-Webserver als Proxy für den eigenen Webservice, also muss Apache installiert und richtig konfiguriert sein. Das schließt unter anderem auch einige Module ein, die vielleicht installiert, aber noch nicht aktiviert sind, zum Beispiel Mod-Rewrite und Mod-Proxy plus Mod-Proxy-HTTP. Diese muss man im Zweifelsfall durch Symlinks in “/etc/apache2/mods-enabled” beziehungsweise »/etc/httpd/mods-enabled« oder das Tool »a2enmod« aktivieren. Bei der Installation aus dem Quellcode stimmen vielleicht die Pfade nicht, etwa bei Debian. Hier hilft ein Blick in die Apache-Error-Logs und die Apache-Konfigurationsdatei »cobbler.conf« weiter.

Um zusätzlich zum Commandline- auch das Web-Interface zu verwenden, ist es zuerst nötig, die Authentifizierung zu konfigurieren. Die Einstellungen finden sich in der Datei »/etc/cobbler/modules.conf« , die auch Module für andere Aufgaben enthält. Die Einstellungen zur Authentifizierung stecken im Abschnitt “[authentication]”. Hier gibt es schon eine ganze Reihe von Möglichkeiten, zum Beispiel zur Authentifizierung per PAM oder LDAP, zur Integration in das Management-Tool Spacewalk oder das Weiterleiten an den Apache-Server für die Integration in Kerberos. Die einfachste Variante ist die Authentifizierung über eine Passwort-Datei, die der Eintrag “module = authn_configfile” festlegt. Mit dem Befehl »htdigest« lassen sich die User-Accounts bearbeiten. Der folgende Aufruf fordert zur Eingabe eines Passworts für den Benutzer “cobbler” auf:

htdigest /etc/cobbler/users.digest “Cobbler” cobbler

Analog dazu lassen sich weitere Benutzer-Accounts anlegen. Die Zugriffskontrolle reguliert ein weiterer Eintrag in »modules.conf« , der mit “authorization” benannt ist. Steht darunter die Zeile “module=authz_allowall”, ist allen authentifizierten Benutzern der Zugriff auf alle in Cobbler verwalteten Objekte erlaubt. Feiner abgestufte Rechtekontrolle ist mit der Option “authz_ownership” möglich.

Bild 1: Vor dem Provisioning muss der Administrator jede einzelne Distribution in Cobbler importieren.

Organisationsstruktur

Grundsätzlich unterscheidet Cobbler Distributionen (Distros), Profile und Systeme. Distributionen sind die zu installierenden Betriebssysteme, die der Administrator über Profile für einen bestimmten Zweck anpassen kann, um zum Beispiel die zu installierende Software zu bestimmen. Systeme legen schließlich die Daten für einzelne Server-Instanzen fest, etwa den Hostnamen, die IP-Adresse und so weiter.

Grundsätzlich erben die spezifischeren Objekte dabei die meisten Eigenschaften der in der Hierarchie darüber befindlichen. So kann der Administrator etwa für die automatisierte Installation schon bei einer Distribution einen Kernel oder ein Kickstart-File angeben, das per Default alle zugehörigen Profile und Systeme übernehmen. Er kann aber für jedes Profil und jedes System die beiden Einträge auch individuell auswählen.

Als Installations-Server übernimmt Cobbler die DHCP- und TFTP-Dienste, über die der zu installierende Rechner mit PXE sein Betriebssystem und die Kickstart- (Red Hat) oder Seed-Datei (Ubuntu/Debian) zur automatisierten Installation bezieht. An erster Stelle steht also der Import einer Distribution. Dies lässt sich am einfachsten bewerkstelligen, wenn Sie eine ISO-Datei herunterladen und sie auf dem Cobbler-Server per Loopback mounten, etwa mit:

mount -o loop ubuntu.iso /mnt

Bei modernen Linux-Distributionen ist die Angabe der Mount-Option normalerweise optional, das Tool ist selbst so schlau, dass es weiß, was es hier machen soll. Jetzt lässt sich die Distribution in Cobbler importieren (Bild 1):

cobbler import --name=ubuntu-trusty --path=/mnt --breed=ubuntu

Neben dem Pfad erwartet Cobbler den Namen der Distribution und mit “--breed” die “Sorte” von Betriebssystem. Für Fedora und CentOS etwa ist hier “redhat” anzugeben. Beim Import müssen Sie darauf achten, eine ISO-Datei zu verwenden, die Cobbler auch verarbeiten kann. Von vielen Distributionen gibt es beispielsweise auch Minimal-ISOs, die Cobbler nicht erkennt beziehungsweise die initiale RAM-Disk nicht findet. Die Server-ISOs von Ubuntu lassen sich problemlos importieren, für die Mini-ISOs sind zusätzliche Import-Optionen nötig:

cobbler import --name=ubuntu-mini --path=/mnt --breed=ubuntu --os-version=trusty --arch=x86_64

Im Web-Interface ist die Import-Funktion unter “Actions / Import DVD” zu finden, aber sie bietet auch nicht mehr Komfort als die Kommandozeile, dafür aber weniger Optionen. Darüber hinaus ist es ebenso nötig, vor dem Import das Image im Dateisystem zu mounten, also müssen Sie sowieso ein Terminal bemühen. Der Importer im Web-Interface zeigt, wie andere Funktionen, ein Protokoll der Aktion an, das Sie über den Menüpunkt “Cobbler / Events” und die Spalte “Log” beim einzelnen Event erreichen. Allerdings ist das dafür vorgesehene Fenster winzig und aktualisiert sich nicht automatisch. Nicht zuletzt sind die dort auffindbaren Fehlermeldungen unbrauchbar, weil der Anwender nichts mit den nackten Python-Exceptions anfangen kann, die die Cobbler-Tools im Fehlerfall ausgeben. Dummerweise ist Cobbler auch nicht ganz frei von Bugs. Wer zum Beispiel eine schon importierte Distribution umbenennt, muss damit rechnen, dass die Umbenennung nicht überall ihren Niederschlag findet, zum Beispiel nicht in den Boot-Optionen eines Systems.

Erkennt Cobbler eine Distribution nicht, kann das an dem vorhandenen Signatur-File »/var/lib/cobbler/distro_signatures.json« liegen, anhand dessen es eine Distribution identifiziert (Bild 2). Ein Aufruf von »cobbler signature report« gibt aus, welche Distributionen das Tool kennt. Die Kombination »cobbler signature update« aktualisiert die Signatur-Datei auf den neuesten Stand, der im Cobbler-Repository vorhanden ist. Wer die Datei von Hand editiert, muss danach den Cobbler-Dienst neu starten, damit die Änderungen aktiv werden.

Bild 2: Auf der Kommandozeile gibt Cobbler die Betriebssysteme aus, die es erkennt und somit unterstützt.
comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite