Die folgende Meldung brachte mich, beim Konfigurieren einiger Service-Checks in Icinga2, kurzzeitig zum Weinen: icinga critical/config: Error: Stack overflow while evaluating expression: Recursion level too…
Kategorie: Nützliches
icinga critical/config: Error: Stack overflow while evaluating expression: Recursion level too deep.
Hat man sich für Icinga2 die Weboberfläche installiert und eingerichtet, möchte man am liebsten auch die Konfiguration von Icinga2 darüber erledigen. Am besten noch zentral für alle Server. Genau hier setzt das Modul Icinga Director an. Ich gebe zu: die Funktionsweise vom Director ist etwas komplexer, als deren Einrichtung. Hat man die Logik dahinter erst einmal verstanden, erleichtert er die Arbeit mit Icinga2 enorm.
Voraussetzungen
Zuerst kommt aber die Installation. Ich starte hier mit einem neuen, sauberen System, wie es auch empfohlen wird. Natürlich kann man den Director auch unter einem Produktivsystem mit fertigen Konfigurationen von Servern und Agenten zum Laufen bringen. Allerdings ist dann etwas mehr Handarbeit notwendig, welche unter Umständen auch den zuverlässigen Lauf des Monitorings negativ beeinflussen kann. Der Knackpunkt ist, dass der Director keine fertigen, aktiven Konfigurationen einliest. Diese bleiben von ihm unangetastet und sind somit kein Bestandteil seiner Einrichtung. Somit müssen die weiterhin händisch über einen Editor gepflegt werden, oder man überträgt sie Stück für Stück.
Die folgenden Voraussetzungen müssen erfüllt sein, damit die Installation auch klappt:
Wer in seiner Freizeit schon mal den einen oder anderen Server an der Start geschoben hat, der wird wissen, dass Fehler immer passieren. So lange es ein Hobby ist und die Server nur zur persönlichen Benutzung laufen, dann ist das auch nicht so wild. Schwierig wird es, wenn auch noch andere Leute diese Server nutzen und man selber für die Zuverlässigkeit verantwortlich ist. Spätestens dann sollte man sich an die Konsole setzen und Monitoring für diese Dienste und Server schaffen.
Das Gute – mittlerweile bieten sehr viele Provider schon von Hause aus ein rudimentäres Monitoring an. So wird meist die Auslastung der CPU, des Arbeitsspeichers und der Netzwerkschnittstelle im Benutzerportal für jeden, einzelnen Server angezeigt. Außerdem bekommt man eine Benachrichtigung, wenn der Webserver keine Seiten mehr ausliefert, oder auf Pings nicht mehr reagiert. Damit kann man bei einem Server schon gut leben.
Aber was ist, wenn man gerne mehrer Server auf einen Blick haben möchte? Wie funktioniert das bei Servern, welche bei unterschiedlichen Providern laufen? Und hier kommt Icinga2 ins Spiel. Die Einrichtung ist gar nicht so kompliziert. Und mit den richtigen Erweiterungen wird daraus ein sehr nützliches Tool für jeden Hobby-Admin. Wie das Ganze aussehen und funktionieren kann, versuche ich hier zu beschreiben.
Ich bin ein Fan von Realtime-Kommunikation. Schnell mal hier und da eine Nachricht abgeschickt und schon ist die Planung perfekt. Kein ewiges Telefonieren oder Emailen sondern schnell eine Nachricht raus und fertig. Um so schlimmer empfinde ich jedoch die schier unendliche Anzahl an Protokollen und Netzwerken, die es für das Versenden von solchen Nachrichten gibt. Und leider gibt es keine Lösung, welche allumfassend für jeden Benutzer funktioniert. Somit müsste man sich für jeden Dienst einen Account und die nötige Software auf allen Geräten installieren.
Daran habe ich schon vor Jahren die Lust verloren. Und hier kommt Trillian – ein Multi-Protokoll-Client. Diese Software ist für Windows, MAC, Android, iOS und sogar für den Blackberry verfügbar. Sollte ein System nicht unterstützt werden, gibt es immer noch den WEB-Zugang, der im Browser auch auf Rechnern sehr gut funktioniert, wenn man die Software nicht installiert hat oder installieren kann.
Vor Kurzem hatte ich mich auf die Schnelle mit dem BMP085 auseinander gesetzt. Und da Adafruit gute Vorarbeit leistete, war das Endergebnis recht schnell erreicht und ich hatte die drei Werte, welche der Sensor ausgeben kann, aus dem unendlichen Schwarz der Konsole auf den Schirm gelockt. Leider sind die Werte dort nicht wirklich nützlich. Also habe ich mir einen Tag Zeit genommen, um noch ein wenig mit dem Sensor zu spielen, die Werte zu speichern und über ein gefälligeres Medium – einen Browser – auszugeben.
Hier nun ein kurzer Abriss darüber, wie ich es anstellte, was ich mir dabei dachte und wie ihr es mir nachmachen könnt, gesetzt den Fall, ihr seid im Besitz eines Raspberrys und eines BMP085. Am Ende könnt ihr euch hier auch das Python-Script laden und selber etwas experimentieren. Und hey, solltet ihr Fragen oder Tipps haben, einfach ab damit in die Kommentare. Aber beginnen wir.
Als stolzer Besitzer einer DiskStation bin ich natürlich permanent auf der Suche nach nützlichen Anwendungen für den Server. Die DiskStation bring dafür von Hause aus schon ein Paket-Zentrum mit, über das man sehr einfach und bequem über die WEB-Oberfläche zusätzliche Softwarepakete installieren und somit den Mehrwert des Servers steigern kann. Manche Pakete bekommt man allerdings darüber leider nicht. Um dennoch in den Genuss einer einfach Installation von zusätzlichen, inoffiziellen Paketen zu kommen, benötigt man einen alternativen Paketmanager, wie z. B. das IPKG (Itsy Package Management System).
Vor einiger Zeit war es nur über die Konsole (SSH) und durch eine manuelle Installation möglich, das IPKG zu installieren. Dank Alexander Over ist es jedoch möglich, das IPKG über das Paket-Zentrum der DiskStation zu installieren. Da ich damit ein paar (lösbare) Probleme hatte, möchte meinen Installationsweg kurz beschreiben. Der Ausgangspunkt ist eine Synology DS2413+ und das aktuelle DSM 4.3. (Ich gehe davon aus, dass jeder weiß, wie er sich über SSH mit der DiskStation verbinden kann.)
Da habe ich neulich nicht schlecht gestaunt, als das Display meiner geliebten EOS 500 D einfach aus ging und auch schwarz blieb. Dabei habe ich eine ganz alltägliche Prozedur durchgeführt, wie mir jeder Benutzer einer Digitalkamera bestätigen würde. Ich habe die kleine Klappe geöffnet, hinter der sich die SD-Card verbirgt, habe die volle Speicherkarte entnommen und durch eine leere Karte ersetzt. Nachdem ich die kleine Klappe schloss, signalisierte diesmal die kleine, rote Kontroll-Led durch ein kurzes Aufblinken nicht – wie sonst immer – den Zugriff auf die Speicherkarte, sondern blieb dunkel. Das Display zeigte ebenfalls kein Leben. Ein kurzer Blick durch den Sucher lies mich erkennen, dass zwar grundsätzlich noch Leben in der Kamera war. Jedoch konnte ich nach dem Anvisieren eines Motivs dieses durch den beherzten Druck auf den Auslöser nicht wie gewohnt digitalisieren. Es passierte einfach nichts!
Ich entzog der Knipse kurz entschlossen den „Saft“, indem ich die Verriegelung vom Akkupack löste und diesen aus dem Griff zog.
ist meist der Satz, mit dem entweder die größten oder zumindest alle ungeplanten Aufgaben starten. So heute auch bei mir. Eigentlich wollte ich „nur mal eben“ den Sensor meiner Canon EOS 500 D reinigen. Die Aufgabe lümmelte nun schon über drei Monate auf meiner Aufgabenliste herum, und nun fand ich es Zeit, diese davon zu tilgen. Die dazu nötigen Materialien hatte ich schon besorgt: ein Mikrofasertuch (ständiger Begleiter meiner Kamera), kompakt verpackte Luft in einer Dose und Reinigungsticks samt Reinigungsflüssigkeit von „Amazonien“. (Die Sticks verlinke ich hier nicht, da sie sich als etwas zu groß herausstellten. Da gibt es Bessere!)
Die nachfolgenden Arbeitsschritte sind recht simpel: Kamera über das Menü auf „manuelle Sensorreinigung“ stellen, die Reinigungsflüssigkeit vorsichtig und wohl dosiert (also nicht in einer „Ich-wässere-mal-eben-den-Küchenfußboden-Menge) auf den Stick aufbringen und dann wischt man von links nach rechts in einem Zug über die gesamte Sensorfläche. Das wiederholt man so oft, bis aller Dreck verschwunden ist. Das war alles kein Problem und schnell erledigt. Aber dann!
Ich werte das Ergebnis für den Anfang mal als Erfolg und gehe nun ins Bett. Trotz der rudimentären Kenntnisse in Elektronik und Programmierung, welche für…
Kaum haben die ersten Arbeiten begonnen, gibt es schon die ersten Verletzten. Nach dem Einsatz im Wohnzimmer als multimediales Abspielgerät (raspbmc), wollte ich den Raspberry Pi wieder ins Arbeitszimmer umsiedeln. Schließlich sollte er mir noch seinen Desktop (raspbian) zeigen. Als ich den Empfänger der Tastatur-Maus-Kombination entfernte, fiel mir ein Stück Plastik entgegen, welches sich sehr schnell als das sehr wichtige, mittleres Teil des USB-Ports zu erkennen gab. Interessanter Weise verließ dieses Stück Plastik sein Platz nicht durch Anwendung übermäßiger Benutzergewalt, oder durch verflixt straffe USB-Stecker, sondern allein durch die normale Nutzung. Ich vermute mal, dass der USB-Port schon vorher etwas angeschlagen war.
Da für mich das Zurücksenden nicht in Frage kam, ich aber unbedingt zwei funktionsfähige USB-Ports wollte, kam für mich nur eine selber durchgeführte Reparatur in Frage.