Planung Und Realisierung Einer Monitoring-Lösung Zur Überwachung Der Netzwerk- Fähigen Geräte Des FTU

Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerk- fähigen Geräte des FTU

April 2016

Julian Merkel Prüflings-Nr. 31133

Dokumentation der betrieblichen Projektarbeit im Rahmen der Abschlussprüfung für Fachinformatiker der Fachrichtung Systemintegration an der Industrie- und Handelskammer Karlsruhe durchgeführt am Fortbildungszentrum für Technik und Umwelt (FTU) Karlsruher Institut für Technologie Hermann-von-Helmholtz-Platz 1 76344 Eggenstein-Leopoldshafen.

KIT – Die Forschungsuniversität in der Helmholz-Gemeinschaft

Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

ii Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Inhalt

1 Ausgangssituation ...... 1 1.1 Projektbeschreibung ...... 1 1.2 Projektumfeld ...... 1 1.3 Kundenwünsche ...... 2 1.4 Teilaufgaben ...... 2 1.5 Prozessschnittstellen ...... 2 1.6 Ist-Analyse ...... 3

2 Ressourcen- und Ablaufplanung ...... 3 2.1 Soll-Konzept ...... 3 2.2 Personalplanung ...... 5 2.3 Sachmittelplanung ...... 5 2.4 Terminplanung ...... 6 2.5 Kostenplanung ...... 7 2.5.1 Hardwarekosten ...... 7 2.5.2 Softwarekosten ...... 7 2.5.3 Personalkosten ...... 7 2.5.4 Gesamtkosten ...... 7 2.6 Ablaufplan ...... 7

3 Durchführung und Auftragsbearbeitung ...... 8 3.1 Auswahl eines Monitoring Systems ...... 8 3.1.1 Nagios ...... 8 3.1.2 Check_MK ...... 8 3.1.3 Bewertung und Systemauswahl ...... 9 3.2 Inventur der vorhandenen Systeme und Netze ...... 9 3.3 Beschaffung der benötigten Software ...... 10 3.3.1 Ubuntu Server – Grundsystem...... 10 3.3.2 Check_MK – Monitoring Software...... 10 3.3.3 Zusätzliche Software ...... 10 3.4 Installation und Konfiguration des Monitoring-Servers ...... 11 3.5 Installation der Monitoring-Software ...... 11 3.5.1 Kopieren des benötigten Pakets ...... 11 3.5.2 Installation des Paketes ...... 12 3.6 Konfiguration der Monitoring-Software ...... 12 3.6.1 Lokal ...... 12 3.6.2 Remote ...... 13 3.7 Inventur und Einpflegen der zu überwachenden Systeme ...... 14 3.7.1 Server und Netzwerkgeräte aufnehmen ...... 14

Julian Merkel iii Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

3.7.2 Monitoring-Agent auf dem Monitoring-Server installieren ...... 14 3.7.3 Monitoring-Server überwachen ...... 14 3.7.4 Weitere Server und Netzwerkgeräte aufnehmen ...... 15 3.7.5 Hostgroups anlegen und Systeme einordnen ...... 16 3.7.6 Info-/Alarm- und Benachrichtigungsketten ...... 17 3.7.7 Qualitätssicherung ...... 19 3.8 Zusätzliche Serverkonfigurationen ...... 19 3.8.1 Authentifizierung mit KIT-Account (LDAP-Anbindung) ...... 19 3.8.2 Weboberfläche über HTTPS ...... 20

4 Projektergebnisse ...... 22 4.1 Weboberfläche ...... 22 4.2 Qualitätssicherung ...... 22 4.3 Übergabe des Projektes ...... 23 4.4 Ist/Soll-Vergleich ...... 23 4.4.1 Realisierte Ziele ...... 23 4.4.2 Abweichungen vom Zeitplan ...... 23 4.5 Ausblick ...... 23

5 Literaturverzeichnis ...... 24

6 Anhang ...... 25 6.1 Anhang 1: Glossar ...... 25 6.2 Anhang 2: Tabellarische Aufführung der zu überwachenden Systeme des FTU ...... 26 6.3 Persönliche Erklärung ...... 30

7 Benutzerdokumentation ...... 1

Typografische Konventionen In diesem Dokument werden folgende typografische Konventionen verwendet:

 Konsolen Befehle, klickbare Elemente und Dateisystempfade sind in nicht proportionaler Schriftart dargestellt.  Programme sind kursiv geschrieben.  Begriffe, die im Glossar (6.1 auf S. 25) erläutert werden, sind mit dem Symbol „“ gekennzeichnet: Beispiel  Auszüge aus Konfigurationen sind in nicht proportionaler Schriftart geschrieben und grau hinterlegt.

iv Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

1 Ausgangssituation

1.1 Projektbeschreibung Das Fortbildungszentrum für Technik und Umwelt (FTU) hat derzeit kein zentrales Monitoring-System zur Überwachung von Netzwerkgeräten und kann deshalb nicht automatisiert über die Verschlechterung eines Systemzustandes informiert werden. Dies geschieht im Moment nur, wenn ein Mitarbeiter die Verschlechterung eines Systems der IT-Abteilung meldet. Das hat einen negativen Einfluss auf die Ausfallzeit und verzögert die Problembehebung.

Durch die Einrichtung eines Monitoring-Systems sollen die Systeme des FTU permanent überwacht und somit frühzeitig die Verschlechterung eines Systemzustands erkannt werden.

Hierfür werden folgende Komponenten benötigt:

 serverbasierte Management-Software Grundsystem  Server-Plugins und Konfigurationsdateien zur speziellen Überwachung diverser lokal installierter Komponenten im Netzwerk  Agenten-Software zur Überwachung der Windows Computer im Institut  Weboberfläche zur Administration der Monitoring Software und Überwachung der Computer Sollte ein Fehler auftreten, werden die entsprechenden Administratoren per E-Mail über die Problematik in Kenntnis gesetzt, wodurch sich Zeit- und Kostenersparnisse ergeben. 1.2 Projektumfeld Das Projekt wird in den Räumlichkeiten des Fortbildungszentrums für Technik und Umwelt durchgeführt, einem Institut mit 34 Mitarbeitern auf dem Campus Nord am Karlsruher Institut für Technologie (KIT).

Das FTU führt als zentrale Fortbildungsstätte am KIT sowohl innerbetrieblich als auch extern für den gesamten europäischen Raum etwa 1.000 Fortbildungs- veranstaltungen mit ca. 12.000 Teilnehmern jährlich in den Fachgebieten „Arbeits- und Gesundheitsschutz“, „Lebensmittel- und Biowissenschaften“, „Informatik“, „Kern- technik und Stilllegung“, „Sprachen“, „Management“, „Strahlenschutz“, „Techno- logien“, „Umwelt“ und „Naturwissenschaften und Technik“ durch (www.fortbildung.kit.edu).

Im Institut befinden sich auf drei Etagen des Gebäudes und in einem separaten Hör- saaltrakt überwiegend strukturiert verkabelt ca. 200 aktive Knoten (Gigabit-Ethernet- Switches, Windows-PCs, Netzwerk-Drucker, NAS, Windows- u. Linux-Server, VMWare Hosts), die in mehrere AD-Domänen und (IP)-Netze, darunter eine DMZ, verteilt sind (s. Abb. 1 auf S. 5).

Julian Merkel 1 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Die IT-Infrastruktur des Fortbildungszentrums für Technik und Umwelt wird von Dipl.- Inform. Torsten Neck, Siegfried Wünstel, Bernd Thomas, Moritz Welsch (Auszu- bildender) und mir, Julian Merkel (Auszubildender), betreut.

Für das Monitoring-System wird eine virtuelle Maschine auf einem bereits vorhandenen VMWare ESXi-Server eingerichtet. 1.3 Kundenwünsche Der Kunde hat den Wunsch, die aktiven Knoten im IP-Netz 141.52.80.0/24 (Instituts- netz, militarisierte Zone) und 141.52.251.192/26 (Schulungsnetz, DMZ) und die unterschiedlichen, darauf laufenden Dienste zu überwachen. So soll permanent geprüft werden, ob die relevanten Systeme des FTU einwandfrei funktionieren und mit dem Netzwerk verbunden sind. Zusätzlich ist es wichtig, dass ausgewählte Dienste wie die Web-Services des Fortbildungszentrums und die benötigten Netzwerkspeicher der Mitarbeiter auf Verfügbarkeit überwacht werden.

Alle überwachten Systeme und Dienste müssen zentral einsehbar sein und bei negativen Vorkommnissen sollen E-Mail-Benachrichtigungen an die dafür zuständigen Mitarbeiter versendet werden. 1.4 Teilaufgaben Aus den Kundenwünschen ergeben sich folgende primäre Teilaufgaben für das Projekt:

 Analyse: Inventur der vorhandenen Netze und Sammlung der spezifischen Anfor- derungen  Systemkonzept: Entwicklung eines Lösungskonzepts und Planung der dafür benötigten Ressourcen und der Realisierung  Realisierung: Installation, Konfiguration und Inbetriebnahme der Monitoring- Lösung  Kontrolle: Probebetrieb, Simulation von Fehlerszenarien und Lösung von aufgetretenen Problemen  Inbetriebnahme: Übergabe der Monitoring-Lösung und Schulung der Mitarbeiter 1.5 Prozessschnittstellen Technisch habe ich auf alle in Frage kommenden Systeme Zugriff über das Netzwerk und entsprechende, administrative Funktionsaccounts, darüber hinaus kann ich mittels eines verfügbaren Zentralschlüssels physisch auf Systeme zugreifen.

Organisatorisch muss ich vor einem ggf. erforderlichen Zugriff auf persönliche Geräte von Mitarbeitern diese informieren bzw. bei zentralen Geräten (Switches, Server, Präsentationsrechner in den Vortragsräumen) eine geeignete Zeit in unserem Veranstaltungsmanagementsystem „SAP-LSO“ ermitteln und mit Auftraggeber und Ausbilder abstimmen.

2 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Grundsätzlich sind letztgenannte Personen auch meine direkten Ansprechpartner bei Fragen, Festlegungen (IP-Vergabe, DNS-Einträge, Nomenklatur) und für mittelbare Beauftragungen z.B. unseres Rechenzentrums (Tabelle 1, S. 3).

Tabelle 1 – personelle Schnittstellen

Schnittstellen Name Funktion Auftraggeber Dipl.-Inform. Torsten Neck Leiter des Fachbereichs Tel.: (0721) 608 24421 Informatik am FTU und E-Mail: [email protected] Projektverantwortlicher Ausbilder Siegfried Wünstel Verantwortlicher Technik Tel.: (0721) 608 23203 E-Mail: [email protected]

1.6 Ist-Analyse Die Systeme des Fortbildungszentrums für Technik und Umwelt sind derzeit nicht systemgestützt und zentral überwacht, wodurch sich ihr Zustand nur am jeweiligen Gerät einsehen lässt. Da die Netzwerkknoten nur durch den jeweiligen Nutzer über- wacht werden, können etwaige Fehler erst spät erkannt und nur selten im Voraus behoben werden. Die zu überwachenden Systeme befinden sich im IP-Netz 141.52.80.0/24 und die meisten Windows-Rechner davon sind Mitglieder der Domäne kit.edu. Zusätzlich sollen die Systeme der demilitarisierten Zone (DMZ) im IP-Netz 141.52.251.192/26 überwacht werden, wovon die meisten Windows- Rechner der Domäne DMZFTU angehören.

Für die Verwaltung und Administration der Netzwerke und der einzelnen Systeme sind die auf S. 2 genannten fünf Mitarbeiter der Stabsstelle IT zuständig. Die informa- tionstechnischen Kenntnisse der restlichen Mitarbeiter sind für solche Aufgaben unzureichend.

2 Ressourcen- und Ablaufplanung

2.1 Soll-Konzept Nach Absprache mit Herrn Neck wird die Monitoring Lösung die Subnetze 141.52.80.0/24 (militarisierte Zone, FTU-Intranet) und 141.52.251.192/26 (DMZ des FTU) betrachten (s. wiederum Abbildung 1 auf S. 5).

Die Netzstruktur erfordert dabei insofern besondere Aufmerksamkeit, als zwar ungehindert aus allen Subnetzen auf die FTU-DMZ zugegriffen werden kann, auf das FTU-Intranet jedoch nur aus diesem Subnetz selbst.

Folglich muss der Monitoring-Server im Subnetz 141.52.80.0/24 platziert werden und wird als virtuelle Maschine auf dem bereits vorhandenen VM-Ware ESXi-Server 141.52.80.33 mit folgenden Parametern aufgesetzt:

Julian Merkel 3 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

 2 vCPUs  32 GB Festplatte  2 GB Arbeitsspeicher  CD-/DVD-Laufwerk  Gigabit-Ethernet Netzwerkkarte Der Server erhält den Hostnamen „FTU-MONITOR.ftu.kit.edu“ und die IP-Adresse 141.52.80.35. Die benötigten Einträge für den DNS-Server des Instituts werden von Herrn Neck angelegt.

Da für die Monitoring-Lösung keine Lizenz-Kosten anfallen sollen, wird hierfür auf eine Open Source Lösung und ein Linux basiertes Betriebssystem zurückgegriffen.

Die Monitoring-Lösung soll den Mitarbeitern der Stabsstelle IT eine zentralisierte und webbasierte Übersicht der Zustände aller überwachten Systeme liefern.

Beim Eintreten von Verschlechterungen über gruppen- oder systemspezifisch festzulegende Schwellwerte sollen E-Mail Benachrichtigungen an festzulegende, zuständige Personen gesendet werden.

Folgende Überprüfungen werden für die Überwachung systemabhängig für die verschiedenen Geräte benötigt: Schwellwert Benachrichtigung an

 Ping Erreichbarkeit aller Systeme Ausfall > 60 sec IT  Windows und Linux Systeme  Festplattenbelegung Freier Platz < 1 GB Benutzer und IT  Arbeitsspeicherbelegung IT  Prozessor Auslastung  Drucker  Toner Füllstand Rest < 5% Bernd Thomas  Fächer Füllstand Rest = 0 Bernd Thomas  SNMP Status IT  Webserver  HTTP Erreichbarkeit Ausfall > 60 sec IT  NAS  SMB Dateifreigaben Ausfall > 60 sec IT  Synology Warnings, Errors IT Statusabfragen  Quota 1 GB unter Limit Benutzer

Die flexible Anpassbarkeit und Erweiterbarkeit der Systemabfragen soll gewährleistet werden.

Zum Abschluss soll im Auftrag von Herrn Neck noch eine Schulung für die Stabs- stelle IT stattfinden, welche den Umgang mit der Monitoring-Lösung veranschaulicht.

4 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

2.2 Personalplanung Wie bereits bei der Beschreibung der Schnittstellen (1.5, S. 2) ausgeführt, kann ich den größten Teil der Tätigkeiten allein und unabhängig durchführen. Lediglich für einzelne Vorgänge benötige ich das Zutun von Herrn Neck und Herrn Wünstel (Tabelle 2):

Tabelle 2 – Personalplanung

Name: Vorname: Abteilung: Tätigkeit: Zeitaufwand: Merkel Julian FTU-IT Projektumsetzung 35 Stunden Neck Torsten FTU-IT Projektunterstützung 2 Stunden Wünstel Siegfried FTU-IT Projektunterstützung 2 Stunden 2.3 Sachmittelplanung Für die Installation der Monitoring-Software ist eine virtuelle Maschine auf dem ESXi- Server mit der IP-Adresse 141.52.80.33 vorgegeben (Tabelle 3).

Tabelle 3 – Sachmittelplanung, Hardware

Hardware: Beschreibung: Server zur Installation der Monitoring-Software (vorkonfigurierte virtuelle Maschine auf dem Server 141.52.80.33, wie in 2.1 auf S. 3 spezifiziert)

KIT-Netz

Abbildung 1 – Netzwerkstruktur des FTU

Wie bereits erklärt, wird das Monitoring-System im IP-Netz 141.52.80.0/24 realisiert, da nur so sowohl das IP-Subnetz 141.52.80.0/24 (Betriebsnetz FTU) als auch das Subnetz 141.52.251.192/26 (DMZ) überwacht werden kann. Verbindungen aus der

Julian Merkel 5 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

DMZ sind in die militarisierte Zone nicht möglich, da die Pakete mit einer dazwischenliegenden Firewall gefiltert werden. Zur Veranschaulichung der netzwerklichen Gegebenheiten dient Abbildung 1 – Netzwerkstruktur des FTU. Der Monitoring Server benötigt ein Betriebssystem und eine Monitoring Software. Für die benötigte Software sollen keine Kosten anfallen (Tabelle 4).

Tabelle 4 – Sachmittelplanung, Software

Software: Beschreibung: Betriebssystem Grundsystem der Monitoring-Software Open Source Monitoring Software Software zur Überwachung der Systeme Für die Durchführung des Projektes benötigte ich außer meiner Arbeitsstation am Arbeitsplatz keine weiteren Sachmittel. 2.4 Terminplanung Durch die Rahmenbedingungen und den Besuch der Berufsschule findet die Durch- führung des Projekts in der Woche vom 18.04.2016 zum 22.04.2016 statt und soll den Zeitaufwand von 35 Stunden nicht überschreiten. Ich bin während der Projekt- durchführung weitestgehend vom Alltagsgeschäft entbunden. Am KIT beträgt die Arbeitszeit der Auszubildenden 39,5 Stunden pro Woche. Da dies den geplanten Zeitaufwand von 35 Stunden um 4,9 Stunden überschreitet, stehen mir für das Projekt arbeitstäglich 7 Stunden zur Verfügung und auch für unvorhergesehene, wichtige Tätigkeiten ist Pufferzeit vorhanden (siehe Tabelle 5 – Terminplanung).

Tabelle 5 - Terminplanung

Vorgang Zeitaufwand Anfang Ende Planungsphase Ist-Analyse 2.5 Std. 18.04.2016 18.04.2016 Soll-Konzept 3,5 Std. 18.04.2016 18.04.2016 Personalplanung 0,5 Std. 18.04.2016 18.04.2016 Sachmittelplanung 2,0 Std. 18.04.2016 19.04.2016 Kostenplanung 0,5 Std. 19.04.2016 19.04.2016 Durchführungsphase Systeme und Netze einteilen 2,0 Std. 19.04.2016 19.04.2016 Beschaffung der Software 1,0 Std. 19.04.2016 19.04.2016 Installation des Grundsystems 1,0 Std. 19.04.2016 19.04.2016 Installation und Konfiguration der Monitoring- 5,0 Std. 19.04.2016 20.04.2016 Software Festlegen von Info-/Alarm- und Benachrichti- 2,0 Std. 20.04.2016 20.04.2016 gungsketten Begleitende Funktionstests 1,0 Std. 20.04.2016 20.04.2016 Qualitätssicherung 4,0 Std. 21.04.2016 21.04.2016 Projektabschluss Dokumentation 8,0 Std. 21.04.2016 22.04.2016 Übergabe und Mitarbeitereinweisung 2,0 Std. 22.04.2016 22.04.2016

6 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

2.5 Kostenplanung 2.5.1 Hardwarekosten Die Monitoring Software wird auf einer virtuellen Maschine installiert, welche sich auf einem bereits betriebswirtschaftlich abgeschriebenen VMWare ESXi-Server befindet. Aufgrund dessen fallen für die Hardware keine Investitionskosten an. Betriebskosten wie Strom, Belastung des Servers durch die virtuelle Maschine und Wartung werden vom Institut nicht auf die Verbraucher umgelegt.

2.5.2 Softwarekosten Die zu verwendende Software, Check_MK, wurde unter der GNU GPL Version 2 und etlichen anderen Open-Source-Lizenzen veröffentlicht und ist daher kostenfrei. Somit fallen auch für die Software keine Kosten an.

2.5.3 Personalkosten Es sind für den Projektverantwortlichen (Julian Merkel) 35 Stunden zu einem Stun- densatz von 35 € zu berechnen: 1.225 €.

Für die Unterstützung durch Kollegen entstehen zusätzliche Kosten. Diese wurden mit 110 € pro Stunde berechnet: 2 · 2 Stunden · 110 €/Stunde = 440 €.

2.5.4 Gesamtkosten Tabelle 6 - Kostenplanung / Gesamtkosten

Beschreibung Kosten Hardwarekosten 0 Euro Softwarekosten 0 Euro Personalkosten 1.665 Euro Summe 1.665 Euro 2.6 Ablaufplan

Julian Merkel 7 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

3 Durchführung und Auftragsbearbeitung

3.1 Auswahl eines Monitoring Systems Für die Auswahl der Monitoring Software werden Nagios und Check_MK verglichen. Das Check_MK Monitoring System ist eine Software-Lösung, die um den Nagios- Kern entwickelt wurde, weshalb sich beide Kandidaten in ihren Grundeigenschaften sehr ähnlich sind.

3.1.1 Nagios Nagios ist eine Software zum Überwachen komplexer IT-Infrastrukturen. Hierfür bietet Nagios eine Sammlung von Modulen zur Überwachung von Netzwerken, Hosts und speziellen Diensten sowie eine Web-Schnittstelle zum Visualisieren der gesammelten Daten. Nagios läuft unter zahlreichen Unix-ähnlichen Betriebssystemen und steht unter der GNU GPL. Dies bedeutet, dass es de facto eine freie Software ist. Die Monitoring-Software basiert auf einem Hauptprogramm, welches mit Plugins Überprüfungen (Checks) durchführt und somit Statusinformationen über vorkonfigurierte Hosts registriert. Da Nagios auf externe Programme bzw. Scripts für Überprüfungen der Systeme zurückgreift, ist diese Monitoring-Lösung grenzenlos erweiterbar. Die Schwächen von Nagios liegen in seinem Web-Interface und der Konfiguration. Im Web-Interface kann lediglich der Status der vorkonfigurierten Systeme eingesehen werden, jedoch können keine Konfigurationen vorgenommen werden. Die Konfiguration der zu überwachenden Systeme findet auf Dateisystemebene in Konfigurations-Dateien statt. Bei größeren Änderungen und vielen davon betroffenen Systemen führt dies jedoch schnell zu Un- übersichtlichkeit und Verwirrung.

3.1.2 Check_MK Das Check_MK Monitoring System ist eine rund um den bewährten Nagios-Kern ent- wickelte Open-Source-Lösung zum IT-Monitoring. Die Software ermöglicht das pro- fessionelle Überwachen von Anwendung, Betriebssystem, Hardware, Netzwerk und Rechenzentrum. Zudem werden Kenndaten erfasst und über Jahre aufgezeichnet, was statistische Analysen und Prognosen ermöglicht. Durch die Architektur der beiden Open-Source-Projekte Check_MK und OMD (Open Monitoring Distribution) bietet es gegenüber anderen Nagios-basierten Lösungen mehrere Vorteile. Check_MK bietet eine regelbasierte, hierarchische Konfiguration, eine hohe Performance durch passive Überprüfungen und über 600 mitgelieferte Checks für die Überwachung verschiedenster Systeme und eine eigene Client-Software zur Über- wachung von Windows- und Unix Clients. Im Gegensatz zu Nagios kann die kom- plette Host-Konfiguration von Check_MK im Webinterface stattfinden und ist somit auch für unerfahrene Benutzer einfach zu bedienen. Check_MK wurde unter der GNU GPL Version 2 und etlichen anderen Open-Source-Lizenzen veröffentlicht und ist daher kostenfrei.

8 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

3.1.3 Bewertung und Systemauswahl Mit einer einfachen Punktebewertung werden die zwei Softwarelösungen verglichen. Hierfür werden einzelne Kriterien bewertet, welche auf eigener Erfahrung und Re- cherchen im Internet basieren. Die einzelnen Kriterien werden mit einer Punktzahl von 1 bis 5 bewertet, wobei 1 die niedrigste (ungeeignetste) und 5 die höchste (best geeignete) darstellt. Die einzelnen Kriterien werden gleich gewichtet (Tabelle 9 – Punktebewertung der Monitoring Systeme).

Tabelle 7 – Punktebewertung der Monitoring Systeme

Kriterium Nagios Check_MK Installationsaufwand 3 5 Konfigurationsaufwand 3 5 Systemanforderungen 3 4 Performance 4 5 Erweiterbarkeit 4 5 Gesamt 17 24 Aufgrund des Ergebnisses der Punktebewertung wird das Projekt mit dem Open Source Monitoring System Check_MK durchgeführt.

Check_MK bietet zudem durch seine automatisierte Installation und webbasierte Konfiguration einen zeitlichen Vorteil. Durch Check_MK wird die Konfiguration erheb- lich verbessert, da sie graphisch vorgenommen wird und bei Änderungen Abhängig- keiten zu anderen Konfigurationselementen berücksichtigt. Zudem ist Check_MK mit über 600 mitgelieferter Checks erweitert, was die Funktionalität weiter verbessert. 3.2 Inventur der vorhandenen Systeme und Netze Bevor mit der Installation und Konfiguration des Monitoring-Systems begonnen wird, werden die in einer Inventur ermittelten Systeme in verschiedene Gruppen eingeteilt. Dazu werden anhand einer bereits vorhandenen Liste (Anhang 1: Tabellarische Auf- führung der zu überwachenden Systeme des FTU, S. 25) die Systeme in folgende Gruppen sortiert:

Tabelle 8 – Systemgruppen

Gruppen Name Überwachungsdienste Windows_Server Ping, Check_MK Agent Windows_Client Ping, Check_MK Agent Linux_Server Ping, Check_MK Agent SIP Ping Synology_Server Ping, Check_Synology_NAS Drucker Ping, Toner, Papier, Status Auch die Zuweisung der Systeme zu den Gruppen und Überwachungsdiensten ist in der Übersicht in Anhang 1: Tabellarische Aufführung der zu überwachenden Systeme des FTU, S. 25 gelistet.

Julian Merkel 9 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

3.3 Beschaffung der benötigten Software Die benötigte Software wurde aus dem Internet heruntergeladen und bis zur Weiter- verwendung auf meinem Arbeitscomputer gespeichert.

3.3.1 Ubuntu Server – Grundsystem Als Grundsystem verwende ich Ubuntu Server 14.04.4 LTS, da dies die Langzeit- support-Version von Ubuntu ist, die Sicherheitsupdates bis April 2019 garantiert.

Ubuntu Server ist unter der Adresse http://www.ubuntu.com/download/server zum Download erhältlich. Die Version 14.04.4 LTS, welche in meinem Projekt verwendet wird, ist unter folgendem Link als ISO-Abbild erhältlich. http://www.ubuntu.com/download/server/thank- you?country=DE&version=14.04.4&architecture=amd64

3.3.2 Check_MK – Monitoring Software Check_MK ist unter der Adresse https://mathias-kettner.de/check_mk_download.php zum Download erhältlich. Die aktuell stabile Version, 1.2.6 (stable), wird in meinem Projekt verwendet. Diese ist unter dem Link https://mathias- kettner.de/support/1.2.6p16/check-mk-raw-1.2.6p16_0.trusty_amd64.deb als ISO- Abbild zum Download erhältlich.

Da Check_MK bereits über 1000 mitgelieferte Check-Plugins verfügt, müssen zur Überwachung der speziellen Systeme, wie zum Beispiel der Drucker und Synology Diskstations zunächst keine Plugins heruntergeladen werden.

Die Windows- und Linuxserver werden mithilfe des von Check_MK zur Verfügung gestellten Monitoring Agents überwacht. Dieser kann nach Installation- und Konfigu- ration der Monitoring-Software über das Webinterface von Check_MK heruntergeladen werden.

3.3.3 Zusätzliche Software Um auf den Server zuzugreifen, verwendete ich zusätzlich zur benötigten Software verschiedene Softwarepakete. Diese waren bereits auf meinem Arbeitscomputer installiert, weshalb ich nicht genauer auf die Beschaffung der Programme eingehen werde. Alle Programme, die hier aufgeführt sind, sind kostenfrei erhältlich. Auf eine detaillierte Beschreibung der Programme wird verzichtet, da die Bedienung dieser Softwarepakete nicht für die Durchführung des Projektes relevant ist.

 Google Chrome: Zur Beschaffung der Software und Verwendung der Web- oberfläche von Check_MK wird ein beliebiger Internetbrowser benötigt. Hierzu verwende ich Google Chrome, Version 49.  VMware vSphere Client: Windows-Anwendung, welche den Zugang zu den Ressourcen eines ESXi-Servers ermöglicht. Sie wird zur Verwaltung von virtuellen Maschinen auf einem ESXi-Server benötigt.

10 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

 PuTTY: Software zum Herstellen von Verbindungen über SSH. Hiermit wird u. a. eine SSH-Verbindung zum Monitoring-Server mit der IP 141.52.80.35 (FTU- MONITOR) hergestellt.  FileZilla: Hiermit können Dateien über das SFTP-Protokoll auf den Monitoring- Server übertragen werden.

3.4 Installation und Konfiguration des Monitoring-Servers Mit dem VMware vSphere Client wurde eine Verbindung zum ESXi Server 141.52.80.33 hergestellt.

Um das Grundsystem auf der virtuellen Maschine zu installieren, wurde das ISO-Ab- bild von Ubuntu auf den ESXi Server 141.52.80.33 hochgeladen, das Abbild als virtuelles CD-ROM in die vorbereitete virtuelle Maschine eingebunden und diese gestartet.

Daraufhin folgte eine für Linux übliche, graphische Installation mit Schritten wie Aus- wahl der Systemsprache, Tastaturkonfiguration, Netzwerkkonfiguration, Zeitkonfigu- ration, Partitionierung der Festplatten sowie das Kopieren der Dateien und die Instal- lation des Systems.

Dabei wurde der Benutzer administrator mit dem Passwort roofracket eingerichtet.

Während der Installation öffnete sich die Auswahl der zu installierenden Standard- Software. In diesem graphischen Konfigurations-Tool wurden folgende Anwen- dungen zur Installation konfiguriert:

 OpenSSH server (Zum Zugriff auf den Server via PuTTY über das SSH Protokoll) Dem Server wurde vom DHCP-Server automatisch eine vordefinierte IP-Adresse vergeben. Dazu trug Herr Neck die Hardware-Adresse des Netzwerkadapters als Reservierung für die IP-Adresse 141.52.80.35 in der Konfiguration des DHCP- Servers ein.

Durch die Installation des OpenSSH Servers ist die Maschine über SSH erreichbar. Eine Überprüfung des Zugangs mit der Anwendung PuTTY erfolgte ohne Probleme. Zur weiteren Konfiguration des Servers wurde PuTTY verwendet.

Zur Sicherstellung, dass alle Softwarepakete auf dem aktuellen Stand sind, wurden noch Updates installiert. Die Aktualisierung des Systems verlief erfolgreich. 3.5 Installation der Monitoring-Software 3.5.1 Kopieren des benötigten Pakets Um die Monitoring-Software Check_MK installieren zu können, wurde das bereits heruntergeladene Softwarepaket check-mk-raw-1.2.6p16_0.trusty_amd64.deb benötigt. Dazu wurde mit FileZilla eine SFTP-Verbindung zum Server FTU-Monitor

Julian Merkel 11 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU aufgebaut. Nun wurde die zuvor heruntergeladene Datei check-mk-raw- 1.2.6p16_0.trusty_amd64.deb in das Home-Verzeichnis /home/administrator auf 141.52.80.35 kopiert (Abbildung 2).

Abbildung 2 - SFTP Verbindung mit FileZilla

3.5.2 Installation des Paketes Zur Installation von Check_MK wurde zunächst das Paket gdebi-core benötigt. Dies wurde mit dem Befehl sudo apt-get install gdebi-core installiert.

Das zur Installation benötigte Paket check-mk-raw- 1.2.6p16_0.trusty_amd64.deb wurde nun mit dem Befehl sudo gdebi check-mk-raw-1.2.6p16_0.trusty_amd64.deb installiert. Während der Installation wurde gefragt, ob das Anwendungspaket installiert werden soll. Dies wurde mit j bestätigt. Die Installation erfolgte nun bis zur Fertigstellung automatisch und ohne Zwischeneingaben.

Nachdem die Installation von Check_MK und allen Abhängigkeiten erfolgreich war, steht der Befehl omd zur Verfügung, welcher das Konfigurieren des Monitoring- Systems ermöglicht. Zur Kontrolle wurde mit dem Befehl omd version die aktuell installierte Version ausgegeben. 3.6 Konfiguration der Monitoring-Software 3.6.1 Lokal Check_MK, das Monitoring-System, baut auf der Open Monitoring Distribution (OMD) auf. Dies ist ein Open-Source-Projekt, welches von Mathias Kettner gegrün- det wurde und sich um die komfortable und flexible Installation einer Monitoring- Lösung aus diversen Komponenten dreht. OMD-basierte Installationen zeichnen sie aus durch:

 Einheitliche Dateipfade – egal welche Linux-Plattform eingesetzt wird  Installation ohne Abhängigkeit von Drittsoftware

12 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

 Vorkonfiguration aller Komponenten Um Systeme zu überwachen, musste zunächst eine Instanz erzeugt werden. OMD (die Monitor-Distribution) unterstützt mehrere Nagios Instanzen, die aber separat verwaltet werden. Dies ermöglicht zum Beispiel eine Instanz für die produktive Nutzung und eine Testumgebung. Eine Instanz hat einen eindeutigen Namen, der beim Anlegen festgelegt wird. Gleichzeitig wird auf dem Server ein lokaler Benutzer mit dem Namen der Instanz angelegt.

Die Instanz wurde mit dem Befehl sudo omd create ftu und der Authentifi- zierung mit dem Nutzer administrator angelegt.

Während des Anlegens der Instanz geschah folgendes:

 Ein Betriebssystembenutzer ftu und eine Gruppe ftu wurden angelegt  Dessen neues Homeverzeichnis /omd/sites/ftu wurde angelegt und diesem übereignet  Homeverzeichnis wurde mit Konfigurationsdateien und Verzeichnissen befüllt  Grundkonfiguration für die neue Instanz wurde erstellt Die weitere Verwaltung der Instanz erfolgte mit den Rechten des neu angelegten Be- nutzers. Dazu wurde der Benutzer mit dem Befehl su - ftu gewechselt und die Instanz ftu mit dem Befehl omd start als Instanz-Benutzer ftu gestartet.

Mit dem Befehl omd status wurde der Zustand der Instanz überprüft, welcher zeigte, dass alle Dienste gestartet sind. Auch bei mehrmaligen Neustart der Instanz gab es keine Fehler (Abbildung 3).

Abbildung 3 - Check_MK Instanz Status

Die Überprüfung der HTTP-Verbindung zu http://ftu-monitor/ftu/ mit Google Chrome war auch erfolgreich.

3.6.2 Remote Nachdem Check_MK installiert und eine Instanz eingerichtet war, konnte die Anmeldung an der Weboberfläche stattfinden. Die Anmeldung erfolgte per Browser an http://ftu-monitor/ftu/ mit dem Standardbenutzernamen omdadmin und dem Pass- wort omd (Abbildung 4).

Julian Merkel 13 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Abbildung 4 - Check_MK Anmeldung an der Oberfläche

Vor den ersten Konfigurationsschritten wurde aus Sicherheitsgründen das Check_MK Administratoren Passwort in roofracket geändert.

3.7 Inventur und Einpflegen der zu überwachenden Systeme 3.7.1 Server und Netzwerkgeräte aufnehmen Nachdem die Authentifizierung mit der Instanz erfolgreich war, wurden die einzelnen Hosts, die zuvor in einer Tabelle (S. 25) inventarisiert wurden, in das Monitoring- System aufgenommen. Dafür waren für die verschiedenen Systeme folgende Schritte notwendig.

3.7.2 Monitoring-Agent auf dem Monitoring-Server installieren Als erstes System wurde das Monitoring-System selbst in die Überwachung aufgenommen. Dazu musste unter der Seite Monitoring Agents im Element WATO – Configuration in der Seitenleiste das Paket check-mk-agent_1.2.6p16- 1_all.deb unter Packed Agents für die Distribution Linux heruntergeladen werden.

Um den Monitoring Agent zu installieren, wurde das bereits heruntergeladene Softwarepaket check-mk-agent_1.2.6p16-1_all.deb benötigt. Dazu wurde mit FileZilla eine SFTP-Verbindung zum Server FTU-Monitor aufgebaut und die zuvor heruntergeladene Datei check-mk-agent_1.2.6p16-1_all.deb in das Home-Verzeichnis /home/administrator auf 141.52.80.35 kopiert.

Der Check_MK Agent wurden in der Konsole mit dem Befehl sudo gdebi check- mk-agent_1.2.6p16-1_all.deb installiert.

3.7.3 Monitoring-Server überwachen Um die zu überwachenden Server und Geräte zu verwalten, wurde auf den Punkt Hosts navigiert. Hier wurde mit klicken auf Create new host ein neuer Host angelegt.

Der Monitoring Server wurde nun mit folgenden Eigenschaften hinzugefügt.

14 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

 Hostname: localhost Mit dem Klick auf Save & go to Services wurde der Host angelegt.

Nachdem die verfügbaren Dienste des Servers automatisch erkannt waren, wurden diese mit einem Klick auf Save manual check configuration gespeichert. Auf der darauf folgenden Bildschirmseite musste auf den orangen Knopf 2 Changes geklickt werden, um dort mit Activate Changes! die Änderungen zu aktivieren und die Überwachung zu starten. Ab diesem Zeitpunkt wird der Server mit Standard- einstellungen überwacht (Abbildung 5).

Abbildung 5 - Check_MK Überwachte Dienste des Monitoring Servers

3.7.4 Weitere Server und Netzwerkgeräte aufnehmen Auf die gleiche Weise wurden weitere Geräte in die Überwachung aufgenommen, jedoch waren für folgende Systeme zusätzliche Schritte notwendig.

3.7.4.1 Windows-Systeme Zur Überwachung der Windows-Systeme wurde der Check_MK Agent für Windows installiert. Er ist so wie auch der Linux Agent unter dem Menüpunkt Host Agents in der Seitenleiste des Webinterfaces verfügbar.

Mit folgendem Script wurde der Agent an alle Windows-Stationen am Fortbildungs- zentrum verteilt.

@echo off cd %LocalAppData% mkdir check_mk cd check_mk copy "\\ftudmz-nas\software\DMZFTU\DeskSave\check_mk_agent.exe" %LocalAppData%\check_mk\check_mk_agent.exe" C:\check_mk\check_mk_agent.exe install net start check_mk_agent

Julian Merkel 15 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Dazu wurde das Script auf einen für alle verfügbaren Netzwerkspeicher abgelegt und über ein Gruppenrichtlinienobjekt automatisiert beim Anmelden des Benutzers gestartet. Seit Windows 2000 Server können Gruppenrichtlinien über die Konsole „Active Directory Benutzer und Computer“ erstellt und konfiguriert werden. Die erstellten Gruppenrichtlinienobjekte können mit bestimmten Organisationseinheiten verknüpft werden, sodass diese auf die Computer oder Benutzer angewendet werden.

3.7.4.2 SNMP-Systeme Das Simple Network Management Protocol (SNMP) ist ein Netzwerkprotokoll um Netzwerksysteme (z.B. Router, Server, Switches, Drucker, Computer, usw.) von einer zentralen Station (Monitoring-Server) überwachen und steuern zu können. Durch die einfache Verwendung und Vielseitigkeit hat sich SNMP zum Standard entwickelt, der von den meisten Managementprogrammen sowie von Endgeräten unterstützt wird.

Zur Überwachung der SNMP-Systeme wurde bei der Konfiguration des Hosts im Kasten Host Tags bei Agent Type die Einstellung SNMP (Networking Device, Appliance) ausgewählt. Die entsprechende SNMP Community wurde ebenfalls eingetragen.

3.7.5 Hostgroups anlegen und Systeme einordnen Nachdem der Einbindung der Hosts in Check_MK wurden diese zur Übersicht in verschiedene Hostgroups sortiert. Dazu wurden in der Konfiguration unter Hosts mehrere Ordner erstellt, welche einer Hostgroup zugeordnet wurden. Die dafür vorgesehenen Gruppen wurden bereits bei der Inventur der vorhandenen Systeme und Netze festgelegt (S. 9).

Um eine Hostgruppe hinzuzufügen, klickt man in der Seitenleiste unter WATO – Configuration auf den Link Host & Service Groups und legt dort die Gruppen mit dem Button New host group an.

Folgende Eigenschaften mussten beim Erstellen der Hostgruppen festgelegt werden:

 Name  Name der Hostgruppe (z.B. Windows_Client)  Alias  Bezeichnung der Hostgruppe (z.B. Windows Arbeitsstationen) Um den erstellten Hostgruppen die Hosts zuzuweisen, wurden im Menüpunkt Hosts Unterordner erstellt, welche die entsprechende Hostgruppe zuweisen. Es wurden folgende Ordner erstellt:

 Drucker  Linux_Server  Synology_Server  SIP

16 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

 Windows_Client  Windows_Server  Switch Für jeden Ordner können Eigenschaften festgelegt werden, die jedoch auch für jeden Host individuell anpassbar sind (Tabelle 9).

Tabelle 9 – verfügbare Ordnereigenschaften

Einstellung Wert Permissions Berechtigungen der Konfiguration für Benutzer SNMP Community SNMP Kennwort zum Zugriff über SNMP Parents Nächster Host für Wegberechnung (z.B. Switch) Agent type Check_MK Agent, SNMP oder No Agent (Ping) Criticality Produktivsystem, Geschäftskritisches System, Testsystem, keine Überwachung Networking Segment Local network (niedrige Latenz), WAN (hohe Latenz), DMZ (niedrige Latenz, sicherer Zugriff)

3.7.6 Info-/Alarm- und Benachrichtigungsketten Um bei Verschlechterungen eines Systems benachrichtigt zu werden, wurden in der Konfiguration Benachrichtigungsregeln festgelegt.

3.7.6.1 Installation des Mailservers Dazu wurde zunächst der Mailserver postfix in einer SSH-Sitzung auf dem Moni- toring Server installiert. Mit dem Befehl sudo tasksel wurde also die Paket- konfiguration von Ubuntu geöffnet und darin der Mail Server ausgewählt und installiert.

Während dieser Installation musste der SMTP-Relay-Server smarthost.kit.edu eingetragen werden, da aus Sicherheitsgründen nur über diesen Ausgang E-Mails aus dem Netzwerk des KIT versendet werden können.

Die Installation des Mailservers verlief erfolgreich. Mit dem Befehl echo Dies ist ein Funktionstest des Mailservers | mail –s „Funktionstest“ [email protected] überprüfte ich, ob ausgehende E-Mails empfangen werden. Der Test verlief erfolgreich und die E-Mail wurde empfangen (Abbildung 6).

Abbildung 6 - Postfix Testmail

Julian Merkel 17 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

3.7.6.2 Kontaktgruppe anlegen Nach der Konfigurierung des Mailservers wurde auf der Check_MK Weboberfläche eine Kontaktgruppe mit dem Namen FTU-IT angelegt. Dieser Gruppe wurde ein Be- nutzer namens FTU-IT zugewiesen.

Die Erstellung einer Kontaktgruppe erfordert die Eingabe folgende Eigenschaften:

 Name: Name der Kontaktgruppe (z.B. FTU-IT)  Alias: IT-Abteilung FTU

3.7.6.3 Benutzer anlegen Um der Kontaktgruppe Empfänger zuzuweisen, wurde im Menüpunkt Users ein Benutzer mit dem Namen FTU-IT und dem Passwort roofracket angelegt. Diesem Nutzer wurden folgende Eigenschaften zugewiesen:

 Username: ftu-it  Full name: IT-Abteilung FTU  Email address: [email protected]  Password: roofracket  Roles: Administrator  Contact Groups: IT-Abteliung FTU  Start-URL: dashboard.py (Startseite der Check_MK Weboberfläche) Damit dieser nun über Zustandsänderungen der Systeme informiert wird, musste die Kontaktgruppe IT-Abteilung FTU den Hosts als Kontaktgruppe zugeordnet werden. Da die E-Mail Adresse [email protected] ein Verteiler auf dem zentralen Exchange-Cluster des KIT ist, der die E-Mail an alle Mitarbeiter der Stabstelle IT weiterleitet, musste lediglich ein Benutzer unter WATO – Configuration  Users auf der Weboberfläche angelegt werden.

3.7.6.4 Zuweisung der Kontaktgruppe zu den Hosts Bei Verschlechterungen von Systemzuständen werden die Kontakte benachrichtigt, die einem Host zugewiesen sind. Initial wurde allen Hosts die Kontaktgruppe IT- Abteilung FTU zugewiesen.

Folgende Optionen wurden konfiguriert:

 Folder: Main directory (Hauptverzeichnis)  Kontaktgruppe: IT-Abteilung FTU  Kommentar: Weist allen Hosts die Kontaktgruppe IT-Abteilung FTU zu

3.7.6.5 Benachrichtigungen konfigurieren Da die zu versendeten E-Mail Adressen einem bestimmten Muster entsprechen sollen, wurden die globalen Benachrichtigungsregeln konfiguriert. Dazu wurde die bereits existierende Standardregel um folgende Konfiguration erweitert:

18 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

 From: Address | [email protected] | Absenderadresse der Benachrichtigung  Reply-To: Address | [email protected] | E-Mail Adresse einer Antwortnachricht

3.7.6.6 Konfiguration überprüfen Um zu testen, ob die E-Mail Benachrichtigung bei Ausfall eines Hosts funktioniert, wurde das Netzwerkkabel des Fileservers FTU-Daten kurzzeitig entfernt. Daraufhin wurde korrekt folgende E-Mail vom Monitoring-Server versendet (Abbildung 7):

Abbildung 7 – Check_MK Benachrichtigungsmail

Die Konfiguration und Überprüfung von Mailserver, Kontaktgruppen, Benutzern und Benachrichtigungen verlief ohne Probleme.

3.7.7 Qualitätssicherung Zur Überprüfung auf Übereinstimmung der geprüften Dienste wurden einzelne Gerät stichprobenartig auf den tatsächlichen Status überprüft. Dazu wurden die Daten auf der Weboberfläche von Check_MK mit denen des jeweiligen Systems verglichen. Die ermittelten Informationen sind korrekt. 3.8 Zusätzliche Serverkonfigurationen 3.8.1 Authentifizierung mit KIT-Account (LDAP-Anbindung) Um das Anlegen von lokalen Benutzern zu vermeiden, wurde eine LDAP-Anbindung an das Benutzerverzeichnis des KIT eingerichtet. Dafür wurde unter dem WATO- Menü Global Settings LDAP unter User Management > Enabled User Connectors aktiviert. Im WATO-Menü Users wurden daraufhin über den Button folgende Einstellungen konfiguriert (Tabelle 10).

Tabelle 10 – LDAP Enstellungen

Option Wert Erklärung LDAP Server kit-ad.scc.kit.edu LDAP-Server des KIT

TCP Port 3269 Port des LDAP-Servers

Julian Merkel 19 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Use SSL Ja Verschlüsselte Verbindung LDAP Version 3 Version des LDAP-Servers Directory Type Active Directory Verzeichnisart Bind Credentials CN=FTU- Benutzername zur Authentifizierung Cloud,OU=DUF,OU=Users,OU=FTU,OU=staff,OU mit dem LDAP-Server =KIT,DC=kit,DC=edu Bind Password Password Passwort zur Authentifizierung mit dem LDAP-Server

User Base DN dc=kit,dc=edu Basisverzeichnis der Benutzer auf dem LDAP-Server

Search Scope Search whole subtree below the base DN Durchsuche alle Unterordner des Basisverzeichnisses Search Filter (&(|(objectclass=person))(|(|(memberof=CN=FTU- Suchfilter: Alle Benutzer der IT,OU=Groups,OU=FTU,OU=Staff,OU=KIT,DC=ki Sicherheitsgruppe FTU-IT t,DC=edu)(primaryGroupID=130391)))) User-ID Attribute mail E-Mail des Benutzers als Benutzername verwenden

3.8.2 Weboberfläche über HTTPS Um schließlich die Verbindung auf die Weboberfläche des Monitoring-Servers abzu- sichern, wurde die Verschlüsselung mit HTTPS eingerichtet. Dazu wurde mit PuTTY eine SSH Verbindung auf den Monitoring-Server aufgebaut und folgende Schritte durchgeführt:

 Zuerst wurde ein selbst-signiertes Zertifikat erstellt, wofür man zunächst einen privaten Schlüssel benötigte. Dieser wurde mit dem Befehl openssl genrsa – out /etc/ssl/private/apache.key 2048 erzeugt. Die Angabe 2048 stellt die Länge des Schlüssels in bit ein.  Da der private Schlüssel nun vorliegt, konnte das eigentliche Zertifikat problemlos erzeugt werden. Dazu wurde das folgende Kommando eingesetzt: openssl req -new -x509 -key /etc/ssl/private/apache.key -days 365 -sha256 -out /etc/ssl/certs/apache.crt (Parameter in Tabelle 11).

Tabelle 11 – Parameter des SSL-Zertifikats

Parameter Bedeutung -days 365 Gültigkeit des Zertifikats -sha256 Signaturalgorithmus für das Zertifikat Nach Eingabe des Befehls wurden noch einige Details zum Inhalt des Zertifikates ab- gefragt. Hier ist der Common Name wichtig, denn hier muss der Domainname stehen, in diesem Fall ftu-monitor.ftu.kit.edu.

20 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

3.8.2.1 Konfiguration von Apache Um TLS/SSL verwenden zu können, musste der Webserver Apache so konfiguriert werden, dass er auf TCP-Port 443 (HTTPS Port) lauscht. Diese Einstellung wurde in der Datei /etc/apache2/ports.conf vorgenommen. Hierbei wurde folgender Abschnitt auskommentiert (vorangestellte # entfernt).

# # Listen 443 #

Die Änderungen wurden darauffolgend mit dem Befehl sudo service apache2 reload von Apache neu eingelesen. Zusätzlich musste das SSL-Modul des Apache mit folgenden Kommandos aktiviert werden: sudo a2enmod ssl sudo service apache2 force-reload

3.8.2.2 SSL-Webseite konfigurieren Abschließend musste noch ein Virtual Host für TLS/SSL eingerichtet werden. Für die Konfiguration wurde die Datei /etc/apache2/sites-available/ssl mit folgendem Inhalt erstellt:

SSLEngine on SSLCertificateFile /etc/ssl/certs/apache.crt SSLCertificateKeyFile /etc/ssl/private/apache.key

# Pfad zu den Webinhalten DocumentRoot /var/www/

Daraufhin wurde der Virtual Host mit diesem Befehl aktiviert: sudo a2ensite ssl.conf sudo service apache2 force-reload

3.8.2.3 Konfiguration der HTTPS-Verbindung für die Monitoring-Instanz Zur Verschlüsselung der Monitoring-Instanz musste die Datei /etc/apache2/sites-enabled/000-default mit folgendem Inhalt innerhalb des Virtual Host Abschnittes ergänzt werden.

RewriteEngine On RewriteCond %{SERVER_PORT} !^443$ RewriteRule (.*) https://%{HTTP_HOST}/$1 [L]

Nach der Konfigurationsänderung musste der Webserver neu gestartet werden. Dies geschah mit dem Befehl service apache2 restart. Die Konfiguration der

Julian Merkel 21 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU verschlüsselten Verbindung auf die Weboberfläche verlief erfolgreich. Dies konnte mit einem beliebigen Webbrowser auf https://ftu-monitor.ftu.kit.edu überprüft werden.

4 Projektergebnisse

4.1 Weboberfläche Die Weboberfläche des installierten Monitoring-Systems zeigt eine taktische Übersicht, sowie eine Host- und Servicestatistik die über alle Probleme informiert. (Abbildung 8)

Abbildung 8 - Check_MK Weboberfläche 4.2 Qualitätssicherung Alle Installationen und Konfigurationen wurden Projektbegleitend auf ihre korrekte Funktion geprüft. Zudem wurden Funktionstests, wie zum Beispiel Systemauslastung oder Verbindungsabbrüche, durch Simulationen erfolgreich durchgeführt.

22 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Zunächst bleibt die Monitoring-Lösung für vier Wochen in einer Test-Phase, in der durch Check_MK generierte Benachrichtigungen untersucht und mit den Beschwer- den und Meldungen der Anwender abgeglichen werden. Bei Unstimmigkeiten sind diese zu beheben. Nach erfolgreicher Test-Phase wird das Monitoring-System als stabil bezeichnet und soll in den Regelbetrieb übergehen. 4.3 Übergabe des Projektes Am 22.04.2016 wurde das erfolgreich realisierte Projekt in einer Vorführung an den Auftraggeber Torsten Neck und die Stabstelle IT übergeben. Die verfasste Benutzer- dokumentation im Anhang ist dafür vorgesehen, den Umgang mit Check_MK sowie Änderungen und Erweiterungen zu erklären und wurde bei der Übergabe überreicht. Zusätzlich zur kurzen Vorführung für die Stabsstelle IT stehe ich für Einweisungen in den Umgang mit Check_MK insbesondere für Moritz Welsch, Siegfried Wünstel und Torsten Neck als Ansprechpartner zur Verfügung. 4.4 Ist/Soll-Vergleich 4.4.1 Realisierte Ziele Die gestellten Ziele des Auftraggebers wurden erreicht:

 Entscheidung für ein Monitoring-System  Installation und Konfiguration der Monitoring-Software  Konfiguration der Monitoring-Lösung zur Überwachung aller systemrelevanten Hosts im Subnetz 141.52.80.0/24 und 141.52.251.192/26  Zentralisierte Übersichtsoberfläche über die überwachten Hosts und Dienste  E-Mail Benachrichtigungen bei Ausfällen und kritischen Zuständen  Schulung der Mitarbeiter der Stabsstelle IT im Umgang mit der Monitoring Lösung Insbesondere konnte die Überwachung aller speziell gewünschten Services in vollem Umfang realisiert werden.

4.4.2 Abweichungen vom Zeitplan In der Zeitplanung gab es Abweichungen in der Planungsphase sowie in der Durch- führungsphase, da die Planung schneller durchgeführt wurde, das Inventarisieren und Eintragen der einzelnen Hosts jedoch länger dauerte als geplant. Beim Projekt- abschluss wurden die geplanten 9 Stunden voll ausgenutzt. 4.5 Ausblick Die Systeme können einzelnen Mitarbeitern der Stabsstelle IT in Obhut gegeben werden und die Benachrichtigungen und Kontaktgruppen daraufhin so angepasst werden, dass jeder Mitarbeiter für bestimmte Systeme und deren Status zuständig ist.

Julian Merkel 23 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Darüber hinaus kann zukünftig auf Basis der im Betrieb gesammelten Zustandsdaten ein System zur Prognose und proaktiven Warnung vor Systemfehlern entwickelt werden.

5 Literaturverzeichnis  https://mathias-kettner.de/  https://de.wikipedia.org/  https://wiki.ubuntuusers.de/Postfix/

24 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

6 Anhang

6.1 Anhang 1: Glossar Begriff Erklärung VMware ESXi-Server Server Betriebssystem von VMware zum betreiben virtueller Maschinen auf einem Server Domäne In einem Netzwerk mit Domänencontroller können mehrere Computer zu einer Domäne zusammengefasst werden Demilitarisierte Zone (DMZ) Computernetz mit sicherheitstechnisch festgelegten Zugriffsmöglichkeiten auf die daran angeschlossenen Server GNU GPL Lizenz Die GNU, General Public License (auch GNU), ist eine Software-Lizenz, welche gewährt, die Software auszuführen, zu studieren, zu ändern und zu verbreiten SSH SSH bedeutet Secure Shell und ist ein Netzwerkprotokoll mit dem man eine verschlüsselte Netzwerkverbindung mit einem entfernen Gerät herstellen kann SFTP SFTP bedeutet SSH File Transfer Protocoll und ist ein Netzwerkprotokoll für verschlüsselten Datentransfer ISO-Abbild Bezeichnung für eine Computer-Datei, welche ein Speicherabbild des Dateisystems einer CD oder DVD enthält SIP SIP bedeutet Session Initiation Protocoll und ist ein Netzwerkprotokoll zum Aufbau, zur Steuerung und zum Abbau einer Kommunikationssitzung. SIP wird als Protokoll in der IP-Telefonie angewendet HTTP http bedeutet Hypertext Transfer Protocol und ist ein Netzwerkprotokoll um Webseiten aus dem Internet in einen Webbrowser zu laden SNMP SNMP bedeutet Simple Network Management Protocol und ist ein Netzwerkprotokoll um Netzwerkgeräte zentral zu überwachen und steuern zu können SNMP Community ‚Passwort‘ zum Zugriff über SNMP Standard: public Hostgroup Gruppierung von Hosts in Check_MK Host Computer, der Dienste in einem Rechnernetz zur Verfügung stellt SMTP-Relay-Server Mail-Server, der von einem Sender E-Mails annimmt und an beliebige Dritte weiterleitet Gruppenrichtlinie Seit Microsoft Windows 2000 eine digitale Richtlinie für verschiedene Einstellungen, die auf bestimmte Gruppen oder Arten von Einstellungen begrenzt ist. LDAP LDAP bedeutet Lightweight Directory Acces Protocol. Netzwerkprotokoll zur Abfrage und Änderung von Informationen verteilter Verzeichnisdienste. TLS/SSL TLS bedeutet Transport Layer Security und ist ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Vorgängerbezeichnung lautet Secure Sockets Layer (SSL) TCP TCP bedeutet Transmission Control Protocol. Es ist ein Netzwerkprotokoll, das vorgibt, auf welche Art und Weise Daten zwischen Systemen ausgetauscht werden sollen. Zuverlässiges, verbindungsorientiertes und paketvermittelndes Transportprotokoll in Computernetzwerken Virtual Host Apache-Webserver Konfiguration, so dass er für unterschiedliche Hostnamen verschiedene Inhalte liefert. Nützlich, um viele Websites auf einem Apache- Webserver zur Verfügung zu stellen.

Julian Merkel 25 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

6.2 Anhang 2: Tabellarische Aufführung der zu überwachenden Systeme des FTU Tabelle 12 - Tabellarische Aufführung der zu überwachenden Systeme des FTU – IP-Netz 141.52.80.0/24

Hostname IP Hersteller Hostgruppe RNP8B7485 141.52.80.1 RICOH COMPANY LTD. Drucker FTU-DNS 141.52.80.2 VMware, Inc. Windows_Server FTU-NECK2 141.52.80.4 GIGA-BYTE TECHNOLOGY CO.,LTD. Windows_Client ftu-ibf-www.ftu.fzk.de 141.52.80.6 VMware, Inc. Windows_Server FTU-WUENSTEL 141.52.80.10 Speed Dragon Multimedia Limited Windows_Client FTU-NECK 141.52.80.11 MITAC INTERNATIONAL CORP. Windows_Client FTU-NECK13 141.52.80.13 ASUSTek COMPUTER INC. Windows_Client FTU-SNMP 141.52.80.16 VMware, Inc. Windows_Server FTU-VMLIC 141.52.80.18 VMware, Inc. Windows_Server ftu-schoenthaler 141.52.80.20 ASUSTek COMPUTER INC. Windows_Client FTU-SERDARUSIC 141.52.80.22 ASUSTek COMPUTER INC. Windows_Client FTU-THOMAS 141.52.80.23 Intel Corporate Windows_Client ftu-mann.ftu.fzk.de 141.52.80.24 ASUSTek COMPUTER INC. Windows_Client FTU-MANGOLD 141.52.80.25 ASUSTek COMPUTER INC. Windows_Client ftu-sasso.ftu.fzk.de 141.52.80.26 ASUSTek COMPUTER INC. Windows_Client FTU-FESSLER-A 141.52.80.27 ASUSTek COMPUTER INC. Windows_Client ftu-balog.ftu.fzk.de 141.52.80.28 ASUSTek COMPUTER INC. Windows_Client FTU-WITT 141.52.80.29 ASUSTek COMPUTER INC. Windows_Client ftu-vmhost.ftu.fzk.de 141.52.80.33 Intel Corporate VMWare_Server FTU-KUHN 141.52.80.38 ASUSTek COMPUTER INC. Windows_Client FTU-PRINTMASTER 141.52.80.40 RICOH COMPANY,LTD. Drucker FTU-MAILOUT 141.52.80.45 Intel Corporation Windows_Client FTU-IBF-NAS 141.52.80.47 Synology Incorporated Synology_Server FTU-MERKEL 141.52.80.50 GIGA-BYTE TECHNOLOGY CO.,LTD. Windows_Client FTU-WELSCH 141.52.80.51 ASUSTek COMPUTER INC. Windows_Client FTU-REINHARD 141.52.80.52 ASUSTek COMPUTER INC. Windows_Client FTU-ANSBACH 141.52.80.53 ASUSTek COMPUTER INC. Windows_Client FTU-FESSLER 141.52.80.61 ASUSTek COMPUTER INC. Windows_Client AULARAUM129-PC 141.52.80.62 Intel Corporation Windows_Client ftu-kautt 141.52.80.63 ASUSTek COMPUTER INC. Windows_Client ftu-zingler.ftu.fzk.de 141.52.80.64 ASUSTek COMPUTER INC. Windows_Client ftu-schrammel 141.52.80.66 ASUSTek COMPUTER INC. Windows_Client FTU-GILLICH 141.52.80.67 CLEVO CO. Windows_Client FTU-LIEBE 141.52.80.68 - Windows_Client FTU-TRUMM 141.52.80.69 ASUSTek COMPUTER INC. Windows_Client BT-PC 141.52.80.76 ASRock Incorporation Windows_Client ftu-sitter-g.ftu.fzk.de 141.52.80.79 ASUSTek COMPUTER INC. Windows_Client FTU-OPSI 141.52.80.100 VMware, Inc. Linux_Server FTU-Anzeige 141.52.80.103 Dell Inc. Windows_Server FTUDC0 141.52.80.106 Hewlett-Packard Company Windows_Server

26 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

ftuvmesxi.ftu.fzk.de 141.52.80.107 VMware, Inc. VMWare_Server FTU-METZIGXP 141.52.80.110 ASUSTek COMPUTER INC. Windows_Client FTUWWW 141.52.80.112 VMware, Inc. Windows_Server FTU-STORAGE 141.52.80.115 Synology Incorporated Synology_Server FTU-DATEN 141.52.80.116 Synology Incorporated Synology_Server FTU-METZIG 141.52.80.117 ASUSTek COMPUTER INC. Windows_Client ftu-printcolor.ftu.fzk.de 141.52.80.119 KYOCERA CORPORATION Drucker ftu-print218.ftu.fzk.de 141.52.80.120 KYOCERA CORPORATION Drucker FTU-PRINT123 141.52.80.121 BROTHER INDUSTRIES, LTD. Drucker ftu-printscan.ftu.fzk.de 141.52.80.127 OKI ELECTRIC INDUSTRY CO., LTD Drucker ftu-ehlermann.ftu.fzk.de 141.52.80.129 ASUSTek COMPUTER INC. Windows_Client ftu-andlauer.ftu.fzk.de 141.52.80.130 ASUSTek COMPUTER INC. Windows_Client ftu-lp125.ftu.fzk.de 141.52.80.131 KYOCERA CORPORATION Drucker KM98C4F6 141.52.80.132 KYOCERA CORPORATION Drucker KMA4F695 141.52.80.133 KYOCERA CORPORATION Drucker ftu-lp121.ftu.fzk.de 141.52.80.134 KYOCERA CORPORATION Drucker ftu-lp119.ftu.fzk.de 141.52.80.135 KYOCERA CORPORATION Drucker ftu-lp118w.ftu.fzk.de 141.52.80.136 KYOCERA CORPORATION Drucker KM98C4E2 141.52.80.137 KYOCERA CORPORATION Drucker ftu-lp117.ftu.fzk.de 141.52.80.138 KYOCERA CORPORATION Drucker ftu-voip155.ftu.fzk.de 141.52.80.140 SNOM Technology AG SIP ftu-voip113.ftu.fzk.de 141.52.80.141 Cisco Linksys LLC SIP ftu-voip142.ftu.fzk.de 141.52.80.142 SNOM Technology AG SIP ftu-mertens.ftu.fzk.de 141.52.80.143 ASUSTek COMPUTER INC. Windows_Client ftu-voip016.ftu.fzk.de 141.52.80.144 SNOM Technology AG SIP ftu-voip039.ftu.fzk.de 141.52.80.146 Cisco Linksys LLC SIP ftu-voip116.ftu.fzk.de 141.52.80.147 Cisco Linksys LLC SIP 141.52.80.148 141.52.80.148 SNOM Technology AG SIP ftu-voip236.ftu.fzk.de 141.52.80.151 Cisco Linksys LLC SIP FTU-155 141.52.80.155 CLEVO CO. Windows_Client FTU-157 141.52.80.157 CLEVO CO. Windows_Client FIRST INTERNATIONAL FTU-211 141.52.80.158 COMPUTER, INC. Windows_Client ftu-162 141.52.80.162 CLEVO CO. Windows_Client FTU-163 141.52.80.163 CLEVO CO. Windows_Client FTU-164 141.52.80.164 CLEVO CO. Windows_Client FIRST INTERNATIONAL FTU-221 141.52.80.169 COMPUTER, INC. Windows_Client ftu-graser 141.52.80.171 ASUSTek COMPUTER INC. Windows_Client FTU-HESS 141.52.80.176 ASUSTek COMPUTER INC. Windows_Client sg-fturch.ftu.fzk.de 141.52.80.189 TP-LINK TECHNOLOGIES CO., LTD. Switch ftu-def-gw.ftu.fzk.de 141.52.80.203 CISCO SYSTEMS, INC. Switch se-ftu3.ftu.fzk.de 141.52.80.205 CISCO SYSTEMS, INC. Switch sg-ftu113.ftu.fzk.de 141.52.80.206 TP-LINK Technology Co., Ltd. Switch se-ftu4.ftu.fzk.de 141.52.80.208 Enterasys Networks Switch sg-ftu112.ftu.fzk.de 141.52.80.209 TP-LINK TECHNOLOGIES CO., LTD. Switch ftu-backup.ftu.fzk.de 141.52.80.226 VMware, Inc. Windows_Server

Julian Merkel 27 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

ftu-axis2.ftu.fzk.de 141.52.80.233 AXIS COMMUNICATIONS AB Axis ftu-nagios.ftu.fzk.de 141.52.80.235 VMware, Inc. Linux_Server FTU-236 141.52.80.236 CLEVO CO. Windows_Client FTU-IT-NAS 141.52.80.242 Synology Incorporated Synology_Server ftu-asterisk.ftu.fzk.de 141.52.80.243 Fujitsu Siemens Computers Linux_Server FTU-BAKSPACE 141.52.80.244 Synology Incorporated Synology_Server FTU-LTIII 141.52.80.246 CLEVO CO. Windows_Client FIRST INTERNATIONAL FTU-116-PC 141.52.80.249 COMPUTER, INC. Windows_Client FTU-156 141.52.80.250 CLEVO CO. Windows_Client

Tabelle 13 - Tabellarische Aufführung der zu überwachenden Systeme des FTU - IP-Netz 141.52.251.192/26

Hostname IP Hersteller Hostgruppe ftudmz-defgw.dmzftu.kit.edu 141.52.251.193 Cisco Switch 141.52.251.194 141.52.251.194 CISCO SYSTEMS, INC. Switch FTUDMZ-RNC 141.52.251.199 BIOSTAR MICROTECH INT'L CORP. Linux_Server ftu111-00.dmzftu.kit.edu 141.52.251.200 ASUSTek COMPUTER INC. Windows_Client ftu111-01.dmzftu.kit.edu 141.52.251.201 ASUSTek COMPUTER INC. Windows_Client 141.52.251.202 141.52.251.202 ASUSTek COMPUTER INC. Windows_Client 141.52.251.203 141.52.251.203 ASUSTek COMPUTER INC. Windows_Client ftu111-04.dmzftu.kit.edu 141.52.251.204 ASUSTek COMPUTER INC. Windows_Client 141.52.251.205 141.52.251.205 ASUSTek COMPUTER INC. Windows_Client ftu111-06.dmzftu.kit.edu 141.52.251.206 ASUSTek COMPUTER INC. Windows_Client ftu111-07.dmzftu.kit.edu 141.52.251.207 ASUSTek COMPUTER INC. Windows_Client ftu111-08.dmzftu.kit.edu 141.52.251.208 ASUSTek COMPUTER INC. Windows_Client 141.52.251.209 141.52.251.209 Windows_Client ftu111-10.dmzftu.kit.edu 141.52.251.210 ASUSTek COMPUTER INC. Windows_Client ftu111-11.dmzftu.kit.edu 141.52.251.211 ASUSTek COMPUTER INC. Windows_Client ftu111-12.dmzftu.kit.edu 141.52.251.212 ASUSTek COMPUTER INC. Windows_Client FTU-PRINT110 141.52.251.215 Hewlett-Packard Company Drucker FTU-TN-P6021cdn 141.52.251.216 KYOCERA CORPORATION Drucker TN-FTU-SOFT 141.52.251.217 Synology Incorporated Synlogy_Server FTUDMZ-LERNWELT 141.52.251.218 VMware, Inc. Windows_Client 141.52.251.223 141.52.251.223 Intel Corporate VMWare_Server FTUDMZ-DC 141.52.251.224 VMware, Inc. Windows_Server DMZFTU-EX 141.52.251.225 VMware, Inc. Windows_Server FTUDMZ-DC2 141.52.251.226 Intel Corporate Windows_Server FTUDMZ-NAS 141.52.251.227 Synology Incorporated Synlogy_Server FTUDMZ-OPSI 141.52.251.228 VMware, Inc. Linux_Server FTU108-00 141.52.251.230 ASUSTek COMPUTER INC. Windows_Client FTU108-01 141.52.251.231 ASUSTek COMPUTER INC. Windows_Client FTU108-02 141.52.251.232 ASUSTek COMPUTER INC. Windows_Client FTU108-03 141.52.251.233 ASUSTek COMPUTER INC. Windows_Client FTU108-04 141.52.251.234 Intel Corporate Windows_Client

28 Julian Merkel Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

FTU108-05 141.52.251.235 ASUSTek COMPUTER INC. Windows_Client FTU108-06 141.52.251.236 ASUSTek COMPUTER INC. Windows_Client ftudmz-ap111.dmzftu.kit.edu 141.52.251.238 TOSHIBA CORPORATION AP TN-FTU-NAS 141.52.251.239 AVM GmbH Synlogy_Server ftudmz-sg039c.dmzftu.kit.edu 141.52.251.240 TP-LINK TECHNOLOGIES CO., LTD. Switch ftudmz-se039c.dmzftu.kit.edu 141.52.251.241 TP-LINK Technologies Co.,Ltd. Switch ftudmz-se112o.dmzftu.kit.edu 141.52.251.243 Hewlett-Packard Company Switch ftudmz-sg108.dmzftu.kit.edu 141.52.251.244 TP-LINK TECHNOLOGIES CO., LTD. Switch ftudmz-sg112.dmzftu.kit.edu 141.52.251.245 TP-LINK TECHNOLOGIES CO., LTD. Switch ftudmz-sg113 141.52.251.246 TP-LINK TECHNOLOGIES CO., LTD. Switch ftudmz-owncloud.dmzftu.kit.edu 141.52.251.251 VMware, Inc. Linux_Server ftudmz-rnc2.dmzftu.kit.edu 141.52.251.252 Linux_Server ftu-gaef.dmzftu.kit.edu 141.52.251.253 Asiarock Technology Limited Windows_Server

Julian Merkel 29 Planung und Realisierung einer Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

6.3 Persönliche Erklärung

30 Julian Merkel

7 Benutzerdokumentation

Eine Monitoring-Lösung zur Überwachung der netzwerk- fähigen Geräte des FTU

April 2016

Julian Merkel

Fortbildungszentrum für Technik und Umwelt (FTU) Karlsruher Institut für Technologie Hermann-von-Helmholtz-Platz 1 76344 Eggenstein-Leopoldshafen.

KIT – Die Forschungsuniversität in der Helmholz-Gemeinschaft

Benutzerdokumentation: Monitoring-Lösung für das FTU

Inhalt

1 Einleitung ...... 4

2 Check_MK Grundlagen ...... 4 2.1 Hosts und Services ...... 4 2.2 Parents ...... 5 2.3 Services ...... 5 2.4 Host- und Servicegruppen ...... 5 2.5 Kontakte und Kontaktgruppen ...... 5 2.6 Benutzer und Rollen ...... 6 2.7 Probleme, Alarme und Benachrichtigungen ...... 6 2.7.1 Gesamtübersicht (Tactical Overview) ...... 6 2.7.2 Info-/Alarm- und Benachrichtigungssystem ...... 6 2.8 Übersicht – Wichtigste Host- und Serviceicons ...... 7 2.9 Benutzeroberfläche des Check_MK Webinterfaces ...... 8 2.9.1 Ansichten von Hosts und Services (Views) ...... 9 2.9.2 Kommandos ...... 10 2.9.3 Quittierung von Problemen ...... 11

3 Konfiguration von Check_MK ...... 12 3.1 Wichtige WATO-Module ...... 14 3.2 Check_MK-Agent ...... 14 3.3 Verwaltung der Hosts ...... 15 3.3.1 Hostname ...... 15 3.3.2 Basic settings: Alias und IP-Adresse ...... 15 3.3.3 Host tags: Check_MK-Agent, SNMP oder No Agent ...... 16 3.3.4 Speichern des Hosts ...... 16 3.4 Benutzerverwaltung ...... 17 3.4.1 Rollen ...... 17 3.4.2 Kontaktgruppen...... 17 3.5 Kontaktgruppen verwalten ...... 17 3.5.1 Kontaktgruppe anlegen ...... 18 3.5.2 Kontaktgruppe löschen ...... 18 3.5.3 Ordner mit Kontaktgruppe verbinden ...... 18 3.6 Benutzer verwalten ...... 18 3.6.1 Benutzer hinzufügen ...... 19 3.6.2 Benutzer bearbeiten ...... 19 3.6.3 Benutzer löschen ...... 20

Benutzerdokumentation 2 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

4 Weitere Informationen ...... 20 4.1 Verbindung auf ftu-monitor mit SSH ...... 20 4.2 Monitoring Instanz prüfen und steuern ...... 21 4.3 Installieren von Updates ...... 22

Julian Merkel Benutzerdokumentation 3 Benutzerdokumentation: Monitoring-Lösung für das FTU

1 Einleitung Die Benutzerdokumentation für die Verwaltung der Monitoring-Lösung ist in vier Kategorien gegliedert:

 Info-/Alarm- und Benachrichtigungsketten,  die Verwendung des Check_MK Webinterfaces,  die Hostkonfiguration mit Check_MK und  weitere Hinweise zum Umgang mit Check_MK.

2 Check_MK Grundlagen Vorerst werden die grundlegenden Konzepte und Begriffe der Systemüberwachung mit Check_MK erläutert. 2.1 Hosts und Services In der Überwachung von Systemen spricht man von Hosts und Services. Ein Host kann vieles sein, z.B.:

 Server  Netzwerkgerät (Switch, Router, Loadbalancer)  Messgerät mit IP-Anschluss (Thermomether, Luftfeuchtesensor)  Gerät mit IP-Anschluss  Ein Cluster aus mehreren Hosts Ein Host hat immer einen der folgenden Zustände:

Zusätzlich hat ein Host einige Attribute, die vom Anwender konfiguriert werden, z.B.:

 Einen eindeutigen Namen (Hostname)  IP-Adresse  Alias-Name, der nicht eindeutig sein muss (optional)  Parents (Geräte, über die ein System mit dem Netzwerk verbunden ist, optional)

Benutzerdokumentation 4 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

2.2 Parents Damit das Monitoring-System den Zustand „UNREACH“ berechnen kann, muss es wissen, über welchen Weg es jeden einzelnen Host erreichen kann. Hierfür kann man bei jedem Host einen oder mehrere sogenannte Parenthosts angeben. Als Beispiel, dass ein Server A vom Monitoring aus gesehen nur über einen Router B erreichbar ist, dann ist B ein Parent von A.

Die Erkennung von Netzwerkausfällen und die Vermeidung von massenhaften Fehl- alarmen in solchen ist Situationen ist die wichtigste Aufgabe der Parents. 2.3 Services Ein Host hat eine Menge von Services, die aber nichts mit den Services von Windows zu tun haben. Ein Service ist ein Teil oder Aspekt des Hosts, der entweder dem Zustand OK entspricht oder nicht. Der Zustand von Services kann nur dann ab- gefragt werden, wenn der Host im Zustand „UP“ ist.

Folgendes Abbild zeigt die Zustände eines Services im Monitoring:

Folgende Reihenfolge verwendet Check_MK um zu bestimmen wie schwerwiegend eine Zustand ist der nicht dem Status „OK“ entspricht:

2.4 Host- und Servicegruppen Zur Übersicht können Hosts und Services gruppiert werden. Hierbei kann ein Host/Service auch in mehreren Gruppen sein. Diese Gruppen sind optional und für die Konfiguration nicht zwingend notwendig. Durch Hostgruppen können zum Bei- spiel alle Linux-Server in die Hostgruppe „Linux_Server“ zusammengefasst werden. 2.5 Kontakte und Kontaktgruppen Hosts und Services können mithilfe von Kontakten und Kontaktgruppen Personen zugeordnet werden. Ein Kontakt ist eine Benutzerkennung der Weboberfläche. Die Zuordnung zu Hosts und Services geschieht nicht direkt, sondern über Kontaktgrup-

Julian Merkel Benutzerdokumentation 5 Benutzerdokumentation: Monitoring-Lösung für das FTU pen. Zuerst wird ein kontakt (z.B. FTU-IT) einer Kontaktgruppe (z.B. admins) zugeordnet. Der Kontaktgruppe werden darauffolgend Hosts oder nach Bedarf auch einzelne Services zugeordnet. Benutzer, Hosts und Services können mehreren Kontakt- gruppen zugeordnet werden. 2.6 Benutzer und Rollen Kontakte und Kontaktgruppen steuern die Zuständigkeit von Personen für einen bestimmten Host oder Service. Die Privilegien für die Konfiguration werden über Rollen gesteuert. Check_MK wird standardmäßig mit drei Rollen ausgeliefert, von denen man zusätzlich weitere Rollen ableiten kann. Jede Rolle definiert bestimmte Berechti- gungen, welche anpassbar sind. Folgende Tabelle zeigt die Bedeutung der Standardrollen:

2.7 Probleme, Alarme und Benachrichtigungen 2.7.1 Gesamtübersicht (Tactical Overview) Jeder Host der nicht im Zustand „UP“ ist und jeden Service, der nicht „OK“ ist, bezeichnet Check_MK als ein Problem. Ein Problem kann zwei Zustände haben, näm- lich unbehandelt (unhandled) und behandelt (handled). Ein neues Problem im Moni- toring-System gilt zunächst als unbehandelt. Sobald ein Nutzer das Problem im Monitoring-Webinterface bestätigt (quittiert, acknowledged), gilt dies als behandelt. Die unbehandelten Probleme sind also die Probleme, um die sich noch niemand ge- kümmert hat. Die Taktische Übersicht in der Seitenleiste unterscheidet deshalb diese beiden Arten von Problemen:

Service-Probleme von Hosts, deren Zustand nicht „UP“ ist, werden in der Übersicht nicht als Problem angezeigt.

2.7.2 Info-/Alarm- und Benachrichtigungssystem Wenn Check_MK feststellt, dass einer der überwachten Dienste vom Status „OK“ in den Status „CRITICAL“ oder „WARNING“ wechselt sendet das System an alle Mitar-

Benutzerdokumentation 6 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU beiter der IT ([email protected]) eine E-Mail Benachrichtigung. Eine E-Mail Benachrichti- gung beinhaltet den betroffenen Host sowie den Status mit Beschreibung des Feh- lers. Folgend ein Beispiel für eine solche Benachrichtigungs-Mail:

Die Benachrichtigungen liefern Problembeschreibungen zu Systemen und ermög- lichen daher eine schnellere und verbesserte Beseitigung von Systemausfällen.

In diesem Beispiel signalisiert die Nachricht, dass der Host ftudmz- ex.dmzftu.kit.edu mit der IP-Adresse 141.52.251.225 nicht erreichbar ist, da die Überprüfung mit Ping keine Antwort erhielt. 2.8 Übersicht – Wichtigste Host- und Serviceicons Die folgende Tabelle gibt eine Übersicht über die wichtigsten Icons, die als Status neben Hosts und Service zu finden sind:

Julian Merkel Benutzerdokumentation 7 Benutzerdokumentation: Monitoring-Lösung für das FTU

2.9 Benutzeroberfläche des Check_MK Webinterfaces Das Webinterface von Check_MK gibt einen schnellen und direkten Zugriff auf die aktuellen Zustände von allen Hosts und Services im Monitoring-System und ist in jedem beliebigen Internetbrowser unter der Adresse https://ftu-monitor.ftu.kit.edu erreichbar. Lediglich eine Verbindung im internen KIT-Netz ist notwendig, da ein Zugriff von externen Geräten nicht möglich ist. Die folgende Abbildung zeigt den Startbild- schirm, den man direkt nach der Anmeldung auf der Weboberfläche erhält.

1. Version der Check_MK Installation 2. Gesamtübersicht der zu überwachenden Hosts und Services und der jeweiligen Zahl von Objekten mit unquittierten und quittierten Problemen. Mit einem Klick auf die Ziffern bekommt man jeweils eine Auflistung der Hosts und Services. 3. Suchfeld indem man nach Hosts und Services suchen kann 4. Ansichten, die Zugriff auf unterschiedliche Auflistungen von Hosts, Services, Übersichten, erweiterte Suchmasken und andere Seiten bietet. 5. Am unteren Rand der Seitenleiste gibt es 3 Knöpfe mit folgenden Funktionen:

6. Name des angemeldeten Nutzers, dessen Rolle und die genaue Uhrzeit 7. Host Statistik (ähnelt der Taktische Übersicht), Aufstellung der Hosts und deren verschiedenen Zustände

Benutzerdokumentation 8 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

8. Service Statistik, zeigt welchen Anteil der jeweilige Status an der Gesamtzahl einnimmt 9. Auflistung aller aktuellen unquittierten Host-Probleme. Ein Klick auf den Titel des Kastens leitet auf eine vergrößerte Ansicht um 10. Nicht quittierte Service Probleme 11. Ereignisse des Monitoring-Systems der letzten vier Stunden 2.9.1 Ansichten von Hosts und Services (Views) Das Anzeigen des aktuellen Status von Hosts und Services in tabellarischen Ansich- ten ist die wichtigste Aufgabe der Weboberfläche von Check_MK. Die Ansichten bieten zahlreiche Funktionen und sind individuell anpassbar.

Check_MK unterscheidet zwischen globalen Views und solchen, die einen Kontext benötigen. Global ist als Beispiel die Liste aller aktuellen Host-Probleme. Einen Kon- text benöeigt die Ansicht „Status of Host ***“. Nämlich die Angabe desjenigen Hosts, dessen Status angezeigt werden soll.

Die globalen Ansichten sind am einfachsten über die Seitenleistenelemente „Tactical Overview“ und „Views“ zu erreichen. In der taktischen Übersicht sind jede der sechs Zahlen klickbar und leitet zu einer globalen Ansicht weiter, die die gezählten Hosts oder Services einzeln auflistet.

Im Element „Views“ sind alle globalen Ansichten, gruppiert nach Thema, erreichbar.

Julian Merkel Benutzerdokumentation 9 Benutzerdokumentation: Monitoring-Lösung für das FTU

Um zu den Einzelheiten eines bestimmten Hosts oder Services zu gelangen klickt man auf die Namen von Hosts oder Services oder auf einen der anderen Spalten in den einzelnen Zellen.

Mit einem Klick auf den Hostnamen, in diesem Beispiel „ftu-storage“, gelangt man direkt zur Seite „Services of host ftu-storage“. Dort findet man dann weitere Knöpfe zu den anderen Ansichten des gleichen Hosts.

2.9.2 Kommandos Mit Kommandos auf Hosts, Services und andere Objekte kann in den Ablauf des Monitorings eingegriffen werden. Kommandos dienen zum Quittieren von Problemen und Setzen von Wartungszeiten. Zu den Kommandos gelangt man mit dem klei- nen Hammer am Titel einer Ansicht. Daraufhin öffnen sich mehrere Kästen, unter an- derem derjenige für die Quittierung von Problemen.

Benutzerdokumentation 10 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Die angezeigten Knöpfe stehen für eine Art von Kommando. Manche brauchen unter anderen weiteren Angaben, wie zum Beispiel einen Text für die Quittierung. Durch Drücken des Knopfes gelangt man zu einer Bestätigung:

Mit der Bestätigung durch „Yes“ wird das gewählte Kommando auf allen in der An- sicht gezeigten Objekten ausgeführt.

2.9.3 Quittierung von Problemen Das Monitoring-System Check_MK unterscheidet bei Problemen zwei mögliche Zu- stände, unbehandelt und behandelt. Bei behandelten, sogenannten quittierten Problemen, geht man davon aus, dass diese zur Kenntnis genommen wurden und sich jemand darum kümmert.

Sobald ein Problem quittiert ist, wird dieses mit einem Symbol gekennzeichnet und taucht in der taktischen Übersicht nicht mehr unter dem Punkt „Unhandled“ auf. Außerdem werden keine wiederholten Alarme mehr versendet.

2.9.3.1 Ablauf einer Quittierung Probleme werden über Kommandos auf den betroffenen Hosts/Services quittiert. Über den gleichen Schritt können Quittierungen auch wieder entfernt werden.

Julian Merkel Benutzerdokumentation 11 Benutzerdokumentation: Monitoring-Lösung für das FTU

Bedeutung der Quittierungsoptionen:

2.9.3.2 Übersicht von Quittierungen Es gibt in der Check_MK Weboberfläche mehrere Möglichkeiten, um Quittierungen anzuzeigen.

Durch folgende zwei Symbole werden quittierte Probleme in allen Ansichten von Hosts und Service gekennzeichnet:

Über das Menü Views  Other  Comments gelangt man zur Liste aller Kommen- tare auf Hosts und Services. Hierzu gehören auch diejenigen, die durch Quittierun- gen entstanden sind. Durch Kommandos können Kommentare gelöscht werden. Dies hat kein Einfluss auf gesetzte Quittierungen.

3 Konfiguration von Check_MK Bei Check_MK wird zwischen der Konfigurationsumgebung, in der die Hosts, Services und Einstellungen verwaltet werden und dem eigentlichen Monitoring, in der die Überwachung unterschieden.

Änderungen in der Konfiguration, wie zum Beispiel das Hinzufügen eines neuen Hosts, haben vorerst keinen Einfluss auf das Monitoring. Dies geschieht erst durch den Button Activate Changes, welcher alle Änderungen, die seit dem letzten Mal

Benutzerdokumentation 12 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU aufgesammelt wurden, aktiviert. Dies hat den Vorteil, dass komplexe Änderungen zuerst vorbereitet werden können, bevor diese angewendet werden. So können nach dem Hinzufügen von Hosts erst noch Schwellwerte gesetzt oder manche Services entfernt werden, bevor diese von Check_MK überwacht werden.

Das Werkezug zur Konfiguration von Check_MK über die Weboberfläche nennt sich WATO (Web Administration Tool). Dieses wird über das entsprechende Element in der Seitenleiste, welches direkten Zugriff auf alle WATO-Module bietet.

Sobald mit WATO eine Änderung an der Monitoring-Konfiguration vorgenommen wurde, wird diese zunächst aufgesammelt und gilt als anstehend (pending). Solche Änderungen erkennt man an dem Knopf in den WATO-Modulen oder an dem Knopf in der Seitenleiste. Durch das Klicken einer dieser Buttons gelangt man zu einer Liste dieser Änderungen.

Durch das Drücken auf den Knopf Activate Changes werden aus den Änderungen eine neue Konfiguration für den Monitoring-Kern erzeugt und diesem den Befehl gegeben, diese ab sofort zu verwenden.

Julian Merkel Benutzerdokumentation 13 Benutzerdokumentation: Monitoring-Lösung für das FTU

Die Liste der anstehenden Änderungen wird dadurch geleert, wobei diese Einträge nicht verloren sind. Über den Knopf Audit Log findet man eine Logdatei von allen Änderungen, welche per WATO jemals gemacht wurden. 3.1 Wichtige WATO-Module Das Administrationstool von Check_MK besitzt für jeden wichtigen Aspekt von Check_MK ein Modul. Diese Module sind besonders wichtig:

3.2 Check_MK-Agent Für die Überwachung von Servern und Workstations wird ein Check_MK-Agent be- nötigt. Hierfür sind über die Weboberfläche die Agenten für elf verschiedene Be- triebssystem-Familien verfügbar.

Die Agenten sind über das WATO-Modul Monitoring Agents abrufbar.

Benutzerdokumentation 14 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Die Agenten für Windows (check_mk_agent.msi) und Linux (Dateien mit .deb oder .rpm) sind im ersten Abschnitt herunterzuladen. Der Agent ist nach Installation dieser Pakete sofort einsatzbereit und mit Check_MK überwachbar. 3.3 Verwaltung der Hosts Über das WATO-Modul Hosts gelangt man zur Verwaltung der Ordner und Hosts. Hier können die zu überwachenden Systeme angelegt und in Ordner gruppiert werden.

In welchem Unterordner man sich gerade befindet erkennt man an folgender Leiste:

Der Knopf , das Klonen eines bereits angelegten Hosts oder das Editieren eines Hosts leitet auf die Seite mit den Attributen des Hosts weiter, welche in drei Abschnitte eingeteilt ist:

3.3.1 Hostname Der Hostname dient innerhalb von Check_MK zur eindeutigen Identifizierung der Hosts. Er wird in interne Referenzen eingetragen, als Teil von URLs verwendet, dient als Teil von Dateinamen und Verzeichnissen und taucht in Logdateien auf.

3.3.2 Basic settings: Alias und IP-Adresse Einen alternativen, beschreibenden Namen für den Host kann in den Basic settings vergeben werden. Dieser wird an vielen Stellen in der Weboberfläche und in

Julian Merkel Benutzerdokumentation 15 Benutzerdokumentation: Monitoring-Lösung für das FTU

Berichten angezeigt. Wird kein Alias vergeben, so wird an dieser Stelle der Hostname verwendet.

Für die Konfiguration der IP-Adresse gibt es folgende Möglichkeiten:

1. Keine IP-Adresse  Hostname muss per DNS auflösbar sein 2. IP-Adresse in üblicher Punkt-Notation 3. Alternativer Hostname, der per DNS auflösbar ist 3.3.3 Host tags: Check_MK-Agent, SNMP oder No Agent Diese Einstellungen konfigurieren die Parameter von Hosts und Services.

Für den Agent type sind die wichtigsten Einstellungen:

Check_MK Der Host soll über den Check_MK-Agenten überwacht werden, Agent der auf dem Host installiert ist SNMP Überwachung über SNMP, in den Basic settings ist die Konfiguration der SNMP-Community möglich. Keine Konfiguration = public No Agent Host wird mit PING-Service überwacht 3.3.4 Speichern des Hosts Nach der Konfiguration des Hosts wird dieser mit dem Knopf Save & go to services gespeichert und man gelangt in das Menü der automatischen Serviceerkennung.

Benutzerdokumentation 16 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Es werden alle verfügbaren Überwachungen des Hosts automatisch erkannt und aufgelistet. Nicht benötigte Überwachungen können mit dem Knopf deaktiviert werden. Mit dem Knopf Save manual check configuration wird der Host gespeichert.

Zur abschließenden Aktivierung der Überwachung müssen die Änderungen noch aktiviert werden. 3.4 Benutzerverwaltung Benutzer in Check_MK gehören zu einer Rolle und können zu einer oder mehreren Kontaktgruppen gehören.

3.4.1 Rollen Die Berechtigungen der Benutzer in der Weboberfläche werden durch Rollen gesteuert. Es gibt drei vordefinierte Rollen:

Rolle Rechte Admin Uneingeschränkte Rechte im System Guest Überwachung der Systeme, jedoch keine Berechtigung zur Konfigurationsänderungen User Kann Konfigurationsänderungen an Systemen die zu seiner Kontaktgruppe gehören vornehmen. Sieht nur Systeme seiner Kontaktgruppe

3.4.2 Kontaktgruppen Benutzer, Ordner, Hosts und Services können mit Kontaktgruppen verbunden werden. Damit wird die Sichtbarkeit in der GUI und die Zuständigkeit für Benachrichtigungen gesteuert. 3.5 Kontaktgruppen verwalten Die Verwaltung für Kontaktgruppen wird über WATO > Contact Groups erreicht.

Mit einem Klick auf das Symbol bearbeitet man die Kontaktgruppe, mit klont man eine Kontaktgruppe und mit kann man eine existierende Kontaktgruppe löschen.

Julian Merkel Benutzerdokumentation 17 Benutzerdokumentation: Monitoring-Lösung für das FTU

3.5.1 Kontaktgruppe anlegen

Eine Kontaktgruppe kann mit einem Klick auf New contact group erstellt werden. Die Felder „Name“ und „Alias“ müssen ausgefüllt werden. Durch Anklicken von Save wird die Kontaktgruppe erstellt.

3.5.2 Kontaktgruppe löschen Durch Anklicken von können nicht mehr benötigte Kontaktgruppen gelöscht werden.

3.5.3 Ordner mit Kontaktgruppe verbinden Um Hosts in Ordnern eine Kontaktgruppe zuzuweisen wird dies in den Einstellungen des Ordners festgelegt. Hierhin gelangt man über WATO > Hosts und öffnet den gewünschten Ordner im Bearbeitungsmodus mit einem Klick auf . Hier können unter dem Menüpunkt Permissions die Kontaktgruppen mit folgende Optionen festgelegt werden:

 Give these groups also permission on all subfolders: Verbindet die Kontaktgruppen mit allen Unterordnern  Add these groups as contacts to all hosts in this folder Alle Hosts im Ordner werden mit der ausgewählten Kontaktgruppe verbunden  Add these groups as contacts in all subfolders: Alle Hosts in Unterordnern werden zusätzlich mit der ausgewählten Kontaktgruppe verbunden 3.6 Benutzer verwalten In die Benutzerverwaltung gelangen man über WATO > Users. Die Liste zeigt alle vorhandenen Benutzer. Da alle Benutzer über die LDAP-Anbindung verwaltet werden müssen keine lokalen Benutzer angelegt werden.

Benutzerdokumentation 18 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Alle Benutzer in der Sicherheitsgruppe FTU-IT können sich durch die LDAP- Anbindung auf der Weboberfläche mit ihren Benutzerdaten authentifizieren.

3.6.1 Benutzer hinzufügen Um einen Benutzer hinzuzufügen muss in der Gruppenverwaltung des KIT (https://team.kit.edu/sites/scc-admin-tools/gruppenverwaltung) der Mitarbeiter der Sicherheitsgruppe FTU-IT hinzugefügt werden. Der Benutzer wird dann durch die LDAP-Anbindung vom Monitoring-System automatisch angelegt.

3.6.2 Benutzer bearbeiten

3.6.2.1 Identify Unter der Rubrik Identify kann lediglich eine Telefonnummer des Nutzers hinterlegt werden.

3.6.2.2 Security Unter der Rubrik Security kann dem Nutzer ein Passwort zugewiesen, der Login gesperrt oder eine Rolle zugewiesen werden.

Julian Merkel Benutzerdokumentation 19 Benutzerdokumentation: Monitoring-Lösung für das FTU

3.6.2.3 Contact Groups Die Rubrik Contact Groups ermöglicht das Verbinden von Kontaktgruppen an den Nutzer. Dafür werden die gewünschten Kontaktgruppen angekreuzt.

3.6.2.4 Personal Settings Im letzten Abschnitt erfolgt die Sprachauswahl, die Sichtbarkeit von Hosts und Services und das kurzzeitige Deaktivieren von Alarmierungen. Am Ende befindet sich das Konfigurationsfeld für die Startseite des Benutzers, welches die Übersicht festlegt, die der Nutzer beim Anmelden an der Weboberfläche sieht.

Die Einstellungen werden durch den Button Save gespeichert.

3.6.3 Benutzer löschen Nicht mehr benötigte Benutzer können mit einem Klick auf das Symbol aus der Benutzerverwaltung gelöscht werden.

4 Weitere Informationen

4.1 Verbindung auf ftu-monitor mit SSH Für eine SSH Verbindung auf den Server wird zunächst ein SSH Client benötigt. PuTTY ist ein solches Programm für Windows, welches unter http://www.putty.org/ verfügbar ist.

Beim Starten von PuTTY erhält man folgendes Menü:

Benutzerdokumentation 20 Julian Merkel Eine Monitoring-Lösung zur Überwachung der netzwerkfähigen Geräte des FTU

Um eine Verbindung zum Monitoring-Server herzustellen muss im Feld Host Name (or IP address) der Hostname ftu-monitor.ftu.kit.edu eingetragen werden. Mit einem Klick auf Open wird versucht eine SSH Verbindung aufzubauen und man erhält ein Linux übliches Konsolenfenster.

4.2 Monitoring Instanz prüfen und steuern Um die Monitoring Instanz zu prüfen muss man zunächst mit dem Befehl sudo –i sich als root authentifizieren. Mit dem Befehl su - ftu kann man dann in den Instanzbenutzer „ftu“ wechseln, der während der Installation angelegt wurde. Mit dem Befehl omd status kann man den Status des Monitoring-Systems überprüfen.

Falls die Instanz nicht den Status running hat, kann man diese mit dem Befehl omd start starten.

Mit dem Befehl omd stop kann die Instanz angehalten werden.

Julian Merkel Benutzerdokumentation 21 Benutzerdokumentation: Monitoring-Lösung für das FTU

4.3 Installieren von Updates Nachdem eine SSH Verbindung aufgebaut wurde und eine Authentifizierung mit dem Server erfolgreich war kann man mit dem Befehl sudo apt-get update && sudo apt-get upgrade alle verfügbaren Updates installieren. Einige Updates können Bestätigung durch den Nutzer erfordern um installiert zu werden.

Benutzerdokumentation 22 Julian Merkel