Moin,
wenn ich altlastenfrei heute eine neue Infrastruktur auf Gluon-Basis hochziehen könnte, was wäre der stabilste/zukunftsträchtigste Ansatz für den Kartenserver (und weitergehende Statistiken)?
Alfred wurde durch respondd(?) abgelöst? Welches Backend für Meshviewer nimmt man da? Ich habe auch 'ne Testinstallation von Meshflix (auf einem alfred-basierten Backend) irgendwo; ist Hopglass State of the Art? Oder Meshviewer-Development?
Ich hab’ da echt den Überblick verloren 
Hi Wusel,
wir benutzen bei uns seid der ablöse von Alfred folgende Kombi:
Map: GitHub - ffrgb/meshviewer: Meshviewer - more in the README
Collector: GitHub - FreifunkBremen/yanic: Yet another node info collector - for respondd to be used with meshviewer to Grafana (with influxdb or graphite)
Datenbank: Downloads
Läuft absolut Störunanfällig im Gegensatz zu Alfred vorher.
Das schöne mit der InfluxDB ist, das man sie noch für weitere Dinge nutzen kann. (+Telegraf)
Yanic kann man über Tags auch gut mit Multisite in der gleichen DB Betreiben.
Map: https://map.ff-en.de/enkreis/#/de/map
Gruß
Danke für die Info; für meinen Geschmack ist meshviewer-ffrgb zu bunt, zumindest in der bremischen Inkarnation. Die Instanz bei den Regensburgern sagt mir etwas mehr zu, die Fonts lassen sich wahrscheinlich per config.json anpassen?
In Anlehnung an die Nachbarn aus dem Münsterland habe ich testweise mal Hopglass-Server + Hopglass aufgesetzt, das finde ich schon recht schnuckelig, auch wenn mir noch ein paar Dinge aus dem Meshflix fehlen. Leider scheint ja auch Hopglass und Hopglass-Server nun ein Auslaufmodell zu sein. Also doch gleich auf Yanic/meshview-ffrgb setzen, @PetaByteBoy? Am Hopglass-Server gefiel mir der direkte Prometheus-Hook; das gibt’s bei Yanic nicht, oder?
Eine Sache ist mir aber noch unklar bzgl. announced respondd, siehe hier (warum batman- und nicht bridge-Interface?).
Hi,
/me Entwickler vom Meshviewer und vermutlich eher einseitige Ansicht, daher wollte ich zuerst nicht antworten. Aber zu deinen Fragen:
Keine der beiden Instanzen ist Vanilla. Bremen ist jetzt auch nicht mein Fall und auf unsere Regensburger Instanz nutzten die Font von der Webseite. Standardfont ist Assistant und es gibt eine Custom SCSS Bereich um genau so etwas anzupassen und keine Konflikte zu bekommen.
Vanilla Instanz (Repo laden NodeJs lokal haben und gulp serve für eine dev Umgebung zum anschauen)
EDIT: https://meshviewer.darmstadt.freifunk.net/ (Live Vanilla Meshviewer)
PR für neues Format wurde gestern in Yanic gemerged und unterstützt den „future“ Branch (siehe Link oben) der vermutlich heute in Meshviewer develop landet. Neue Sachen wie Nexthop,2 TQ werte usw. NICHT kompatibel mit anderen Backends. Yanic arbeitet auch mit respondd und unterstützt aktuell Influx und Whisper/Graphite.
Also soweit ich mitbekommen hab soll Hopglass weiterentwickelt werden und der Link von oben verweist eher auf den Fork von unserem Repo. GitHub - hopglass/ffrgb-meshviewer: WIP - HopGlass based on Freifunk Regensburg Meshviewer fork
xaver
Nur kurz von unterwegs …
Wie immer ist das etwas schwierig; ich bin sehr dankbar für Meshviewer & die Tools drum rum. Das Netz visualisieren zu können halte ich für ziemlich essentiell, sowohl für die Außendarstellung als auch Netzplanung.
That said: 2014 war das Aufsetzen der Kartenservices eher kein Spaß.
Mit respondd haben wir ein Standardformat für die Quelldaten; besteht nicht die Möglichkeit, auch die verarbeiteten Daten zu standardisieren, damit verschiedene Tools darauf zugreifen können?
Ja, Koordination saugt, macht keinen Spaß und frißt Zeit. Aber machte es nicht ‚aus 10.000 Fuß betrachtet‘ doch Sinn? (Siehe API, freifunk-karte, …)
Vlt interessant die Infrastruktur die aktuell viele Communites nutzten die den Meshviewer haben.
Struktur PDF mit Links (81,2 KB)
Schöne Visialisierung, danke.
Derzeit ist das bei uns noch alles alfred-basiert (statt gluon-anounced/respondd), „yanic“ sind ein pre-Meshviewer- (die alte Karte haben wir noch als „Geo-Picker“ im Config-Mode mitgeschleppt, da Meshviewer das damals nicht konnte) sowie ein Meshviewer-ffmap-backend, ffapi-Daten werden aus dem ffmap-backend-Output erzeugt. Drum herum gibt’s dann noch Kram, der im Zweifel mit rrdtool im Hintergrund arbeitet …
Das tut „meist“ — nur, wenn es nicht tut (~ 1x im Jahr, nicht soo schmerzhaft), ist das mehr so ein stochern im Nebel. Daher das Ziel, hier mal feucht durchzuwischen und mit was modernem durchzustarten. (Ohne Funktionsverlust und zuviel optische Änderungen, wenn möglich.)
Als TSDB ist hier Prometheus gesetzt; Ausfluß des späten Aufspringens auf diesen Zug. Da fließen schon die Daten der HVs und VMs rein und werden per Grafana aufbereitet. Insofern fällt dann wieder alles raus, was nicht direkt mit Prometheus spricht oder wo nicht zumindest Tools für die Übergangszeit bereitstehen (KISS; zudem: mehr als eine TSDB zu betreiben erscheint nicht sinnvoll).
Ich weis nicht wie die Daten in das Prometheus kommen. Yanic muss nichts schreiben, dass ist eine config und eventuell kann man auch ein Prometheus Anbindung bauen. Es scheint einen go client zu geben GitHub - prometheus/client_golang: Prometheus instrumentation library for Go applications
Prometheus-Exporter fragen i. d. R. eine /metric-URL ab, vgl. Exporters and integrations | Prometheus
Cool, kannte ich nicht, danke! Leider wieder ein anderes Format als der Hopglass Server liefert (http://hopglass.4830.org:4000/metrics)
Gleiches Format nur anders formatiert mit leicht abweichenden metrics 
Ja, das meinte ich; Format ist ja von Prometheus vorgegeben 
Ich setz’ jetzt mal „for the time being“ auf Hopglass Server + Prometheus, dann ist zumindest schon mal die Alfred-Abhängigkeit weg Muß ja eh’ 'ne Zeit parallel laufen der Kram.
Es gibt auch diese möglichen Kombinationen:
HopGlass-Server mit experimentellem neuen Hopglass
Yanic mit experimentellem neuen Hopglass
Demo dieses neuen experimentellen HopGlass hier: https://pbb.lc/build/#/en/map
Äh, dort funktioniert der Zurück-Button des Browsers nicht mehr richtig. Innerhalb der Seite selbst schon, aber man kommt nicht mehr von dort ins Forum zurück.
Ich hol’ das mal neu hoch, aus $Gründen:
… fragte ich vor über 2 Jahren. Viel Zeit ist ins Land gegangen, HopGlass mit Server kam und (gefühlt) ging, yanic ist da und kann verschiedene Formate, und was Meshviewer angeht, gab’s mal aktive Entwicklung in Regensburg und dann einen lauten Knall …
Aus dem Münsteraner Ansible fällt derzeit ein HopGlass samt zugehörigem HopGlassServer raus, das ist ja soo schlecht nicht, aber AFAICS auch nicht zukunftsfähig. Ich hätte da gerne was aktiv entwickeltes, d. h. wohl yanic und ein später Fork der Regensburger Meshviewer-Weiterentwicklung (die IIRC ein spezielles Datenformat wollte?) — Vorschläge?
Wir wollen zum Meshviewer, aber wegen diversen Änderungen im Backend und auch im Gluon klemmt das noch. Alles vermutlich kein Hexenwerk, hat nur noch keiner Zeit für gehabt.
Wir wollen zum Meshviewer, aber wegen diversen Änderungen im Backend und auch im Gluon klemmt das noch. Alles vermutlich kein Hexenwerk, hat nur noch keiner Zeit für gehabt.
Die Frage ist ja gerade, welchen MV man als Basis nimmt. Welcher Fork wird aktuell noch weiterentwickelt, welcher ist hinreichens feature-complete & stabil? Hab’ da den Faden verloren und möchte nicht mit meinem Fork von Annodunnemals starten 
Das mit multiplen yanics habe ich vor 'nem Jahr oder so schon mal umgesetzt, aber da noch auf HG-Basis, IIRC.
