Sollten wir das nicht in einem zweiten Schritt machen? Um erst einmal zu sehen, das alle Knoten in das neue Netz rüber kommen?
Sonst verlieren wir den überblick an welcher Stelle es hakt!
Wir sollten auch nicht vergessen, das u.U. viele Knoten Offline sind wegen dem Lockdown. So sieht es mir auf jeden Fall auf der Karte aus bei vielen die Langzeit Offline sind. (unter anderem sind einige Kneipen Offline, Fitnesstudios, und Vereinsheime, …)
Ist halt in der tng-FW drin; in der fastd-site.conf gehen alle ‘Domänen’, wie das im Gluon-Sprech heißt, entweder auf die 4 fastd-Server für GT oder die 2 für Müritz. In der l2tp-site.conf haben gut, gto, gt8, rhw sowie wrz/neb und fsl jeweils andere v6-ULA-Adressen und Gateways.
Kann man rückbauen, zumal eh’ noch eine weitere tng-Firmware nötig ist: mit dem Schwenk auf tng als stable soll tng ja eingestellt werden — aber dann würden heutige tng-Knoten niemals mehr Updates bekommen. (Gleiches gilt für den, an der Müritz oft eingesetzten, master-Branch.)
Firmwarebuild 1.1.5~42 (sic!) würde Autoupdater von tng auf rawhide und von master auf stable setzen — und noch kein Mesh-Splitting vornehmen. Dennoch ändern sich die Ports, für Kreis GT von 10000 auf 10001 (Mesh GT Stadt) und an der Müritz von 10169 auf 10005 (Mesh Müritz).
Einwände, Kommentare?
Meine bedenken sind eher wegen der Port Änderungen. Einen Fallback Server mit 10000 Port geht nicht, oder? (Evtl. auch ohne Funktionalität. So könnten wir dann aber gezielt die Knotenbetreiber ansprechen und würden dann nicht nur einen Offline Knoten sehen)
Ist aktuell nicht vorgesehen, sprich gibt keinen. (Und wenn, dann müßten es ja zwei sein, Müritz lief seit jeher auf 10169.)
Es geistert allerdings die Idee herum, daß die Knoten nach Erstinstallation in ein »Default-Mesh« kommen und aus diesem dann per zentraler Konfiguration ins »Ziel-Mesh« verschoben werden. Damit könnten die Veränderungen an der Gluon-Basis weiter reduziert werden, was die Adaption neuerer Versionen beschleunigen könnte. Und im Zweifel auch wieder Offline-Konfiguration möglich gemacht werden — wobei es dafür bislang keine Nachfrage gab …
Bei denen hatte ich vor, sofern eingetragen, die Kontaktmailadresse mit einem Hinweis auf die Änderungen (Link zu den Beiträgen) einmalig anzuschreiben; möglichst als individuelles Ticket zwecks Nachverfolgbarkeit.
Die alten fastd-Gateways könnten sicherlich noch bis 31.03.21 oder so weiter laufen; ich hatte auch nicht direkt vor, am 01.02.21 00:00 diese runterzufahren. Ein Enddatum würde ich aber schon setzen wollen, und sei es, um die (v4-) IPs wieder freizubekommen.
Fallback in dem Sinne geht mit der Ansible-basieren Automatisierung auch nicht. Die Portnummer ermittelt sich aus, Pseudocode, “Port=$Portbasis + $Domainnummer”. Domainnummer ist ein numerischer Wert, mehr oder weniger willkürlich in einer Konfigurationsdateil festgelegt für alle Meshes.
Natürlich kann man in der Firmware l2tp-gut00.4830.org:10000 bei den »NRW-Meshes« und l2tp-wrz00.4830.org:10169 bei den »MeckPomm-Meshes« hinzufügen — und diese beiden Gateways bekäme man auch über Ansible deployed, denke ich.
Nur: dann würden sich Knoten zufällig mit einem der Gateways verbinden, also entweder mit ihren »richtigen« Meshes (Lokalisierung Stadtgebiet GT über Port 10001, Nordkreis über 10003, …), ggf. aber auch mit dem Fallback-Gateway. Sprich: wir würden in Kauf nehmen, daß wir die eigentlich getrennten Meshes über Knoten bridgen könnten (zwei Knoten mit WLAN-Mesh und zwei Uplinks, einer nach 10001, einer nach 10000) oder von Knoten zu Knoten sich die dahinterliegende Infrastruktur ändert (anderer v4- und v6-Bereich), die Clients also beim AP-Wechsel offline gehen.
Gefühlt haben wir im Kreis GT keine Handvoll Knoten, die auf Port 10000 festgenagelt sind — es ist kaum nachgefragt worden, was freizuschalten sei. Ich weiß von einem Autohaus, wo das vor ~5 Jahren relevant war. Aber ja, wir wissen es nicht.
Hmm, OK, also Aufmerksam sein und schauen das wir alle mit bekommen.
Und dann das Netz stabil halten und schauen das wir bei neuen Knoten aktive Knotenaufsteller haben.
Ich denke, das geht relativ gut:
https://map03.4830.org/map_Freifunk%20KreisGT/ (fastd-Karte; rawhide updated auf L2TP-FW => Knoten gehen in fastd-Mesh offline):
https://newmap.4830.org/map_Freifunk%20KreisGT/ (L2TP-Karte; Knoten tauchen neu in L2TP-Mesh(es) auf):
Ebenso Feldberg; aus Müritzer fastd-Karte raus …
… tauchen sie auf Feldberger Karte auf — zumindest bis auf zwei:
Hmm, 17258-HDG-Offloader hat’s schein’s nicht geschafft, und dadurch ist auch 17258-HDG-Tagungsraum wohl offline.
Vielleicht weiß @charrr näheres? Bei den ERXen gibt’s ja ein seit Gluon v2020.1 bekanntes Problem (1.1.5~41 basiert aber noch auf Gluon 2018.2.x; keine Ahnung, ob es da auch zum Problem werden kann):
Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
das hatte ich schon erwartet. dort muss noch die portfreigabe in der firewall geändert werden. werde mal kontakt zum it dienstleister von denen aufnehmen.
bleibt es denn bei port 10005/6 für fsl oder ist absehbar, dass sich das in nächster zeit nochmal ändert?
können wir die Links der funktionierenden Karten als Linksammlung z.B. auf https://map.4830.org/? Ich habe mittlerweile drölfzig Links wo Karten sein könnten, aber es nicht mehr sind.
Ja, der virtuelle Webserver map.4830.org wird wohl auf eine Webserver-VM (web01.4830.org oder so) umziehen, dort dann auf die neuen Ziele für die kommunizierten Links (map.4830.org/ffgt, map.4830.org/mueritz) zeigen (per redirect denke ich). hopglass.4830.org und die anderen temporären Mapserver werden dann wieder eingestampft.
BTW, irgendwas ist mit dem Tile-Caching auf newmap.4830.org im Argen 
2a06:e881:260c:1:1202:b5ff:feb1:ae68 - - [10/Jan/2021:14:36:15 +0100] "GET /tiles_cache/osm_mapnik/12/2143/1353.png HTTP/2.0" 500 251 "https://newmap.4830.org/map_Freifunk%20KreisGT/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0"
Wäre klasse, wenn sich das jemand ansehen könnte; ich verstehe gerade nicht, was Nginx da hat.
Edit: Bzw. überhaupt, wie das Tile-Caching funktioniert; stammt alles aus Ansibe und tat 'ne zeitlang 
Hallo! Du (Kai ‘wusel’ Siering via Freifunk Kreis GT) hast geschrieben:
BTW, irgendwas ist mit dem Tile-Caching auf newmap.4830.org im Argen
2a06:e881:260c:1:1202:b5ff:feb1:ae68 - - [10/Jan/2021:14:36:15 +0100] “GET /tiles_cache/osm_mapnik/12/2143/1353.png HTTP/2.0” 500 251 “https://newmap.4830.org/map_Freifunk%20KreisGT/” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0”
Wäre klasse, wenn sich das jemand ansehen könnte; ich verstehe gerade nicht, was Nginx da hat.
Fixed.
proxy_set_header Host $http_host;
darf NICHT gesetzt werden, sonst weiss OSM/Fastly nicht wo die Reise
hin gehen soll.
auskommentiert.
Cord
Erm, bei mir nicht?
2a06:e881:260c:1:1202:b5ff:feb1:ae68 - - [10/Jan/2021:16:31:56 +0100] "GET /tiles_cache/osm_mapnik/12/2144/1356.png HTTP/2.0" 500 263 "https://newmap.4830.org/map_Freifunk%20KreisGT/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0"
Shift-Reloaded, root@newmap ~ # systemctl restart nginx.service gemacht. Still no tiles?
Hallo! Du (Kai ‘wusel’ Siering via Freifunk Kreis GT) hast geschrieben:
Erm, bei mir nicht?
2a06:e881:260c:1:1202:b5ff:feb1:ae68 - - [10/Jan/2021:16:31:56 +0100] “GET /tiles_cache/osm_mapnik/12/2144/1356.png HTTP/2.0” 500 263 “https://newmap.4830.org/map_Freifunk%20KreisGT/” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0”
Shift-Reloaded,
root@newmap ~ # systemctl restart nginx.servicegemacht. Still no tiles?
Please retry.
Ugly hack enabled…
proxy_set_header Host a.tile.openstreetmap.org;
Cord
Works, danke! Lustig; hat sich da »kürzlich« was bei OSM geändert? Weil, initial läuft’s, aber auch auf map03.4830.org zeigen sich erste Ausfallerscheinungen. Und auch die Münsterländer Karte zeigt bei mir nur noch grau — ihr Ansible hat da auch noch den $host-Header drin.
Hallo! Du (Kai ‘wusel’ Siering via Freifunk Kreis GT) hast geschrieben:
Works, danke! Lustig; hat sich da »kürzlich« was bei OSM geändert? Weil, initial läuft’s, aber auch auf map03.4830.org zeigen sich erste Ausfallerscheinungen. Und auch die Münsterländer Karte zeigt bei mir nur noch grau — ihr Ansible hat da auch noch den $host-Header drin.
keine AHnung. Mittlerweile zeigen ([abc].)?tile.openstreetmap.org alle
auf fastly und immer auf dieselben IPs.
Damit das da funktionieren kann muss man den richtiugen Host-Header
mitschicken.
Vielleicht haben die kürzlich erst umgestellt? Muss wohl:
Cord
Okay, dann kann dies wohl weg:
upstreams:
name: openstreetmap_backend
servers:
- a.tile.openstreetmap.org
- b.tile.openstreetmap.org
- c.tile.openstreetmap.orgIst nginx intelligent genug damit der bei mehreren IPs auch mehrere durchprobiert falls eine mal fehlschlägt?
Bei [a-c].tile.openstreetmap.org bestünde immerhin die Chance das da verschieden aufgelöst wird.
Hallo,
Ja Nginx kann sowas grundsätzlich. Bevor wir hier zu einer finalen Konfig kommen, würde ich aber erst einmal herausfinmden wollen was OSM dazu schreibt. Mit der Umstellung muss es doch irgendwelche Empfehlungen von denen geben?
Cord