Select Page

NETWAYS Blog

Versteckte Director-Features: Update-Only Sync-Regeln

Heute möchte ich ein neues kleines Feature im Icinga-Director vorstellen: die Möglichkeit, mit Sync-Regeln keine vollständigen Objekte zu verwalten, sondern nur bestimmte Eigenschaften von bestehenden Objekten zu steuern. Das klingt erst mal banal, also wozu das Ganze?

Bereits seit der ersten Director-Version ist es möglich, mehrere Import-Quellen in einer Sync-Regel miteinander zu kombinieren. Allerdings ist das in der Praxis nicht immer ganz so einfach. Spätestens wenn die zweite Quelle nur Zusatzinfos liefern soll, dabei aber mehr Hosts als die erste enthält – dann wird es kompliziert. Viele Import-Quellen lassen sich filtern, da kommt man schon weiter. Und seit einiger Zeit gibt es auch wenn die Quelle das nicht kann die Möglichkeit, via Property-Modifier Zeilen filterbasiert zuzulassen oder abzuweisen.

Der übliche Trick an der Stelle ist dann aber häufig das Anlegen von entsprechenden Datenlisten im Director. Diese befüllt man über dedizierte Sync-Regeln mit Leben und kann sie dann via Map-Modifier am primären Host-Import nutzen. Das funktioniert einwandfrei, ist aber ein wenig umständlich.

Director Sync-Rule - Update-Only

Director Sync-Rule – Update-Only

Beides ist mittlerweile nicht mehr erforderlich. Im aktuellen Master-Branch und in der kommenden Version 1.8 gibt es die Möglichkeit, sogenannte “Update-only” Sync-Regeln anzulegen. Dabei kann man einem beliebigen Objekt-Typ (meist Hosts) eine Reihe von zusätzlichen Eigenschaften aus einer anderen Quelle verpassen, ohne aber zu riskieren dass diese Zweitquelle jetzt ungewollt Hosts hinzufügt oder gar entfernt.

Einfach, aber nützlich. Und das war’s auch schon für heute, wünsche euch ein schönes Wochenende!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Das Runde ist das Fleckige

Pandemie. Es sollte wohl so sein,
Jetzt hab ich Zeit und bin daheim.
Blöd gelaufen, doch was mach ich nun?
Ach, es gibt doch immer was zu tun.

Jetzt ist Icinga hier am Start,
Das ging schnell, war nicht hart.
Die Installation ging flott voran,
Doch der Stress fing dann erst an.

Schließlich will ich alles messen
Und dabei auch nichts vergessen.
Dabei war ich ganz beflissen
Um alles überwacht zu wissen.

Ich hab an diesen freien Tagen
Manchen Sensor neu vergraben,
Den halben Garten neu verrohrt
Und manchen Türstock angebohrt.

Kann Kälte und auch Wärme messen,
Weiß wer den ganzen Strom gefressen.
Bewegungsmelder und 'ne Webcam dran:
So seh ich was der Rasenmäher kann.

Mit Gewichtssensor und ein paar Platten
Muss ich jetzt auch nicht mehr raten
Wieviel von diesem schwarzbraunweißen
Zeug die Tauben täglich runter... schmeißen.

Und so meint' ich alles wär bedacht,
Doch wurd ich überrumpelt über Nacht.
Ungeplant war da ein Change passiert
Frech, unverhofft und ungeniert.

Eine Notification gab es nicht,
Keine Webcam hielt was sie verspricht.
Der ganze Garten voll, in jeder Ecke
Ihr glaubt es kaum was ich entdecke.

Das muss wohl dies' Corona sein
Jetzt zieht es auch bei mir hier ein.
Ich flipp gleich aus, das Zeugs ist rund
Sieht aus Eier - doch in bunt!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Irgendwer muss es halt machen

Ostern ist gerade erst vorbei,
Dann Tag der Arbeit, erster Mai.
Davor, danach brauchst Brückentage:
Zur Erholung, keine Frage.

Die Völlerei der letzten Wochen
Zehrte ziemlich an den Knochen.
Die Magenwand hat überstrapaziert
Wer gefastet hat und nicht trainiert.

Geniert euch nicht, euch sei's gegönnt:
Schaltet ab, sooft ihr's könnt.
Bald ist Pfingsten, Christi Himmelfahrt,
Das Leben das ist ganz schön hart.

Nur einer, der muss ständig laufen,
Darf nicht rasten, niemals saufen.
Wird gern beschimpft, sieht selten Lohn
Schuftet mühsam, schwer und monoton.

Muss ständig in die Runde fragen
Bis wirklich alle Hallo sagen,
Meldet alsdann jeden als gestört
Der sein Rufen nicht erhört.

Wer opfert sich für solche Sachen?
Irgendwer muss es halt machen.
Einsam tut damit hervor
Sich von Icinga 2 der Core.

Die Moral von der Geschichte?
Lasst ihn schuften, zu die Kiste.
Eure Woche ist erst mal zu Ende,
Tschüss Icinga, es ist Wochenende!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Monitoring: alles ist geregelt. Aber!

Es könnte so einfach sein. Auf der einen Seite eine Reihe von Import- und Sync-Definitionen welche aus den unterschiedlichsten Quellen unsere zu überwachenden CI’s importieren. Excel, CMDB, Datenbanken, AWS, JSON, YAML, LDAP, VMware, Active Directory – alles geht. Quellen werden kombiniert, Daten angereichert und wo nötig geradegebogen. Egal wie mies die Daten sind, der Director wird’s schon richten.
Auf der anderen Seite stehen mächtige Apply-Regeln. Diese weisen regelbasiert aus einem liebevoll vorbereiteten Service-Katalog das zu was passt. Ausnahmen von der Regel sind knifflig, nämlich dann wenn wöchentlich jemand wieder einen Schwellwert anders haben möchte. Genau dort wo wir’s nicht bedacht haben, dort wo Konstrukte mit vars am Host schnell hässlich werden.

Auch hier hilft der Director, mit den “Custom Variable Overrides” fühlt es sich so an als würde man wirklich diesem einen Service auf dem einen Host einen anderen Schwellwert verpassen. Alles gut soweit. Die Regeln sitzen, für Schwellwerte sind die Overrides da.

Nun ist unsere Welt aber leider nicht perfekt. Und das ist auch gut so, sonst wäre sie furchtbar langweilig. Für unsere Regeln bedeutet das leider, dass sie im Laufe der Zeit immer umfangreicher und komplizierter werden. Bis wir erneut an dem Punkt angelangen, an dem wir wieder am liebsten alles selbst machen würden. Wir haben nämlich Angst, dass es kaputt wird wenn es ein Kollege anpackt.
Klar, der Director hat ein wunderbares Aktivitätslog, man kann hinterher mit dem Finger auf eben diesen Kollegen zeigen und es heroisch selbst wieder geradebiegen. Ein Klick auf “Restore” hilft dabei. Aber wenn man sich dann allein dadurch besser fühlt, dann hat man charakterlich durchaus noch Möglichkeiten an sich selbst zu arbeiten.
Zudem gab es vorher unnötigen Stress. Über zwei Wochen ist niemandem aufgefallen, dass die Checks für einen wichtigen Job auf ein paar Servern verschwunden sind. Am Wochenende ist das Ding an die Wand gerannt, das Monitoring blieb stumm. Bemerkt hat’s der Kunde, und wir mussten uns mal wieder so doofe Sprüche wie “Ja habt ihr denn kein Monitoring?” anhören. Und alles nur, weil jemand mal wieder eine simple doppelte Verneinung falsch verstanden hat.
Mit dem Director v1.5.0 sind die häufigsten Ausnahmen von der Regel jetzt ein Kinderspiel. Man muss die Apply-Regel gar nicht mehr anfassen, einfach auf besagtem Host die Services anzeigen lassen, einen wählen, Blacklist, fertig:

Im Hintergrund rendert der Director passende Ignore-Regeln und alles ist gut. Man kann wieder einen Task mehr an seine Kollegen delegieren und sich um Wichtigere Dinge kümmern. Also den Raspberry der den Wasserstand der Kaffeemaschine im Auge behält. Was in der v1.5.0 sonst noch alles neu ist steht im Release-Blogpost des Icinga-Blogs.

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Die Extrawurst

Icinga Web 2 bietet eine Reihe von Möglichkeiten, Gruppen-Mitgliedschaften zuzuweisen. Am häufigsten werden Gruppenmitgliedschaften entweder via Web angelegt oder aus einem LDAP-Verzeichnis gezogen. Der bekannteste Vertreter dabei ist Microsofts Active Directory.
Weniger bekannt ist, dass man in eigenen Modulen Benutzer- sowie Gruppenmitgliedschafts-Backends bereitstellen kann. Manchmal braucht man aber gar nicht ein volles Backend, sondern nur ein paar kleine Korrekturen. Aus einem solchen Grund entstand diese Woche in einem Kundenprojekt ein neues Icinga Web 2 Modul: Extragroups.

Zusätzliche Gruppen für jeden

Einmal installiert, lassen sich in der config.ini des Moduls flexible Regeln definieren.
[Jeder ist ein Mimimi]
add_groups = "Mimimi"

Das allein hat erst mal keinen Effekt, also hinterlegen wir in der /etc/icingaweb2/roles.ini eine Rolle, welche unseren Usern eine entsprechende Einschränkung verpasst:
[Mimimi Demo]
groups = "Mimimi"
monitoring/filter/objects = "host_name=*mi*"

Sobald wir uns neu anmelden sind wir Mitglied der Gruppe “Mimimi” und sehen nur noch Hosts welche “mi” enthalten. Dabei ist nebensächlich, ob eine Benutzergruppe namens “Mimimi” existiert oder nicht.

Mustervergleich mit Benutzernamen

Lasst uns das Ganze ein wenig einschränken:
[Alle Heuler sollen Mimimis werden]
user_filter = "username=*heul*"
add_groups = "Mimimi"

Was hier passiert dürfte klar sein, wir machen nur noch unsere Heuler zu Mimimis.

Regeln basierend auf Umgebungsvariablen

Ihr möchtet alle Benutzer mit ein paar Ausnahmen in eine spezielle Gruppe geben, aber nur wenn diese remote arbeiten? Erstellt einfache eine auf deren IP-Range basierende Regel:
[Einschränkung wenn via VPN verbunden]
env_filter = "REMOTE_ADDR=192.0.2.*"
user_filter = "username!=tom&username!=admin"
add_groups = "Via VPN verbunden"

Ähnlich wie REMOTE_ADDR in diesem Beispiel können alle vom Web-Server bereitgestellten Umgebungsvariablen benutzt werden. Im nächsten Beispiel zeigen wir Netzwerk-Admins welche via Nagstamon angemeldet sind lediglich wirklich wichtige Hosts und Services:
[Filter für Nagstamon]
env_filter = "HTTP_USER_AGENT=Nagstamon*"
user_filter = "group=Network Admin"
add_groups = "VIP objects filter"

VORSICHT: Der User-Agent kann einfachst gefälscht werden. Dieses Beispiel dient dem Komfort unserer Benutzer: sie wollen in Nagstamon nicht mit allen Problemen belästigt werden. Für sicherheitskritische Regeln taugt der User-Agent nicht.

Mehrere Gruppen zuweisen

Manchmal will man mehrere Gruppen auf einmal zuweisen, ohne die ganze Regel zu klonen. Das lässt sich einfach bewerkstelligen, denn add_groups akzeptiert eine Komma-getrennte Liste:
[VPN-Benutzer einschränken]
; ..
add_groups = "Eingeschränkte Benutzer, Spezielle Dashboards, Business-Prozesse"

Soll die Gruppenliste noch dynamischer sein? Vorausgesetzt dass ein Webserver-Modul oder dessen Konfiguration diese Information bereitstellt, lässt sich jede Umgebungsvariable via {VARIABLE_NAME} nutzen:
[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"

Auch in Strings die aus Umgebungsvariablen kommen funktioniert das Komma (,) als Trennzeichen. Und man kann natürlich Variablen-Platzhalter mit statischen Werten kombinieren:
[Eine Reihe von Gruppen]
add_groups = "Spezial-Gruppe, {REMOTE_GROUPS}, {HTTP_AUTHZ_GROUPS}"

Auf Gruppenmitgliedschaften basierende Regeln

Der user_filter erlaubt auch Regeln basierend auf bereits zugewiesene Gruppen. In unserem umfangreicheren letzten Beispiel erhalten alle Benutzer zusätzliche Gruppenmitgliedschaften via HTTP_AUTHZ_GROUPS. Na gut, jeder außer der guest und der admin-Benutzer.
Wenn sie Nagstamon nutzen während sie via VPN verbunden sind, sollen sie zusätzlich in die Gruppe Nagstamon Remote kommen.
Wird Nagstamon ohne VPN benutzt, sollen Mitglieder der Gruppen “Linux Benutzer” und/oder “Unix Benutzer” in die Gruppe “Nagstamon Lokal” kommen. Alle außer dem admin:
[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"
user_filter = "user_name!=guest&username!=admin"

[Nagstamon via VPN]
env_filter = "REMOTE_ADDR=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
add_groups = "Nagstamon Remote"

[Nagstamon ohne VPN]
env_filter = "REMOTE_ADDR!=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
user_filter = "username!=admin&(group=Linux Benutzer|group=Unix Benutzer)"
add_groups = "Nagstamon Local"

Dabei gilt es zu beachten, dass der Filter basierend auf die group-Eigenschaft nur Gruppen sieht, welche von vorhergehenden Regeln zugewiesen wurden. Von anderen Backends bereitgestellte Gruppenmitgliedschaften sind nicht zugänglich.
Das war’s auch schon, viel Spaß!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Veranstaltungen

Tue 27

GitLab Training | Online

October 27 @ 09:00 - October 28 @ 17:00
Tue 27

Graylog Training | Online

October 27 @ 09:00 - October 28 @ 17:00
NETWAYS Headquarter | Nürnberg
Nov 04

Vorstellung der Monitoring Lösung Icinga 2

November 4 @ 10:30 - 11:30
NETWAYS Headquarter | Nürnberg
Nov 24

Elastic Stack Training | Online

November 24 @ 09:00 - November 26 @ 17:00
Dec 01

Foreman Training | Nürnberg

December 1 @ 09:00 - December 2 @ 17:00
NETWAYS Headquarter | Nürnberg