Batman aktualisieren - Verfahrensablauf?

Fortsetzung der Diskussion von Subdomäne Möhnequelle (Brilon/Willingen/Olsberg):

Habt ihr da irgendwas speziell gebastelt, damit reine Meshknoten nicht ausgesperrt werden?

Wir befinden uns ja grade noch in der Testphase. Es werden also X Knoten per Hand umgeflasht bzw. neue Knoten kommen direkt rüber. Für alte Knoten müssen wir uns vielleicht was überlegen.

Den größten ähnlich gelagerten Fall liefert wohl Aachen:

Ich bevorzuge nach wie vor das NW-Verfahren.

Könntest du das bitte etwas ausführlicher beschreiben?

Wenn ich mich recht entsinne, wurde dort eine Verzögerung zwischen Download des Updates und Installation des Updates gesetzt, richtig?

Der Autoupdater wurde von uns umgeschrieben, MeshRouter bekommen zuerst das Update. Die VPN Router haben eine waittime bekommen, sodass diese zu erst aktualisiert werden. Bei uns hat dies wunderbar funktioniert

1 Like

Hast Du zur Veranschaulichung evtl einen Link in ein GIT?

Klar, hier ist der Mod
https://git.nordwest.freifunk.net/ffnw/packages/blob/master/autoupdater-mod/files/lib/ffnw/autoupdater-mod/autoupdater

Ich bin zwar kein Programmierer, aber ich nehme an, das ist der Schlüssel, bzw. der eigentliche Patch?

  if direct_vpn == true then
	wait(28800) -- Wait for 8h
  elseif mesh_lan == true then
	wait(21600) -- Wait for 6h
  else
	wait(14400) -- Wait for 4h
  end

Genau. Daran sieht man, wir einfach der Mod funktioniert

Auf welchen Wert hattet ihr das update-Intervall und die propability gesetzt, passend zu obigen 8/6/4-Verzögerungen?

(Bei einem Wechsel des Funk-Kanals wäre das für mich ebenfalls eine Möglichkeit. Wäre also praktisch, das standardmäßig im regulären Gluon-Updater zu haben.)

Ist der Patch schon Upstream an die Gluon Entwickler gegangen, so das jede Community davon profitieren könnte? Grundsätzlich ist die Idee ja nicht schlecht zeitversetzt erst die Mesh Knoten und dann die restlichen zu Updaten.

Gerade auch im Hinblick auf die Umstellung von IBSS zu 802.11s ist der Patch ja gut anwendbar.

Probability ist meines Wissens doch schon raus aus Gluon. In der Example site.conf taucht das schon nicht mehr auf.

Nein, weil das vorerst parallel geschaltet wird. Das ist also nicht erforderlich.

Also kurz ausführlicher:

Ihr habt das also alles auf Clientseite gemacht? Also eine Zwischenfirmware, die den Autoupdater ändert und das nicht auf Serverseite implementiert? Die Probability müsste dann so eingestellt werden, dass alles an einem Tag stattfindet.

Theoretisch könnte es auch Meshknoten geben, die nur über zwei Hops zu einem VPN-Uplink kommen. Das hattet ihr vorher ausgeschlossen? Gibt es da einen Algorithmus um zu ermitteln, ob es solche Knoten gibt?

Grüße
MPW

Ja gut, wären dann zwei Updates hintereinander. Denn warum soll man sich dauerhaft mit 2 Mesh Methoden rum schlagen? Wird doch bestimmt Airtime fressen wenn sowohl IBSS und 802.11s Beacons gesendet werden.

Genau - eine zwischen Firmware, die den Autoupdater verändert hat. Wir werden mal intern absprechen, wie wir alle Communitys teil haben lassen.

Genauere Fragen könnt ihr auf unserer ML nordwest@lists.ffnw.de erfragen.

Programmiert hab ich den mod nicht :smiley:

Richtig, aber das kann man dann erstmal testen und dann eben so innerhalb von ein paar Tagen machen. Dazu das Risiko eingehen, da evtl. Knoten aus dem Netz zu kicken.

Ich fände es zumindest sehr praktisch, das als Option „Im normalen Gluon“ zu haben, um Kanäle zu wechseln, oder Namen des „Batbone/Wifimesh“-Adhocs. Ohne gleich ewige Diskussionen führen zu müssen um manuelle Listen und noch manuellere Updates.

Es wäre übrigens praktisch, bei erfolgreichem Download (als in der Wartezeit) die Ausführung des „dhcp.scripts“ zu verhindern, damit dieses nicht zu Speicherpanik in „Groß-Domains“ führt.