ich überlege, wie man das am sinnvollsten baut, wenn die Unifi-Geräte sich auf mehr als ein Dutzend verschiedene L2-Domains verteilen. Die sind aber alle in einem Controller.
Es gibt da mehrere Möglichkeiten, die mir aber alle schmerzhaft erscheinen.
Nochmal Frage zur Architektur, ich habe da Verständnisproblem, wie ich das SCript möglichst wenig Traffic erzeugen lasse (und vielleicht ohne eine VM auskomme, die in N domains hängt)
Welche Rolle hat der besagte Offloader in diesem reporter?
Wo wollte man das Script sinnvollerweise drauf installieren?
Mein Szenario:
Mapserver, die mehrere Dutzend Domains bedient (und zu unterschiedlichen Maps aggregiert)
Unifi-Controller, der NICHT im Freifunk-L2 hängt, und
Es ist völlig egal, wo der Unifi Controller hängt unserer ist auch nicht im L2 Netz, so lange der unifi_respondd irgendwie an den hinkommt, kann er ihn abfragen.
Du kannst den Mapserver einfach angeben, nachdem keiner der Mapserver wirklich überprüft ob die Daten die reinkommen plausibel sind, kannst du für alle Domains sprechen egal ob die Konfiguriert sind. Die Karte macht nachher vermutlich das richtige draus.
Der Weg vom Script zum Controller ist mir klar.
Aber wie kommen die Informationen in den Mapserver, ohne dass die Daten in allen Domains erscheinen?
Zumindest beim Hopglas kann man zwar nach Domains filtern, ich müsste dann aber das json mit (allen) Unifies in allen Domains laden und dann erst im Client filtern?
Alternativ wäre, das Script n mal für entsprechend viele Domains zu installieren und den Host in die jeweilige Domain zu hängen, damit er dem Mapserver die respond-pakte auch in die richtige hopglas-server-Instanzu liefert.
Zu dem Thema ist mir noch eingefallen, wenn du jeweils einen User erstellst der nur auf die jeweiligen Sites im Unifi Controller kann passend zur L2 Domain für die der unifi_responnd läuft. Dann solltest du ohne doppelte Daten auskommen.
root@avm4040-gluon# pip3 install -r requirements.txt
[…]
ERROR: Could not install packages due to an OSError: [Errno 28] No space left on device: '/usr/lib/python3.6/site-packages/geopy/geocoders/mapbox.py'
root@avm4040-gluon:~/unifi_respondd# df -h .
Filesystem Size Used Available Use% Mounted on
overlayfs:/overlay 22.7M 22.4M 296.0K 99% /
vielen Dank für die tolle Arbeit.
Wir haben bisher für das einbinden der Unifi-Geräte eine von uns angepasste Version des unifi-meshviewer-generator genutzt. Dieser ist aber leider nicht sehr robust bei Änderungen und zerschießt uns regelmäßig die Karte.
Daher habe ich mir mal euren unifi_respondd angeschaut.
Nach einigem probieren habe ich es nun auch zum laufen gebracht. Die Möglichkeit, die Knoten über yanic zu integrieren gefällt mir sehr, da sie so auch in der Statistik ohne umwege erfasst werden.
Nun ergeben sich für mich noch 3 Fragen:
Wie können die Knoten verortet werden? Im Controller sind die Knoten mit Hilfe der Map eigentlich verortet. Das hatte so auch mit unserer alten Variante funktioniert.
Ist es möglich bestimmte Unifi-Sites nicht mit auszugeben? Wir verwalten mit unserem Controller auch einige Installationen, die wir nicht auf der Karte haben möchten.
Wäre es möglich, die fallback-Domain „ffmuc_unifi_respondd_fallback“ über die config einstellbar zu machen? Dies in der unifi_client.py (richtige Stelle?) zu editieren ist sicherlich nicht update-sicher bzw. ich müsste das Git-Repository forken…