Icinga2 GitLab Health Check

GitLab
Neulich hatten wir bei einigen GitLab Updates auf die neueste Version das Problem, dass die Dienste nach dem Update zwar korrekt alle wieder gestartet wurden und daher unser alter Monitoring Check “Service: gitlab” den Status “Gitlab OK: All services are running!” zurückgeliefert hat, auch der Check “Service: http git.netways.de” “HTTP OK: HTTP/1.1 200 OK” geliefert hat, und daher hat ohne manuelle Prüfung niemand vermutet, dass im Hintergrund doch etwas schief gelaufen war (z.B. die Datenbank Migration während einem Update, oder ein vergessenes skip-XXX File im /etc/gitlab Verzeichnis).
Auch wenn man das Update direkt auf der command line ausgeführt hat, konnte man in der abschliessenden Meldung nicht sehen, ob noch alles o.k. ist.
Festgestellt hat man das dann erst, wenn man sich in der GitLab Admin Area unter “Health Check” den Status angesehen hat.
Unten ein Beispiel wie es aussieht, wenn alles i.O. ist (Zur Info: Die Beispiel URL und Token gibt es nicht):
GitLab Status
D.h. ein neuer Check musste her, und den gibt es auch direkt bei GitLab zum Downloaden unter:
https://gitlab.com/6uellerBpanda/check_gitlab/blob/master/check_gitlab.rb
Der alte Check lief dabei direkt auf den einzelnen GitLab Hosts. Das war mit dem neuen Check allerdings ein Problem, weil er als Voraussetzung Ruby >2.3 hat, und wir z.B. noch einige Hosts unter Ubuntu Trusty betreiben.
Deshalb wird der neue Check direkt auf dem Monitoring Server (auch Ubuntu Trusty) ausgeführt, der zu diesem Zweck zusätzlich per rvm mit einem z.Zt. neuen Ruby 2.5.1 ausgestattet wurde, wobei im Ruby Skript das Shebang leider hardcoded eingetragen werden musste, weil es (zumindest unter Trusty) nicht anders funktioniert hatte (ohne grösseren Aufwand und vielen Änderungen an anderen Systemdateien):

#!/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby

Nachdem die Token zum Zugriff im Bild oben seit einigen GitLab Versionen deprecated sind zugunsten einer IP Whitelist, hat das den Deploy des Checks zusätzlich erleichtert.
Der Aufruf des Checks sieht dann z.B. so aus:

root@icinga2-server:~# check_gitlab.rb -m health -s https://gitlab.netways.de -k
OK - Gitlab probes are in healthy state

Damit das dann auch funktioniert, muss auf der entfernten GitLab Instanz noch die IP Whitelist unter /etc/gitlab/gitlab.rb eingetragen werden:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.1/8','10.XX.XX.XX/24']

Am besten checkt man natürlich nur über ein internes Netz, wie oben im Beispiel angegeben.
Das ganze kann man auch über ein GitLab Puppet Modul realisieren, indem man die Whitelist über Hiera oder Foreman verteilt:
Beispiel Hierarchie im Foreman:

gitlab:
    gitlab_rails:
      monitoring_whitelist:
      - 127.0.0.1/8
      - 10.XX.XX.XX/24
Stefan Gundel
Stefan Gundel
Senior Systems Engineer

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Noob vs. Icinga 2

Nachdem unser Michael Friedrich letzte Woche einen Blog-Post zum 9. Icinga Geburtstag auf icinga.com veröffentlicht hat, fängt man schon mal an, über die eigenen ersten Schritte mit dem Icinga 2 Stack nachzudenken. Vor allem, wenn man auf einem Live-System mal wieder über etwas aus der Anfangszeit stolpert.
 

Eines meiner ersten Aha!-Erlebnisse war recht klein, jedoch wurde mir dann versichert, dass da auch gestandene User bzw. Admins darüberstolpern. Kern der Frage war damals: “Warum geht dieser *biep* http-check nicht?!” Als Symptom zeigte sich, dass unserem Check der Zugriff verweigert wurde – und das, obwohl doch alle Permissions korrekt gesetzt waren. Da grübelt und googlet der Junior System Engineer erstmal eine Zeit lang. Um das Verfahren hier abzukürzen – es gibt folgende Möglichkeiten, das Problem anzugehen:
Der Grund liegt darin, dass der Check durch den Parameter –expect einen String mit dem Returnwert 200 als Default erwartet. Von daher kann man

  • als Quick’n’Dirty Lösung ganz einfach eine leere Datei mit dem Namen index.html im entsprechenden Verzeichnis angelegt werden
  • den String nach –expect auf einen sicher zu erwartenden Wert setzen, z. B. 302.
  • mit –url einen Pfad angeben, der geprüft werden soll, z. B. /start/menu

Auch schön war der Punkt, an dem man verstanden hat, was es mit dem Parameter command_endpoint auf sich hat – und man plötzlich merkt, dass unterschiedliche Festplatten z. B. auch unterschiedliche Füllstände aufweisen. Genauso faszinierend ist es natürlich auch, dass man durch Apply Rules viele Services weitläufig ausrollen oder umgekehrt auch einschränken kann.
Um nun abschließend einen unserer NETWAYS Consultants zu zitieren: “Das Kommando icinga2 daemon -C sollte man jedem neuen User irgendwohin tätowieren!”
Als Fazit aus den letzten zwei Jahren mit Icinga 2 kann ich ziehen, dass einem der Einstieg recht gut und schnell gelingt – egal, ob es sich um das Aufsetzen, die Wartung oder die täglich Nutzung handelt. Wer sich vor allem von letzterem gerne selbst überzeugen möchte, kann bei den NETWAYS Web Services in unserem kostenfreien Testmonat sowohl einen Icinga 2 Master als auch Satellite starten. Wer sich gerne tiefer in die Materie einarbeiten möchte, kann sich auf icinga.com schlau machen. Dort ist nicht nur die offizielle Dokumentation zu finden, sondern auch Termine zu Trainings und Events. Sehr zu empfehlen ist auch die überarbeitete Auflage des Buches Icinga 2: Ein praktischer Einstieg ins Monitoring von Lennart Betz und Thomas Widhalm.
Bildquelle: https://memegenerator.net/instance/40760148/jackie-chan-dafuq-is-wrong-with-ur-icinga-checks

Nicole Lang
Nicole Lang
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Auf der Suche nach Rootkits

Gut, das man auf Unix-Betriebssystemen keinen Virenscanner benötigt ist Interpretationssache und natürlich stark vom jeweiligen Einsatzzweck des Systems abhängig. Bei Fileservern für Windows-Systeme macht dieser nämlich durchaus wieder Sinn. Was man jedoch auf allen, zumindest öffentlich erreichbaren, Servern haben sollte ist eine Routine zur Suche nach tiefer gehenden Kompromittierungen. Hier bietet sich der Rootkit Hunter an, welcher nach Rootkits, Backdoors und lokalen Exploits sucht.
Im Normalfall steht Rootkit Hunter bereits als fertiges Paket zur Verfügung und kann über das distributionseigene Paketmanagement als rkhunter schnell installiert werden. Im Anschluss an die Installation sollte man sicherstellen das der Rootkit Hunter auch über die aktuellen Schädlingsdefinitionen vergügt, das geschieht über folgenden Aufruf:

~# rkhunter --update
[ Rootkit Hunter version 1.4.0 ]
Checking rkhunter data files...
  Checking file mirrors.dat                                  [ No update ]
  Checking file programs_bad.dat                             [ No update ]
  Checking file backdoorports.dat                            [ No update ]
  Checking file suspscan.dat                                 [ No update ]
  Checking file i18n/cn                                      [ No update ]
  Checking file i18n/de                                      [ No update ]
  Checking file i18n/en                                      [ No update ]
  Checking file i18n/zh                                      [ No update ]
  Checking file i18n/zh.utf8                                 [ No update ]

Mit dem Parameter “propupd” speichert Rootkit Hunter den aktuellen Zustand des Systems als Referenz und gleicht diesen Stand bei zukünftigen Durchläufen ab. Daher sollte man sicherstellen das RKHunter nur auf einem bisher unkompromittierten System in Betrieb genommen wird. Am Besten ist es also den Rootkit Hunter direkt im Anschluss an eine Betriebssystemneuinstallation zu installieren.

~# rkhunter --propupd
[ Rootkit Hunter version 1.4.0 ]
File updated: searched for 169 files, found 138

Damit Rootkit Hunter keine unnötigen Warnungmeldungen generiert, empfiehlt es sich diesen Aufruf auch nach gravierenden Änderungen am Betriebssystem (u.a. auch bei Kernel-Updates, etc.) durchzuführen.
In der zentralen Konfigurationsdatei “/etc/rkhunter.conf” sollte unter “OS_VERSION_FILE” sichergestellt werden das RKHunter das verwendete Betriebssystem identifizieren kann. Außerdem kann ggf. die Mailadresse für Benachrichtigungen bei “MAIL-ON-WARNING” angepasst werden. Danach steht einem ersten Systemcheck nichts mehr im Wege:

~# rkhunter --check
[ Rootkit Hunter version 1.4.0 ]
Checking system commands...
...
Checking for rootkits...
...
Checking the network...
...
Checking the local host...
...
System checks summary
=====================
File properties checks...
    Files checked: 138
    Suspect files: 2
Rootkit checks...
    Rootkits checked : 303
    Possible rootkits: 0
Applications checks...
    All checks skipped
The system checks took: 9 minutes and 18 seconds
All results have been written to the log file (/var/log/rkhunter.log)
One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)

Warnungen protokolliert RKHunter ausführlich nach “/var/log/rkhunter.log” und gibt am Ende des Durchlaufs eine Kurzzusammenfassung aus. Je nachdem welche Warnungen beim Durchlauf auftreten erfordert dies ggf. entsprechende Konfigurationsanpassungen in “/etc/rkhunter.conf”. Danach ist es angebracht einen erneuten Checkdurchgang zu starten bis keine Warnungen mehr auftreten.
Ist ein konsistenter Zustand des System erreicht sollte Rootkit Hunter selbstverständlich in regelmäßigen Abständen ausgeführt werden. Dafür kann der folgende Befehl als Cron-Aufruf hinterlegt werden:

~# rkhunter --crontab

Mit “chrootkit” steht auch eine Alternative zum Rootkit Hunter bereit. In diesem Sinne kann ich Ihnen nur noch wünschen das diese Tools bei ihrer Arbeit keine unerwünschten Eindringlinge entdecken!

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.

Warnschwellen für check_load festlegen

In der Praxis ist es gar nicht so einfach festzulegen, wann ein Server wirklich überlastet ist und wie man das mittels Nagios oder anderer Monitoring Tools messen kann. Auf einem Linux Server ist eines der Kriterien dafür die Load. Und alleine über diesen einen Performance Wert, was normale Werte sind und ab wann der Server zu viel Load hat, gibt es wahrscheinlich Hunderte von Meinungen.
Wichtig ist auf jeden Fall, dass die Load zu der Anzahl der CPUs und der Cores passen muss, denn eine Load von 2 auf einer Dual CPU Dual Core Maschine, bedeutet gerade mal, dass die CPUs zur Hälfte ausgelastet sind. Und dann ist ja auch noch wichtig in welcher Zeiteinheit. Eine Load von 2 in der letzten Minute ist weniger schlimm, als 1,5 in den letzten 15 Minuten. Aus diesen Gründen kann es nicht schaden, sich ein paar Minuten mit den Warnschwellen seiner check_load Service Checks zu befassen. Hier wird das ganze in einem Blogpost nochmal etwas genauer erklärt.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.