Seite wählen

NETWAYS Blog

Benachrichtigung mal einfach

Neulich beim Kunden, sollte folgendes Szenario zur Benachrichtigung umgesetzt werden. Der Weg, also ob Mail, Slack oder Telegram, soll vom Benutzer abhängig sein, je nach dessen Vorliebe. Ist beim Benutzer eine Mailadresse gesetzt, wird er auch per Mail informiert. Soll die Benachrichtigung hingegen via Telegram bzw. Slack erfolgen, muss der notwendige Empfangs-Hook über ein User-Custom-Attribute angegeben werden.

Wer zu benachrichtigen ist, wird am Host-Objekt angegeben. Die zu benachrichtigen Benutzer können hierbei in einer Liste (host.vars.notification.user) oder über die Mitgliedschaft in einer Gruppe, die ebenfalls am Host in einer Liste (host.vars.notification.groups) angegeben werden, zu gewiesen.

Sei ein Benutzer admin Mitglied der Gruppen icingaadmins und linuxadmins. Soll bei folgendem Host

object Host "localhost" {
  import "generic-host"

  address = "127.0.0.1"

  vars.notifiction = {
    groups = [ "icingaadmins", "linuxadmins", "vips" ]
  }
}

für den Benutzer admin, aber keine doppelten Nachrichten versandt werden, kann dies zunächst mit dieser Regel umgesetzt werden:

apply Notification "mail-admin to Host {
  import "mail-host-notification"
  users = [ "admin" ]

  assign where "admin" in host.vars.notification.users || f("admin", host.vars.notification.groups)
}

Über den ersten Teil der assign-Regel wäre das Vorhandensein von admin in der Liste der zu benachrichtigen Benutzer am Host abgehandelt. Der zweite Teil ist eine selbstdefinierte Funktion die ein true zurück liefert, sofern der Benutzer mindestens einer der Gruppen aus der Liste angehört.

function f(user,groups) {
  if (typeof(groups) == Array) {
    for (grp in groups) {
      if (grp in get_user(user).groups) {
        return true
      }
    }
  }
  return false
}

Nun möchte man nicht für jeden Benutzer am Icinga-System eine solche Notification definieren, zumal die Services noch nicht berücksichtigt sind, dann wären deren für jeden Benutzer, immer gleich zwei Notification-Definitionen. Notifications werden vom Config-Compiler immer nach den User- und Usergroup-Objekten ausgewertet, somit kann die Notification zu ein Notification-for, die eine Schleife über alle bekannten Benutzer führt, umgewandelt bzw. erweitert werden:

apply Notification for (user in get_objects(User)) to Host {
  import "mail-host-notification"
  users = [ user.name ]

  assign where user.name in host.vars.notification.users || f(user.name, host.vars.notification.groups)
  ignore where ! get_user(user.name).email
}

Die abschließende ignore-Klausel stellt sich, dass keine Notification für Benutzer erzeugt wird, die keine Mailadresse angegeben haben. Sollen nun die selben Benutzer, nicht nur für den Host, sondern auch über Probleme bei den zum Host gehörigen Services benachrichtigt werden, ist das ganze nur noch eine Fingerübung:

apply Notification for (user in get_objects(User)) to Service {
  import "mail-service-notification"
  users = [ user.name ]

  assign where user.name in host.vars.notification.users || f(user.name, host.vars.notification.groups)
  ignore where ! get_user(user.name).email
}

Äquivalente Notifications lassen sich damit auch für die alternativen Benachrichtigungswege Slack, Telegram und weitere erstellen.

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.

Was ist Consul und wozu dient es?

Eine Beschreibung in einem Wort ist hier Service Mesh. Was jemanden, der sich zuerst mit Consul beschäftigt, ebenfalls nicht wirklich weiterhilft. Dieser Blogpost zeigt die Features von Consul auf und gibt Hinweise zu deren Anwendung.

Consul verwaltet Services und Knoten in der Art eines „Verzeichnisdienstes“, also in der Form was läuft wo? Zugegriffen wird dabei über DNS oder alternativ mittels HTTP(s). Consul wird entweder im Modus Server oder Agent betrieben. Die Server speichern die Daten, kommen mehrere zum Einsatz werden die Daten automatisch synchronisiert.

Auf die Daten kann man direkt auf den Servern mittels DNS oder HTTP(s) zugreifen oder über den eh benötigten Agenten. Über den Agenten meldet sich jeder beliebige Knoten bzw. Host in Consul an und wird als Node registriert. Ebenfalls können dann auch Services registriert werden. Ein Webserver z.B. registriert sich so zum Beispiel als neues Cluster-Mitglied zu einem bereits bestehenden Services. Zusätzlich können auch Tags gesetzt werden, die sich via DNS-Abfrage dann als Aliases darstellen.

Nur was macht man nun mit diesen Informationen? Einfach wäre es nun seinen eigentlichen DNS auf diese Informationen weiterzuleiten. Dies geht wie oben schon angedeutet mit Anfragen entweder direkt an die Server oder über einen auf den DNS-Servern betriebenen Agenten. Damit ist leicht ein DNS-Round-Robin zu realisieren.

Möchte man hingegen einen Load-Balancer als Proxy für seinen Dienst betreiben, kommt Consul-Templates als eigenständiges Produkt ins Spiel. Es handelt sich hierbei um eine Template-Engine, die die Informationen aus Consul in Konfigurationsdateien überführt. Die Konfiguration kann dabei noch um zusätzliche Konfigurationsparamter, aus dem in Consul integrierten Key-Value-Store, angereichert werden.

Abschließend bietet Consul als weiteres Feature die Verwaltung einer Certificate Authority (CA). Die ausgestellten Zertifikate können sogleich mit Hilfe des Agents via Proxy (sidecar proxy) zur Absicherung der betriebenen Dienste mittels TLS eingesetzt werden. Das geschieht völlig transparent und Konfigurationsdateien müssen nicht angepasst werden.

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.

Graphite-API für Grafana und Icinga Web 2

Ziel dieses Posts ist es, am Ende die Metriken über die Graphite-API als Backend für Grafana und das Icinga-Web-2-Module graphite betreiben zu können.

Grafana übernimmt hierbei optional die Visualisierung über eigene Dashboards, was ansonsten Graphite-Web leistet. Für Icinga Web 2 ist Grafana nur erforderlich, falls nicht das Module graphite zum Einsatz kommen soll, sondern stattdessen grafana zur Darstellung im Icinga Web 2 verwendet werden sollte.

Die Graphite-API ist in Python implementiert und soll hierbei via HTTPS angesprochen werden. Zusätzlich ist der Zugriff via Basis-Authentifizierung zu beschränken. Dies alles überlassen wir dem Apache, auch die API lassen wir mittels WSGI im Apache laufen.

Der Vorteil gegenüber dem Graphite-Web liegt darin, die ganzen Django-Bibliotheken nicht zu benötigen und auch kein DB-Backend a la SQLite, MySQL oder PostgreSQL. Nachteil ist, das Projekt Graphite-API wird nicht vom Graphite-Team betrieben, somit ist die Pflege und Aktualität nicht sichergestellt.
mehr lesen…

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.

Selbstsignierte Zertifikate oder semantische Korinthen in der IT


Heute ergreife ich mal die Chance etwas Definitionsreiterei zu betreiben, da ich im Umfeld feststellte, dass nicht klar ist, was ein selbstsigniertes Zertifikat ist und was sprachlich gesehen überhaupt ein Zertifikat ist.

Ein Zertifikat ist der beglaubigte öffentliche Schlüssel passend zu einem privaten. Man generiert also zuerst ein Schlüsselpaar, zu diesem Zeitpunkt darf man nun eigentlich für den öffentlichen Schlüssel nicht von Zertifikat sprechen, da es nicht signiert ist. Zunächst wird dann eine Zertifikatsanfrage (certificates request) erzeugt und an eine Zertifizierungsstelle (CA) gesendet. Zurück bekommt man ein Zertifikat, den eigenen nun beglaubigten öffentlichen Schlüssel.

An einem selbstsignierten Zertifikat (self sign certificate) ist keine CA beteiligt, auch keine eigene, nicht öffentliche. Es handelt sich auch hierbei um den öffentlichen, der jedoch durch den eigenen zugehörigen privaten signiert wird. Logischerweise sollen diese Zertifikate nur für den internen Testgebrauch verwendet werden, da ja keine dritte Instanz die Gültigkeit garantiert.

Ein solches selbstsigniertes Zertifikat ist schnell gebaut:

$ openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem

Demnach muss nun die Validierung gegen sich selbst wie folgt aussehen:

$ openssl verify -verbose -x509_strict -CAfile certificate.pem certificate.pem
certificate.pem: OK

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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 14: Profile Part VI

This entry is part 14 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Nachdem letzte Woche der Nginx verwendet wurde, wenden wir uns im nun vorerst letzten Teil der Konfiguration des Apaches als Webserver zur Auslieferung von Icinga Web 2 zu.
Der Apache kommt unter Debian als abhängig zu installierendes Paket von icingaweb2 mit und wird ensprechend konfiguriert. Damit dies unsere Anforderung an den Apache nicht wieder überschreibt, sorgen wir dafür, dass das Paket icingaweb2 vor der Klasse apache installiert wird. Hierfür müssen wir das Managment des Pakets durch die Klasse icingaweb2 unterbinden.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse apache aus dessen Modul.

 

[ruby]
if $web_server == ’nginx‘ {
[…]
} else {
#
# Apache
#
$manage_package = false
Package[‚icingaweb2‘]
-> Class[‚apache‘]
package { ‚icingaweb2‘:
ensure => installed,
}
class { ‚::apache‘:
default_mods => false,
default_vhost =>false,
mpm_module => ‚worker‘,
}
apache::listen { ’80‘: }
$web_conf_user = $::apache::user
include ::apache::mod::alias
include ::apache::mod::status
include ::apache::mod::dir
include ::apache::mod::env
include ::apache::mod::rewrite
include ::apache::mod::proxy
include ::apache::mod::proxy_fcgi
apache::custom_config { ‚icingaweb2‘:
ensure => present,
source => ‚puppet:///modules/icingaweb2/examples/apache2/for-mod_proxy_fcgi.conf‘,
verify_config => false,
priority => false,
}
}
[…]
[/ruby]

Der Apache wird von uns komplett mit allen Modulen für Icinga Web 2 verwaltet, da sich die Defaults für RedHat und Debian zu sehr unterscheiden. Auch hier, wie bei Nginx, entfernen wird alle Konfiguration sonstiger auszuliefernder Webseiten und benutzen die vom Icinga-Web-2-Modul zur Verfügung gestellt Beispielkonfiguration.

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.