man kann im Autoupdater die Router mit „Essen“-, „E“- und „FF-E“-Prefix erkennen und automatisch updaten. Da in den Firmware-Images kein SSH-Publickey einkompiliert ist, könnte man nur die Router per SSH updaten, wo manuell ein Publickey von jemandem von uns eingetragen wurde. Alle anderen Router müssten entweder manuell eingetragen werden oder später manuell neu geflasht werden (Falls es überhaupt welche gibt). Zum Glück gibt es keine Router, die über mehrere Communities meshen. Das wäre nämlich zukünftig nicht mehr möglich.
Hatte ich beim Treffen gestern leider vergessen nachzufragen…
Wie ist der aktuelle Stand? Wann wird das Update der Knoten, die noch in der Ruhrgebietsdomäne sind, durchgeführt?
Sollte doch kein Problem sein, auf dem Webserver von dem Autoupdater ein Script laufen zu lassen, das im schlimmsten Fall die Statusseite der Router ausliest und ihnen dann für das Essener Prefix die neue Firmware ausliefert. Die Public Keys sind ja die gleichen, wie bei der Ruhrgebietsfirmware…
Und wegen den Knoten, die nur über Funk angebunden sind, sehe ich auch kein Problem. Dann werden denen eben zuerst die Updates gegeben. Mir sind jetzt keine exklusiv über Funk angebundenen Knoten bekannt, die nicht dauerhaft laufen.
Außerdem kann man das ja mit einzelnen Knoten problemlos austesten.
Kann ich mich auch einlesen und das machen, wenn da ein Zeitmangel bei den Ruhrgebietsadmins herrscht.
Also aus meiner Sicht würde nichts dagegen sprechen. Seit 2 Wochen läuft bei mir IPv6 und ich hatte seitdem auch nur 1-2 DNS-Fehler. Das ist nicht mehr als in der Ruhrgebietsdomäne oder bei meinem Anbieter zuhause. Scheint jetzt alles relativ problemlos zu funktionieren.
Aus aktuellem Anlass hole ich den Thread hier auch nochmal hoch und frage nach dem Stand der Updateplanung für die Knoten die noch in der Ruhrgebietsdomäne sind.
Seit Sonntag ziehen Router automatisch nach Essen um, seit heute auch nach Witten, Hamm und Emscherland.
Momentan nur Nodes, die nicht via Wifi meshen, kurzfristig dann auch Nodes, die nur 1x Meshen (zwei Router an einem Standort, einer hat Uplink) und Nodes, die mit anderen Nodes meshen, die selbst Uplink haben.
cool, dass es endlich klappt. Gerade habe ich zwar viel um die Ohren, aber ich würde das machen, wenn es keine andere Möglichkeit gibt.
Sind die Updateserver nicht von einem Ruhrgebietsrouter ohne Uplink erreichbar, der mit einem Essener Router mit Uplink mesht? Da sie ja die gleiche BSSID haben und zumindest der BATMAN-Traffic anscheinend ungehindert durchgeht, sollte es ja kein Problem sein, eine Route für den Updateserver hinzuzufügen.
Dann könnte man zumindest alle Router in Essen auf die gleiche Firmware bringen.
Ein weiterer Schritt wäre dann, eine Hierarchie anzufertigen, um im nächsten Update die BSSID zu ändern.
Aber ist das überhaupt notwendig? Es gibt doch im Gluon Autoupdater die Priority und Probability. Würde es nicht ausreichen, eine Priority von 3 zu setzen und eine Probability von etwa 0.6? Da wir kaum Knoten ohne Uplink in Essen haben, die häufig ausgeschaltet werden und sich jeder Router das Firmwareimage schon in den RAM lädt, sobald er es findet (standartmäßig wird einmal pro Tag geprüft, wenn ich mich nicht irre), verstehe ich nicht den ganzen Aufwand.
Die Meisten Subdomänen haben unterschiedliche Kanäle, Mesh-BSSIDs und Batman-Versionen. Dortmund z.B. hat Batman15 und wifimesh-dortmund auf Kanal 1 usw…
Ich verstehe nicht was du meinst. Der wird doch benutzt. Es geht darum, welche Firmware dem Autoupdater ausgehändigt wird, wir geben ja jetzt nicht mehr statisch die selbe Firmware an alle Router, die beim selben Server nach der selben Datei fragen, sondern je nach Domäne unterschiedliche. Und wenn wir einfach jedem Node das Update geben zerfällt das Wifi-Mesh und die dahinterliegenden Nodes sind offline und nie wieder erreichbar ohne manuellen Eingriff am Gerät.
Genau… und da die Essener Router wegen einer Fehlkonfiguration mit den Ruhrgebietsroutern meshen (BSSID ist gleich), brauchen wir das doch garnicht, wenn wir über die Essener Supernodes Zugriff auf die Updateserver geben, die die Ruhrgebietsrouter anfragen.
D.h. mit ein paar IP-Rules können wir ALLE Ruhrgebietsknoten in Essen auf die Essener Firmware updaten und niemand wird ausgeschlossen. Im zweiten Update müssen wir dann die BSSID ändern und das funktioniert wahrscheinlich problemlos mit dem Gluon Autoupdater.
Wir brauchen in Essen dein Script mit den erweiterten Funktionen für Knoten, die keinen Uplink haben wahrscheinlich garnicht.
Womöglich kannst du die jetzt einfach alle updaten und wenn nicht, müssen wir ein paar Routen auf den Essener Supernodes setzen…
EDIT: Wenn du Lust hast, kann ich ja mal nen Router ohne Uplink mit der Ruhrgebietsfirmware flashen und den mit einem Essener Router mit Uplink meshen lassen. Dann versuchst du den zu updaten und wir sehen, obs funktioniert…
Übrigens hätte ich es sinnvoll gefunden, wenn das Ruhrgebiet vor dem Umzug auf eine Firmware mit einem verkleinertem Updateintervall geupdatet worden wäre, damit man verlorengegangene Knoten mit einem mobilem Knoten und gefaktem Updateserver hätte updaten können.
Hast du denn ein Backup von den JSON-Files, damit wir überhaupt feststellen können, wo ein Knoten verloren gegangen ist?
Wieso sollten sie? Die Knoten haben doch genug Zeit, um sich die Updates runterzuladen. Das was du jetzt machst, ist nicht besser als der Autoupdater.
Mit Probability wird gesetzt, wann die ersten Knoten anfangen, die Updates zu installieren.Mit Priority wird gesetzt, wann die Knoten auf jeden Fall ihr Update installieren.
Priority=3, Probability=0.6 heißt soweit ich weiß:
Nach 3 Tagen müssen alle Knoten geupdatet sein. Nach nicht ganz zwei Tagen fangen die ersten an, die Updates zu installieren. Und sobald die Router ein neues Update entdecken, laden sie es sich in den RAM (am Tag 0 sozusagen)…
Router werden nur ausgeschlossen, wenn irgendein Depp seinen Router ohne Uplink immer ausschaltet (denn dann geht der RAM-Inhalt verloren) und das Zufällig in dem Fall zwischen Tag 2 und 3…
Ich würds ja machen, aber ich hab keinen Zugriff auf die Server…
Mich hingegen interessiert der Fuckup, weil wir hier nen Haufen Cross-Community-Traffic haben und dein derzeitiges Vorgehen das Problem nicht löst, sondern die Server nur noch mehr belastet.
Ich habe bei mir nen Meshviewer installiert, der sich die nodes.json per Runwhen runterlädt. Da waren heute mittag nur noch etwa 110 Knoten drin.
Gut, dann lade ich mir mal ein Backup, falls da wieder auf myteriöse Weise Knoten verschwinden…
ich meinte die JSON an sich … da sollten keine Nodes verschwinden … ich hab da noch 30 Tage alte Testnodes drin, die seitdem nicht mehr online waren
ABER, wenn du die von dem RG Server ziehst, dann ist das richtig, da die nicht von dem backend, sondern von dem Splitter erzeugt werden … die original JSON hat aber alle Nodes inne (EDIT: ich glaube, das ist so. Das müsste ich nochmal nachschauen. Also, das der Splitter die offline Nodes auslässt)
.