[freifunk-public] Neue Experimental-Firmware 1.10.0~exp20201202

[Ralf Jung]

Hallo Sebastian,

> wenn ich das richtig verstehe, dann ist es auch wichtig dass alle Knoten
> eines bestehenden meshes die gleichen autoupdater Einstellungen haben
> (enabled 1/0 und auch die gleiche branch, experimental/stable).
> Sprich: Entweder machen alle mesh-Partner das update mit, oder keine.
> Andernfalls tritt der von Dir beschriebene Effekt genauso ein und es
> switcht nur ein Teil des meshes in die neue Domain. Es zerfällt also
> weil der "Domain Director" die Knoten mit alter FW dann nicht
> berücksichtigen kann?

Nicht ganz. Wichtig ist, dass alle Knoten eine Firmware-Version mit dem 
Director-Client haben. Knoten ohne Director-Client ignorieren den Director 
einfach und bleiben in ihrer alten Domain. Wenn wir das im gesamten Netz 
ausrollen, können wir den Director also erst scharf schalten, wenn wirklich alle 
Knoten, die in einem Mesh sind, auf eine Firmware mit Director-Client 
aktualisiert haben.
Welche Firmware das genau ist und ob da der Autoupdater aktiv ist oder die neue 
Firmware per Hand installiert wurde, ist dabei egal.

Der Plan ist also grob der:
* Firmware 1.10 auf den Stable-Kanal tun.
* Warten, bis zumindest in einer Domain (also in einem Landkreis) alle Knoten, 
die Mesh-Partner haben, eine 1.10er-Firmware haben.
* Director für diese Domain aktivieren und diese Knoten alle migrieren.

Viele Grüße,
Ralf

> 
> Grüße
> Sebastian
> 
> 
> Am 03.12.20 um 19:00 schrieb Ralf Jung via freifunk-public:
>> Hallo allerseits,
>>
>> im experimental-Kanal des Autoupdaters rollen wir jetzt die neue
>> Firmware 1.10.0~exp20201202 aus. Damit aktualisieren wir auf Gluon
>> v2020.2.1
>> (https://gluon.readthedocs.io/en/v2020.2.x/releases/v2020.2.1.html).
>>
>> Vor allem jedoch haben wir eine angepasste Version des Darmstädter
>> "Domain Director" eingebaut, mit dem wir die vorhandenen Knoten
>> automatisch auf unsere neuen Domains verteilen und so die Größe des
>> Mesh-Netzwerks reduzieren wollen. Wir werden dabei aufpassen, dass
>> lokale Mesh-Wolken geschlossen in dieselbe Domain migrieren. Wer
>> darauf nicht vertrauen mag, kann den Director in den erweiterte
>> Einstellungen im Konfig-Modus deaktivieren; dann kann es jedoch
>> passieren, dass benachbarte Knoten, die den Director aktiviert haben,
>> migrieren und dadurch lokale Meshes aufgetrennt werden.
>>
>> Technisch läuft das so, dass wir auf dem mgmt-Server eine kleine
>> Datenbank haben, wo für jeden Knoten anhand der angegebenen
>> Geokoordinaten bzw den benachbarten Mesh-Knoten eine Ziel-Domain
>> eingestellt ist. Die Knoten fragen regelmäßig beim Server nach, was
>> denn ihre Ziel-Domain ist, und wenn diese von der gesetzten Domain
>> abweicht wird ein Wechsel geplant. Der Zeitpunkt des Wechsels wird
>> dabei vom Server festgelegt. So können wir z.B. den Wechsel für "in 2
>> Wochen" ankündigen; es reicht also, wenn ein Knoten in diesen 2 Wochen
>> irgendwann mal für mehr als eine Stunde online ist, damit er weiß,
>> wann und wohin der Wechsel stattfindet.
>> Ob für einen Knoten ein Wechsel geplant ist, kannst du per SSH
>> herausfinden:
>> uci get ffda.director.target
>> uci get ffda.director.switch_after
>>
>> Vorerst wird jedoch nicht großflächig automatisch migriert, wir werden
>> nur auf einigen unserer Knoten experimentieren, ob das mit der
>> Migration so funktioniert. Wenn du da mitmachen willst, melde dich
>> bitte, dann können wir die Migration auch für deine Knoten aktivieren
>> und schauen was passiert. :)
>>
>> Viele Grüße,
>> Ralf und Marvin
>