Seite wählen

NETWAYS Blog

Platz da LConf, der Director kommt!

Lange Zeit war das von NETWAYS entwickelte Tool LConf das Mittel der Wahl wenn ein grafisches Konfigurationsfrontend für Icinga gesucht wurde. Mit Icinga 2 und dem damit einhergehenden geänderten Konfigurationsformat litt jedoch die Kompatibilität, außerdem ist das ursprüngliche Konzept von LConf mit der Zuweisung von Services über Vererbungen eines OpenLDAP-Baumes spätestens mit den vielen Möglichkeiten der Apply Rules von Icinga 2 überholt.
Als eigenes Modul in Icinga Web 2 integriert, ist der Director das einzige Konfigurationstool das eine vollständige Unterstützung für Icinga 2 bietet. Die Kommunikation erfolgt dabei direkt mit der API des Icinga 2 Cores (seit Icinga 2.4). Daher stellt sich also die Frage: Wie lässt sich die Icinga Konfiguration von LConf am Besten auf den Director, respektive von Icinga 1.x auf Icinga 2.x migrieren?
Icinga Web 2 bietet bereits nativ eine Unterstützung für LDAP, diese steht auch den Modulen zur Verfügung. Um LConf nun als Import Source im Director zu verwenden, muss dafür in Web 2 noch eine entsprechende Resource eingerichtet werden.

Host in LConf


Bei der Import Source reicht es dann i.d.R. aus die Objektklasse auf lconfHost einzuschränken, denn mehr als nur Hosts zu importieren, macht in den wenigsten Fällen sind. Services sollten aufgrund von CheckCommands aus der Icinga Template Library (= ITL) sowieso neu gemacht und in dem Zuge auch gleich überdacht werden. Durch die Apply Rules liegt der Fokus auf Host Eigenschaften anhand deren später Services zugewiesen werden können. Neben Standardattributen stehen hier auch sog. Custom Attribute oder Custom Variablen (CustomVars) zur Verfügung, mit denen weitere individuelle Informationen wie beispielsweise Betriebssystem, Rolle oder Standort hinterlegt werden können.
Normalerweise ist es bei Hosts ausreichend cn, lconfAddress, lconfAlias und lconfHostCustomvar zu importieren. Da CustomVars in LConf mit Unterstrich vorm Bezeichner und einem Leerzeichen vor dem eigentlichen Wert angegeben werden müssen, sieht das in der Vorschau der Import Source beispielhaft so aus:

[
„_operatingsystem Linux“,
„_role Webserver“,
„_rack Rack01“
]

Diese Syntax kann vom Director nur schwer weiter verarbeitet werden, daher gibt es dort seit kurzem den Modifier „Transform LConf CustomVars to Hash„, mit dem das Ganze wie folgt transformiert wird:

{
operatingsystem: „Linux“,
rack: „Rack01“,
role: „Webserver“
}

Host im Director


Bei der darauf aufbauenden Sync Rule können dann alle CustomVars mit „All custom variables (vars)“ automatisch umgesetzt werden, dabei spielt es keine Rolle ob die Hosts eine, keine oder mehrere Custom Attribute definiert haben.
Damit ist es sehr einfach die Hosts aus dem bestehenden LConf-Baum bereits im Produktivbetrieb schon auf die künftige Verwendung mit Icinga 2 vorzubereiten und sie dann mit dem Director einmalig oder regelmäßig zu importieren, sodass zumindest ein paar Andenken an den „geliebten“ LConf bleiben…
Wer hier oder auch bei anderen Aufgaben mit Icinga und dem Director noch Unterstützung benötigt, kann aber natürlich auch gerne auf uns zukommen.

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Puppet Hash Injection

forge-logoFolgende Ausgangssituation, wir wollen eine Konfigurationsdatei zeilenweise mit beliebigen Optionen und den zugehörigen Werten verwalten. Hierzu benutzen wir eine Defined Resource, um jeweils einen Eintrag zu konfiguration:

define config::setting(
  $option = $title,
  $value,
) {
  file_line { "config::setting::${option}":
    line => "${option} = ${value}",
    ...
}

Nun möchten wir jedoch aus einer Klasse heraus, einen einfachen Hash zur Deklaration verwenden und nicht einen Hash of Hashes.

class { 'config':
  options => { 'opt1' => 'alpha', 'opt2' => 'beta' },
}

Das Problem ist nun, dass wir aus options einen Hash der folgenden Form machen müssen, um mit create_resources, opt1 und opt2 anlegen zu können.

{ 'opt1' => { 'value' => 'alpha' },
  'opt2' => { 'value' => 'beta' },
}

Ruby bietet für Hashes eine Methode inject, die wir innerhalb eines inline_templates anwenden. Die inline_template Funktion liefert jedoch nur Strings zurück und keinen Hash. Deshalb geben wir den String in YAML zurück, den wir abschließend mit der im Module puppetlabs-stdlib enthaltenen Funktion parseyaml wieder in einen Hash der geforderten Form umwandeln.

class config(
  $options = {},
) {
  create_resources('config::setting',
    parseyaml(inline_template(
      '<%= @options.inject({}) {|h, (x,y)| h[x] = {"option" => x, "value" => y}; h}.to_yaml %>'))
  )
}
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.