das wäre im Gluon wiki (das jeder mit GitHub Account editieren kann) in der Tat deutlich besser aufgehoben als hier…
ist nicht vorgesehen, da das legacy mesh mit dem übernächsten Release wegfallen soll voraussichtlich.
aber das wurde dir ja im IRC eigentlich schon einmal gesagt
wie funktioniert dann das Upgrade von komplexeren Lan-Mesh-Netzen?
Ist da irgendwie parallelbetrieb zeitweise möglich, so wie beim Wechsel von adhoc zu 11s?
ja. ohne manuelles basteln, indem du ein Gerät im „komplexen Lan-Mesh-Netz“ hast, das zwei Ports hat, dann legst du auf einen legacy und auf den anderen VXLAN.
mit manuellem Basteln kannst du auch beides auf den selben Port legen.
weitere Alternative, wie beim Funk-Mesh: den entferntesten node zuerst umstellen, schrittweise bis zum Offloader/VPN-Knoten fortführen.
Das setzt aber voraus, dass man SSH-Zugang auf alle Knoten der Domains hat, was leider/zum Glück illusorisch ist.
Also zumindest für uns wäre da erstmal eine Migration-Sackgasse.
Was heisst denn „beim übernächsten Release“? Sind damit „major revision numbers“ oder „point-releases“ gemeint?
es musst ja nicht du selbst sein, Freifunk ist ja häufig dezentral (heute weniger als früher).
falls gar niemand Zugriff hat:
komplexe IT deployen ohne dass irgendjemand Zugriff hat? very good idea. applause.
Wir haben Richtfunkstrecken (P2MP, Stock-FW) an deren Enden unterschiedliche Sites (und Verantwortliche) zuständig sind.
Das könnte mehr als spannend werden, da einen „zentralen“ Umschalttermin zu vereinbaren, wo alle gleichzeitig an den Konsolen bereit sitzen…
Wenn man dies setzt, dann darf der Knotenbetreiber den Hostname nicht mehr leer lassen. Dafür haben wir bisher immer ein extra Paket benutzt: gluon-config-mode-hostname-no-pretty. Das ist jetzt obsolet.
Selective Auto-Update beschreibt mit englischen Worten den Vorgang ein automatisches Update selektiv auszurollen, also nur auf einen bestimmten Knoten oder eine ausgewählte Gruppe von Knoten.
Es handelt sich dabei nicht um ein feststehendes Verfahren und kann verschiedenartig umgesetzt werden.
Die häufigste Implementierung selektiert die Knoten anhand ihrer IP Adresse am Webserver, der die Update-Dateien ausspielt.
Hierfür eignet sich z.B. bei nginx das Geo Modul.
Werden die Settings des Minute-Autoupdaters (oder wie das jetzt heisst) irgendwie an den Kartenserver übertragen?
Dann könnte man im Meshviewer vorher kontrollieren, ob denn alles richtig eingestellt ist vor dem Ausrollen der Signaturen.
Alternativ könnte man halt die betroffenen Knotenbetreiber schonmal vorwarnen, dass sie mit hoher wahrscheinlichkeit zum Zeitpunkt x manuell das Update einspielen müssen, da der Autoupdater ihre Knoten aus dem Netz kicken wird.
vor 9 Tagen gab es eine weitere Änderung.
Wenn man beim „alten“ Meshing (auf Kabel) vorerst bleiben möchte, also noch nicht VXLAN nutzen will, muss man in der site.conf im Bereich „mesh“ noch ergänzen: vxlan = false,
siehe:
Nachtrag:
Die Planungen sehen derzeit aber vor, dass das alte Meshing ab dem übernächsten Release verschwindet.
VXLAN hat einfach sehr viele Vorteile, alleine schon weil es standardisiert ist und Domains nicht aus Versehen gebrückt werden können.
Diskussionen hierüber nicht in diesem Thread, sondern auf der Gluon ML oder im IRC-Channel.
Bei Tests hat hier das VXLAN-Meshing nicht mehr funktioniert, wenn zwischen den Knoten eine WDS-Verbindung bzw. PowerLine-Verbindung sitzt. Wenn vxlan = true in der site.conf eingetragen ist, funktioniert meines Wissens auch die Option network.mesh_{lan, wan}.legacy='1' nicht mehr. Gibt es dafür einen Workaround?