Hallo @nomaster, @CyrusFox
wir sind soweit, dass wir die kompletten Knoten der Region auf unsere Supernodes loslassen können.
Habt ihr von Witten schon ein konkretes Vorgehen oder sollen wir unseren Plan dafür ausbreiten?l
1 „Gefällt mir“
Um den Aufwand für die Rheinufer Admins klein zu halten schlage ich folgendes vorgehen vor:
- Abschalten der Autoupdates außerhalb des fastd tunnel um Router identifizierbar zu machen.
- Mittels .htaccess oder anderen einfachen Mitteln ein Update an alle Router der Regio Aachen ausrollen, es soll als einzige Änderung einen neuen Updateserver und neue Signaturen für Updates enthalten. Die Router bleiben Teil der Domäne Rheinufer und der Updateserver wird per fastd ebenfalls in Domäne Rheinufer eingebunden. Aachen stellt eine Liste mit den entsprechenden IPv6 Adressen
- Die Aachner kümmern sich um das Verfahren bei dem die Router in der richtigen Reihenfolge Updates bekommen damit keine Satteliten raus fliegen. Bei diesem Update wird tatsächlich die Domäne gewechselt.
4 „Gefällt mir“
So ähnlich schwebte mir das auch bereits vor. Ich dachte an eine Auslieferung eines Updates, dass den Auto-Updater so verändert, dass er beim nächsten Lauf die Koordinaten oder andere Infos mitschickt, um dann ein entsprechendes neues Image zu bekommen.
Anschließend können wir das Netzsegment recht einfach aufteilen, in dem wir die Supernodes per Update wechseln.
geht also nicht so naiv wie gedacht.
nächste Idee sowas zu implementieren ist dann (wie in der Diskussion von NeoRaider dort vorgeschlagen):
- static string aus dem gluon-autoupdater Paket generieren lassen
- dem autoupdater diesen static string anhängen
bei ersterem würde ich eventuell zu einem Cron-Job tendieren, der die nötigen Informationen per uci set ... volatil in den config-Baum schreibt - ohne uci commit schreibt sowas ja den Flash nicht kaputt und da die Information sowieso ständig durch den Cron neu generiert wird muss sie ja auch nicht persistent abgespeichert werden.
Vielleicht könnte man auch einfach die MAC Adresse aus der IPv6 Adresse nutzen um die Nodes zu segmentieren.
Apache setzt dazu die Umgebungsvariable HTTP_REMOTE_ADDR.
Ich nehme mal an, dass das Autoupdate via IPv6 ausgeführt wird?
Jain - die Nodes mit Uplink gehen mit ihrer eigenen WAN-IP raus… für die Mesh-Satelliten ohne eigenen Uplink ist das kein Problem…
Sofern wir nur IPv6 erlauben und externe IP Adressen verbieten wird daraus mein ursprünglicher Plan und somit ein: Ja
Diese Einschränkung führt lediglich dazu dass wir nur in der Lage sind Knoten zu versorgen die im Mesh Netz sind, also im Regelbetrieb alle.
Offensichtlich zieht sich die Sache noch.
@nomaster @CyrusFox wir haben eine Menge roamender Clients die vollständig ihre Konnektivität verlieren, das ist großer Mist.
Können wir als Sofortmaßnahme wechselseitig auf unseren Supernodes die IPv4 Gateway Adressen der jeweils anderen Domäne Eintragen? Zusätzlich sofern nicht identisch noch die DNS Server Adressen. Das ist in Sekunden erledigt und verbessert das Freifunk Erlebnis für die Nutzer enorm.
1 „Gefällt mir“
@nomaster, ich hoffe die Genesung geht voran. @CyrusFox, geht für dich die angedachte Migrationsmethode auch in Ordnung?
Welchen Server verwendet ihr denn für die Updates, apache, nginx, was anderes? Dann machen wir euch das Config File fertig.
Wollt ihr die Übergangs Firmware die nur unsere Schlüssel und Update Server einführt und sonst nichts ändert selber kompilieren oder wollt ihr nur die Manifest Dateien unterzeichnen?
Klingt soweit OK, wir haben nur keine Updateserver mehr direkt im Mesh sondern nur via Public V6 und V4.
DNS-Server können wir nicht hinzufügen, wir nutzen dafür Anycast und das würde den Vorteil davon negieren. IP-Adressen der Supernodes könnte klappen sofern das nicht mit dem Routing irgendwas zerschießt.
Ich würde einfach jede Node Anhand der Public V6 bzw anhand des Mac-Adressen Anteils der Public V6 identifizieren und per Proxy-Pass an euren Update-Server weiterleiten sollte eine Node von euch nach Updates schauen.
Die wichtigste Grundvoraussetzung ist, dass all eure Knoten irgendwie die 2a03:2260:114::b0b erreichen, für die Reihenfolge kritisch sind die reinen Mesh Knoten. Bei diesen können wir sicher sein dass sie nur über ihre Freifunk IPv6 Adresse anfragen werden. Da ich die Statusseite der Rheinufer Router aus dem Aachener Netz öffnen kann sollte das passen. Das ist aber Schritt 2
Bei Schritt 1 müssen wir zunächst zusehen, dass wir allen Aachener Knoten in beliebiger Reihenfolge das Migrations Update verpassen. In der Regel sollte IPv6 bevorzugt werden, falls nicht gibt es mit Sicherheit Möglichkeiten es zu erzwingen.
ist ja noch die Frage wie rum, oder hab ich das überlesen…?
- Aachen baut (normale) ffac-Firmware, legen die bei uns ab und das Manifest wird von Rheinufer unterzeichnet, dass die Nodes diese als Update akzeptieren
- es gibt ein Rheinufer-Intermediate-Update, welches in der site-conf die ffac-Schlüssel drin hat, dass dann beim nächsten Update-Check sich per proxy-pass durch die Rheinufer-Server sich das ffac-Image holt…
ersters ist ja quasi fertig und muss nur noch ne Unterschrift im Manifest kriegen
zweiteres war mir schon zu kompliziert als ich es gerade hingeschrieben habe … 
und gerne darf auch unser externer Update-Server 2001:470:78c4:201::ffac:80 benutzt werden - der hat auch alle Images - mir nur vorher bitte bescheid sagen, dass ich dort auch noch die Regel mit den Satelliten-zuerst einbaue
In etwa so, hier nochmal das an die so oder so externen Update Server angepasste Vorgehen:
- Mittels .htaccess oder anderen einfachen Mitteln ein Update an alle Router der Regio Aachen (in der Domäne Rheinufer) ausrollen, es soll als einzige Änderung einen Aachener Updateserver (eine direkte IPv6 Adresse, zusätzlich ein dns name als Reserve) und neue Signaturen für Updates. Aachen stellt eine Liste mit den entsprechenden IPv6 Adressen für eine whithelist.
- Die Aachner kümmern sich um das Verfahren bei dem die Router in der richtigen Reihenfolge Updates bekommen damit keine Satteliten raus fliegen. Bei diesem Update wird tatsächlich die Domäne gewechselt.
An sich ist Schritt 1 überflüssig, aber so können wir dem Rheinufer Arbeit sparen und sicher sein, dass wir keine falschen Router umziehen.
Die werden sich dann aber nicht mit der neuen Firmware verbinden. Ihr habt ja sicherlich einen anderen Adhoc Wifi Namen und evtl einen anderen Channel. Das intermediate Update wird dann zwar klappen aber wenn ihr auf eure Firmware mit anderen Settings umschwenkt gibt es Probleme.
Ich würde „Satelliten“ manuell Updaten
Ich bin zuversichtlich, dass wir es automatisch schaffen indem wir zunächst nur Satteliten (und Knoten die alleine sind) auf die Whitelist nehmen.
Ist natürlich in gewisser Weise auch manuell, aber so müssen wir nicht in der ganze Städteregion herum reisen oder Leuten das flashen erklären die ihren Knoten nur bei uns abgeholt haben.
Naja das Problem ist das die Satelliten dann keine Verbindung zu den Nodes mit Uplink bekommen und dann ohne Netz dastehen. Das Update der Uplink-Nodes muss wenn dann innerhalb von 5-10 Minuten nach dem flashen der Satelliten geschehen was allerdings schwer ist da das Autoupdate nicht genau zu einem Zeitpunkt ausgeführt wird und auch nicht auf jeder Node zum gleichen Zeitpunkt.
Die Erfahrung zeigt außerdem das ein Autoupdate etwa 1-2 Tage dauert, es wird also eine Zeit geben wo bei euch ganze Wolken ohne Uplink dastehen.
Daher kommt ja auch die Idee der Gluon Devs das sich Nodes dann als Clients auf die Uplink-Nodes verbinden. Das ist allerdings noch nicht fertig.
Wird der alte Plan noch weiterverfolgt eine Firmware mit zwei Sätzen Settings für das Mesh auszuliefern, wo dann am Zeitpunkt X geswitcht wird?
(Nur aus Interesse)
Wenn es nicht anders geht, wäre das in meinen Augen bei einer geschickten Auswahl des Update-Zeitraums und einer begleitenden PR zu verschmerzen.
Wir werden keinen Wert für probability in der Übergangs Firmware einstellen, meine Tests zeigen, dass das update dann innerhalb einer Stunde stattfindet.
Im Rheinufer ist hier 0,08 konfiguriert, das Update wird also nur ~2x am Tag versucht. Obwohl er trotzdem stündlich eine Manifest Datei zu laden scheint.
Dank der whithelist fürs Update können wir uns ja von Wolke zu Wolke voran tasten.
Täuscht es mich, oder wird die Probability seit Gluon 14.3 gar nicht mehr verwendet?
Wenn ich mir /usr/sbin/autoupdater durchlese, hat nur noch die PRIORITY im Manifest einen Einfluss auf den Update-Zeitpunkt. Der Algorithmus ist auch in den Release-Notes zur 14.3 beschrieben:
Updates will be attempted at night, between 04:00 and 5:00, with a specific probability. When less than PRIORITY days have passed (calculated using DATE and the current time), the probability will proportional to the time passed. I.e. the update probability will start at 0 and slowly increase to 1 until PRIORITY days have passed. From then, the probability will be fixed at 1.
Außerdem wird einen Tag später (also nach PRIORITY+1 Tagen) nicht nur nachts zwischen 4 und 5 Uhr ein Update versucht, sondern stündlich.
Will man ein Update ASAP durchführen, könnte man also noch den DATE-Eintrag im Manifest Rückdatieren, sodass das Autoupdate denkt, das Update sei älter als PRIORITY+1 Tage. Dann müsste das Update beim nächsten Versuch, also spätestens nach einer Stunde, durchgeführt werden.