Select Page

NETWAYS Blog

User aus LDAP in Icinga Director Importieren

Ich hatte das Vergnügen mich etwas mit dem Icinga Director zu beschäftigen dabei war eine der Aufgabenstellungen die User aus unserem LDAP in den Director zu Importieren. Im Folgenden werde ich erläutern, welche Schritte notwendig sind, um dies zu tun. Dabei ist zu beachten, dass jede LDAP-Umgebung anders aussieht und diese nicht ganz genau für jede passen.

Zuerst legen wir im Backend an, woher der Director sich die Daten ziehen soll. Das tun wir in der resources.ini, welche unter /etc/icingaweb2/ liegt.
Dort fügen wir das Untenstehende ein und passen die Daten an unsere LDAP-Umgebung an.

[ActiveDirectory]
type = "ldap"
hostname = "example.com“
port = "389"
encryption = "starttls"
root_dn = "dc=example,dc=com"
bind_dn = "cn=serviceuser,ou=users,dc=example,dc=com"
bind_pw = "password"
timeout = "5"

Wenn das geschafft ist, wechseln wir zu Icinga Web 2 und gehen dort auf Configuration > Application > Resources und klicken dort auf ActiveDirectory um unsere Konfiguration zu überprüfen. Dort steht dann das, was wir gerade in die ressources.ini eingetragen haben. Natürlich kann dies auch gleich hier grafisch konfiguriert werden, aber der nächste Schritt muss eh auf der Kommandozeile erfolgen.

Die Vertrauenstellung zu Certificate Authority (CA) des Active Directory funktioniert überall ein bisschen anders:
Auf CentOS sind die LDAP-Clienttools gegen OpenSSL und Mozilla NSS gelinkt, heißt sie nutzen den zentralen Truststore und man kann die eigene CA folgendermaßen hinzufügen:

# cp /tmp/ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust extract

Möchte man den zentralen Truststore nicht nutzen, kann man in der ldap.conf den Pfad unter TLS_CACERTDIR abändern und die Methode c_hash nutzen:

# cd $(grep TLS_CACERTDIR /etc/openldap/ldap.conf | cut -f2 -d" ")
# cp /tmp/ca.pem .
# ln -s ca.pem $(/etc/pki/tls/misc/c_hash ca.pem | cut -f1 -d" ")

Alternativ dazu kann auch eine Datei mit allen zu vertrauenden Zertifikaten genutzt werden, wozu die Konfiguration auf TLS_CACERT geändert werden muss.

# vi /etc/openldap/ldap.conf
TLS_CACERT /etc/openldap/certs/ca.pem

Dies ist beispielsweise bei Ubuntu, wo die LDAP-Clients gegen GnuTLS gelinkt sind, der Standard und man kann das CA-Zertifikat an die Datei:

TLS_CACERT /etc/ssl/certs/ca-certificates.crt

Wenn das geschafft ist und man die Daten Quelle hinzu gefügt hat, muss man noch den PHP-FPM-Service neustarten via systemctl restart rh-php73-php-fpm.service. Ab jetzt wechselt man in das web und konfiguriert von dort aus weiter.

Danach wechseln wir auf den Icinga Director, und gehen zu „Import Data Sources“, dort fügt man dann eine neue Datenquelle hinzu. Diese könnten so aussehen:

Add import source

Hier noch zur Erklärung des LDAP-Filters:
(memberof=CN=icinga,OU=Groups,DC=example,DC=com)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(mail=*)
Hinter memberof steht der Distingushed Name einer Gruppe, in der alle gewünschten benutzer enthalten sind, die userAccountControl steht für gesperrte Benutzer und wird entsprechend durch das ! negiert und da wir per Mail benachrichtigen wollen muss auch das Attribute mail gesetzt sein.

Zum Schluss wieder auf Add drücken und dann ist auch schon die Import Source erstellt.

Um die Daten noch anzupassen können Modifiers unter Icinga Director > Automation > Import source > Modifiers hinzugefügt werden. In unserem Fall wollen wir die Gruppenmitgliedschaft in den Abteilungen in einem einfacheren Format.


 

Zunächst wechseln wir in Icinga Director > Users > Contacts > User Templates > Add um ein Template zu erstellen bevor wir mit der Sync Rule beginnen können.
Hier sind ein paar Felder wichtig, welche geändert werden sollten, wenn man nicht den Default von Icinga 2 übernehmen möchte. Das sind folgende:

 

Dann auf Add drücken und dann sollte auf der linken Seite „User aus LDAP – not in use – ” stehen.

Als nächstes oben in der Tabliste zu Groups wechseln und dort dann Usergruppen anlegen. (Beispielsweise jede Abteilung als eigene Gruppe o. ä. )

 

Danach wieder links auf Icinga Director > Synchronize > Add, dort muss dann ein Rule name, Object Type, Update Policy sowie Purge eingestellt werden. Zum Schluss wieder Add drücken.

Damit ergibt sich folgende Liste an Properties für den User.

Jetzt noch die Properties setzen diese sind wieder in der Tablist zu finden. Hier müssen folgende Eigenschaften für jede Property gesetzt werden:

Jetzt muss nur Import und Synchronisation einmal gelaufen sein und das wars. Schon sind alle Benutzer aus dem LDAP in Icinga und können ggf. benachrichtigt werden.

Nathaniel Donahue
Nathaniel Donahue
Junior Consultant

Nathaniel hat 2019 die Wirtschaftsschule abgeschlossen. Wegen seinem Interesse am IT-Bereich entschied er sich dafür eine Ausbildung zum Fachinformatiker im Bereich Systemintegration zu machen und fing im September 2019 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er gerne am Computer, allerdings meistens zum Spielen, oder er unternimmt etwas mit seinen Freunden.

Benachrichtigungen mit Icinga 2 mal anders

Vor Kurzem stand ich im Rahmen eines Kundentermins vor der Anforderung noch die Benachrichtigungen für das Icinga 2 Setup umzusetzen. “Soweit kein Problem” dachte ich mir, allerdings war die genaue Anforderung dann doch etwas speziell: Sowohl bei Hosts als auch bei Services können SLA’s gesetzt werden (“gold”, “silver” oder “bronze”). Wenn bei einem Service kein SLA gesetzt ist, greift das Servicelevel des Hosts. Hier der erste Entwurf dazu:

apply Notification "host-mail-gold" to Host {
  import "mail-host-notification"

  period = "gold"
  users = host.vars.contacts

  assign where host.vars.sla == "gold"
}

apply Notification "service-mail-gold" to Service {
  import "mail-service-notification"

  period = "gold"
  users = service.vars.contacts

  assign where (host.vars.sla == "gold" && ! service.vars.sla) || (service.vars.sla == "gold")
}

read more…

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.

Computer Viren in der Cloud

Verschiedene Anbieter von Anti-Virus Produkten bieten mittlerweile SaaS Platformen an um eine zentrale Übersicht über den Status aller Systeme zu bekommen. Dort wird dann neben allen Details eine Übersicht von Alarmen bzw. Bedrohungen verfügbar.

Ein Kunde stellte mich vor die Herausforderung aus diesen Platformen per API die aktuellen Alarme und Probleme abzufragen, daraus sind zwei neue Plugins entstanden.

Hinweis: Wir machen hier keine Werbung für die Produkte, nur unsere Plugins. Wir stehen aktuell in keiner Geschäftsbeziehung zu beiden Anbietern.

read more…

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Windows: One Framework to Monitor them all by Christian Stein | OSMC 2019

This entry is part 4 of 4 in the series OSMC 2019 | Recap

At the Open Source Monitoring Conference (OSMC) 2019 in Nuremberg, Christian Stein captivated the entire conference room with his presentation “Windows: One Framework to Monitor them all”. His demo was the highlight of his presentation, which ended up with enthusiastic applause. You have missed him speaking? We have got something for you: Watch the video of Christian’s presentation and read a short summary (below).

At OSMC international monitoring experts meet annually to set and discuss future trends and objectives. Since 2006 the event takes place every autumn in Nuremberg, Germany. Leading specialists present the full scope of Open Source monitoring and are ready to answer your hardest questions. Discuss with top developers, exchange knowledge and learn wen techniques.

You want more? In-depth workshops the day prior to the conference and a Hackathon provide further possibilities to extend your skills and deepen your knowledge in IT monitoring and management.

The next OSMC takes place in 2021 in Nuremberg.

More information and tickets at osmc.de.


Windows: One Framework to Monitor them all

Christian Stein signed up with a talk titled “Windows: One Framework to Monitor them all” and the intention to turn the Windows side of Icinga upside down. After giving a short run down of the the current issue with “Icinga for Windows” and his attempts at fixing them, we get to the good stuff.

An Icinga PowerShell Framework supported by Powershell 4.0 or higher, but let‘s get into the juicy details: The framework comes with a lot of features, to easily extend it within your environment and to simplify monitoring on Windows as well. Additionally, there is a dev-toolkit, which offers plenty of possibilities for developers to give the framework their own tweak. As of now, there are four repositories beyond the framework itself. Up first and most important to mention is icinga-powershell-kickstart, which provides a basic PowerShell script to interactively install the framework. Also rather essential for the framework is the icinga-powershell-plugins repository, which provides a collection of Windows check plugins.

Want to run the framework as a service? Glad you asked. There is a repository for that as well. It’s also covered by the kickstart wizard. Check icinga-powershell-service to find out more or to give some feedback. If you’ve always asked yourself why you should run appliances as a service, there are several benefits. Like the service running before a user logs on and continuing to run, without a logged on user.

Last but not least, even most essential, the framework itself. If we look at the current ways to make Icinga work on windows, they are good, but not great. The icinga-monitoring-framework provides tools and configuration to make icinga monitoring on windows possible, almost natively, except for said repositories.

Having said all that and more, Christian went on with a live demo of the Framework, gave some installation advice and by that I mean, delved deeper into the kickstart script. He also showed off some features and gave some best practice advice. So, all that was left to say is… whats next?

Christian announced, that it will be available on PowerShell Gallery, which will not only help the project grow, but make it even more available as is. And of course, there will be more plugins. For those eagerly waiting for one of these, the next release hopefully provides MSSQL, Active-Directory, Exchange and Hyper-V plugins.

The community’s and the customer’s interest in better windows monitoring is undeniable, but we depend on your feedback and support on this, the respective repository is the place to be, and if you can’t figure, which one it fits, just post your issue at: https://github.com/Icinga/icinga-powershell-framework/issues

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

Tornado – Extend Icinga 2 for Active and passive Monitoring of complex heterogeneous IT Environments by Francesco Cina & Patrick Zambelli | OSMC 2019

This entry is part 3 of 4 in the series OSMC 2019 | Recap

At the Open Source Monitoring Conference (OSMC) 2019 in Nuremberg, Francesco Cina and Patrick Zambelli whirled up a „Tornado – Extend Icinga 2 for active and passive Monitoring of complex heterogeneous IT Environments”. If you missed their presentation: See the video of their introduction to Tornado and its use cases, and read a summary (below).

The OSMC is the annual meeting of international monitoring experts, where future trends and objectives are set. Since 2006 the event takes place every autumn in Nuremberg, Germany. Leading specialists present the full scope of Open Source monitoring and be ready to answer your hardest questions. Learn new techniques, exchange knowledge and discuss with top developers.

In-depth workshops the day prior to the conference and a Hackathon provide further possibilities to extend your skills and deepen your knowledge in IT monitoring and management.

The next OSMC takes place in 2021 in Nuremberg.
More information at osmc.de.


 

Tornado – Extend Icinga 2 for Active and passive Monitoring of complex heterogeneous IT Environments

Monitoring Challenges: Pool vs. Event.

First of all we have to explain the difference between Pool and Event approach. Icinga and nagios use the polling approach, which is scheduling monitoring or checks in a static time interval to get a specific state. You can derive from this state if the status from monitored device or service is critical or ok. That means, we know not only the results of monitoring but also the monitored systems. By Polling we have centralized configuration and control. This will be performed either agentless e.g. SHH, SNMP or through an agent for example Icinga, NSClient++.

Contrarily to this historical approach is the event based approach. On the one side we accept the matrix all the time from the remote system and we don’t know exactly what will come, but on another side we have to understand the incoming protocol and derive if there is a problem or not.

 

Advantages and disadvantages of polling and event:

Polling Pros

  • Control when a check should be executed
  • Get only the data which you are interested in
  • Knowing the context from the system you are interacting with (context = host, service, performance data)

Polling Cons

  • Static configuration for monitored architecture (not good for a changeable one e.g. micro services)
  • Continuously usage of resources day and night
  • Not all data is retrievable via polling

 

Event Pros

  • No delay to react when event happens
  • No need to know what to receive but understand it
  • Dynamic on fast changing architecture
  • Listen to channel => new added hosts are integrated

Event Cons 

  • Need to face large amount of data (peaks)
  • Lack for filtering at source. We can lose information specially when the protocol is not reliable e.g. UDP or SNMP
  • Risk to lose information
  • Not the right approach for host alive and service availability  

Combination of both Polling (Icinga 2) and event (Tornado) will definitive a winning:

With Icinga 2 we have the advantage to start a project very quickly and easily. We have a wide range of checks in the community. Through Templates we can create a reusable monitoring. We can adapt to changes in the architecture by interacting with CMDB or domain controller for example.

With Tornado we listen on the monitored host to the output of a service on a specific channel then we convert this output via collector to Json, which is the only recognized language by Tornado. After that we compare the flow with by regular expression created rules. In the end we forward an action to Icinga 2 – “Critical” for example. 

That means, when our infrastructure grows with new hosts we can monitor the availability from these hosts and their services with Icinga 2. We can control the output from services with Tornado.

 

How to handle the increased load?

01. Scale the monitoring system horizontally

When our servers and services grow, we can increase the number of monitoring instances. This is not good because it doesn’t work out of the box and too many problems will appear. Moreover the throughput does not go linearly. At a number of scaled nodes the overhead of communication and sycronization between them will take more time than analyzing the traffic itself.

02.  Use a big data system

We put a big data system between events and the monitoring system, for example kafka, spark, cassandra. The idea is, we reprocess the messages or the events and send only the important ones to the monitoring system. In this way we will reduce the flow against our monitoring system. This will definitely lead to reduce the load as well. It is a real solution but terribly expensive and needs a lot of knowledge with the used data system.

03. Tornado

Why is Tornado the solution?

  • Can handle millions of events per second per CPU
  • Stateless: the nodes don’t need to communicate to each other
  • Cloud-ready
  • Has collectors which translate events from format X to Tornado format (Json)
  • Take decision based on the event content
  • Cheap because it doesn’t need too much resources 

Tornado decides to pass the events to Icinga when they match the pipelines and the rules we defined in Tornado. Not suitable events will be dropped.

 

You liked this blog post and want to read more about different monitoring solutions? Then browse through our blog series, visit our YouTube channel or just contact us.

 

Afeef Ghannam
Afeef Ghannam
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

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