Dies ist der letzte Teil des Artikels, hier ist der Anfang
Beim letzten Mal habe ich darüber geschrieben, wie ich das Monitoring von Geräten umgesetzt habe. Jetzt geht es um das Management. In Diskussionen mit den „Technikern“ auf Seite des Auftraggebers stoße ich oft auf ein eingeschränktes Verständnis der Möglichkeiten solcher kleinen Geräte (mit begrenztem Speicher und Leistung). Viele glauben, dass das Maximum, was wir benötigen, das Senden eines Reboots ist, für ernstere Probleme würden wir eine Mannschaft schicken.
Aber die Praxis zeigt, dass das nicht ganz richtig ist. Hier ist eine kleine Liste häufiger typischer Aufgaben:
- Netzwerkdiagnose und -behebung. Hinter dem Ethernet-Port Ihres Routers „lebt“ normalerweise ein anderes Gerät mit seiner eigenen internen IP-Adresse. Manchmal muss es „gepingt“ werden. Oder Tunnelmanagement – wenn bei einem Router, der über ein 3G-Modem arbeitet, das Tunnel plötzlich nicht hochgeht, aber wir den Router sehen können.
- Systemwartung. Firmware-Updates, Upgrade von Dienstscripts.
- Akrobatik. Man könnte dies auch „Exzesse“ nennen, aber der Begriff „Akrobatik“ ist, zitiere, Die Fähigkeit eines Zirkuskünstlers, das Gleichgewicht in einer instabilen Körperhaltung zu halten. — ist passender. Solche Situationen entstehen aufgrund des begrenzten Budgets des Auftraggebers. Unten habe ich ein paar Beispiele angeführt, aber da sie keinen direkten Bezug zum Thema haben, sind sie in die Anmerkungen verschoben.
Wi-Fi-ÜberwachungIn den letzten fünf Jahren hat ein modernes Thema vor allem in den großen Einzelhandelsketten an Bedeutung gewonnen. Man schlendert gemächlich durch die Verkaufsräume, während das eigene Mobilgerät mit aktiviertem Wi-Fi unermüdlich Probe-Requests versendet, um sich mit einem Netzwerk zu verbinden. Diese Daten werden analysiert, um zu ermitteln, wie oft man den Laden besucht und welche Wege man zurücklegt. Die gesammelten Informationen werden ausgewertet und in Form von Heatmaps dargestellt, auf deren Grundlage Manager versuchen, Gelder von der Unternehmensführung oder Investoren zu erhalten. Währenddessen bleibt die Aussage: „Es gibt kein Geld, aber Sie halten durch…“, und das tatsächliche Ergebnis muss präsentiert werden. Dann kommt das alte Lied: „Ja, ja, später werden wir natürlich die nötigen Systeme installieren, aber jetzt müssen wir dem Auftraggeber Ergebnisse zeigen! Übrigens, wir haben vergessen zu erwähnen, dass der Auftraggeber uns erlaubt hat, unsere Geräte über Wi-Fi mit seinem Hotspot zu verbinden, allerdings unter allgemeinen Bedingungen, als wären wir Gäste.“ So kommt es, dass komplizierte Routerkonfigurationen erforderlich werden: mehrere Wi-Fi-Schnittstellen werden eingerichtet, von denen eine mit dem Hotspot verbunden ist und eine andere die Umgebung überwacht. Dabei wird hastig das tcpdump-Ergebnis gespeichert, das anschließend in ein Archiv gepackt wird, während der Router, als ob er an Überlastung leidet, versucht, den Inhalt an einen FTP-Server zu übertragen. Es ist nicht überraschend, dass der Router oft „abstürzt“ und in der Folge remote „reanimiert“ werden muss.
RadiusHier kann die Situation vereinfacht durch folgende Aussage des Auftraggebers beschrieben werden: „Wir möchten ein dezentrales Netzwerk von Hotspots, die auf nicht näher spezifizierter Hardware betrieben werden, über Kanäle, deren Art wir noch nicht kennen. Ach, das haben wir vergessen zu erwähnen: Wir möchten nicht nur Werbung an die Kunden ausspielen, sondern auch alles um den Aufstellungsort des Hotspots herum analysieren. Nein, wir wissen derzeit nicht, wozu das gut sein soll, aber wir werden uns schon etwas einfallen lassen – das schaffen wir, schließlich haben wir diese Idee auch entwickelt.“
Und wir dürfen nicht vergessen, dass angesichts vieler unvorhersehbarer Umstände die Verwaltung unter nichtstandardisierten Bedingungen erfolgen muss, wenn wir nicht direkt über IP: Port auf den Router zugreifen können und einfach auf ein Signal von ihm warten müssen. Wenn wir abstrahieren, kann der Dialog zwischen Server und Router folgendermaßen dargestellt werden:
- Router: Hallo. Ich bin der Router, gibt es Aufgaben für mich?
- Server: Router, ich habe dich registriert, du bist aktiv. Hier ist die Aufgabe: Zeige mir das Ergebnis des Befehls ifconfig.
- Router: Hallo. Ich bin der Router, beim letzten Mal hast du mich gebeten, das Ergebnis von ifconfig zu zeigen. Hier ist es. Gibt es Aufgaben für mich?
- Server: Router so und so, ich habe dich registriert, du bist aktiv. Es gibt keine Aufgaben für dich.
Die interessanteste Frage ist: Wie kann der entfernte Router eine bestimmte Menge an Informationen senden? Im vorherigen Teil habe ich beschrieben, dass auf dem Router aufgrund begrenzter Ressourcen nur eine „reduzierte“ Version von wget läuft, die nur über GET funktioniert, und es gibt keinen FTP-Client oder curl. Genauer gesagt, wir brauchen eine universelle Methode, unabhängig von den Besonderheiten des Image-Baus. Ich habe mich für die Verwendung von wget entschieden. Genauer gesagt, nun, wie soll ich sagen „entschieden“ – ich hatte einfach keine Wahl 🙂
Eine sofortige VorbemerkungMeine Lösung zur Verwaltung ist funktional, nicht stark eingeschränkt und ich bin mir sicher – ungeschickt, obwohl sie die meisten meiner Kunden zufriedenstellt. Wie könnte es besser gemacht werden? Man könnte ein kleines Tool schreiben, das über Port 80 binäre Daten via POST sendet. Dieses Tool in die Firmware des Routers integrieren und dann über Bash darauf zugreifen. Doch die Realität sieht so aus: a) es muss schnell sein b) eventuell müssen wir alles auf dem vorhandenen "Zoo von Routern" umsetzen c) "nicht schaden!" – wenn der Router funktioniert und andere Aufgaben erfüllt, sollten Änderungen möglichst wenig die bestehenden Funktionen beeinträchtigen.
Kommen wir zur Implementierung. Angenommen, Ihr Kunde möchte den Router aus Zabbix unkompliziert und bequem mit einem "Mausklick" neu starten. Heute beginnen wir mit der Beschreibung der Implementierung in Zabbix.
Im Menü „Verwaltung“ -> „Skripte“ fügen wir ein neues Skript hinzu. Wir nennen es „Reboot“ und geben als Befehl „php /usr/share/zabbix/reboot.php {HOST.HOST}“ an.
Weiter: Menü „Monitoring“ -> „Letzte Daten“ -> „Rechtsklick auf den gewünschten Netzwerknoten“. So wird das Menü nach der Hinzufügung des Skripts aussehen.
Dementsprechend platzieren wir das Skript reboot.php im Verzeichnis /usr/share/zabbix (bei Ihnen kann es anders sein, ich verwende das Root-Verzeichnis von Zabbix).
Hinweis zur SicherheitUm die Erklärung zu verdeutlichen, verwende ich im Skript nur die ID des Routers, aber kein Passwort. In der Produktionsversion wird dies nicht empfohlen! Warum ich das so gemacht habe: Weil die Frage, wo man Passwörter für Router aufbewahrt, sehr groß ist. Im Zabbix selbst in den „Inventardaten“? Eine widersprüchliche Praxis. Eine Möglichkeit wäre: den Zugriff auf die Datei reboot.php von außen einzuschränken.
Die Datei reboot.php
set_charset("utf8");
// "Senden" Sie den Reboot-Befehl durch Ändern des Feldes task in der Tabelle users. Im Feld task können Sie jeden Befehl senden.
$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
$sql_users->bind_param('s', $user);
$sql_users->execute();
$sql_users->close();
?>Das ist alles. Bleibt die Frage offen, wie man das Ergebnis der Ausführung eines Befehls vom Gerät erhält. Schauen wir uns die Aufgabe am Beispiel des Befehls ifconfig an. Einen solchen Befehl kann man an das Gerät senden:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, wobei:
message=`ifconfig` — wir weisen der Variablen $message das Ergebnis des Befehls ifconfig zu
wget « — unser Skript a.php, das Router registriert und Nachrichten von ihnen empfängt
u=user&p=password!&m=$message — die Zugangsdaten und der Wert der Anfrage-Variable m — erhält den Inhalt der Variablen $message
-O /tmp/out.txt — die Ausgabe in die Datei /tmp/out.txt ist in diesem Fall nicht erforderlich, aber wenn man diesen Parameter nicht angibt, funktioniert wget nicht
Warum funktioniert das nicht richtig?Weil dies ein potenzielles Sicherheitsrisiko darstellt. Der harmloseste Fehler, der passieren kann, ist, dass im Ergebnis Ihrer Befehle beispielsweise das Zeichen „&“ erscheint. Deshalb müssen alle Daten, die von den Routern gesendet und an den Server empfangen werden, gefiltert werden. Ja, mir ist das peinlich, wirklich. Zu meiner Verteidigung kann ich nur sagen – dass der gesamte Artikel dem Management von Routern mit nicht vordefinierter Firmware und unbestimmten Kommunikationskanälen gewidmet ist.
Und zur zukünftigen Nutzung: Ich habe noch nicht herausgefunden, wie man mit den Standardmitteln von Zabbix die Ergebnisse (zum Beispiel das Ergebnis eines Befehls), die auf den Server kommen, darstellen kann.
Ich möchte daran erinnern, dass alle Quellcodes aus dem Git-Repository heruntergeladen werden können unter der Adresse:
Quelle: habr.com
