seit einiger Zeit arbeite ich an einem kleinen Projekt um per announced Informationen von den Nodes abzufragen. Das ganze ist im Prinzip mittlerweile sogar in der Lage alfred abzulösen. Hier der Link
Die Vorteile von meinem Projekt gluon-announced sind:
Es ist möglich Information zu einzelnen Nodes per REST abzufragen
Statistiken werden für Prometheus aufbereitet
Es werden alle Daten weiterhin für den meshviewer aufbereitet
Einfache Installation, da nur eine statisch gelinkte Binärdatei
Individuell konfigurierbare Abfrageintervalle
In Dortmund betreiben wir damit jetzt seit einiger Zeit testweise eine Karte neben der klassischen ffmap-backend Installation und es funktioniert sehr zufriedenstellend. Vor allem die Integration mit Prometheus sehe ich als großen Vorteil um Probleme besser visualisieren und überhaupt erkennen zu können.
Was allerdings noch fehlt ist die Seite für Supernodes und map-Server. Grundsätzlich kann man den respondd auf Debian kompilieren. Aber die Lua-Skripte müssen an vielen Stellen angepasst werden und ich habe eigentlich mit dem ganzen Konzept respondd/announced ein wenig Bauchschmerzen. Ich möchte nur sehr ungerne auf den Supernodes einen Dienst laufen lassen, der als Root laufen muss (weil Port 1001 genutzt wird und der Daemon keinen Cap drop kann) und der aus den teilen der Query ungefiltert einen Pfad zusammenbaut. Ich sehe da aktuell recht viel Angriffsfläche.
Auch aufgrund dieser Angriffsfläche schwebt mir daher aktuell ein anderer Ansatz vor, Informationen über Nodes zu sammeln. Da wir den Nodes durch unsere Infrastruktur sowieso einiges an zentralen Servern vorgeben (Supernodes, NTP-Server, DNS-Server) wäre auch recht unproblematisch eine Art „Collection-Server“ anzugeben und die Nodes pushen in den passenden Abständen aktualisierte Informationen an diesen Server. Dadurch würden statische Infos (wie die nodeinfos) nur nach dem Start übertragen, sich oft und regelmäßig Informationen wie Uptime und Traffic könnten in regelmäßigen Abständen übertragen werden (auch als eine Art „Keep-Alive“) und sich unregelmäßig ändernde Informationen könnten bei jeder Änderung direkt übertragen werden (Mesh-Neighbours, Clients etc.). Ich könnte in meinen bestehenden gluon-collector wahrscheinlich recht einfach einen CoAP-Server einbauen um solche Informationen per CoAP entgegen zu nehmen.
Das ist jetzt erstmal nur eine grobe Idee und ich bin auf Feedback gespannt. Also sowohl zum gluon-collector, als auch zu der Idee Node-Informationen per CoAP auf einer zentralen Instanz zu sammeln.
Das kann man doch umgehen, indem man den Daemon auf einen port > 1024 lauschen laesst, und per iptables Anfragen auf Port 1001 nach Port xxx weiterleitet.
Es läuft schon seit Wochen stabil in Dortmund und imho experimentieren Essen und andere Communities damit. Zusammen mit @chrisno wird sogar gerade eine Version getestet, die auf mehreren Interfaces arbeiten kann.
Läuft derzeit im Test wesentlich besser als der alfred Kram. Weniger CPU, load.
Das Praktische sind die metcrics für Prometheus, die mit rausfallen.
Sobald das auf mehreren Instanzen läuft, wird das alfred bei uns komplett ersetzen.
@chrisno braucht es dafür was besonderes auf Node-Seite? Wo kommen die Daten genau her? Ist all das verfügbar, was derzeit von Alfred übermittelt wird?
Zwei Sachen fehlen mir noch. Die Möglichkeit für mehrere Instanzen(da ist @dereulenspiegel gerade mit dran) und etwas über die Supernodes. Ich denke da brauchen wir ein announce Script auf eben diesen.
@MrMM der gluon-collector ist auch in der Lage eine legacy nodes.json zu importieren, dadurch gehen Dinge wie die Zeit seitdem ein Node Teil des Netzes ist nicht verloren.
Was tatsächlich in Dortmund ein Problem ist, sind Leute die nicht den Autoupdater nutzen (weil sie z.B. ihre Firmware selber bauen) und schon länger nicht geupdatet haben bzw. aus irgendwelchen Gründen die announced-Pakete entfernt haben. Aber das ist bei rund 350 Nodes nur eine Hand voll.
Für die Supernodes könnte man tatsächlich einfach die announced Skripte portieren. Ich hatte da mal angefangen. Das Problem was ich damit hatte war, dass respondd aktuell als root laufen muss und praktisch die Ausführung beliebiger Lua-Skripte erlaubt. Das finde ich auf den Nodes schon unschön, auf einer Supernode möchte ich so etwas auf keinen Fall.
Entweder man bringt respondd capabilities drop bei oder man implementiert was anderes, was auf die Requests für announced hört.
theoretisch ginge das natürlich, wäre aber eher eine Art fieser Hack. Denn die Aufgabe vom gluon-collector ist es die Nodes in einem Mesh abzubilden. Und zwar anhand der Informationen, die von den Nodes aus dem Mesh erhältlich sind.
Die schönere Variante ist es also, wenn auf den Supernodes noch ein passender Agent läuft, der diese Infos bereitstellt. Genauso wie auf den kleinen Nodes. Wenn also jemand darüber nachdenkt die Funktion „alias-Datei“ zu implementieren, sollte er darüber nachdenken ob die Entwicklungszeit nicht besser in einem passenden Agent für Supernodes eingesetzt wäre. Aber gegen gut gemachte Pull Requests wehre ich mich auch nicht.
ERRO[0310] Error parsing json client=[fe80::62e3:27ff:fe76:302e%bat0]:1001 error=json: cannot unmarshal number 2230774334.0000001 into Go value of type uint64 json={"statistics":{"node_id":"60e32776302e","clients":{"wifi":0,"total":0,"wifi24":0,"wifi5":0},"rootfs_usage":0.53571428571428567,"memory":{"cached":3092,"total":28540,"buffers":1492,"free":6128},"uptime":396457.45,"idletime":379270.32,"gateway":"a2:8c:ae:6f:f6:01","processes":{"total":44,"running":1},"traffic":{"tx":{"packets":84254,"dropped":156,"bytes":14200785},"rx":{"bytes":624691967,"packets":5692690},"forward":{"bytes":870,"packets":6},"mgmt_tx":{"bytes":2230774334.0000001,"packets":10944893},"mgmt_rx":{"bytes":766253396,"packets":4530778}},"loadavg":0.13}}
Map Sagt:
TypeError: Cannot read property ‚nodes‘ of undefined
also der Error im Log kommt daher, dass 2230774334.0000001 kein gültiger Integer-Wert ist. In dem Json ist das die Anzahl der Bytes des Traffic. Das sieht also eher nach einem Bug in einem Lua-Skript von announced aus, denn Bruchteile von einem Byte sollte es beim Traffic nicht geben.
TypeError: Cannot read property ‚nodes‘ of undefined
Das kann schonmal auftreten kurz nachdem der gluon-collector gestartet ist. Der braucht etwas um alle Infos zu sammeln und aktuell generiert er vorher keine gütige nodes.json. Das wird in Zukunft aber sicher noch geändert.
Sind schon Debian bzw RPM Pakete geplant? Ich installiere eher ungern Compiler auf den notwendingen Servern wo die Software laufen soll. Außerdem erleichtert es das Setup ungemein
