Announced statt alfred im Mesh nutzen und der nächste Schritt

Hallo zusammen,

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.

Grüße :smile:

8 Likes

@RubenKelevra @Felix macht ihr das bei euch nicht schon mit den Statistiken per zentralem Server?

Ich bin kein Fan von zentralen Servern und denke, announced braucht noch ein bisschen Entwicklung. Bis dahin reicht alfred aus.

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.

Das ginge tatsächlich. Aber für viele der Lua-Skripte benötigt man wahrscheinlich immer noch recht weitreichende Rechte.

Kann man die sehen die Karte?

1 Like

@dereulenspiegel ist das ein teil davon https://status.ffdo.de/
gib uns doch mal einen link bitte.

Hi! Die Karte gibt es unter http://map.ffdo.de/meshviewer-test/ Die Statusseite wird aktuell noch anders generiert.

Hallo,

ist das tool mittlerweile nutzbar?

Gruß
Fabian

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.

Moin,

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.

Gruß

Chrisno

Wie ist euer vorgehen damit in der Übergangszeit nicht ein Teil der Knoten aus der Karte raus fliegt?

Moin,

momentan laufen die parallel. Was soll da rausfliegen?

Gruß

Chrisno

@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?

Moin @dgoersch,

auf Router Seite braucht es nichts. gluon-announce ist seit 2015.1 (?) mit drin und aktiv.
Auf Server-Seite braucht es GitHub - ffdo/node-informant: Small utility to collect node information in a Freifunk network via announced.
Ja, es ist alles über die Router an Informationen verfügbar, was es jetzt auch gibt. Als JSON für den Meshviewer und als metric für Prometheus. Außerdem noch extra Infos.

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.

Gruß

Chrisno

1 Like

Hi,

@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.

Hi @dereulenspiegel,

ich habe den gluon-collector gerade mal testweise in Troisdorf aktiviert. Funktioniert auf den ersten blick super!

Was natürlich fehlt sind dinge wie VPN uplinks. Kann man das nicht wie im ffmap-backend mit einer aliases Datei implementieren?

1 Like

Hi @stefan

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.

1 Like

Die Agent variante gefält mir natürlich auch besser!

Baut da denn schon wer etwas?

EDIT:

Hast du eine erklärung für den Fehler hier: Freifunk Troisdorf - loading... ?

Die jsons kannst du unter http://data.freifunk-troisdorf.de/troisdorf/jsons/ sehen

Log:

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

Hi,

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.

1 Like

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 :slight_smile: