Seite wählen

NETWAYS Blog

Icinga Installationsmethoden (und Wissenswertes zu Komponenten und Subscription)

Im ersten Teil bin ich auf die passende Plattform und die Wahl des passenden Betriebssystems eingegangen. Wenn du den ersten Teil noch nicht gelesen hast, dann solltest du das jetzt nachholen und anschließend hier weiterlesen!

In diesem Post beantworte ich nun die Frage, ob du das System eher als „Pet or Cattle“ ansehen solltest, was sich natürlich auf Installationsmethode, Management und einige weitere Aspekte auswirkt. Auch welche Icinga-Komponenten für mich ein Muss, eine nette Ergänzung oder doch eher ein Spezialfall sind, ist Teil meines Blogposts. Nebenbei beantworte ich dir hoffentlich auch die Frage, ob du dafür mittlerweile eine Icinga-Repository-Subscription brauchst oder nicht.

Wie installieren wir nun?

Bevor ich auf die Installation von Icinga eingehe, muss ich einen kleinen Exkurs einschieben und zwar zum Thema Agent. In meinen Augen gibt es kein agentenloses Monitoring, denn selbst wenn man SSH dafür her nimmt, nutzt man den eigentlichen Anmeldedienst als Monitoringagent und muss dafür etwas konfigurieren. Daher habe ich lieber einen dedizierten Agenten installiert und hier bietet die Nutzung von Icinga als Agent in meinen Augen die meisten Vorteile. Wir erhalten eine hohe Kommunikationssicherheit, Verfügbarkeit auf vielen Plattformen, einheitliche Konfiguration und keinen „Medienbruch“ durch externe Komponenten.

Daher möchte ich mit der Annahme starten, dass wir drei Arten von Installation haben. Zum einen das zentrale System, zum anderen die Agents und je nach Größe und Aufbau dazwischen noch Satelliten. Bei allen drei Varianten beantworte ich zudem die Frage, ob es sich aus meiner Sicht dabei um „Pet or Cattle“ handelt.

Auf dem Agent brauchen wir Icinga und eine gewisse Zahl Plugins für die lokalen Checks installiert. Zudem muss die Kommunikation mit dem übergeordneten System konfiguriert sein. In einer großen Umgebung wird die Zahl der Icinga-Agenten sehr schnell sehr groß und wir reden hier sicher von „Cattle“. Deshalb setzen wir hier auf ein gut konzipiertes Konfigurationsmanagement. Ich empfehle die Nutzung der offiziellen Puppet-Module oder Ansible-Collection anstatt etwas selber zu entwickeln. Wer diese Werkzeuge nicht für seine Windowssysteme nutzt, bekommt mit Icinga for Windows ein sehr gutes Hilfsmittel an die Hand.

Der Satellit dient üblicherweise nur dazu, die Last zu verteilen oder Netzwerkstrukturen abzubilden und kommt ohne Webinterface aus. Daher braucht es auch nicht viel mehr als bei einem Agent, wahrscheinlich nur kleine Anpassungen an der Konfiguration und mehr Plugins. Trotz der vermutlich überschaubaren Anzahl an Satelliten würde ich diese als „Cattle“ einordnen und wie Agents managen.

Beim zentralen System wird es dann doch etwas komplizierter. Neben den bisherigen Komponenten Icinga und den gewünschten Plugins braucht es die Datenbank als Schnittstelle und das Webfrontend für eine grafische Darstellung.
Als Freund des „Keep it simple (and) stupid“ würde ich sagen Hochverfügbarkeit nimmt uns die Virtualisierungsplattform ab, Lastverteilung bekommen durch Satelliten und Agents und die Kommunikation zwischen den verschiedenen Komponenten ist auf einem System am einfachsten und sichersten. So ein System kann aber entsprechend viel Ressourcenbedarf entwickeln und aus vielen Komponenten bestehen. Wer das vermeiden will, verteilt diese auf verschiedene Systeme und gewinnt damit die Möglichkeit, alles separat zu skalieren. Dann sind wir aber schnell weit weg von simpel! Egal wie die Umsetzung am Ende aussieht, hier haben wir ein System oder einen Verbund aus Systemen, das ich als „Pet“ betrachten würde.
Um diese Komponenten zu installieren, gibt es für mich drei valide Installationswege: manuell, semi-manuell mit dem Icinga-Installer oder auch automatisiert.

Der manuelle Weg ist für viele wohl der transparenteste und da man ja eine neue Software kennenlernt und noch nicht alle Stellschrauben kennt, auch der naheliegendste. Aber wer diesen Weg einmal beschritten hat, merkt hier schnell, dass der große Vorteil von Icinga, die Flexibilität und Integration bestehender Lösungen sich bei der Installation in einen Nachteil verwandelt. Schließlich muss ja genau jede dieser Komponenten installiert und das dafür notwendige Stellschräubchen gedreht werden.

Vollständig automatisieren ist zum Einstieg aber auch schwierig, daher stellt der Icinga-Installer von NETWAYS einen sehr guten Mittelweg dar. Vor allem verbaut man sich nicht die spätere Automatisierung. Auch gut geeignet ist der Weg als mögliche Restore-Möglichkeit oder zum einfacheren Bereitstellen von Testumgebungen. Als Puppet-Nutzer hat man sogar noch den Vorteil, dass der Installer auf genau diesen Modulen aufbaut und das Wissen bereits vorhanden ist oder ausgebaut werden kann.
Ein weiterer Vorteil des Icinga-Installers sowie der Puppet-Module, Ansible-Collection und Icinga for Windows ist, dass nach einem Update eventuell notwendige Änderung direkt vorgenommen werden. Somit wird das einfache Update über Pakete noch mal vereinfacht.

Welche Komponenten sollte mein Icinga haben?

Datenbank

Was installiere ich nun am besten auf dem zentralen System? Die erste Komponente ist natürlich die Datenbank. Hier stehe ich vor zwei wichtigen Entscheidungen. Zum einen, welches Datenbankschema ich nutzen will, den bisher verwendeten IDO oder die neue IcingaDB. Zum anderen, ob ich MySQL oder PostgreSQL als Backend einsetze. Bei einer neuen Installation würde ich ganz klar auf die IcingaDB setzen! Einzige Ausnahme wäre eine andere Komponente spielt noch nicht sauber mit. Aber auch hier wäre mein Ansatz eher über Issues diese Komponente dazu bewegen, IcingaDB zu unterstützen, also noch mit IDO zu starten. Als Backend würde ich MySQL empfehlen, was vor allem an der Verbreitung im Icinga-Umfeld liegt. Es ist einfach das häufiger genutzte und damit auch deutlich mehr getestete Backend. Wenn in Deinem Unternehmen jedoch PostgreSQL genutzt wird, gibt es aus meiner Sicht keinen Grund, hier nicht auf das gewohnte Backend zu gehen.

Frontend

Die zweite Komponente ist das Frontend, besser bekannt als Icinga Web. Hier brauchen wir neben den entsprechenden Abhängigkeiten auf alle Fälle noch das zusätzliche Modul Icinga DB Web, da wir uns für IcingaDB als Backend entschieden haben.

Alle Icinga-Komponenten die ich nachfolgend aufzähle, sind optionale Module. Dennoch will ich dir manche davon noch empfehlen.

Optionale Module

Als erste Entscheidung bei den „nicht-grundlegenden“ Modulen werfe ich die Frage nach dem Icinga Director in den Raum. Ich muss sagen, für mich ist das grafische Konfigurationstool fast schon gesetzt. Zum Warum, wieso, weshalb kommt in Kürze ein weiterer Blogpost von mir. Darum gibt es von mir hier nur den Hinweis, dass Du diese Entscheidung möglichst früh treffen solltest. Und zwar weil eine nachträgliche Migration einiges an Arbeit, aber auch Umdenken erfordert, die man sich so sparen kann.

Die erste Erweiterung, die ich persönlich als notwendig erachte, ist die Ergänzung um eine Graphing-Lösung. Ohne diese zeigt einem Icinga zwar sehr schön den aktuellen Status an, mit einem Graphing-Modul erhält der Status aber noch mal deutlich mehr Kontext. Mein Beispiel dafür ist immer die volllaufende Festplatte, bei der ich dank der Graphen leicht sehe, ob akuter Handlungsbedarf besteht oder der nächste Wartungstermin reichen wird. Ich bin zwar persönlich immer noch großer Fan der Einfachheit von Graphite, aber InfluxDB ist hier einfach die modernere Lösung und braucht auch deutlich weniger Pflege. Baut man also einen neuen Datenpool auf, empfehle ich InfluxDB und würde es sogar mit auf dem zentralen System installieren. Gibt es in Deinem Unternehmen schon eine bestehende Graphing-Lösung würde ich Icinga an diese anbinden, sodass man vielleicht später Daten korrelieren kann. Als Frontend zu den Daten ist aus meiner Sicht Grafana die erste Wahl. Das dazugehörige Modul kann problemlos in Icinga Web integriert werden.

Für weitere empfehlenswerte Erweiterungen hat man zu Beginn noch nicht genug Daten, daher empfehle ich Reporting, die Modellierung von Geschäftsprozessen oder das Cube-Modul für eine spätere Runde aufzusparen.

Heißt ich würde eher schauen, mit welcher Integration kann man vielleicht punkten oder mit welchem Eye candy Benutzer überzeugen. Hier können die Entscheidungen sehr unterschiedlich ausfallen!
Das Map-Modul hat mir schon oft freudige Anwender beschert, da plötzlich eine ganz andere Sicht auf die Umgebung gegeben ist. Auch über die vSphere-Integration hab ich schon gehört, dass diese übersichtlicher sei als die eigentlich vSphere-Oberfläche. Schau dich da also mal bei den Modulen um, meistens finden meine Kunden etwas, das sie direkt oder zumindest in einer späteren Ausbaustufe haben wollen.

Bevor wir zum letzten Themenbereich kommen, will ich auf ein Modul noch gesondert eingehen: Director-Branches, weil es nur mit der Icinga-Repository-Subscription verfügbar ist. Da es den Director erweitert, kommt es eh nur infrage, wenn Du dich für die grafische Konfiguration entschieden hast.
Bei der Erweiterung stellt sich die Frage, wie viele Editoren hat Deine Konfiguration bzw. wie viele soll sie haben. Wenn Du hier einen Nutzerkreis größer den eigentlichen Monitoringadministratoren anstrebst, ist das Modul auf alle Fälle einen Blick wert. Es erweitert den Icinga Director um Git-ähnliche Branching-Workflows und Review-Prozesse. Das erhöht zwar in gewissem Maß die Komplexität und ist somit nicht für jeden das Richtige, verhindert aber Situationen nach dem Motto „Viele Köche verderben den Brei“.

Die Frage nach der Subscription

Zum Abschluss nun noch meine Antwort auf die Frage „Brauche ich die Icinga-Repository-Subscription?“. Das ist eine sehr berechtigte Frage, zu deren Beantwortung ich hier ein paar Überlegungen mit Dir teilen will.
Wenn Dir der Community-Support reicht, suchst Du Dir die dazu passende Distribution aus, also vermutlich Debian.
Director-Branches kann jedoch für einen bestimmten Benutzerkreis hilfreich und den Preis einer Subscription wert sein. Ob Du und Dein Team dazu zählen kannst im vorangehenden Abschnitt noch mal prüfen.
Hast Du eine Umgebung, in der Du aber Red Hat Enterprise Linux oder SUSE Linux Enterprise Server überwachen möchtest und den Agenten nutzen, aber nicht selber paketieren willst, kannst Du eine Repository Subscription von Icinga erwerben.

Eine andere, aus meiner Sicht lohnendere Möglichkeit ist die Nutzung einer NETWAYS Support-Subscription, die Du auch über NETWAYS als erfahrenen Icinga-Partner bekommst.
Die Variante „Basic“ beinhaltet zum Repository-Zugriff bereits eine unlimitierte Anzahl von Support-Anfragen, allerdings mit Reaktionszeiten von 8 Stunden. Wer sich nicht solange gedulden kann oder will schaut besser auf die Variante „Premium“ mit kürzeren Reaktionszeiten und zusätzlich einem Tag Remote-Consulting für die jährliche Review der Umgebung. Für Umgebungen in denen das Monitoring eine wirklich kritische Komponente ist, gibt es noch die Variante „Enterprise“ mit Support rund um die Uhr und zwei Tagen Remote-Consulting. Wer es individueller braucht, wendet sich direkt an meine Kollegen vom Vertrieb.
Der Vorteil jeder Variante, Du hast nicht nur Zugriff auf die Software sondern immer direkt eine Ansprechperson.

Schlusswort

Im Rahmen meiner beiden Beiträge habe ich versucht, den passenden Detailgrad zu finden, sie nicht unnötig in die Länge zu ziehen, meine Empfehlungen aber nachvollziehbar darzulegen. Ob mir das gelungen ist, überlasse ich meinen Leser:innen zu beurteilen ;-). Zumindest hoffe ich meine Entscheidungen und welche Beweggründe zu diesen führen, sind für Dich nachvollziehbar und hilfreich.
Falls Du nun Interesse an Icinga gefunden hast und es auch in Deinem Unternehmen vorschlagen oder sogar einführen willst, führen ich oder ein:e Kolleg:in gerne eine individuelle Betrachtung der vorhanden IT-Umgebung durch. Im Rahmen eines solchen Consultingtermins erstellen wir gerne zunächst ein Proof of Concept. Natürlich können wir auch gleich mit der Implementierung von Icinga beginnen.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Icinga – so wählst du Plattform und Betriebssystem

Aus zahlreichen Kundenprojekten, die ich im Laufe meiner Zeit bei NETWAYS durchgeführt habe, haben sich für mich einige Best Practices bei der Einrichtung und Konfiguration von Icinga ergeben. Um diese state-of-the-art Icinga-Installation zu beschreiben, dachte ich mir, ich gehe hier im Blog so vor wie ich es im Consulting auch würde. Das heißt, als Erstes gehe ich auf die richtige Plattform ein also primär das Betriebssystem, aber auch ob Hardware, virtuelle Maschine oder gar Container.
Um den Rahmen nicht zu sprengen wird es einen zweiten Teil geben, in dem ich ich dann die Frage „Pet or Cattle“ beantworte, darauf eingehe, welche Icinga-Komponenten für mich einfach dazu gehören und nebenbei beantworte ich hoffentlich noch die Frage nach der Icinga-Repository-Subscription.

Hardware, virtuelle Maschine oder gar Container?

Starten wir also einmal ganz am Anfang und überlegen uns, welche Vor- und Nachteile wir von einer Hardware-Lösung hätten. Für mich gibt es hier immer noch einen großen Vorteil und zwar, dass man mit Hardware eine Icinga-Monitoring-Lösung aufbauen kann, die unabhängig von der zu überwachenden Umgebung ist. Leider ist dies in der Praxis in den meisten Fällen nicht so gegeben, wie man sich das als Consultant erhofft. Oder es ist mit viel Planung und weiteren Komponenten verbunden. Denn schon allein so etwas wie der Alarmierungsweg per Mail verkompliziert dies ungemein.
Daher überwiegen für mich in den meisten Fällen die Vorteile virtueller Maschinen und die damit verbundenen komfortablen Managementmöglichkeiten. Man muss sich nur bewusst machen, wovon dann das Monitoring abhängt, was davon vielleicht zu kompensieren ist und was einen Ausfall auslöst, der im schlimmsten Fall einen Blindflug bedeutet.
Wenn virtuelle Maschinen aus meiner Sicht die meisten Vorteile bieten, sind Container dann der nächste logische Schritt? Das Icinga-Projekt bietet auf jeden Fall eigene Container an, hat den Icinga-Prozess container-freundlich gebaut und einige Kunden laufen sehr erfolgreich mit diesem Konzept. Aber wenn ich mir die Plugin-Fähigkeit von Icinga und Modularität von Icinga Web so anschaue, so stehen diese Eigenschaften, die ich als Vorteile ansehe, dem Container-Ansatz doch etwas im Weg. Vor allem wenn dann ein Plugin durch ein Icinga-Web-Modul zur Verfügung gestellt wird, welches ohne Agent im Container nicht aufrufbar ist.

Wahl des Betriebssystems

Bei der Wahl des Betriebssystems bin ich ein großer Fan davon, auf bereits bestehendes Know-how zu setzen. Daher rate ich meinen Kunden Icinga auf der gewohnten Linux-Plattform zu installieren. Da aber jede Distribution ihre Eigenheiten sowie Vor- und Nachteile hat, müssen wir das Thema Betriebssystem etwas detaillierter betrachten. Und da sie direkt mit der Wahl der Distribution zusammenhängen, gibt es einen kleinen Exkurs in Richtung Monitoring-Plugins.

Debian-Familie

Hier ist es relativ einfach, denn für Debian und Ubuntu stellt das Icinga-Projekt Pakete frei zur Verfügung. Diese gibt es für jede bekannte Version, auch für einen ARM-Build in Raspberry Pi OS ist gesorgt.
Einzige kleine Einschränkung: Support gibt es im Falle von Ubuntu nur für LTS-Releases.
Damit Icinga nicht nur schön aussieht, sondern auch die gewünschte Überwachung liefert, werden Plugins benötigt. Monitoring-Plugins ist in der Debian-Familie die Quelle für die gleichnamigen Pakete. Hier bekommen wir eine paketierte und gut supportete Standard-Plugin-Sammlung, die zudem noch einfach zu installieren und gut gepflegt ist.
Etwas verwirrend ist der Benutzer „nagios„, der im weiteren Verlauf von den Icinga-Paketen weiterverwendet wird, die Nagios-/Icinga-1-Konfiguration, die durch die Plugins abgelegt wird, und die grobe Aufteilung auf Pakete.
Dass hier statt mit setuid mit Filesystem-Capability gearbeitet wird, finde ich persönlich sehr gut. Heißt, wir haben bei den Check Plugins Vor- und Nachteile, die aber vor allem dann eine Rolle spielen, wenn wir verschiedene Distributionen im Einsatz haben.
Einzig meine persönlichen teils negativen Erfahrungen mit Ubuntu lassen mich eher ein Debian empfehlen, Stichwort „Sonderwege“.

Red-Hat-Familie

Bei der Red-Hat-Familie wird es aus meiner Sicht komplizierter. Fangen wir mit Red Hat Enterprise Linux (RHEL) an. Hier gibt es die Pakete vom Icinga-Projekt auf Basis einer Repository-Subscription. Nachdem hier explizit auf RHEL gebaut wird, Partnerverträge bestehen etc. finde ich das ein berechtigtes Vorgehen!
Nächste in der Familie wären eigentlich CentOS Linux bzw. CentOS Stream. Ich sage hier eigentlich, denn CentOS Stream wird zukünftig nicht mehr aktiv unterstützt. Was heißt das für aktuelle Nutzer von CentOS? Es wird (Stand heute) keine Pakete für CentOS Stream 8 und 9 geben. Da es sich bei diesen Distributionen um den Upstream zu RHEL handelt, könnten theoretisch die RHEL-Pakete genutzt werden.
Leider werden auch die RHEL-Derivate Rocky Linux, AlmaLinux und Oracle Linux nicht aktiv als Icinga-Systeme unterstützt. Hier findet sich auf der Icinga-Homepage jedoch der Hinweis, dass die RHEL-Pakete bei Systemen, die zu 100-Prozent binär-kompatibel sind, genutzt werden können. Das ist zumindest bei Rocky Linux und AlmaLinux der Fall. Ob es sich dabei um eine gute Lösung für den Einzelfall handelt, muss man selbst entscheiden.
Erfreulicher sieht es dahingehend bei Amazon Linux aus. Im Rahmen der Icinga-Subscription bekommt man Zugriff auf die entsprechenden Pakete.
Alternativ kann mit Fedora auf Community-Support gesetzt werden.

Kommen wir zu den Check Plugins für Red-Hat. Hier befinden sich die Nagios-Plugins in einem zusätzlichen Repository, den „Extra Packages for Enterprise Linux“ oder im Fall von Fedora in den normalen Repos des Fedora-Projekts. Es handelt sich also um eine andere Quelle als diejenige, die bei Debian-basierten Systemen zum Einsatz kommt. Wie bei Debian wird aus „historischen Gründen“ die Gruppe „nagios“ verwendet und mit setgid gearbeitet, um Plugins höhere Rechte zu geben.
Man merkt, dass die Situation bei Red-Hat-Derivaten deutlich komplexer ist als bei Debian. Und besonders CentOS-Nutzer müssen sich aktuell nach Alternativen umsehen, was innerhalb der Community zu der einen oder anderen kritischen Stimme geführt hat.

Um der Komplexität etwas entgegenzuwirken, bauen wir bei NETWAYS wieder selbst Pakete. Unsere Buildplattform orientiert sich am Icinga-Projekt, daher bauen wir auf CentOS Linux 7, RHEL 8 und 9. Unsere Buildziele orientieren sich an unseren Kunden. Wir bauen und testen also für CentOS und RHEL, gehen von Funktion auf Rocky Linux und AlmaLinux aus, aber betrachten nicht Fedora, Oracle Linux und Amazon Linux.

SUSE-Familie

Bleibt noch SUSE Linux Enterprise Server (SLES). Diese Pakete sind ebenfalls nur für Subscription-Kunden zugänglich. Eine Alternative für alle SUSE-Fans wäre openSUSE, welches ich persönlich ebenso wie Fedora normalerweise nicht in einem Unternehmensumfeld sehe. Es soll jedoch ab 15 SP 3 zu 100-Prozent binär-kompatibel mit SLES sein, wodurch es vielleicht für den einen oder anderen in Frage kommt. Hier gibt es direkt Monitoring-Plugins über das Packagehub-Repository und da wir als NETWAYS bisher wenig Anfragen in dem Bereich hatten, bauen wir aktuell noch nicht standardmäßig für SLES.

Andere Systeme kommen nicht als Plattform für das zentrale System infrage, aber als Agent wird auch noch Windows supportet und bauen lässt sich die Software selbst auf weiteren Plattformen. Im Fall von FreeBSD und Alpine Linux werden sogar Pakete von der Community bereitgestellt.

Zusammenfassung

Welche Distribution kann ich nun empfehlen?
Debian ist sinnvoll für all diejenigen, denen der Community-Support ausreicht. Wer eh schon auf Enterprise-Support beim Betriebssystem setzt, für den lohnen sich die RHEL-Pakete, auch wenn diese mit einer Icinga-Subscription verbunden sind. Alle anderen Optionen sind auch valide, aber fühlen sich einfach nicht optimal an.
Wer eine heterogene Umgebung zu überwachen hat, findet im Icinga-Umfeld neben der Verfügbarkeit, wie man oben raus lesen konnte, ein paar kleinere Baustellen, die mit Erfahrung aber leicht zu handhaben sind. Für diese kann aber das Icinga-Projekt recht wenig, denn auch wenn man versucht hat, in der Vergangenheit in Zusammenarbeit mit allen Distributionen einen gemeinsamen Kurs zu finden, ist dies leider nicht immer gelungen.

Damit sind wir am Ende des ersten Teils meiner Vorstellung meiner persönlichen state-of-the-art Icinga-Installation. Ich hoffe Dir damit weiterhelfen zu können!
Falls Du bereits jetzt Interesse an Icinga gefunden hast und es auch in Deinem Unternehmen vorschlagen oder sogar einführen willst, führen ich oder ein:e Kolleg:in gerne eine individuelle Betrachtung der vorhanden IT-Umgebung durch. Im Rahmen eines solchen Consultingtermins erstellen wir gerne zunächst ein Proof of Concept. Natürlich können wir auch gleich mit der Implementierung von Icinga beginnen.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Kommende Icinga Web-Funktion: Rememberme

Wir freuen uns immer über Feedback von euch, um Icinga noch besser zu machen. Viele Icinga-Benutzer haben die Meinung geäußert, dass sie gerne eine Rememberme-Checkbox auf der Login-Seite von Icinga Web hätten, damit sie sich nicht jedes Mal anmelden müssen, wenn sie Icinga Web besuchen.
Wir haben an diesem neuen Feature speziell während des Home-Office gearbeitet und planen, es in der nächsten Version von Icinga Web zu veröffentlichen.

Hier sind einige Schritte, wie dies funktioniert:

  • Wir führen ein neues „remember me” Cookie und ein „Stay logged in” checkbox auf der Login Seite ein.
  • Alle sensiblen Benutzerinformationen werden mit einem RSA-Schlüsselpaar verschlüsselt.
  • Das Cookie läuft nach 30 Tagen ab.
  • Die Erneuerung erfolgt automatisch nach einer erfolgreichen „remember me” Authentifizierung und beinhaltet die Neuerstellung des RSA-Schlüsselpaares und des Cookies mit 30 Tagen Ablaufdatum.
  • Die Authentifizierung über das „remember me” Cookie löst unseren normalen Authentifizierungsprozess aus, d. h. die Anmeldung mit dem Benutzernamen und dem Kennwort und die Erstellung eines neuen Sitzungs-Cookies bei erfolgreicher Authentifizierung.
  • Das Cookie wird gelöscht, wenn die Authentifizierung fehlschlägt oder ein Logout ausgelöst wird.

Um die Geheimnisse des Benutzers sicher zu speichern, erzeugen wir auf der Serverseite ein RSA-Schlüsselpaar bei der Erstellung des „remember me” Cookies. Das Schlüsselpaar wird in unserer Web-Datenbank gespeichert. Der Inhalt des Cookies sieht wie folgt aus:

  • Öffentlicher Schlüssel
  • Benutzername und Kennwort, verschlüsselt mit dem öffentlichen Schlüssel

Damit ist der öffentliche Schlüssel unser gemeinsames Geheimnis. Bei der Authentifizierung über das „remember me” Cookie suchen wir den öffentlichen Schlüssel in unserer Datenbank, entschlüsseln die Geheimnisse mit dem privaten Schlüssel und lösen unsere normale Authentifizierung mit dem entschlüsselten Benutzernamen und Passwort aus.

Warum lösen wir die normale Authentifizierung aus?

Die normale Authentifizierung beinhaltet bereits die Überprüfung der Kombination aus Benutzernamen und Passwort. Auf diese Weise prüfen wir, ob der Benutzer existiert oder das Passwort geändert wurde.
Wenn das Cookie bereits existiert und der Benutzer die Seite besucht, entschlüsseln wir die Benutzergeheimnisse und versuchen, uns damit anzumelden. Das funktioniert genauso, als ob der Benutzer diese Informationen manuell eingegeben und auf Login geklickt hätte.

Du kannst die Entwicklung dieser Funktion auf Github verfolgen. Wenn Du einen anderen Vorschlag oder einen neuen Feature Vorschlag hast, den Du gerne sehen würdest, kannst Du gerne ein Issue auf Issue auf Github öffnen.

 

Sukhwinder Dhillon
Sukhwinder Dhillon
Developer

Sukhwinder hat 2021 seine Ausbildung als Fachinformatiker für Anwendungsentwicklung bei NETWAYS erfolgreich abgeschlossen. In seiner Freizeit fährt er gerne Fahrrad, trifft sich mit Freunden, geht Joggen oder sitzt vorm Computer und lernt etwas Neues.

NETWAYS Webinarkalender im Juli

NETWAYS Auch im Juli gibt es wieder zwei Webinare, in welchen wir einerseits den aktuellen Stand von Icinga Web 2 zeigen wollen und auf der anderen Seite unser SMS Alarmierungs Webinar, in welchem wir unsere SMS Hardware an Linux und Icinga 2 anbinden.
Hier noch einmal die nächsten Termine zusammengefasst:

Titel
Zeitraum Registrierung
Icinga Web 2: Neuheiten im Webfrontend 08. Juli 2015 – 10:30 Uhr Anmelden
Linux: Einrichten einer SMS-Alarmierung 23. Juli 2015 – 10:30 Uhr Anmelden

Wer unsere bisherigen Webinare verpasst hat, kann sich diese in unserem Webinararchiv natürlich kostenfrei ansehen.

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".

Letzter Aufruf für das Icinga Web 2 Webinar

icinga_logo_200x69 Nachdem letzte Woche erfolgreich die Open Source Monitoring Conference (OSMC) stattgefunden hat und aufgrund der vielen Info-Blogposts der ein oder andere vielleicht den Webinar-Reminder übersehen hat, möchte ich natürlich kurz vor dem Icinga Web 2 Webinar noch einmal darauf aufmerksam machen.
Morgen um 10:30 Uhr wollen wir die aktuelle Version von Icinga Web 2 inkl. der eingebauten Features und den Installer vorstellen. Eine Registrierung ist natürlich bis morgen Früh noch möglich.
Wer sich für die nächsten Webinare in diesem Jahr noch interessiert, kann sich natürlich auch gleich registrieren:

Webinar Thema Termin und Registrierung
Puppet: Windows Configuration Management 12. Dezember 2014 – 10:30 Uhr
NETWAYS: Jahresrückblick 2014 18. Dezember 2014 – 10:30 Uhr

In unserem Webinar-Archiv findet man auch noch die bisherigen Webinare, um die Wartezeit zu überbrücken.
Bis morgen!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".