Alle Macht den Hosts

Und so geht‘s:

1. Installieren

Einfach auf der Konsole des orcharhino folgenden Befehl eingeben:

foreman-installer --enable-foreman-plugin-discovery --foreman-plugin-discovery-install-images=true

Dies installiert das Discovery-Plugin sowie das Discovery-Image. Dieses müssen die Hosts booten, um das Plugin im orcharhino anzusprechen.

Bei einer Neuinstallation ab orcharhino Version 3.6 lässt sich das Plugin komfortabel über den orcharhino-installer installieren.

2. Konfigurieren

Nach der Installation stehen auf der Managementoberfläche zwei neue Seiten zur Verfügung:

1. Discovered Hosts im „Hosts“-Menü zeigt die gefundenen Hosts an
2. Discovery Rules im „Configure“-Menü verwaltet die Regeln zur automatischen Konfiguration gefundener Hosts

Sowie ein neuer Tab in den Settings namens Discovered.

Um möglichst schnell Ergebnisse zu sehen, legt man sich eine Discovery Rule an.

Als Vorlage für die Konfiguration der Hosts muss eine Host Group angegeben werden. Um festzulegen auf welchen Hosts diese Regel greifen soll, werden im Search Feld entsprechende Kriterien angegeben. Die nötige Datenbasis liefert der Host selbst an orcharhino. Daher schreibt man zunächst nur

facts.hello = world

in das Feld.

• Hostname wird leer gelassen. Dadurch entscheidet das Discovery-Plugin selbst, welchen Hostnamen es vergibt.
• Hosts Limit wird auf 0 gelassen. Dies deaktiviert die Limitierung. Ein Wert größer Null hätte zur Folge, dass nur eine bestimmte Menge an Hosts über diese Regel ausgerollt werden kann.
• Priority wird noch nicht benötigt. Dieser Wert würde die Präferenz der Regel definieren, wenn der Search Ausdruck unterschiedlicher Regeln auf gleiche Hosts passen würde (je kleiner der Wert umso höher die Priorität).
• Enabled Haken setzen, da diese Regel auch verwenden soll.
• Locations und Organizations wird wie üblich gesetzt.

Wichtig ist noch, dass das vollautomatische Ausrollen von Hosts in der Konfiguration des Discovery-Plugins aktiviert ist. Dazu geht man im „Administer“-Menü auf Settings, dort auf den Tab Discovered und setzt den Wert Auto Provisioning auf Yes.

Somit ist die Basiskonfiguration abgeschlossen.

3. Host provisionieren

Auf dem Host, auf dem die neue Regel augerollt werden soll, wird nun vom Netzwerk aus  gebootet. Als nächstes wählt man im Bootmenü das Foreman Discovery Image aus. Wenn der Host nicht vom DHCP des orcharhino bedient wird, kann der Host auch mittels ISO-Image gebootet werden. Dieses findet man hier: http://downloads.theforeman.org/discovery/releases/latest/. Es handelt sich dabei um ein Hybrid-ISO-Image. Dieses lässt sich auch auf bootfähigen USB-Sticks installieren.

Erscheint das Bootmenü, aber nicht der Eintrag für das Foreman Discovery Image, hilft es im orcharhino unter Hosts -> Provisioning Templates auf die Build PXE Default Schaltfläche zu klicken. Dies erzeugt die Bootmenüeinträge erneut.

Ist das Discovery-Image gebootet, hat man in der ersten Anzeige die Wahl. Wenn man nichts tut, läuft alles automatisch und der Host meldet sich selbstständig mit seinen Daten im orcharhino an.

Drückt man eine beliebige Taste bevor der Countdown abläuft, werden die verschiedenen Werte abgefragt. Diese benötigt das Discovery-Image, um sich im orcharhino zu melden.

Die IP Konfiguration wird auf DHCP belassen. Ebenso ändert sich an der Netzwerkschnittstelle nichts. Bei Hosts mit mehreren Netzwerkschnittstellen kann es eventuell Sinn machen, hier einzugreifen.

Nun besteht noch die Möglichkeit, die URL des orcharhino zu ändern – insofern eher ein  Smart Proxy oder ein anderer orcharhino verwendet werden soll.

Das Custom facts Formular, das als nächstes kommt, ist besonders wichtig für diesen beschriebenen Anwendungsfall. Denn hier können wir eigenen Fakten über das System definiert werden. Bei der Discovery Rule wurde in diesem Fall angegeben, dass die Regel greifen soll, wenn

facts.hello = world

ist.

Damit die Regel für diesen Host anwendbar ist, muss auf dieser Seite das Fact „hello“ mit dem Wert „world“ definiert werden.

Damit ist die Datensammlung komplett und der Host schickt die Daten an den orcharhino. Die folgende Anzeige fasst alles nochmal zusammen und normalerweise könnte man hier noch diverse Aktionen ausführen bzw. Logs oder alle Fakten einsehen, die an den orcharhino geschickt wurden. Da jedoch Auto Provision aktiviert ist, wird der Host selbstständig einen Reboot ausführen und mit der Installation beginnen. Damit ist nun der erste Host vollautomatisch ausgerollt.

4. Die Feinheiten

Hostname

Der neue Host heißt nun macXXXXXXXXXXXX (wobei XXXXXXXXXXXX die MAC-Addresse des Hosts ist) – das ist in Ordnung, aber es gibt sicher schönere Namen.

Glücklicherweise lässt sich das anpassen. Wenn man nur einen anderen Präfix verwenden möchte, so kann man einfach die Einstellung Hostname prefix im Discovered Reiter der Globalen Einstellungen im orcharhino ändern.

Wer es noch schöner möchte kann für die Discovery Rule das Feld Hostname setzen. Es macht hier natürlich wenig Sinn, einen festen Wert zu vergeben. Daher kann man ein Template angeben. Dieses muss in der embedded Ruby Notation angegeben werden. Hier ein paar Beispiele:

• host<%= rand(1000).to_s.ljust(3, '0') %> 

  • =>erzeugt Hostnamen die mit host beginnen, gefolgt von einer 3-stelligen Zufallszahl. Der Clou dabei ist, dass .ljust(3, ‚0‘) dafür sorgt das die Zahl immer 3 Stellen hat. Ist die erzeugte Zahl 4, wird der Hostname host004 erzeugt.

• host<%= @host.facts['uniqueid'] %> 

  • =>fügt das fact uniqueid an den Hostnamen an. Hier können auch die Facts verwendet werden, die auf dem Host selbst zuvor definiert wurden (z.B. das hello fact). Eine Liste aller facts findet man auf dem Host, wenn das Discovery Image erfolgreich gebootet hat und sich der Host erfolgreich am orcharhino gemeldet hat. Es darf natürlich keine Auto Provisioning Regel gepasst haben, weil der Host sonst sofort neustartet und ausgerollt wird. Alternativ wird die Liste auch angezeigt, wenn man im orcharhino bei den Discovered hosts einen gefundenen Host anklickt.

• <%= @host.hostgroup.name %>-<%= rand(1000).to_s.ljust(3, '0') %>

  • =>hat zwei Teile. Der erste verwendet den Namen der Hostgroup; im konkreten Beispiel wäre das Debian9. Man sollte natürlich den Namen der Hostgroup entsprechend setzen. Dabei ist besonders darauf zu achten, dass keine Zeichen verwendet werden, die in Hostnamen nicht erlaubt sind (z.B. ., _). Echte Profis können die unerlaubten Zeichen über Ruby-Methoden der String-Klasse dynamisch entfernen (z.B. mit gsub()). Diese Regel könnte zum Beispiel folgenden Hostnamen erzeugen: Debian9-042. Den zweiten davon zeigt das zuvor aufgeführte Beispiel.

Search Filter

Die Erstellung einer Filterzeichenkette ist nicht sehr komplex, das das Eingabefeld automatisch Vorschläge macht. Neben den bereits erwähnten Fakten die mit facts. beginnen, gibt es auch einige Standardwerte, wie die Anzahl der CPUs auf dem Host (cpu_count) oder die Größe des Hauptspeichers in Megabyte (memory).

Die Vergleichsoperatoren sind größtenteils wie gewohnt:

• = (!=) prüft auf (Un-)Gleichheit
• < (<=) prüft ob der linke Wert kleiner (kleiner oder gleich) dem rechten ist
• > (>=) prüft ob der linke Wert größer (größer oder gleich) dem rechten ist
• ^: Dieser Operator prüft ob der linke Wert in einer Liste auf der rechten Seite vorhanden ist.
  Beispiel:

  • cpu_count ^ (2,4,6,8) 

  • trifft zu, wenn der Host 2, 4, 6 oder 8 CPUs hat.
• !^ prüft ob der linke Wert nicht in einer Liste auf der rechten Seite vorhanden ist.

Über die Worte and, or und not lassen sich die Ausdrücke logisch verknüpfen. Wenn man beispielsweise alle Hosts mit höchstens 2 CPUs sowie weniger als 2GB Hauptspeicher sucht, die keine 2 Festplatten haben, entsteht folgende Abfrage:

cpu_count <= 2 and memory < 2048 and not disk_count = 2

Mit Klammern lassen sich die Suchfilter optisch und logisch besser gruppieren. Beispielsweise fügt man ein not am Anfang ein und markiert über die Klammern den Geltungsbereich, wenn man die Abfrage invertieren will:

not(cpu_count <= 2 and memory < 2048 and not disk_count = 2)

Discovery-Image anpassen

Das Discovery-Image basiert auf CentOS 7 und sollte für die meisten Fälle ausreichend sein. Es kann passieren, dass das Discovery-Image einfach nicht booten will, weil sich beispielsweise eines der Kernelmodule quer stellt. Dazu kann es hilfreich sein die Kernel Commandline anzupassen. Angenommen es soll verhindert werden, dass ein bestimmtes Kernelmodul geladen wird (z.B. pcspkr). Dann würde man eine Blacklist einfügen. Dafür hängt man die Kernelparameter folgendes anhängt:

 modprobe.blacklist=pcspkr.

Damit würde das pcspkr Modul nicht mehr vom Kernel eingebunden.

Die Kernel Commandline lässt sich beim Netzwerkboot einfach anpassen, indem man das Foreman Discovery Image auswählt und dann zunächst [TAB] drückt. Dadurch werden die voreingestellten Werte angezeigt und lassen sich einfach bearbeiten, bevor man mit [Return] das Image startet.

Es ist möglich die Kernelparameter des Images dauerhaft zu ändern. Für das ISO-Image benutzt man am besten das Discovery Remaster Script. Beim Booten über das Netzwerk ist die Anpassung ein bisschen schwieriger, da man hierfür mitgelieferte Templates bearbeiten muss. Zunächst sucht man auf der Provisioning Template Seite nach Templates die auf ‚discovery‘ enden. Unter den Ergebnissen sind das pxelinux_discovery Snippet, welches in den meisten Fällen das richtige ist, sowie das pxegrub2_discovery, das für UEFI-Bios verwendet wird. In diesen Snippets wird die Kernel Commandline definiert. Da diese jedoch von orcharhino mitgeliefert werden ist Vorsicht geboten: Bei einem Update können Änderungen überschrieben werden. Um die Snippets zu bearbeiten muss man sie zuerst entsperren (‚Unlock‘). Ist man mit dem bearbeiten fertig, ist es essentiell auf der Provisioning Template Seite auf Build PXE Default zu klicken. Erst dann stehen die Änderung im Netzwerkbootloader zur Verfügung.

Weiterführende Literatur

• Foreman Discovery Plugin (englisch)
  • Globale Einstellungen (englisch)
  • Discovery Image Konfigurationsoptionen (englisch)
  • Remastering Discovery Image (englisch)
• embedded Ruby
  • Stringmethoden in Ruby (englisch)
• Variablen für Template in der Discovery Rule (englisch)