Liebes Icinga 2, sag "Aaaaaah"

Die meisten, die schon mal ein Support Ticket aufgemacht haben, kennen das:
“Hallo, ich hab’ ein Problem, weil blah blubb.”
“Hi, das ist schade. Ich hab’ hier ein paar Seiten Doku über Euer Setup. Ist das noch aktuell?”
Und erst dann geht’s los mit der eigentlichen Fehlersuche. Das hat vor allem den Hintergrund, dass viele unserer Kunden sehr unterschiedliche Ansätze haben, wie sie ihr Setup betreuen und mit uns zusammenarbeiten. Manche kontaktieren uns nur im Notfall, andere nehmen nur grössere Umbauten mit uns gemeinsam vor und pflegen alles andere selbst und wieder andere lassen alles von uns machen. Deshalb kommt auch immer erst die Frage, ob sich nicht vielleicht was geändert hat, was natürlich völlig ok ist, nur wissen muss man es für den Support.
Oder man stellt eine Frage im Monitoringportal. Dann kommt da auch gern mal: “Sag erstmal, was für ein Setup Du hast.”
Und genau für diese Fälle gibt’s jetzt (oder eher demnächst) das “Icinga 2 Diagnostics Script”. Das Script soll zwei Anwendungsfälle haben:

  • Einen ersten Überblick über die Eckdaten einer Installation
  • Eine umfassende Datensammlung um alle Feinheiten abzuklopfen

Dabei liegt der Fokus klar auf der ersten Anwendung. Icinga und die damit verbundenen Tools haben eine unglaubliche Flexibilität und können auf so viele unterschiedliche Arten verwendet und konfiguriert werden, dass es oft ziemlich aufwändig sein kann, einen ersten Überblick zu erhalten. Deshalb soll das Script einen nicht gleich mit Unmengen an Information überwältigen, sondern sie sinnvoll und übersichtlich aufbereiten. Dazu probiert es meist verschiedene Befehle durch, die einem Betriebssystem Informationen entlocken können und listet die Ausgabe dann entsprechend aufbereitet auf.
Der andere Modus sammelt so viele Informationen wie er nur kann, inklusive Logfiles, Konfiguration, Datenbankdumps, etc. Weil diese Daten manchmal Informationen enthalten, die man nicht rausgeben darf oder will, ist das nicht der Default Modus.
Egal, welchen Modus man verwendet, das Script sammelt die Daten und legt sie auf dem Host ab, der sie eingesammelt hat. Es gibt also keinen versteckten “Phone-Home” Mechanismus oder eine “praktische” Verschlüsselung, die nur verschlüsselte Daten zurücklässt, sodass der User nicht sieht, was er da verschickt. Auch ein Ändern der Daten ist vor dem Versand natürlich möglich, um z.B. Passwörter zu entfernen.
Ein Wunschtraum für die Zukunft wäre, dass das Script im Überblicksmodus auch auf ungewöhnliche Dinge prüft und nur meldet, wenn es etwas Erwähnenswertes gefunden hat. Also z.B. wenn eine Datenbank nicht dem Schema entspricht, das mitgeliefert wird – entspricht es, gibt’s aber keinen “Ok” Eintrag, um die Übersicht nicht zu beeinträchtigen.
Das Script ist aktuell noch auf dem Stand eines schnellen Hacks, der nach einem Dokumentationstermin bei einem Kunden entstanden ist. Ich habe damals versucht, die relevantesten Eckdaten des Setups zu dokumentieren und mir notiert, welche Befehle ich benutzt habe. Das wurde noch etwas erweitert (Danke Dirk, für die vielen guten Ideen) und einige davon in ein Script gegossen. Wie wahrscheinlich die meisten, die selber Projekte laufen haben, bin ich noch höchst unzufrieden mit dem Funktionsumfang, dem Errorhandling, dem Scripting-Stil, usw. Da ich aber nicht wieder ewig warten will, bis ich doch mal Zeit finde, daran weiter zu schrauben, folge ich der Empfehlung meiner Kollegen und mache ein offizielles Icinga-Projekt daraus. Das motiviert mich erstens sicherlich dazu, eher weiter zu arbeiten und andererseits, wird so wohl eher auch mal jemand den ein oder anderen Pull-Request schicken. Bitte habt aber Verständnis dafür, dass der Fokus darauf bleibt, den Output übersichtlich zu halten.
Inzwischen befindet sich das Script schon in einem GitHub Repo im Icinga Bereich. Wer es testen möchte, Ideen dafür hat oder auch mitarbeiten möchte, findet dort alles Nötige.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Clustershell und Foreman-API

i-love-apisForeman bietet die Möglichkeit verschiedene Informationen über die Hosts einzusehen. Dazu gehören der Status, das Betriebssystem, Ressourcen etc. Möchte man nun, auf mehreren Hosts gleichzeitig ein Kommando absetzen, kann man sich auf jedem einzelnen einloggen oder eine Clustershell aufbauen.
Hierfür gibt es verschiedene Tools die dies erlauben. Eine Unbequemlichkeit die hier jedoch schnell aufkommt, ist das kopieren und einfügen der Hostnamen in die Commandline. Aus diesem Grund, habe ich etwas Zeit investiert und ein Ruby Script geschrieben, das es mir ermöglicht, mit festgelegten Filtern nach speziellen Listen von Hostnamen zu suchen und diese als eine einzige Ausgabe zu speichern. Ich habe für das erzeugen von Clustershells “csshX” im Einsatz, welches ich auch direkt mit eingebunden habe.
Das get_hosts Script gibt es als GIST.
In diesem Script wird zunächst eine “config.yml” geladen, in der die Foreman-URL und der Nutzername definiert sind. Eine Passwortabfrage erfolgt in diesem Script direkt auf der Commandline. Anschließend wird die Ausgabe der Foreman-API nach dem Auflisten aller Hostinformationen in JSON geparst und alle verfügbaren Parameter für die Hosts in das entsprechende Array gespeichert. Mit dem Parameter “-s / –server” gibt man einen String an, nachdem speziell gesucht werden soll. Diese Ausgabe wird zusätzlich mit angehängt.
Gefiltert wird nach:
1) Reports enabled
2) OS Ubuntu 14.04 / Debian 8
3) Kein Match auf net-* oder netways.de (Als Beispiel)
Von den selektierten Hosts werden die Hostnamen in einer Commandline-Ausgabe mit einem Leerzeichen getrennt ausgegeben. Verschiedene werden sich eventuell fragen: “Wofür brauche ich das? Wieso sollte ich so ein Script verwenden?”
Die Antwort ist einfach: Bequemlichkeit und live Übersicht, was gerade passiert. Die Suchparameter lassen sich sehr leicht anpassen und die Ausgabe des Scriptes wird etwas an Zeit der administrativen Aufgaben sparen, vorallem dann, wenn man mehr als nur 2 oder 3 Server mit Puppet bespielen lassen möchte.
user@computer ~/Documents/ruby/foreman $ ruby script.rb
Enter password:
[ ] Trying to establish a connection...
[OK] Password correct
[OK] Connection established
[ ] Collecting data...
[OK] Data collected
[RESULTS]
Ubuntu
csshX --login root test1.test.de test2.test.de test34.test.de test19.test.de mail.test.de icinga-001.test.de
Debian
csshX --login root icinga-002.test.de db-003.test.de db-021.test.de
Finished succesfully

Wie bereits erwähnt, ist hierfür noch eine “config.yml” Datei nötig, die gewünschte Parameter enthält. In diesem Fall die URL und den usernamen. Aber auch ein Gemfile, das sich in Ruby um bestimmte Versionen von Gems kümmert. (Mit einem “bundle install” können diese installiert werden)
Die config.yml und das Gemfile gibt es ebenfalls als GIST.
Eingebaute “rescue Execptions” im Script selbst, geben entsprechende Rückmeldung, sollte der Login oder eine der auszuführenden Verarbeitungsschritte fehlschlagen und brechen den Vorgang an dieser Stelle ab.

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Braintower SMS Gateway – Icinga Plugin verfügbar!

icinga_logo_200x69Trotz Weihnachten und dem bevorstehenden Jahreswechsel sind wir natürlich nicht untätig und stehts dabei unser Portfolio an Plugins weiter auszubauen. Heute möchte ich die Gelegenheit nutzen, um zum Jahresende ein nützliches Plugin für die Überwachung unserer Braintower Geräte mit Icinga vorzustellen.
Das kleine Python-Plugin bedient sich dabei der Statusseite des Gateways und liefert unter anderem Informationen über die Failed-Queue, die Signalstärke sowie die Uptime.
Will man das Gateways überwachen, ruft man das Plugin einfach mit folgenden Parametern auf:

./check_braintower -H 192.168.1.1 --signal-warning -85 --signal-critical -90

Die Werte der Parameter muss natürlich jeder auf seine Bedürfnisse anpassen 🙂
Als Ergebnis erhält man dann beispielsweise folgende Ausgabe:

BRAINTOWER OK - que: 0 failed: 0 signal: -83db total: 0 state: Idle load: 0;0.03;0.05 time: 1451320254 disk free: 647569408 uptime: 9 min, 0 users

Selbstverständlich kann man nicht nur die Signalstärke überwachen, sondern eine Vielzahl von Parametern. Mit –help erhält man hier eine schöne Erklärung über die Möglichkeiten:

usage: check_braintower [-h] -H HOSTNAME [-T TIMEOUT] [-Q QUEUE] [-F FAIL] [--signal-warning SIGNAL_WARNING] [--signal-critical SIGNAL_CRITICAL]

optional arguments:

-h, –help show this help message and exit
-H HOSTNAME, –hostname HOSTNAME The host address of the SMS Gateway
-T TIMEOUT, –timeout TIMEOUT Seconds before connection times out (default 10)
-Q QUEUE, –queue QUEUE The warning threshold for the amount of queued SMS (default 1)
-F FAIL, –fail FAIL The critical threshold for failed SMS (default 1)
–signal-warning SIGNAL_WARNING The warning threshold for the minimum signal strength (in db, default 0)
–signal-critical SIGNAL_CRITICAL The critical threshold for the minimum signal strength (in db, default 0)

 
Wer das Plugin ausprobieren möchte, kann dies natürlich gerne tun – wir freuen uns über Feedback! Verfügbar ist es auf Icinga Exchange und in unserem NETWAYS Git.

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Azubis erzählen: März 2015 Jean

This entry is part 4 of 12 in the series Azubis erzählen

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

Hallo,
ich schreibe hier als Azubi im Development einen Blogppost zur Serie “Azubis erzählen”. Dieser ist nach diesem Absatz auch zu lesen, aber zunächst werde ich vorstellen.
Ich bin 21 Jahre alt und arbeite seit einem halben Jahr bei Netways. Vorher war ich Student an der Erlanger Universität. Meine Aufgaben haben fast immer mit Icinga 2 zu tun, hin und wieder müssen auch sonstige Aufgaben erledigt werden, mal mehr programmiertechnischer Natur und mal weniger.
Eine dieser Aufgaben war das Script, das das Vorkommen eines Datums in einer Tabelle zählen sollte, doch bevor ich mich damit beschäftigen konnte musste ich erst einmal dafür sorgen das die richtige Datei geöffnet wird. Die Dateinamen sind etwa so kodiert:
NAME_DATUM_UHRZEIT_NUMMER.ENDUNG

rx

Die Matrix war ein Perl Programm. Deswegen machen die Nachfolger auch so wenig Sinn


Wichtig sind dabei eigentlich nur Datum und Uhrzeit, doch wie unterscheidet man diese von den übrigen Teilen des Dateinamens?
Unterstriche zählen fiel als Erstes weg, da der NAME meist selbst noch Unterstriche enthielt. Also muss rückwärts gesucht werden. die Endung erkennt man daran, dass ein Punkt vor ihr steht… leider kann so eine Datei auch mehrere Endungen haben, etwa .txt.gz für komprimierte Dateien. Und wenn der NAME dann selbst einen Punkt enthalten kann…
Also musste eine andere Lösung her: regex
Die regular expression
Lange war ich etwas eingeschüchtert von regex, oft sah ich nur Monster wie dieses hier (Soll Email Adressen validieren, und ist dabei nicht einmal 100% korrekt, wenn man es genau nimmt) und wer will schon mit so einer Wand Text arbeiten müssen?
Also Augen zu und durch, anhand dieses Tutorials brachte ich mir also die regex Grundlagen bei, denn zum Lernen ist hier immer Zeit. Gar nicht mal so schwer, zum Glück gibt es dann noch diese Seite auf der man nach Herzenslust ausprobieren kann.
Nun aber zu meinem konkreten Problem:
deq_2214_20140415_140857_0413.txt.gz
Nach dem Muster oben ist klar, dass es sich um eine verpackte Textdatei, die 413te am 15.4.2014 aus der Serie ‘deq_2214’, gespeichert um 14:08:57, handelt. Aber selbst wenn man das Muster nicht schon vorher kennt ist es leicht es zu erkennen, für einen Menschen. Für einen Computer eben nicht (Daher sind Computer Menschen in Go noch unterlegen, während sie im Schach unschlagbar sind).
Aber ein dummer Computer kann gut stur Schemata überprüfen:
(\w+)_(\d{8})_(\d{6})_(\d{4})(\.txt)(\.gz)?$
Ist die Lösung, Erklärung:

(\w+)    # Fasse den Anfang zu einer Gruppe zusammen ("deq_2214")
  _      # Unterstriche dienen als Abtrennung und werden übergangen
(\d{8})  # Eine Gruppe aus genau acht Zahlen, das Datum ("20140415")
  _
(\d{6})  # Eine Gruppe aus genau sechs Zahlen, die Uhrzeit ("140857")
  _
(\d{4})  # Eine Gruppe aus genau vier Zahlen, die Nummer ("0413")
(\.txt)  # Die Endung ".txt"
(\.gz)?  # Die optionale Zusatzendung ".gz"
  $      # Sorgt dafür das nach der Endung nichts mehr kommen kann
         # (".txt.gz.temp" ist ungültig)

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!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Hollywood auf der Bash

In diesem Blogpost möchte ich euch zeigen wie Ihr relativ einfach und ohne großen Aufwand auf der Shell eigene Kassenschlager à la Hollywood produzieren könnt. Dafür benötigte Tools stehen auf den gängigen Linux-Distributionen bereits über die Standard Utilities (util-linux bzw. util-linux-ng) zur Verfügung.
Den Großteil der Zeit eines Filmregisseurs beansprucht natürlich die aufwändige und oft kräftezehrende Produktion der einzelnen Filmszenen, wir benutzen hierzu unsere virtuelle Kamera namens script.
Script steht eigentlich für Typescript und lässt sich z.B. mit “maschinengeschriebenes Schriftstück” übersetzen. Genau das produzieren wir jetzt! Script möchte von uns dazu lediglich den Namen der Zieldatei haben, also:

# script recordfile
Script wurde gestartet, die Datei ist recordfile

oder alternativ:

# script -f recordfile
Script wurde gestartet, die Datei ist recordfile

Nun kann die wilde Bash-Show starten und wenn wirklich keine neuen Ideen mehr nachkommen lässt sich die Aufnahme mit [Strg] + [d] beenden, es erscheint folgende Ausgabe:

# exit
Script wurde beendet, die Datei ist recordfile

Die Wiedergabe der Datei recordfile kann nun beispielsweise mit dem altbekannten cat erfolgen. Da uns diese Methode vermutlich nicht allzu viele begeisterte Zuseher einbringen wird, erweitern wir die Aufnahme um einen sog. Timingaufruf, das könnte so aussehen:

# script -t 2> time.file record.file

Natürlich muss auch hier die “virtuelle Kamera” am Ende wieder mit  [Strg] + [d] beendet werden. Bei der Wiedergabe unterstützt uns nun scriptreplay, das die Sequenzen deutlich massentauglicher darstellt:

# scriptreplay time.file record.file

Zugegeben – unsere Zuschauerzahlen werden sich wohl noch nicht (gleich) mit denen der großen Hollywood-Blockbuster vergleichen lassen, aber was nicht ist kann ja noch werden. In diesem Sinne: Klappe… und Action!

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

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 Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.