Monitoring Powershell scripts with Icinga 2

The need to to monitor arbitrary Powershell scripts comes up now and then and often there are some workarounds or alternatives, NSClient for example, named. However in order to have something I can link refer people to when the topic comes up again, I’ll try to provide a quick and simple to adapt solution. Keep in mind that this assumes you have Icinga 2 up and running on your Windows host, Powershell installed and are reasonably sane.
First the the check script I used for demonstration purposes in this case, all it does is check whether a process is running and returning OK or CRITICAL based on that.

if ($args.Length -lt 1) {
	Write-Output "Script requires one argument (Process)"
$state = Get-Process $proc -ErrorAction SilentlyContinue
if ($state) {
	Write-Output "PROCESS OK '$proc' is running"
} else {
	Write-Output "PROCESS CRITICAL '$proc' is not running"

Safe it as check_proccess.ps1 somewhere you can find it again. In this case I put next to the other check plugins.
The following are the check_command object and Service apply. And as it turns out it’s not that easy of a task as I thought, it’s mostly Windows fault really… Getting the exit code of a script from Powershell returned to icinga2 required some trickery (credit goes to NSClient for that one). The result is a bit of weird CheckCommand, which can and should be improved.

object CheckCommand "powershell" {
    import "plugin-check-command"
    command = [ "cmd" ]
    arguments = {
        "Weird command" = {
            value = "/c echo $powershell_script$ $powershell_args$ ; exit ($$lastexitcode) | powershell.exe -command -"
            description = "This is needed because powershell would not tell us the exit code otherwise"
            skip_key = true
apply Service "check_powerpoint" {
    import "generic-service"
    check_command = "powershell"
    vars.powershell_script = PluginDir + "\check_process.ps1"
    vars.powershell_args = "POWERPNT"
    assign where host.vars.os == "Windows"

Der Icinga Buildserver, Version 3

Letztes verbliebene Bild des alten Icinga Jenkins

Der Icinga-Buildserver, erreichbar unter, läuft in dieser Form jetzt etwa ein Jahr. Doch gibt es noch immer ein paar Probleme die mit diesem Setup bestehen: So ist das Hinzufügen neuer Jobs noch etwas umständlich, das provisionieren dauert länger als uns lieb ist und besonders übersichtlich ist die Konfiguration auch nicht. Um diese Probleme anzugehen haben wir uns noch einmal mit Puppet und Jenkins auseinandergesetzt.
Wie vorher verwenden wir ein jenkins puppet-modul, nur diesmal haben wir es mit einem speziellen icinga-jenkins Modul erweitert. Dieses Modul erlaubt es uns spezielle pipeline-jobs mit geringem Konfigurationsaufwand zu erstellen. So ist das unterstehende Beispiel alles was zu konfigurieren ist um eine komplette Pipeline zu erstellen. Selbst der spezielle Umgang mir RPM und Deb ist zu großen Teilen vereinheitlicht und funktioniert für alle Projekte gleich.

    control_branch: snapshot
      'debian-jessie': {}

Die Pipeline erstellt dabei nicht nur einen, sondern gleich vier Jobs: “source”, “binary”, “test” und “publish”. Diese verarbeiten die specfiles, bauen das Paket, testen es und veröffentlichen es auf
In Produktion ist unser Modul noch nicht, aber um den testen und konfigurieren zu können haben wir Vagrant Boxen gebaut. Mit Hilfe derer bauen wir zur Zeit das icinga-jenkins Modul weiter aus um den bestehenden Buildserver komplett mit den neuen Pipelinejobs abbilden zu können. Wir hoffen unseren Buildprozess damit noch einfacher für Entwickler zu machen und dank der neuen Testsphase für Pakete Problemen in Zukunft besser vorzubeugen zu können

Monitoring Windows with Icinga 2 and NSCP

Monitoring Windows systems can be quite a hassle without the right tools. While Icinga 2 comes with a few check plugins for Windows, sadly they only allow for the most basic monitoring. A tool which is often used for this reason is NSClient++ (NSCP). This little extendable GPL software uses its own checks and even comes with a fully functioning web interface.

The monitoring view of the NSCP Web interface

The monitoring view of the NSCP Web interface

But there are problems with this solution in that it does not work with Icinga 2 out of the box and a few tweaks are necessary. To ease working with these two tools I have written a new Icinga 2 Windows Plugin “check_nscp”, which works like check_nt only that is is less restrictive in its parameters and allows for any NSCP Query to be used.
The following is an example Icinga 2 config which uses check_nscp to monitor the memory used by the Icinga 2 process.

object CheckCommand "nscp-memory-proc" {
    import "nscp-windows"
    vars.nscp_win_query = "check_process"
    vars.nscp_win_args = [
apply Service "icinga-mem" {
	import "generic-service"
	check_command = "nscp-memory-proc"
	vars.nscp_memory_proc_proccess = "icinga2.exe"
	vars.nscp_memory_proc_warn = "70m"
	vars.nscp_memory_proc_crit = "200m"
	assign where == NodeName

This requires the CheckCommand for check_nscp which will be released together with check_nscp in one if the coming Icinga 2 Versions.

Windows git tools

From time to time I start up my Windows 7 VirtualBox because there is some Windows-specific issue in Icinga 2 to solve. And the first thing to do then is to pull the Icinga 2 repository. The obvious way to do that is to enter git pull in the right directory at least on *nix. But Windows is not Linux and likes to everything a bit more graphical so I put my cynicism aside and tried out two graphical Git tools (again): TortoiseGit and SourceTree


I used TortoiseSVN back in 2006/7 (that’s a long time so I might remember things incorrectly) and it was my first interaction with version control, without really knowing what version control was. And I wasn’t particularly fond of it, especially the gigantic right-click-context-menu was of my distaste. Now, nearly ten years later, I’m testing its sister software. And this time I know what I’m doing, I hope.
It all looks familiar but less Windows XPish. The context menus are still there but aren’t as intrusive as I remember them to be but I still get lost configuring it. Where or how do I add a SSH Key again? After that is taken care of it is time to check how it holds up against plain Git in a shell.
Commit, push, pull and fetch all work like expected. Amends are easy to make, bisect works reasonably well but can’t seem to find an equivalent of something like git rebase -i HEAD~3. One thing that stood out was the log, it’s neat. A bit ugly but really neat.
I’m surprised how good TortoiseGit works, yet there seems to be no way to access the full power of Git in case something goes really wrong. All you can do is delete the repository and delete the repo and clone it anew.


I used SourceTree when I first started at NETWAYS in 2014 and abandoned it after a short while. It looked nice but had too many problems to be of much use, so let’s see how it changed in over a year.
sourcetreeThe first change I noticed is the installer, it now requires you to create an Atlassian account. After I gave my E-mail to Atlassian and accepted they may send me whatever information they think might interest me (you don’t get a choice there) I am greeted by a much smoother interface than a year ago, in German because the language default is based on you operating systems locale.
And what else did change? Not much, everything is still where it was. Commit still commits and pull still pulls. When I first used SourceTree I did not get too deep into it’s features but trying out a few of them I found them to be lacking: like TortoiseGit SourceTree is mostly just a fancy wrapper around Git commands, but SourceTree is missing bisect. Compared to TortoiseGit its actions are also hidden a lot deeper inside of sub menus, for example Actions->Resolve Conflicts->Launch External Merge Tool, to start vimdiff. To make up for it’s lack of features it hast the Terminal button which launches a Git shell in the selected repositories directory and you have the full power of Git at your fingertips.

Git Bash

In the end nothing beats Git Bash. It’s not fancy, it only has one context-menu: Git Bash here.ok this is fine
But don’t forget that “with great power comes great responsibility”, as Spiderman’s uncle used to say when he wrote sudo. You want to throw the remote master away and substitute you own, because you have some good reason to or just want to create chaos?
git push repo +master:new_master
If you want to learn more about Git, we are offering Git trainings too.

Das Icinga Buildserver Projekt

Der neue Icinga Buildserver soll die Pakete in Docker Containern die das entsprechende Zielsystem ab um rpm- und deb-Pakete auf gleiche Art betreuen zu können. Das heißt anstatt die eigentlich praktischen Build-Umgebungen wie pbuilder und sbuild werden nicht verwenden.
Stattdessen haben wir ein paar lustige Bash-Skripte gebaut die das kompilieren und verpacken übernehmen. Vor allem bei Debian Paketen gibt es dabei ein paar interessante Schritte die sonst von eben genannten Tool übernommen werden. Wie etwa das finden von Abhängigkeiten:

dpkg-checkbuilddeps 2>&1 \
  | grep "^$prefix" \
  | sed -e "s/$prefix//" -e s'/([^)]*)//g' -e 's/ \+| \+/|/g'

Das Ganze ist es dann aber Wert, wenn erst einmal umgezogen wurde. (Man kann an der Seite sofort merken ob es sich um die alte oder neue handelt)
Das ganze Projekt geht inzwischen schon etwas länger aber nähert sich jetzt seiner Vollendung.

Ein zweiter Blick auf die OSMC

Diese Woche fand wieder die Open Source Monitoring Conference statt, ich war zum zweiten mal dabei. Und diesmal mehr als Teilnehmer als als helfende Hand, so konnte ich mir knapp die Hälfte aller Vorträge anhören. Für viel mehr hätte ich mich teilen oder durch die Zeit reisen müssen, die Vorträge werden aber ab kommende Woche im Archiv zum anschauen und herunterladen erhältlich sein. Bei meinem ersten Besuch letzten Jahres war ich gerade einen Monat bei NETWAYS und hatte nicht viel Ahnung von Monitoring, Graphing und co, das hat sich aber geändert und ich konnte allen Vorträgen folgen.
Da meine Kollegen schon seit Montag fleißig über die Veranstaltung, Abendveranstaltung und Vorträge bloggen habe ich mir zwei Vorträge herausgesucht die mir besonders gefallen haben und über die ich ausführlicher berichten möchte.

Prometheus: A Next-Generation Monitoring System – Fabian Reinhartz

Prometheus ist ein Monitoring System aus dem Hause Google und soundcloud das ich seit Juni verfolge als ich einen Vortrag dazu auf der letzten GPN gesehen habe. Prometheus unterscheidet sich von Icinga in dem das es metrikbasiertes symptom-based Monitoring betreibt (im Gegensatz zu Icingas zustandsorientierten cause-based Vorgehen), dafür bring es ein paar sehr schöne Features mit sich wie eingebaute Dashboards die mit vorberechneten Daten gefüttert werden können, einem alertmanager der mit sogenannten rules, welche sehr komplex und mächtig werden können, gesteuert werden kann. Das ganze funktioniert sogar ganz ohne Abhängigkeiten, eine Leistung die die Sprache Go ermöglicht.
Nach dem Vortragen der Fakten wechselte Fabian Reinartz in die Konsole und setzte schnelle ein Demo System auf. Falls das jemand ausprobieren will: Es gibt Docker Container

Testing in Production – Devdas Bhagat

Go ahead, deploy to production! It’s just a testing environment anyways.

Mit diesem Zitat fasste Devdas Bhagat am Ende seinen Vortrag zusammen. Hier erwähne ich gleich dass der Referent aus dem E-Commerce Bereich kommt und man diese Philosophie bitte nicht in Sicherheitskritischen Designs einsetzen sollte, etwa Brücken, Raketen oder Kaffeemaschinen.
Mit seinem Vortrag "Testing In Production"
Die Idee dahinter ist anstatt lange herumzuüberlegen und dann Entscheidungen zu treffen einfach alle Alternativen in der realen Welt zu testen und dann anhand von Kunden Reaktionen die erfolgreichste auszuwählen. Dabei greift Devdas eine ungern gehörte Wahrheit auf: Kein System kann perfekt sein, vor allem nicht wenn es mit Menschen in Kontakt kommt. Daher eröffnete er auch das Credo:

Good enough is good enough

Das treibt jeden Perfektionisten die Schweißperlen auf die Stirn, aber Tautologien sind nun mal immer wahr. Leider ging er mir in seinem Vortrag zu wenig auf Details ein: Wie sammle ich die Metriken? Was für Programmierer brauche ich die sich trauen “einfach mal zu machen”? Damit war ich auch nicht der einzige und es gab eine sehr interessante und fröhliche Fragerunde nach dem Vortrag so dass alle ohne Unklarheiten in die Pause gehen konnten.
So bleibt mir noch zu sagen das ich mich auf die OSMC nächstes Jahr schon freue, hoffentlich wieder mit vielen interessanten Vorträgen.

dwm – Der beste Window Manager


Ein Screenshot meiner dwm Umgebung auf der Arbeit. Zu sehen sind die statusbar, das tiling und floating Verhalten und die Workspaces

Der dynamic window manager ist, im Gegensatz zu seinem Windows Namensvetter “Desktop Window Manager”, eine ressourcenschonende, volle tiling Umgebung. Wie bei allen anderen suckless Projekten stehen auch bei dwm die Vermeidung von bloat und die Codequalität im Vordergrund. So bewegt sich der Sourcecode im Bereich eines halben Megabytes während i3 schon mit über zehn daher kommt. Er kommt extrem minimalistisch in seiner Grundform, mit nur ein paar sinnvollen default Einstellungen, aber auch hoch konfigurierbar.
Konfiguration wird direkt im Quellcode vorgenommen was zur folge hat dass das Programm nach jeder Änderung neu kompiliert werden muss. Deshalb ist auch wenig sinnvoll Pakete für dwm zu verwenden, Gentoo feeling auf allen Distributionen also. Und wo wir grade bei Distributionsunabhängigkeit sind: Die beste Quelle für Informationen und Tipps zur Verwendung von dwm ist sein Eintrag in der ArchWiki.

Ein Ausschnitt aus der config.h

Ganz im Geiste der Sache wird in Form von Patches die in die eigene Konfiguration gemerged werden erweitert. Das wohl praktischste, gar notwendige Tool dabei ist dmenu, mit diesem Leichtgewicht
lassen sich bequem jederzeit Programme starten. Auch eine Uhr oder Batterieanzeige sind keine Selbstverständlichkeit und müssen entweder selbst gebaut oder von anderen dwm Nutzern übernommen werden.
Am Ende war es mir den Aufwand jedenfalls wert, wenn ich jetzt noch eine ordentliche Konsolen alternative für pidgin finde muss ich die Maus gar nicht mehr berühren.

Host-only network with virtual CentOS 7 instances

There are a bunch of guides out there on how to create a virtualbox network to work with about every client distribution there is. This is another one, for CentOS 7. All you will need to do this is a text editor and a minimal CentOS 7 installation, no networkmanager, no ifconfig.
If you want your box to be able to connect to the internet you will first need to add a NAT adapter, which is the default so you probably won’t have to do anything.
Now to the hard part:

1. Create a Host-Only network

Create Host-Only network
You can ignore the ipv6 part. But you should use an ipv4 address and network mask that make sense. A /24 should do the job in most cases. Also make sure disable the DHCP Server

2. Add a Host-Only network adapter to your machine

add network

3. Configure the vbox network

The following commands are to be run from the box itself and assume a standard CentOS 7 installation.
First you need to know the name of your Host-Only interface.

# ip a 

The right interface is the one without an ipv4 address, in my case enp0s8.
Now you will need to create an ifcfg for that interface.

# vim /etc/sysconfig/network/scripts/ifcfg-enp0s8 

Now just restart the network service

# systemctl restart network.service 

To check whether everything worked check ip a and try to ping the new ip from the host machine.

Azubis erzählen: Juli 2015 Jean

This entry is part 8 of 13 in the series Azubis erzählen

Name: Jean-Marcel Fach
Ausbildungsberuf: Fachinformatiker für Anwendungsentwicklung
Abteilung: Icinga2 core development
Lehrjahr: 1

Nach einer längeren Berufsschul- und Urlaubsphase kam ich wieder in Firma, dort liefen schon die Vorbereitungen für Icinga 2.4. Nach einem ein-wöchigem Workshop war grob umrissen wie der Arbeitsplan für die nächsten paar Monate aussieht. Als erster Meilenstein gilt der HTTP Server, welcher Anfragen dieses Schemas entgegennimmt und antwortet. Einen Teil der Information machen die URLs auf die der Server angesprochen wird aus, für diese einen Parser zu schreiben wurde meine Aufgabe.
Nun sind *normale* URLs wie “” allen bekannt und jedem der mal genauer hin geschaut hat wird aufgefallen sein, dass sich bei allen Seiten im Internet ein Muster erkennen lässt. Dieses URL-Muster wurde zuerst im RFC 1738 und später im RFC 3986 genauer beschrieben, diese 60 Seiten Dokument lassen sich grob so zusammenfassen: Das Muster einer URL ist immer `Schema:Autorität/Pfad?Anfrage#Fragment`. Nun haben die einzelnen URL-Teile wieder eigene Regeln. Etwa bedeutet ein ‘//’ in der Autorität, dass ein Hostname zu erwarten ist. Oder ein ‘gopher’ als Schema ändert nochmal mehr. Es ergeben sich so eine Reihe von URLs die gültig aussehen, es aber nicht sind und anders herum, aber dazu später mehr.
Im Bezug auf die Implementation, dachte ich zuerst an eine Zustandsmaschine: aus dem vorherigen Zeichen ergibt sich, wie das nächste zu verstehen ist. Leider konnte ich mich mit keiner Implementation in c++ so richtig anfreunden. Ein riesiges switch-case Konstrukt fällt aus da es eben riesig und daher unübersichtlich und hässlich würde. Und die Alternative mit Objekten schien zu dieser Zeit den Rahmen zu sprengen, würde mir aber dieselbe Aufgabe noch einmal gestellt werden, würde ich aber diesen Weg wählen. So fiel die Wahl am Ende, nach all dem Rumprobieren, doch auf eine sequentielle Abarbeitung der fünf Teile. Da die URLs nur http oder https sein werden, konnten viele Probleme umgangen werden.
URL tests
Die tatsächliche Implementation war dann relativ einfach, doch dann kamen die Randfälle. “/” ist gültig und “/??[]=?#?=@” auch, wenn sie auch unsinnig sind. Daher mussten Tests geschrieben werden. Und dann wurde so lange geschraubt, bis alle Tests erfolgreich durchgeführt wurden.
Der Code findet sich wie immer im Icinga 2 git.

Python statt PHP

Gründe gegen die Verwendung von PHP findet man im Internet viele, auch Alternativen werden in regen Mengen angepriesen. Nun musste ich mir eine davon aussuchen wenn ich meine Vorurteile gegenüber PHP nicht bestätigen oder verlieren wollte.
Zum Glück wurde ein Kollege auf mein Dilemma aufmerksam und konnte mich in Richtung Flask weisen und so all meine Probleme lösen, und zwar mit Python. Um Bjarne Stroustrup zu paraphrasieren: “There are only two kinds of languages: the ones people complain about and the ones nobody uses. And then there is Python” Mehr oder weniger. Nun verkauft sich Flask als microframework, als ich das letzte mal davon hörte mussten Banken gerettet werden und der Schrottmarkt brach ein. Laut Flask ist damit natürlich kein Wirtschaftsplan gemeint sondern (Übersetzt von mir):

“Das “micro” in microframework bedeutet Flasks Ziel ist es den Kern einfach aber erweiterbar zu halten”

Soso, sehr schön. Damit ist auch das Anstands-Erwähnen der Philosophie abgehakt und endlich kann Code gezeigt werden.

from flask import Flask
app = Flask(__name__)
def hello():
    return "Hello World!"
if __name__ == "__main__":

Etwas länger als ein `echo “Hello World!\n”;` aber definitiv ein Programm mit einer Main Funktion, return und imports. Fühlt sich eben besser an als diese schwarze Magie die sonst am Werk ist. Leider reicht das nicht um eine schöne Seite zu bauen, daher kommt Flask mit Jinja2, dank dieser Template Engine kann das Design einfach ausgelagert und von der Programm Logik getrennt werden. So ist es möglich die Entwicklung des Backends des Frontends und die des Frontends des Frontends auch bei kleinen Projekten aufzuteilen. Also genau das was ich brauche. Python, ho!