Probleme mit dem ffmap-backend

[phip]

Freut mich, dass Du es geschafft hast. Ich habe deinen Patch

--- a/lib/list.js
+++ b/lib/list.js
@@ -31,7 +31,7 @@ function nodetable(table, fn) {
     
     row.append("td").text(function (d) { return d.name?d.name:d.id })
     row.append("td").text(function (d) { return d.flags.online?"online":"offline" })
-    row.append("td").text(function (d) { return d.clients.length })
+    row.append("td").text(function (d) { return d.clientcount })
     row.append("td").text(function (d) { return d.wifilinks.length })
     row.append("td").text(function (d) { return d.vpns.length })
     row.append("td").text(function (d) { return d.geo?"ja":"nein" })

bei uns eingepflegt, nun funktioniert auch unsere Liste. Vielen Dank dafür.

[CHRlS]

Bei euch steht in der list_compiled.js aber:

row.append("td").text(function (d) { return d.clients.length })
row.append("td").text(function (d) { return d.wifilinks.length })
row.append("td").text(function (d) { return d.vpns.length })

siehe: http://map.freifunk-wuppertal.net/list_compiled.js

[phip]

danke Chris, ich war im falschen Kartenordner … ist schon zu lange her

[CHRlS]

aber kann man das nicht auch so schreiben das er erst clientscount versucht, dann clients.length, um alle Versionen abzudecken?

quasi

row.append("td").text(function (d) { return d.clientcount?d.clientcount:d.clients.length })

Bei uns ist @johnyb der Mann mit Ahnung, also nehmt mich einfach nicht für voll, war nur ne Idee…

[steffend]

@CHRlS

row.append(„td“).text(function (d) { return d.clients.length })

teste mal:

row.append("td").text(function (d) { if (d.clientcount != 0) {
      return d.clientcount; 
    } 
    else { 
      return d.clients.length; }
    })

Schnell und dirty zusammengeschrieben
Für richtige zahlen müsste das in die graph_compiled.js aber auch noch rein irgendwo… Aber List sollte so gehen.

[tcatm]

Warum nutzt ihr nicht den aktuellen master von je ffmap-backend und ffmap-d3? Dort habe ich Clientcount- und Statistikprobleme kürzlich behoben.

[steffend]

Also ich nutze von beidem den aktuellen Master, aber damit wurden im Graph keine Clients von Gluon Version<=2014.3.1 angezeigt ebensowenig in der Liste.
Problem ist eben, dass Gluon 2014.3.1 oder älter keine Clients mit alfred-json -r 159 -z ausgibt und die aktuelle ffmap ohne die Angabe irgendwie nichts anfangen kann.

[CHRlS]

Ich kann das Backend im Ruhrgebiet aktuell nicht upgraden, da ich dann erstmal jemanden brauche der unsere nodes_merger und nodes_filter gegen den aktuellsten Output prüft und ggfs. instand setzt.

Wenn die Communities ihre klein geschnittenen nodes.json nicht mehr haben oder der Verein die gemergete nodes.json aller Kollisionsdomänen nicht mehr hat, dann werde ich standesrechtlich mit Fackelzug erhängt

Aber bis auf die Stats Images läuft bei uns auch alles tofte, mit den jq gemergeten Alfred Daten (aus 158 und 159) als Alias angegeben und leichten Modifikationen in der Liste, da wir sämtliche Gluon Stände zwischen 0.4 und 0.6 im Einsatz haben…

[tcatm]

Bist du sicher, dass du den aktuellen master von ffmap-backend hast? Die Abhängigkeit von der Clientzahl in den alfred-Daten ist erst im dev Branch (Achtung: Dafür gibt’s noch kein Frontend) aus genau dem Grund drin. master zählt im Moment noch Clients in batadv-vis.

[steffend]

ja, mein Problem basierte ja darauf, dass mein ffmap-d3 (Branch for-uplink) mit den Clientanzahldaten des aktuellen ffmap-backend Masters bei Nodes mit Gluon älter oder gleich 2014.3.1 nichts anfangen konnte (angeblich 0 Clients). Mit Gluon 2014.4 werden die Clients korrekt angezeigt, „clientcount“ in der nodes.json…
Hab jetzt leider keinen Node mit 2014.3 mehr zum testen.
https://github.com/freifunk-ehingen/ffmap-backend
https://github.com/freifunk-ehingen/ffmap-d3/tree/ehingen-master

[Reka]

@CHRlS

Wenn die Communities ihre klein geschnittenen nodes.json nicht mehr haben oder der Verein die gemergete nodes.json aller Kollisionsdomänen nicht mehr hat, dann werde ich standesrechtlich mit Fackelzug erhängt

Wie wäre es mit einer Test-/Pilotumgebung, die schrittweise aufgesetzt wird, eine prima Map zeigt und erst nach einer Übergangsfrist, nach der sich alle an die neuen Gegebenheiten angepasst haben, das alte System komplett ersetzt?

[phip]

@tcatm

Warum nutzt ihr nicht den aktuellen master von je ffmap-backend und ffmap-d3? Dort habe ich Clientcount- und Statistikprobleme kürzlich behoben.

Deine Arbeit ist großartig Nils! Vielen Dank für ffmap-d3.

Ich nutze Gentoo und ich habe was dagegen, dass mir npm und Grunt irgendetwas am System vorbei installieren. Mir reicht ein klares „dies und jenes muss sich auf dem System befinden, notfalls bitte deinen Administrator darum“ und die Installation der ffmap-d3 sollte ohne Root-Rechte möglich sein. Für das Backend habe ich über Sudo den Zugriff auf die Batman-Tools erlaubt, aber das ist von Batman so gewollt, dass es ein Root bedient.

Ich habe von Webentwicklung keine Ahnung und bin das, was npm und Grunt anstellen nicht gewohnt.

[CHRlS]

@Reka

Wie wäre es mit einer Test-/Pilotumgebung, die schrittweise aufgesetzt wird, eine prima Map zeigt und erst nach einer Übergangsfrist, nach der sich alle an die neuen Gegebenheiten angepasst haben, das alte System komplett ersetzt?

Das ohnehin!

Aber ohne einen Entwickler der sich committed (sei es Domi, Julian oder ein neuer) bringt uns das nicht weiter…

[tcatm]

npm und Grunt kann man beides so verwenden ohne dass es wild ins System schreibt. Sowas gefällt mir nämlich auch garnicht. Die Doku dazu in der README ist aktuell tatsächlich etwas dürftig. Werde ich demnächst überarbeiten. Bis dahin helfen vielleicht meine Notizen:

Update README for bower/grunt-cli/...

[johnyb]

Wär ich dabei, sowas zu pflegen und zu entwickeln. Derzeit entwickle ich halt gegen Upstream (ffnord/ffmap-d3) und Nils hat mir mittlerweile dort auch Schreibrechte verpasst.

Ich hab derzeit leider keine leistungsfähige Hardware im Mesh, sodass ich selber immer nur temporär Dinge hosten kann. Eventuell sollte ich das mal ändern

[CHRlS]

@johnyb

Ich hab derzeit leider keine leistungsfähige Hardware im Mesh, sodass ich selber immer nur temporär Dinge hosten kann. Eventuell sollte ich das mal ändern

Kann ich Dir bereitstellen, das ist das kleinste Problem!

[steffend]

Wir haben gestern batman-adv aus dem freifunk-gluon Repository auf unserem Gateway installiert (soll ja viele patches beinhalten). Seitdem schmiert mkmap.sh mit folgendem Fehler ab:

Traceback (most recent call last):
  File "./batman.py", line 77, in 
    vd = bc.vis_data()
  File "./batman.py", line 13, in vis_data
    vds = self.vis_data_batctl_legacy()
  File "./batman.py", line 31, in vis_data_batctl_legacy
    output = subprocess.check_output(["batctl","-m",self.mesh_interface,"vd","json","-n"])
  File "/usr/lib/python3.4/subprocess.py", line 616, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command '['batctl', '-m', 'bat0', 'vd', 'json', '-n']' returned non-zero exit status 1

[CHRlS]

Die Version hat kein batadv-vis:

@tcatm

Das batman-adv-legacy unterscheidet sich wie folgt vom „normalen“ 2013.4:

vis ist rausgepatcht

no_rebroadcast ist reingepatcht
ein paar Bugfixes aus dem neueren batman-adv wurden zurückportiert (siehe commitlog)

[steffend]

also batadv-vis (selbst kompiliert) liefert Daten:

root@gw1:~# batadv-vis
digraph {
	subgraph "cluster_ea:98:f6:2a:94:9e" {
		"ea:98:f6:2a:94:9e"
	}
	"ea:98:f6:2a:94:9e" -> "56:4b:5d:3c:ef:eb" [label="1.000"]
	"ea:98:f6:2a:94:9e" -> "e8:94:f6:2a:94:9e" [label="TT"]
	"ea:98:f6:2a:94:9e" -> "34:23:ba:d5:cd:1d" [label="TT"]
	"ea:98:f6:2a:94:9e" -> "b8:27:eb:c5:31:92" [label="TT"]
	"ea:98:f6:2a:94:9e" -> "68:09:27:08:f9:12" [label="TT"]
	subgraph "cluster_a2:f7:c1:65:50:ee" {
		"a2:f7:c1:65:50:ee"
	}
	"a2:f7:c1:65:50:ee" -> "56:4b:5d:3c:ef:eb" [label="1.000"]
	"a2:f7:c1:65:50:ee" -> "a0:f3:c1:65:50:ee" [label="TT"]
	"a2:f7:c1:65:50:ee" -> "c0:9f:42:6c:4d:78" [label="TT"]
	subgraph "cluster_56:4b:5d:3c:ef:eb" {
		"56:4b:5d:3c:ef:eb"
	}
	"56:4b:5d:3c:ef:eb" -> "ea:98:f6:2a:94:9e" [label="1.000"]
	"56:4b:5d:3c:ef:eb" -> "a2:f7:c1:65:50:ee" [label="1.000"]
	"56:4b:5d:3c:ef:eb" -> "ee:db:3b:5e:a2:ed" [label="TT"]
}

Nur batctl liefert keine…

[CHRlS]

@steffend

Nur batctl liefert keine…

Vermutlich weil eben vis support komplett rausgepatcht wurde…

@tcatm

Das batman-adv-legacy unterscheidet sich wie folgt vom „normalen“ 2013.4:

vis ist rausgepatcht

no_rebroadcast ist reingepatcht
ein paar Bugfixes aus dem neueren batman-adv wurden zurückportiert (siehe commitlog)

selbst wenn es dann manuell installiert auf dem Server ist, nutzt das wenig, wenn batman respektive batctl es nicht mehr nutzen, nutzen können, nutzen wollen, usw