Noch einer:
- In allen Paketen muss man im Makefile in den Depends:
gluon-config-mode-core-virtualingluon-config-mode-coreändern
Alle Pakete, die Übersetzungsfunktion benutzen müssen angepasst werden:
-
Diese Zeile ergänzen:
local pkg_i18n = i18n '{ hier den namen des i18n .pot-Templates einsetzen (ohne Endung) }' -
translate()durchpkg_i18n.translate()ersetzen
Außerdem müssen alle Models/Views/Controller für die „advanced settings“ von /lib/gluon/web nach /lib/gluon/config-mode verschoben werden.
Coole Sache das hier als Liste zu führen. Ich überlege gerade, ob wir das in einem Beitrag als Wiki zusammen führen sollten?
Ich hätte noch diese Punkte:
- site.conf: Nächster-Knoten in Array umwandeln
- site.conf: Domain-Hash hinzufügen
Geänderte Funktionalität:
- Sofern eine Passwortanmeldung per LuCi konfigurierbar sein soll: gluon-web-admin — Gluon 2021.1 documentation
- VXLAN ersetzt standardmäßig das klassische LAN-Mesch. Ggfs. abschalten. Wie das beim Kompilieren geht, weiß ich noch nicht.
2 „Gefällt mir“
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. 
major, of course
und nicht in Stein gemeißelt.
1 „Gefällt mir“
selective auto-update geht übrigens immer remote, auch ohne SSH-Zugriff.
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…
Das war mein Punkt: Kein Autoupdate möglich!
1 „Gefällt mir“
Mit diesem PR könnte man in solchen MoL-Wolken die Reihenfolge festlegen und dann einfach autodaten:
Neue Option für den Config Mode:
config_mode = {
hostname = {
optional = false,
},
...
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.
Siehe gluon/site.rst at master · freifunk-gluon/gluon · GitHub (Bereich config_mode : optional)
Was ist selective auto-update und wo ist es beschreiben? Mr. Google kennt den Begriff nur in diesem Post.
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.
Noch eine Änderung in der site.conf:
- config_mode.owner.obligatory=true → config_mode.owner.optional=false
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.
5 „Gefällt mir“
beachtet, dass die Option inzwischen ganz entfernt wurde. seit 2017.1.8 ist das contaktfelt immer nur noch optional (damit dies DSGVO konform ist)