Seite wählen

NETWAYS Blog

Trick 17 mit dem Director

Möchte man die Schnittmenge aus mehreren Importquellen im Icinga Director vereinen, so gibt es dafür einen Lösungsweg der bislang vielen noch nicht bekannt ist.
Beispielhaft dienen folgende zwei SQL-Tabellen als Ausgangslage, testhost03 ist dabei nur in der Tabelle „hosts01“ enthalten:
MariaDB [cmdb]> SELECT * FROM cmdb.hosts01;
+----+------------+----------+---------+
| id | hostname   | address  | os      |
+----+------------+----------+---------+
|  1 | testhost01 | 10.0.0.1 | Windows |
|  2 | testhost02 | 10.0.0.2 | Linux   |
|  3 | testhost03 | 10.0.0.3 | Windows |
+----+------------+----------+---------+

MariaDB [cmdb]> SELECT * FROM cmdb.hosts02;
+----+------------+----------+---------+
| id | hostname   | address  | os      |
+----+------------+----------+---------+
|  1 | testhost01 | 10.0.0.1 | Windows |
|  2 | testhost02 | 10.0.0.2 | Linux   |
+----+------------+----------+---------+

Um nun die Daten aus beiden Quellen abzugleichen ohne gleich Objekte im Director zu erzeugen, behilft man sich mit einer Datenliste als Zwischenschritt. Die ID der neu erstellten Datenliste wird später benötigt und kann über die Director-Datenbank herausgefunden werden:
MariaDB [director]> SELECT * FROM director.director_datalist WHERE list_name = "Hosts from 2nd import source";
+----+------------------------------+-------------+
| id | list_name                    | owner       |
+----+------------------------------+-------------+
|  2 | Hosts from 2nd import source | icingaadmin |
+----+------------------------------+-------------+

Wie dem Namen der Liste unschwer zu entnehmen ist sollen dort die Hosts aus der 2ten Importquelle, also von „hosts02“, zwischengespeichert werden.
Mit diesen Informationen kann die entsprechende Sync Rule für die Synchronisation der Hosts aus der 2ten Quelle in die Datenliste erstellt werden. Neben der ID als jeweilige „list_id“ (hier „2“) werden die Felder „entry_name“ und „entry_value“ definiert:

Nach dem Syncvorgang erhält die Datenliste die entsprechenden Einträge. Im Beispiel sind das testhost01 und testhost02. In der Import Source für die erste Datenquelle werden deren Einträge nun anhand des „Map“-Modifiers mit den Einträgen aus der Datenliste abgeglichen:

Damit ergibt sich folgende Vorschau der Import Source:

In der darauf aufbauenden Sync Rule ist es wichtig eine entsprechende Filter expression zu setzen:

Ist sie negiert, wie im vorangegangenen Beispiel, werden die Hosts die in beiden Datenquellen vorkommen erzeugt. Im Beispiel wären das testhost01 und testhost02. Liegt keine Negierung vor (z.B. „map=“), so werden nur die Hosts erzeugt die in der zweiten Datenquelle nicht vorkommen. Also beispielhaft testhost03. Damit der Filter greift, muss der Bezeichner (hier „map“) allerdings auch als Eigenschaft der Sync Rule vorkommen.
Der Icinga Director hält noch wesentlich mehr Funktionen für verschiedenste Anwendungsbereiche bereit. Das vorangegangene Beispiel dient lediglich dazu die Fähigkeiten dieses mächtigen Tools etwas zu veranschaulichen. Bei weiteren Fragen rund um den Director oder auch Icinga 2 stehen wir bei NETWAYS natürlich gerne zur Verfügung.

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.

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.

Sync Git repositories to GitHub

GitHub-Mark-120px-plusWhile we still have our own repositories located at https://git.netways.org it’s reasonable to sync the existing repositories to GitHub targetting a wider audience (and not everyone likes the gitorious web interface either). There are certain requirements syncing git repositories in general:

  • create, update and delete branches
  • create and delete tags
  • don’t always clone the repository but fetch local changes

Aside from that, you’ll need

  • a shell user, e.g. github on a box running the sync
  • ssh key for pushing remote origin
  • small sync script
  • a cronjob for that sync script, e.g. every 5 minutes
  • git binary >= 1.7.10 providing the –prune option

If you are planning to push your local repository (in our example, git.netways.org) to github.com, you’ll also need the following

  • add the public ssh key to your github user at https://github.com/settings/ssh
  • ensure that this user is allowed to push your company’s repositories (make it a team member)

The sync script part is easy thanks to the possibilities git already provides. An older version of the sync script is used for syncing the Icinga Github repositories in a similar fashion. For Icinga, it’s most important to sync the git tags, making the release tarballs available on Github.

#!/bin/bash
REPO_HOME="/data/scm/sync"
declare -A REPOS
# syntax is [github_repo]="netways_repo"
REPOS=([ingraph]="ingraph/ingraph" [lconf]="lconf/lconf" [lconf-icinga-module]="lconf/icinga-module" [lconf-web]="lconf/lconf-web")
cd $REPO_HOME
for REPO_GITHUB in "${!REPOS[@]}"
do
	REPO_LOCAL=${REPOS[$REPO_GITHUB]}
        echo "### Processing repo $REPO_LOCAL"
        if [ ! -d $REPO_LOCAL ]; then
                git clone --bare --mirror git://git.netways.org/$REPO_LOCAL.git $REPO_LOCAL
        fi
        (cd $REPO_LOCAL; git fetch --prune; git push --prune git@github.com:NETWAYS/$REPO_GITHUB.git +refs/heads/*:refs/heads/* +refs/tags/*:refs/tags/*)
done

git {fetch,push} –prune ensures that deleted branches/tags on the source repository are also deleted on the target repository.
Saving the sync script as /data/scm/sync/create_and_sync allows you to add the following cron job every five minutes:

# su - github
$ crontab -e
# Sync repos to github
*/5 * * * * /data/scm/sync/create_and_sync > /dev/null 2>&1

Ynetways_githubou can check the result watching the development branches at https://github.com/netways for LConf and inGraph – if you’re looking for your own custom git integration, don’t hesitate to contact us 🙂
PS: Another cool way of syncing github repositories is the Icinga Exchange integration!