Vom Noob-OS zum IPv6-Router

Eigentlich habe ich in meinem letzten Blog-Post angekündigt, diesmal “den abgebissenen Apfel bis auf den Kern” zu schälen. Aber gerade als ich alle Vorbereitungen dafür abgeschlossen hatte, erinnerte mich ein außergewöhnlich religiöser Kollege (der an dieser Stelle nicht namentlich genannt werden möchte) daran, was Adam und Eva damals widerfahren ist, nachdem sie vom selbigen Apfel “nur” abgebissen hatten. Ein Risiko von solchem Kaliber für einen einzigen Blogpost einzugehen, wäre einfach nur unverhältnismäßig. Deshalb beschränke ich mich in diesem Beitrag darauf, dem Skript vom letzten mal IPv6-Unterstützung zu verleihen.

Bestandsaufnahme


Weder die Topologien der Netzwerke, noch die damit einhergehenden Probleme haben sich seit dem letzten Beitrag geändert. Das Setup wurde “lediglich” auf IPv6 umgestellt – schließlich wird man in Zukunft über die Nutzung von IPv4 wahrscheinlich ähnlich wertend reden wie heute über die Nutzung von Schreibmaschinen. Das Problem besteht darin, dass eine VM im Netz 2001:db8::192.0.2.16/124 nicht ohne weiteres mit Containern im Netz 2001:db8::192.0.2.32/124 kommunizieren kann, da sie nicht weiß, dass letztgenanntes Netz hinter der VM 2001:db8::192.0.2.18 liegt. Um dieses Problem zu beheben, kann man entweder jeder einzelner betroffener VM diesen Weg beizubringen – oder man nutzt…

Statische IPv6-Routen auf Mac OS X

Leider ist dies etwas schwieriger, als die Einrichtung von IPv4-Routen – zumindest wenn die VMs mit Parallels betrieben werden. Dem Host wird nämlich die IP 2001:db8::192.0.2.17 nicht automatisch zugewiesen. Und es gibt anscheinend keine Möglichkeit, dies über die Netzwerkeinstellungen dauerhaft zu ändern.

Dann eben durch die Hintertür…

Das zuletzt bereits angelegte Skript /usr/local/sbin/add-static-routes.sh, das beim Systemstart automatisch ausgeführt wird (siehe letzten Blogbeitrag), kann für diesen Zweck mitgenutzt werden, indem man am Ende folgende Zeile hinzufügt:

/usr/local/sbin/assign-inet6-address.pl "$(/usr/local/sbin/get-iface-by-inet-address.pl 192.0.2.17)" 2001:db8::192.0.2.17/124

Alle Skripte, die nicht im letzten Blogpost auftauchen stehen am Ende dieses Blogposts. Die konkreten Daten sind nicht aus der Luft gegriffen, sondern müssen mit den Parallels-Netzwerkeinstellungen übereinstimmen – wobei die Adresse der Netzwerk-Schnittstelle “Subnetz + 1” sein sollte:

2001:db8::c000:210 + 1 = 2001:db8::c000:211 = 2001:db8::192.0.2.17

Zurück zu der Route

Nach der eben vollendeten Überwindung der Parallels-Hürde steht der Eigentlichen statischen Route nichts mehr im Wege. Diese wird einfach in /usr/local/sbin/add-static-routes.sh mit aufgenommen:

/usr/local/sbin/add-static-route6.pl 2001:db8::192.0.2.32/124 2001:db8::192.0.2.18

Diese Route tritt spätestens nach einem Neustart in Kraft. Mangels Geduld kann man auch die zwei hinzugefügten Zeilen direkt auf der Kommandozeile ausführen:

# bash
bash-3.2# /usr/local/sbin/assign-inet6-address.pl "$(/usr/local/sbin/get-iface-by-inet-address.pl 192.0.2.17)" 2001:db8::192.0.2.17/124
bash-3.2# /usr/local/sbin/add-static-route6.pl 2001:db8::192.0.2.32/124 2001:db8::192.0.2.18

Fazit

“Warum extrem einfach wenn es auch unnötig kompliziert geht?” Diesem Motto werde ich auch weiterhin treu bleiben – also stay tuned!

Skripte

/usr/local/sbin/get-iface-by-inet-address.pl

#!/usr/bin/perl
# (C) 2017 NETWAYS GmbH | GPLv2+
# Author: Alexander A. Klimov
my $inet_addr = shift;
exit 2 if ! defined $inet_addr; # RTFM at https://wp.me/pgR2o-rur
my $iface;
$inet_addr = quotemeta($inet_addr);
POLL: for (;;) {
	for (`/sbin/ifconfig`) {
		if (/^(\S+?): /) {
			$iface = $1
		} elsif (defined($iface) && /^\tinet $inet_addr /) {
			print $iface;
			last POLL
		}
	}
	sleep 1
}

/usr/local/sbin/assign-inet6-address.pl

#!/usr/bin/perl
# (C) 2017 NETWAYS GmbH | GPLv2+
# Author: Alexander A. Klimov
my $iface = shift;
my $inet6_addr = shift;
exit 2 if !(defined($iface) && defined($inet6_addr) && $inet6_addr =~ m~^(.+)/(\d+)$~); # RTFM at https://wp.me/pgR2o-rur
my $status = system("/sbin/ifconfig", $iface, "inet6", $1, "prefixlen", $2) >> 8;
die "/sbin/ifconfig: $status" if ($status != 0)

/usr/local/sbin/add-static-route6.pl

#!/usr/bin/perl
# (C) 2017 NETWAYS GmbH | GPLv2+
# Author: Alexander A. Klimov
my $destination = shift;
my $gateway = shift;
exit 2 if !(defined($destination) && defined($gateway) && $destination =~ m~^(.+)/(\d+)$~); # RTFM at https://wp.me/pgR2o-rur
$destination = $1;
my $destination_prefixlen = $2;
my $gatewayBin = ip6adr2bin($gateway);
POLL: for (;;) {
	for (`/sbin/ifconfig`) {
		if (/^\tinet6 (.+?)(?:%\S+)? prefixlen (\d+)/) {
			if (ip6bin2prefix($gatewayBin, $2) eq ip6bin2prefix(ip6adr2bin($1), $2)) {
				my $status = system("/sbin/route", "add", "-inet6", "-prefixlen", $destination_prefixlen, "-net", $destination, $gateway) >> 8;
				die "/sbin/route: $status" if ($status != 0);
				last POLL
			}
		}
	}
	sleep 1
}
sub ip6adr2bin
{
	my $raw = shift;
	if ($raw =~ /::/) {
		my ($head, $tail) = split(/::/, $raw);
		$head = ip6part2bin($head);
		$tail = ip6part2bin($tail);
		return $head . ("0" x (128 - (length($head) + length($tail)))) . $tail
	}
	ip6part2bin($raw)
}
sub ip6bin2prefix
{
	my $addr = shift;
	my $prefixlen = shift;
	substr($addr, 0, $prefixlen) . ("0" x (128 - $prefixlen))
}
sub ip6part2bin
{
	join("", map({ /\./ ? join("", map({ sprintf("%08b", $_) } split(/\./, $_))) : sprintf("%016b", hex($_)) } split(/:/, shift())))
}
Alexander Klimov
Alexander Klimov
Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der...

Vom Noob-OS zum IPv4-Router

Dass man die Docker-Alternative LXD ohne große Hürden auch auf Mac OS X betreiben kann, habe ich in meinem letzten Blog-Post bereits detailliert erläutert.
Leider kann ich im Rahmen meiner Arbeit nicht alles in diesen Ubuntu-Containern betreiben. Die Entwicklungsumgebungen für so manche Anwendungen wie z. B. Icinga Web 2 werden mit Vagrant provisioniert und dieses Programm lässt sich nur sehr mühsam an LXD koppeln. Deshalb komme ich nur mit der einen LXD-VM wohl oder übel nicht aus.
Spätestens wenn die anderen VMs (oder deren Container) mit den LXD-Containern kommunizieren müssen, stößt dieses Setup an seine Grenzen… oder?

Das Setup im Detail


Wie auch jeder andere Gewerbebetrieb, in dem keine Schreibmaschinen mehr zum Einsatz kommen, verfügt NETWAYS über ein internes IP-Netz – beispielhaft mit den Host-Adressen 192.0.2.1 – 192.0.2.14. Der Router zum Internet beansprucht für sich die 192.0.2.1 und meinem Arbeitsgerät ist die 192.0.2.2 zugeteilt.
Um mit meinen virtuellen Maschinen kommunizieren zu können, teilt meine Workstation sich ein IP-Netz mit ihnen (192.0.2.17 – 192.0.2.30). Und schließlich sollen auch meine LXD-Container nicht so isoliert sein wie ein Schreibmaschinen-Nutzer – deshalb teilen sie sich ein wieder anderes IP-Netz (192.0.2.33 – 192.0.2.46) mit der LXD-VM.
Wenn nun ein Knoten einen anderen ansprechen will, muss er entweder im selben IP-Netz sein wie der gewünschte Gesprächspartner – oder in der Netz-Hierarchie unter einem Router stehen, der den gewünschten Gesprächspartner erreichen kann.

Beispiel #1

LXD-Container #1 will mit 192.0.2.50 kommunizieren, ist aber nicht im selben Netz. Ihm bleibt nichts anderes, als über sein Standard-Gateway, 192.0.2.33, zu senden und zu hoffen, dass die Verbindung erfolgreich zustande kommt. Die LXD-VM ist aber auch nicht im selben Netz. Daher muss sie sich wiederum auf ihren Standard-Gateway (192.0.2.17) verlassen. Meine Workstation delegiert wiederum an 192.0.2.1 usw.. Und wenn da draußen tatsächlich eine 192.0.2.50 online ist (und alle Internet-Router so rund laufen wie unser Firmen-Gateway) kommt letztendlich die Verbindung erfolgreich zustande.

Beispiel #2

VM #1 will mit 192.0.2.34 kommunizieren, ist aber nicht im selben Netz. Ihr bleibt nichts anderes, als an ihr Standard-Gateway, 192.0.2.17, zu delegieren. Leider weiß Mac OS nichts vom Netz 192.0.2.32/28 und delegiert an unser Firmen-Gateway. Das und alles dahinter kann noch so rund laufen, aber der Zug in Richtung des LXD-Container-Netzes ist längst abgefahren.
Aber ich würde nicht schon gut 3,5 Jahre bei NETWAYS arbeiten wenn ich diese Hürde nicht spielend einfach überwinden könnte. Dazu braucht es nur…

Statische Routen auf Mac OS X

Natürlich könnte ich auch auf jeder VM eine statische Route hinterlegen, aber das wäre zusätzlicher Aufwand bei jeder VM-Erstellung. Sollte darüber hinaus die Anzahl der VMs mit Linux-Containern zunehmen, steigt damit auch mein Aufwand beim Routen-Management nicht zu knapp…
Deshalb ist es langfristig so oder so sinnvoller, alle VMs an die Workstation delegieren zu lassen und diese zum Router zu befördern. Wie praktisch, dass Mac OS X auf 4.4BSD basiert und damit zur *nix-Familie gehört. Damit ist dieses Vorhaben ein Kinderspiel (wenn man weiß wie es geht).

Jetzt aber endlich mal Butter bei die Fische

Schritt 1: Konzentration!

Um Mac OS die gewünschten statischen Routen beizubringen, muss man tiefer ins System eingreifen, als es ein durchschnittlicher Mac-Nutzer es gewohnt ist. Dabei lässt sich mit ein bisschen Schusseligkeit sehr viel kaputt machen. Wenn Du gerade z. B. eine ordentliche Portion G&T konsumiert hast… habe Geduld. Morgen ist auch noch ein Tag und Mac OS läuft schon nicht weg.

Schritt 2: Root-Rechte

Obwohl Mac OS sich an weniger versierte Nutzer richtet, bietet es die Möglichkeit, Root-Rechte zu erlangen wie man das von verbreiteten GNU/Linux-Distributionen kennt:

Alexanders-MacBook-Pro:~ aklimov$ sudo -i
Password:
Alexanders-MacBook-Pro:~ root#

Schritt 3: Hilfs-Skripte

Die eben erlangten Privilegien berechtigen uns, Skripte in dem OS vorbehaltene Verzeichnisse zu platzieren – wovon wir auch Gebrauch machen, indem wir zunächst das Verzeichnis /usr/local/sbin erstellen und darin zwei Skripte ablegen:

Alexanders-MacBook-Pro:~ root# mkdir -p /usr/local/sbin
Alexanders-MacBook-Pro:~ root# vim /usr/local/sbin/add-static-route.pl
Alexanders-MacBook-Pro:~ root# chmod 0755 /usr/local/sbin/add-static-route.pl
Alexanders-MacBook-Pro:~ root# vim /usr/local/sbin/add-static-routes.sh
Alexanders-MacBook-Pro:~ root# chmod 0755 /usr/local/sbin/add-static-routes.sh

Das erste Skript, /usr/local/sbin/add-static-route.pl, dient dem Hinzufügen von statischen Routen, sobald die entsprechende Netzwerk-Schnittstelle online ist:

#!/usr/bin/perl
# (C) 2017 NETWAYS GmbH | GPLv2+
# Author: Alexander A. Klimov
my $destination = shift;
my $gateway = shift;
if (!(defined($destination) && defined($gateway))) {
    exit 2 # RTFM at https://wp.me/pgR2o-rlj
}
my $gatewayDec = ip4_2dec($gateway);
POLL: for (;;) {
    for (`/sbin/ifconfig`) {
        if (/^\tinet (.+?) netmask (.+?) /) {
            my $mask = hex($2);
            if (($gatewayDec & $mask) == (ip4_2dec($1) & $mask)) {
                my $status = system("/sbin/route", "add", "-net", $destination, $gateway) >> 8;
                die "/sbin/route: $status" if ($status != 0);
                last POLL
            }
        }
    }
    sleep 1
}
sub ip4_2dec
{
    hex(join("", map({ sprintf("%02x", $_) } split(/\./, shift()))))
}

Das zweite Skript, /usr/local/sbin/add-static-routes.sh, ruft das erste Skript auf und fügt damit konkrete Routen hinzu:

#!/bin/bash
set -e
set -o pipefail
/usr/local/sbin/add-static-route.pl 192.0.2.32/28 192.0.2.18

Die Kommandozeilen-Schnittstelle des ersten Skripts habe ich extra so gestaltet, dass die Routen-Liste (das zweite Skript) möglichst einfach erweitert werden kann. Wenn bspw. eine zweite LXD-VM mit der IP-Adresse 192.0.2.21 dazukommt und mit ihren Containern über das Netz 192.0.2.64/28 verbunden ist, gehört folgende Zeile ans Ende der Routen-Liste:

/usr/local/sbin/add-static-route.pl 192.0.2.64/28 192.0.2.21

Schritt 4: Autostart

Damit das zweite Skript nicht bei jedem Systemstart manuell ausgeführt werden muss, lassen wir Mac OS es für uns automatisch starten:

Alexanders-MacBook-Pro:~ root# pushd /Library/LaunchDaemons
/Library/LaunchDaemons ~
Alexanders-MacBook-Pro:LaunchDaemons root# vim mystaticroutes.plist
Alexanders-MacBook-Pro:LaunchDaemons root# launchctl load mystaticroutes.plist

Inhalt von mystaticroutes.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>MyStaticRoutes</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/local/sbin/add-static-routes.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

Fazit

Obwohl mich die Kollegen aus den eigenen Reihen – aber auch aus NMS und PS – spätestens seit diesem Blogeintrag mit besorgten Blicken überschütten, werde ich einfach nicht müde, das Noob-OS von Apple auf biegen und brechen meinen seltsamen Bedürfnissen entsprechend aufzubohren.
Abonniert gerne kostenlos diesen Blog um auch über die nächste Runde informiert zu werden – wenn ich den abgebissenen Apfel bis auf den Kern schäle…

Alexander Klimov
Alexander Klimov
Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der...

Monthly Snap February: Events, Webinar, Docker, Backup and Icinga

weekly snapFebruary started with the announcement news that OSDC 2016 – Program is online! while Thomas talked about his Presentation SSHave your Puppets! on Config Management Camp in Gent.
 
Lennart shared tips to standardize Perl-Plugins and Jean-Marcel introduced the Icinga Buildserver Project.
Christian presented the new webinar calendar 2016 while MariusG took a deeper look on the Docker-Registry.
Pamela counted 8 weeks to the OSDC 2016 with Stephen Benjamin´s talk on “Foreman in Your Data Center”.
 
Last but not least David explained why Backups are important.
Vanessa Erk
Vanessa Erk
Head of Finance & Administration

Vanessa ist unser Head of Finance und somit mit ihrem Team für das Geld, Controlling und die Personalverwaltung zuständig. Außerhalb des Büros ist sie sportlich unterwegs und widmet sich hauptsächlich dem Yoga. Auf das offizielle Yoga-Teacher-Training (RYT 200), das sie mit Bravour bestanden hat folgte gleich eine Zusatzausbildung zur Vertiefung ihres Wissens. Ihr Fleiß dahingegen wird zukünftig wohl noch mehreren älter werdenden NETWAYS´lern zugutekommen.

Perl-Plugins standardisieren

Im Icinga- bzw. Nagios-Umfeld wird für Plugins gerne Perl eingesetzt. Das Monitoring Plugins Projekt stellt mit dem Monitoring Perl-Modul eine standardisierte Schnittstelle zur Verfügung mit der sich schnell und einfach eigene Plugins programmieren lassen, die den Richtlinien für Plugins entsprechen.
Auszüge aus einem Plugin zum Abfragen des Status eines Apache-Webservers soll den generellen Aufbau verdeutlichen. Das komplette Skript ist auf Github veröffentlicht.

$plugin = Monitoring::Plugin->new;

Zuerst instantiert man neues Objekt und bereitet mit der Methode Getopt->new die Verarbeitung von Optionen vor.

$options = Monitoring::Plugin::Getopt->new(
  usage   => 'Usage: %s [OPTIONS]',
  version => $VERSION,
  url     => 'https://github.com/lbetz/nagios-plugins',
  blurb   => 'Check apache server status',
);

Optionen mit beschreibenden Text für den Aufruf des Plugins werden dem Objekt mit der Methode arg hinzugefügt. Mit spec wird die Variable festgelegt in der, der Wert der Option abgelegt wird. Die Variable lautet hier hostname. Nach der Pipe folgt die Option für das Plugin, hier ein H. Die Zuweisung des Buchstabens s bedeutet, dass hier ein String übergeben wird.

$options->arg(
  spec     => 'hostname|H=s',
  help     => 'hostname or ip address to check',
  required => 1,
);

Weitere Typen sind i für einen Integer oder das als Suffix angehängte + für einen Schalter. Mit -s wird also gesteuert, dass die Anfrage via HTTPS zu erfolgen hat. getopts erledigt dann die Übernahme der Optionen in Variablen.

$options->arg(
  spec     => 'port|p=i',
  help     => 'port, default 80 (http) or 443 (https)',
  required => 0,
);
$options->arg(
  spec     => 'ssl|s+',
  help     => 'use https instead of http',
  required => 0,
);
$options->getopts();

Ausgehend davon, dass auch die üblichen Optionen für Schwellwerte implementiert sind, kann ein Threshold-Objekt erzeugt werden. Dieses wird später für die Status-Ermittlung herangezogen.

$threshold = Monitoring::Plugin::Threshold->set_thresholds(
  warning  => $warning,
  critical => $critical,
);

Die aus den Optionen ermittelten Variablen lassen sich nun für den HTTP-Request benutzen.

$request = HTTP::Request->new(GET => 'http://'.$options->hostname.'/server-status/?auto');

Nachfolgend ist der HTTP-Response auszuwerten. Hier ist in $OpenSlots die Anzahl der noch zur freien Verfügung stehen Slots abgelegt.

$plugin->add_perfdata(
  label => 'OpenSlots',
  value => $OpenSlots,
  uom   => q{},
  threshold => $threshold,
);

Performance-Daten lassen sich mit der Methode add_perfdata dem Pluginoutput hinzufügen, hier OpenSlots=n. Abschließend wird in Abhängigkeit der Schwellwerte der Return Code berechnet und das Plugin mittels exit beendet.

$plugin->nagios_exit($threshold->get_status($OpenSlots), 'some plugin output');
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.

Perl statt PHP und Python

Wir hatten schon das Thema ja mit Python und auch mit PHP, zum Abschluss möchte ich noch die Möglichkeit mit Perl aufzeigen.
Darf ich wieder vorstellen: Mojolicious

A next generation web framework for the Perl programming language.

Die Installation erfolgt ganz einfach:

$ curl -L https://cpanmin.us | perl - -M https://cpan.metacpan.org -n Mojolicious

Mit dem Programmcode:

use Mojolicious::Lite;
get '/' => {text => 'Hello, World!'};
app->start;

Die Ausführung erfolgt dann mit:

$ morbo hello.pl

Wie auch bei den anderen Microframeworks, läuft alles recht schnell und einfach von der Hand.
Wer mehr Informationen zu Mojolicious braucht, der wird bei Perl-Magazin fündig 😉
An der Stelle, viel Spaß damit!

inDoc – Mach es dem Support einfacher…

16811692146_85b370edb1_oBeim eröffnen eines Tickets ist es immer das gleiche. Welches Betriebssystem? Welche Version der Applikation? Immer die gleichen Fragen… Ihr habt keine Lust mehr Informationen zusammen zu sammeln? Dann nehmt doch inDoc!
inDoc ist eine kleine Sammlung an Skripten die Informationen aus eurem Monitoring-Setup sammelt und diese in einer XML-Datei speichert. Auf diese Weise wird z. B. die icinga.cfg oder auch Daten über den laufenden Icinga Prozess (PID, Speicherverbrauch, usw.) gesichert.
Aber keine Angst, der Entwickler ist nicht die NSA! Die Daten sind dann ausschließlich auf eurem Server und Passwörter werden in formschöne Sterne (******) verwandelt.
Der XML-Output ist neutral und kann mit allen gängigen Programmiersprachen wieder eingelesen werden, womit das gute Stück auch für Dokumentationszwecke genutzt werden kann. Ein erstes Beispiel hierfür zeigt das Skript inDoc2HTML.pl.
In der Praxis ist inDoc denkbar einfach:
icinga@monitoring-host# git clone https://github.com/NETWAYS/indoc
icinga@monitoring-host# cd indoc
icinga@monitoring-host# ./inDoc.pl

That’s it! 🙂
Das war kurz und schmerzlos, aber was hab’ ich nun davon?

icinga@monitoring-host# ls -la /tmp/inDoc-out/
total 56
drwxr-xr-x 3 icinga icinga 4096 Aug 14 18:49 .
drwxrwxrwt 4 root root 4096 Aug 14 18:54 ..
-rw-r--r-- 1 icinga icinga 492 Aug 14 18:49 check_disk.xml
-rw-r--r-- 1 icinga icinga 450 Aug 14 18:49 check_http.xml
-rw-r--r-- 1 icinga icinga 449 Aug 14 18:49 check_load.xml
-rw-r--r-- 1 icinga icinga 7456 Aug 14 18:49 icinga.xml
-rw-r--r-- 1 icinga icinga 2434 Aug 14 18:49 indoc_base.xml
-rw-r--r-- 1 icinga icinga 12875 Aug 14 18:49 inDoc.xml
-rw-r--r-- 1 icinga icinga 1476 Aug 14 18:49 pnp4nagios.xml
drwxr-xr-x 2 icinga icinga 4096 Aug 14 18:48 savedFiles

Ohne weitere Optionen schreibt das Skript nach /tmp/inDoc-out. Hierunter findet ihr die Discovery-Ergebnisse der einzelnen Module. Das inDoc.xml beinhaltet die Informationen aller Module. So sind die Daten bequemer weiter zu verarbeiten.
Das ganze Set an Skripten wird von Zeit zu Zeit erweitert. Icinga 2 wird selbstverständlich zu den ersten gehören 😉
Picture by GotCredit – https://www.flickr.com/photos/jakerust

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.