Fastd mit ansible-ffms: Howto?

Korrekt. Mangels Testkandidaten fällt das manchmal hinten über.

Danke dir.

Sagt mal, dies protocol static static_domaene{{domaene[0]}} { in bird6.conf.j2, soll das für FFRL/FFNW-Upstream sein? Macht irgendwie sonst keinen Sinn, /56er-Routen zu erzeugen, oder was übersehen ich?

V6 läuft bei uns derzeit nur über den FFRL, weil wir unser PI-V6 noch nicht richtig in Betrieb haben. Das steht auch noch auf das langen langen Aufgabenliste.

Du hast fast die Frage beantwortet :slight_smile: Der FFRL routet IIRC bis auf /56 runter, daher würde es Sinn machen, /56er Routen aus den /64ern zu machen, die in den Meshes konfiguriert werden. @stefan6, wie haltet Ihr das, nähmt Ihr auch /64er?

Hintergrund der Frage: wir (FFGT) sind ja auch mit eigenem AS unterwegs, wir routen intern auf /64er runter, daher sind im Ansible aus beliebigen /64ern erzeugte /56 kontraproduktiv. Ich würde daher dies entsprechend in if defined FFRL…" -Abfragen packen, oder eine neue Variable, Upstream_v6_min_prefix oder so, einführen.

Hi,

ja, bei uns geht auch /64 :wink:

1 „Gefällt mir“

Beim FFRL geht meines Wissens nach auch /64, aber nur eine gewisse Anzahl, ein paar Hundert oder so.

Dann stellt sich die Frage, warum Ihr die Domänen-/64 (oder was immer da angegeben wird vom Nutzer — was anderes als ein /64 macht für SLAAC aber keinen Sinn) in bird6.conf.j2 auf /56 erweitert? Weiß das noch wer? :slight_smile:

Ja, weil der FFRL früher keine /64 angenommen hat. :stuck_out_tongue:

Ok :slight_smile:

Zum Kartenserver hab’ ich auch 'ne Frage: wir haben Ortskürzel als Site-/Domänenidentifizierung, also „gut“, „rhw“, „wrz“ und so, Ihr, soweit ich das sehe, „ffmsd01“, „ffmsd60“ usw. Ihr konfiguriert per Ansible den Hopglass-Server so, daß er auf allen Tunneln zu den Domänen lauscht und dann greift Ihr über Rewrite-Regeln im Nginx auf z. B. $server:4000/nodes.json?…&site=d01 zu, sehe ich das richtig?

Eine echte Trennung der Datensammlung auf Mesh-Ebene ist das aber nicht? Wenn ich in Domäne d01 einen Knoten mit Kennung d60 laufen ließe (Config-Änderung auf dem Knoten), würde der auf der Karte in Domäne 60 auftauchen, oder? Dafür rennt nur ein Hopglass-Server, statt ein Datensammler pro Domäne/Mesh …

Kurz gesagt: Ja. :slight_smile:

btw. man möchte nicht 70x Hopglass-Server haben auf dem Karten Server. Das hab ich ausprobiert und für scheiße befunden. Vor allem weil die VM sich beim Booten so schnell zerledert das man die Instanzen auch nicht mehr beendet bekommt… :see_no_evil:

Man kann natürlich den Sammeldienst / Hopglass-Server auf den Gateways laufen lassen. Hat aber dann das Problem das man ${AnzahlGatewaysInDomäne} Endpunkte per Domain in das Frontend einbinden muss und keinen Punkt mehr hat wo man Zentral Knotendaten hat. Doof für Freifunk API, freifunk-karte.de oder was auch immer…

Yo, macht Sinn. Hab’s etwas umgebaut für uns, da wir mit Strings arbeiten und nicht dXX; ist halt eine Rewrite-Rule je Domäne, aber es gibt komplexere Nginx-Configs :slight_smile: Außerdem können die Daten auch von $Woanders kommen, so können wir auf newmap.4830.org auch die Daten von den Yanics des alten Setups anzeigen (andere batman-Version) :heart:. Ich mach’ die Tage mal 'nen PR.

PR ist raus:

Ein paar Erweiterungen der Rollen:

  • BREAKING CHANGE: über ipv6backbone64prefixstr muß nun der interne v6-Präfix für Tunnel gesetzt werden — 2a03:2260:115:ffa1:: sollte nur FFMS nutzen.
  • BREAKING CHANGE: Port 25 wird vom Mesh gen Internet blockiert.
  • BREAKING CHANGE: Um ‚zone „{{freifunk.kurzname}}.“‘ weiterhin konfiguriert zu bekommen, muß „have_local_kurzname_zone“ gesetzt werden. (Wir nutzen 4830.org als freifunk.kurzname, und damit erzeugt die Rolle eine falsche Version der öffentlichen Domain. Zudem tun „private“ TLDs in aktuellen, insbesondere mobilen, Browsern eher so mäßig — mit DoH wird’s auch haarig.)
  • ospf_nat_ip kann analog ff*_nat_ip verwendet werden, um diese IP im internen Routing per OSPF bekannt zu machen.
  • gateways_l2tp_slovenija nutzt letzten python2-kompatiblem commit vor der Änderung auf python3-only.
  • Es gibt eine „FFGT-Version“ des Mapservers, welche statt numerische Domains zu erzwingen mit normalen Textbezeichnern umgehen kann, ferner können dem Hopglass auch externe Quelle zugeführt werden.
  • Bei ipv6_direkt_ausleiten wird ein zusätzlicher OSPF-Prozeß gestartet, der die lokalen Netze dem internen Routing bekannt macht, sodaß auch der Rückweg klappt.
  • Kleinere Fixes.
1 „Gefällt mir“

Neue Frage: wie wird Graphite befüllt? Bei meinen Knoten bleiben die statistischen Daten irgendwie auf der Strecke, z. B. bei https://newmap.4830.org/map01/#!v:m;n:8c3badd95829 :frowning: Yanic pustet die Daten ja auf Wunsch in eine InfluxDB, aber Hopglass-Server kann das AFAICS nicht (hat dafür einen Prometheus-Endpunkt)?

Wir drücken unsere node-stats mittels https://github.com/FreiFunkMuenster/node-stats in eine Graphite / Carbon-cache Instanz mit Grafana Frontend.

Graphite ist von den Möglichkeiten her ganz nice erinnert aber Ressourcen Verbrauchs technisch ehr an die dicke Oma von Nebenan. Wenn ich es neu aufbauen würde dann würde ich Persönlich vermutlich auf InfluxDB setzen.

Ah. Leider wird das aber AFAICS nicht deployed, weil auskommentiert:

Da kann ich ja lange warten/suchen :wink:

Jo die Rolle ist nie Fertig geworden… :man_shrugging:

Hmm, ja, bin nicht der erste, der da reintappt :wink: Okay, kein Hexenwerk, Rolle fixe ich heute abend. Noch 'ne kurze Frage: ich hätte auch Bedarf, nodes.json an Graphite zu verfüttern.

Allerdings:

root@newmap /opt/node-stats # ./main.py --hopglass-raw https://newmap.4830.org/proxy_ffgt/nodes.json
Open config.json from file: ./config.json
Download nodes.json from URL: https://newmap.4830.org/proxy_ffgt/nodes.json
Traceback (most recent call last):
  File "./main.py", line 65, in <module>
    main()
  File "./main.py", line 38, in main
    handler = DataHandler(rawJson.data, config.data, args.alternative_now, rawType)
  File "/opt/node-stats/DataHandler.py", line 53, in __init__
    self.interfaces = self.__mapIfIDtoNodeID__()
  File "/opt/node-stats/DataHandler.py", line 249, in __mapIfIDtoNodeID__
    for nodeID, nodeData in self.data.items():
AttributeError: 'list' object has no attribute 'items'

Aus dem Code hatte ich gehofft, daß nodes.json statt raw.json erkannt werden sollte, aber das trügt?

Gibt’s ggf. 'ne magische jq-Zeile, um nodes.json nach raw.json zu wandeln?

Puh… das kann vermutlich der @descilla besser beantworten.

nicht das ich wüsste.

Das wäre mal interessant zu wissen; habe jetzt extra Yanic (läuft für den Altkram) aktualisiert, da der neuerdings auch eine raw.json liefern kann — aber diese raw.json ist was anderes als das, was Hopglass-Server produziert, grmpft.