Abou Chleih

{the magic lies between the brackets}

Menü Schließen

Kategorie: Netzwerk

Check_MK Überwachungs-Skript für EMC VNXe Maschinen (Unisphere CLI)

Zur Überwachung von VNXe Storage Systemen (NAS) innerhalb von Check_MK gab es keine ordentlichen Funktionen.
Im Netz findet man auch nicht viel zu diesem Thema.
Allerdings bieten die VNXe Systeme eine Remote Möglichkeit zur Konfiguration via Shell, die sog. Unisphere CLI; kurz: UEMCLI.
Diese wird für die verschiedensten Systeme angeboten, allerdings für Linux Systeme nur in Form ein .rpm Datei (Red Hat Package).
Auf Debian Systemen steht man jetzt etwas blöd da, also konvertierte ich das Paket mit alien in das .deb Format.

faviconunispherecli-linux-64-x86-en-us_3.0.0.1.16-2_amd64.deb

Nach der Installation finden sich die Binaries der uemcli im Pfad /opt/emc/uemcli/bin.

vnxe_check

Das Skript, welches wir in Check_MK aufrufen werden, müssen wir nun in einen für den Check_MK user verfügbaren Pfad packen (hier: /opt/omd/sites/monitor/local/share/check_mk) und via chmod -x ausführbar machen. Die Rechte müssen evtl. auch angepasst werden.
Im Anschluss können wir einen Legacy oder Classical Check in Check_MK anlegen, welcher das Programm ausführt.
Davor allerdings noch die Security Level der UEMCLI via /opt/emc/uemcli/bin/setlevel.sh -l auf low setzen, damit die Zertifikate nicht mehr manuell akzeptiert werden müssen.

Nun können wir das Programm mit folgendem Befehl ausführen: /opt/omd/sites/monitor/local/share/check_mk/vnxe_check <HOST> <USER> <PW> <PATH> <COL> <OPTIONAL REGEX>
Es gibt die entsprechenden Codes zurück. Die Fehlercodes von Degraded/Minor failure/Major failure werden als CRITICAL angezeigt (Returnvalue 1), bei einem Programmfehler oder leerer Response (timeout) wird UNKNOWN zurückgegeben (Returnvalue 2), bei einem Fehlercode OK_BUT wird WARNING angezeigt (Returnvalue 2)

First parameter: IP/Domainname
Second parameter: username and domain in the following structure: <DOMAIN>/<USER>
Third parameter: password
Fourth parameter: directory or file which is queried (see manual inside the bash file)
Fifth parameter: column index of health status (see manual inside the bash file)
Sixth parameter is optional: grep filter which looks for the beginning of a line and returns the whole line  | grep \“.*$6.*\“

Der letzte Parameter wird von mir verwendet, um einzelne Geräte innerhalb eines Arrays anzusprechen, bspw. eine einzelne Platte im Disk Array

Intel I218-LM Treiber für Windows PE in Enteo DSM (HP 840 G2)

Windows 8 ist in den meisten Betrieben noch nicht sehr verbreitet. Ultrabooks werden dennoch meist mit diesem OS und bald auch mit Windows 10 ausgeliefert.
Um einen neuen Rechner in Enteo DSM zu betanken, importiert man alle Treiber vom Laptop (hier: HP Ultrabook 840 G2) in die Enteo DSM Umgebung.
Es werden automatisch die aktuellen Treiber als Driver Package erstellt.
Leider gibt es hier einige Probleme mit der Boot Environment, welche auf WinPE 3.x und 4.x basiert.
Die Treiber sind nicht kompatibel und so können entsprechende Pakete von der Boot Environment nicht mehr aus dem Netzwerk geladen werden.
Auf der Suche nach den passenden Treibern, findet man viele User mit gleichen Problemen, allerdings sind die dortig verlinkten Websites meist nicht mehr verfügbar.
Die Lösung für WinPE 3.0 x64 ist hier wie folgt:

Für x32 Boot Environments sollte man einfach in den x64 durch x32 ersetzen, das sollte dann ebenso funktionieren!

Die passenden Treiber bekommt man in einer Intel I218-LM Treibersammlung von Intel.
Hier entpackt man zuerst das Paket und navigiert in den Ordner PRO1000\Winx64\NDIS63. Dort findet man nun eine Sammlung versch. Treiber für die Netzwerkkarten.
Anhand der .inf-Dateien kann man den passenden Treiber finden. Im Fall des HP 840 G2 Ultrabooks lautet die ID der NIC VEN_8086&DEV_15A2&SUBSYS_2216103C.
Der wichtige Teil ist hier die DEV-ID, also die 15A2.
In den .inf-Dateien finden wir nun versch. IDs und suchen nach folgendem Part:

%E15A2NC.DeviceDesc% = E15A2.6.2.1, PCI\VEN_8086&DEV_15A2
%E15A2NC.DeviceDesc% = E15A2.6.2.1, PCI\VEN_8086&DEV_15A2&SUBSYS_00008086
%E15A2NC.DeviceDesc% = E15A2.6.2.1, PCI\VEN_8086&DEV_15A2&SUBSYS_00011179

Quelle: e1d63x64.inf

Wie die Quelle vermuten lässt, ist die Datei die e1d63x64.inf. Nun haben wir den passenden Treiber.
Da Enteo bereits ein passendes Driver Package erstellt hat, legen wir eine neue Revision dessen an und löschen die alten Treiber aus Extern$/drv/{XY…..-….-….-ABCD}.
Nun kopieren wir den Treiber in den Ordner.
Anschließend müssen wir noch die projconf.inf anpassen, welche in Extern$/drv/ liegt. Enteo beschreibt hier die benötigten Treiber. Die Werte passen aber nicht mehr!

;Please do not edit anything manually in this luxurious file.

[Version] Signature=“$Windows NT$“

[Hardware IDs] PCI\VEN_8086&DEV_15A2&SUBSYS_2216103C

[PCI\VEN_8086&DEV_15A2&SUBSYS_2216103C] File=drv\{XY….-…-…-ABCD}\e1d63x64.inf
Friendly=“Intel(R) Ethernet Connection (3) I218-LM“

Nun das Paket neu distributen, in die Boot Environment aufnehmen und verteilen lassen. Der Treiber wird dann automatisch von Enteo geladen.

Migration von bestehender Check_MK Installation auf OMD

Da die Repositories von Debian nicht die aktuelle Version von Check_MK beinhalten, aber nur diese die Funktion besitzt SNMP Traps zu empfangen und auswerten, musste ich einen Server von einer manuellen Installation auf die OMD Installation umstellen und bestehende Daten migrieren.
Die Migration ist eigentlich sehr einfach.
Man nimmt die Daten aus dem Verzeichnis /etc/check_mk/ des alten Servers und kopiert diese auf den neuen in den Ordner /opt/omd/sites/{SITE}/etc/check_mk.
Danach überprüft man die Rechte und weist als Eigentümer (rekursiv) den Sitenamen {SITE} zu.
Danach sollten die Daten für das System beschreibbar sein.

Nun kann man sich einloggen, wird aber kurz darauf feststellen, dass die Rechte nicht stimmen. So ist der omdadmin bzw. sind die bestehenden User zwar existent, aber nicht in den richtigen Gruppen.
Also gehen wir in das Verzeichnis /opt/omd/sites/monitor/etc/check_mk, öffnet die Datei multisite.mk und fügt in der Zeile admin_users = [ ... ] den Punkt ,"omdadmin" zu.
Nun kann man die bestehenden User anpassen und die Rechte zuweisen.

Fertig! Die groben Einstellungen sind nun importiert. Dienste oder Spezialabfragen über Plugins müssen allerdings, falls versch. Nagios Versionen, neu geschrieben/installiert werden.

Pluginsverzeichnis für Check_MK ist /usr/lib/nagios/plugins. Die eigenen Plugins in diesem Verzeichnis müssen nun in das Verzeichnis von OMD kopiert werden /opt/omd/versions/1.20/lib/nagios/plugins.

Nun muss man noch die Rulesets in Check_MK entsprechend den neuen Verzeichnissen anpassen bspw.:

bash /usr/lib/nagios/plugins/my_Check_bla -H $HOSTADDRESS$ -C public -v 2c -t raid -w 90 -c 95

bash /opt/omd/versions/1.20/lib/nagios/plugins/my_Check_bla -H $HOSTADDRESS$ -C public -v 2c -t raid -w 90 -c 95

Nun sollte der Server wie gewohnt funktionieren.

Falls nicht, liegt es daran, dass der Server die alten, gecacheden Daten als valide ansieht und die neuen, da evtl. neuer Syntax, als invalide.
Beheben lässt es sich, indem man die Hosts neu prüfen lässt:

omd$mysite: check_mk -u
omd$mysite: check_mk -I {host}
omd$mysite: check_mk -v {host}

{host} ist optional, sollte das Argument nicht genannt werden, so wird der Task auf alle Hosts ausgeführt.

Natürlich müssen noch eventuell Freigaben bezüglich der Domänennamen oder IPs berücksichtigt werden. Bspw. SNMP Freigabe nur auf IP x.

Erste Schritte: Installation und Erstkonfiguration von Nagios3/Check_MK auf Debian 7.0

Um meine Windows Server 2008 R2 Server, sowie meine Virtualisierungsinfrastruktur (auf VMWare ESXI) zu monitoren, suchte ich nach einer einfachen, aber auch umfangreichen Lösung.
So stieß ich auf das sehr verbreitete Nagios Softwarepaket, welches allerdings erst mit vielen Plugins ausgestattet werden muss, um vernünftig zu funktionieren.
Daraufhin habe ich meine Suche fortgeführt und bin auf die Open Monitoring Distribution (kurz: OMD oder OMDistro) gestoßen, welche die wichtigsten Plugins und Softwarepakete in einem Paket zusammenfasst, die da wären:

  • Check_MK (umfangreiche Erweiterung auf Nagios)
  • Nagios3
  • NagVis (Visualisierungsplugin)
  • Thruk (WebInterface)
  • Icinga (WebInterface)

Ich habe mich jetzt hier aber für Check_MK und Nagios3 (logischerweise) entschieden.
Die Installation auf einem Grundsystem (hier: Debian 7.0) ist sehr einfach.

Eine statische IP Adresse muss in der network configuration gesetzt sein!

Zu aller erst lädt man sich die Distribution als .deb-Paket auf der offiziellen Website herunter und verbindet sich per SSH auf den Server.
Ich nutze im folgenden für den Datenverkehr auf den Server winSCP, welches auf SSH basiert.
Via winSCP kann man die Datei in das Verzeichnis „/usr/local/“ kopieren – natürlich sind auch andere Pfade möglich – und führt den Befehl zur Installation via gdebi aus:
gdebi /usr/local/omd-0.43_0.43lucid1_amd64.deb
Anschließend folgt man den Anweisungen, setzt die Kennwörter und konfiguriert das System.
Nach der Installation muss man noch überprüfen, ob das Modul „HTTP Redirects/Proxy“ aktiviert ist.
a2enmod proxy_http
Danach aber noch schauen, ob die Einstellungen in /etc/apache2/mods-enabled/proxy.conf richtig und sicher sind (Zugriff von außen blockieren).
Nun können wir die OMD starten, indem wir zuerst den Pfad noch festlegen, hier http://<IP>/Monitoring/:
omd create Monitoring
omd start

Nun navigiert man zu folgender Seite http://<IP>/Monitoring und sieht alle o.g. Funktionen.
Man navigiert nun zu Check_MK und geben die Admin Daten (Standarduser: omdadmin, PW: omd) ein.
Hier kann nun über die Schaltfläche Hosts, neue Hosts anlegen:

wato_hostscheckmk_newhost

 

Anschließend gibt man die Daten des Servers ein und wählt den Agent Type SNMP, wenn man SNMP nutzen möchte. Anschließend definiert man noch die Community und klickt dann auf „Safe & Go To Services“.
Hier bekommt man dann eine Fehlermeldung, dass keine Rückmeldung via SNMP stattfand

snmp_error

 

Man muss nun also noch SNMP auf dem Windows Server aktivieren.
Dazu verbindet man sich via RDP auf den Server, öffnet den Server Manager und navigiert zu Features und Feature hinzufügen.
Anschließend wählt man den SNMP-Dienst aus und lässt diesen installieren.
Nach der Installation öffnen wir die services.msc und navigieren zum Dienst „SNMP-Dienst“. Hier klicken öffnet man nun die Eigenschaften und definiert den Agent, sowie die die Community und akzeptierte Hosts:
snmp_1 snmp_2
Community ist hier: Check_MK (Rechte: NUR LESEN), die IP-Adresse des Nagios3-Servers ist 192.168.178.128, Kontakt und Standort kann man frei wählen.
Anschließend quittieren wir alles mit Übernehmen und OK.

In Check_MK können wir nun nochmals den Service-Scan ausführen und bekommen einige Infos über SNMP zugeschickt
checkmk_services

Jetzt speicher man alles und lässt die Änderungen aktiv werden:

activate_changes

Fertig! Der Server wird nun monitored und über das Dashboard lassen sich nun die Hosts überwachen.

Installieren und Konfigurieren von OpenWRT auf dem TP-Link WR710N

Der TP-Link WR710N war für kleine WLAN-Netze gut zu gebrauchen, ansonsten aber sehr langsam und instabil.
Da ich gute Erfahrungen mit meinem WR841N auf OpenWRT gemacht hatte, habe ich mich kurzerhand entschlossen auch den WR710N auf OpenWRT „umzurüsten“.
Dies ging leider nicht so einfach via Plug&Play.
Nun aber von Anfang an:

Achtung: Die Hardwareversion des TP-Link WR710N ist sehr wichtig, hier ist nur von der Version (EU) v1.1 die Rede!
Funktionalität von anderen HW-Versionen kann man hier erfahren.

Über das Repository kann man den aktuellsten Softwarestand herunterladen, in unserem Fall ist das  die openwrt-ar71xx-generic-tl-wr710n-v1-squashfs-factory.bin.

Über die Upgradefunktion der Weboberfläche unseres Routers wird die Binary-Datei, als das Update, nun aufgespielt.
Dies kann nun etwas dauern. Im Nachhinein ist der Router nur über TELNET (vorher als Putty herunterladen) über die IP 192.168.1.1 verfügbar.
Grundsätzlich ist kein root-Kennwort gesetzt und man gelangt direkt ins Terminal. Hier gleich ein sicheres (!) Passwort für den Root vergeben:
passwd

Nun muss man erstmal (sollte man ein eigenes Netz schon in Betrieb haben) die IP-Konfiguration vornehmen.
Dazu im Terminal die Datei /etc/config/network mit dem Editor vi bearbeiten.
vi /etc/config/network

Hier nun das Interface „lan“ wie gewünscht einstellen, also:
(Per ‚a‘ kommt man in das Bearbeitungsmenü, per ESC wieder ins Kommandomenü, zum Löschen einer Zeile ‚d‘ im Kom-Menü drücken)

option ipaddr 'x.x.x.x'
option gateway 'x.x.x.x'
option dns 'x.x.x.x'

Nun speichern wir per ESC + wq + Enter.

Anschließend startet man den Router per „Strom-Weg“ neu. (Der Init-Befehl  läuft bei mir leider immer in eine Boot-Schleife).
Nun kann man den Router per definierter IP-Adresse erreichen.
Will man jetzt die Weboberfläche Luci installieren, muss man opkg update ausführen.
Bei mir waren die Links in der opkg.conf veraltet, wodurch das Update bei allen Repos mit einem 404-Error abbrach.
Also muss man die /etc/opkg.conf wieder mit vi bearbeiten:
vi /etc/opkg.conf
und die Links mit diesen hier ersetzen, bsp:

src/gz barrier_breaker_base http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base

Wichtig ist der aktuelle Link: http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages

Danach nochmals opkg update ausführen.

Jetzt sollten alle Repos aktualisiert sein und man kann mit der Installation von Softwarepaketen beginnen.
So installiert man nun die Weboberfläche mit:
opkg install luci
Alle Dependencies werden hierbei direkt mitinstalliert.
Also noch den http-Server via /etc/init.d/uhttpd start starten und anschließend kann man das Webinterface besuchen, indem man die IP-Adresse per Webbrowser aufruft.
Optional, damit der HTTP-Server immer beim Booten startet:
/etc/init.d/uhttpd enable

Das war’s! Nun hat man einen vollständigen und stabilen Router mit VLAN-Fähigkeit, Firewall, VPN etc.

© 2018 Abou Chleih. Alle Rechte vorbehalten.

Thema von Anders Norén.