[Solved] Meshviewer + Gateway announcen

Moin!

Nach langer Zeit versuche ich mich mal an nem Update unseres Meshviewers. Vorher hatten wir ne ganz alte Version noch mit ffmap-backend laufen. Was neues sollte/musste her. Zuerst mit HopGlass versucht, aber das wollte irgendwie gar nicht. Lag mit Sicherheit aus einer Mischung von eigener Unfähigkeit sowie mangelnder Dokumentation.

Habe mich dann mit Yanic GitHub - FreifunkBremen/yanic: Yet another node info collector - for respondd to be used with meshviewer to Grafana (with influxdb or graphite) und dem neuen Meshviewer GitHub - ffrgb/meshviewer: Meshviewer - more in the README auseinander gesetzt und mit Hilfe eines Kollegen auch diese dann zum laufen bekommen.

Nur unsere Gateways erscheinen nicht. Logisch, irgendwie vermisse ich beim Yanic die Möglichkeit ne alias.json anzulegen, wie es früher beim ffmap-backend möglich war.

Auch die Geschichte mit auf den Gateways laufenden respondd will nicht so recht. Die respondd Programme für Server die ich bis jetzt gefunden haben lassen sich entweder gar nicht starten oder liefern keine Daten. Hab jetzt eines gefunden das bei mir jetzt zu mindestens läuft. GitHub - freifunk-saar/node-respondd: A respondd server written in node.js.

Aber die Info das der Server ein Gateway ist scheint nicht an den Meshviewer übermittelt zu werden.

Hat jemand ne aktuelle HowTo für die ganzen aktuellen Map Geschichten irgendwo, am besten in Deutsch, wo man sich mal selbst wieder auf Stand bringen kann?

2 „Gefällt mir“

Da kannst Du auch GW flags und andere dinge™ per Hand setzen.
Alfred / Respondd

1 „Gefällt mir“

Wie @Comacho schon richtig gesagt hat dann respondd und den anouncer (Name ist etwas irritierend). Einfach laufen lassen und alle Infos und links tauchen auf.

Kannst auch gerne im IRC vorbei schauen. hackint #meshviewer

xaver

Den habe ich als erstes ausprobiert. Der lies sich zwar starten, aber hat keine Daten gesendet. Ich habe auch kein Config File für das Teil gefunden wo ich angebe auf welchem Interface er lauschen und seine Daten senden soll wenn ein Multicast Request kommt. Scheint mir komplett nur für das FFNord Netz angepasst zu sein.

Hier zeigt sich mal wieder wie wichtig ne gute Dokumentation ist. Man kann dieser ffnord-alfred-announce respondd.py tatsächlich Parameter mitgeben. Warum zum Teufel ist das nicht dokumentiert?

Ok. Direkt auf der als Root Console aufgerufen mit dem Parameter ./respondd.py -i br-ffue -b bat0 tut das Teil was es soll. Als Dienst jedoch nicht. Es werden keine Daten gesendet.

● respondd.service - Respondd
Loaded: loaded (/etc/systemd/system/respondd.service; enabled)
Active: active (running) since So 2017-05-14 11:58:31 CEST; 8min ago
Main PID: 1949 (python3)
 CGroup: /system.slice/respondd.service
       └─1949 python3 /opt/ffnord-alfred-announce/respondd.py -i br-ffue -b bat0

Mai 14 11:58:31 ffue-sv01 systemd[1]: Starting Respondd...
Mai 14 11:58:31 ffue-sv01 systemd[1]: Started Respondd.
1 „Gefällt mir“

Schnell einen PR stellen!

Also wir setzen das von Anbeginn unserer Community (EN-Kreis) ein, allerdings benutzen wir Alfred und nicht respondd.

    usage: announce.py [-h] -d DIRECTORY [-b BATMAN]

optional arguments:
  -h, --help            show this help message and exit
  -d DIRECTORY, --directory DIRECTORY
                        structure directory
  -b BATMAN, --batman BATMAN
                        batman-adv device


Usage: ./announce.sh [-i <ifname>] [-b <batadv-dev>] [-u <alfred socket>]

Was fehlt denn deiner Meinung nach noch an Dokumentation? Github Issue :smiley:

Genofire (yanic/meshviewer)

Auch für die link erkennung ein zweites -i auf das vpninterface, welches in den bat0 eingehangen

Ffrgb und Bremen nutzten alfred-announce von ffnord. Rolle aus Bremen für ansible:
https://github.com/FreifunkBremen/ansible/tree/master/roles/respondd

Die Idee das umzubenennen und in unsere Doku zu packen existiert schon länger, aber bisher nicht geschehen.

1 „Gefällt mir“

PR = Public Relation?

Anyway, wieso läuft das Teil auf der Konsole und nicht als systemd Service?

PR = Pull Request (auf Github)

Wir machen das so:

:/usr/local/bin# cat alfred-announce
#!/bin/bash

# for every device for which a alfred instance should run
for MESH in /sys/class/net/*/mesh; do
  BATIF=$(echo $MESH | sed -r 's/\/sys\/class\/net\/(.*)\/mesh/\1/')
  MASTER=$(echo $BATIF | sed -r 's/bat/br/')
  /opt/alfred-announce/announce.sh -b ${BATIF} -i ${MASTER} -u /var/run/alfred.${BATIF}.sock
done

Zusammen mit einem cronjob :

# Puppet Name: update-alfred-announce
* * * * * PATH=/opt/alfred/:/bin:/usr/bin:/sbin:/usr/sbin/:$PATH /usr/local/bin/alfred-announce

Ihr benutzt ALFRED. Wir wollen Respondd nutzen. Und die Frage ist immer noch wieso das respondd.py in der Shell tut wie es soll, aber als Systemd Service nicht.

Spontan würde ich sagen weil es als Dienst nicht die gleichen Rechte hat oder Pfade fehlen.

@Freifunker wie sieht denn das Config-File für den Service aus?

Sieht so aus das noch Rechte fehlen!

@Handle

So sieht meines aus:

[Unit]
Description=Respondd

[Service]
ExecStart=/opt/ffnord-alfred-announce/respondd.py -i br-ffue
Restart=always
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[Install]
WantedBy=multi-user.target

Keiner ne Idee?

Auch wenn ich das File so setze, also explizit als Root laufen lassen, funktioniert es nicht im systemd.

[Unit]
Description=Respondd

[Service]
ExecStart=/opt/ffnord-alfred-announce/respondd.py -i br-ffue
Restart=always
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User=root

[Install]
WantedBy=multi-user.target

So, klappt jetzt.

[Unit]
Description=Respondd

[Service]
ExecStart=/opt/ffnord-alfred-announce/respondd.py -i br-ffue
Restart=always
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
WorkingDirectory=/opt/ffnord-alfred-announce

[Install]
WantedBy=multi-user.target

WorkingDirectory scheint gefehlt zu haben. Jedenfalls übermittelt das Teil jetzt Daten zur Map.

2 „Gefällt mir“