7 Beiträge wurden in ein neues Thema verschoben: Gluon-Paket kompiliert für v2017.1.4 nicht aber für den Master (04.01.2018)
Da sind ja inzwischen schon ein paar mehr Änderungen im master, die man berücksichtigen muss, das sollten wir Mal alles auflisten. Oder gibt es so eine Liste schon?
Lasst uns hier Mal alle sammeln!
„eventually“ bedeutet nach Definition nicht wie man meinen könnte „eventuell“, sondern wie ein Blick ins Englisch-Deutsch Wörterbuch verrät, „schließlich“ oder „schlussendlich“
Update: As we are preparing the addition of multi-domain support to Gluon,
site_seed
has been renamed todomain_seed
in the latest master. – @anon75826926
Soweit ich das sehe, sind nur folgende Änderungen nötig:
-
site_seed
indomain_seed
umbenennen -
GLUON_ATH10K_MESH
in site.mk umbenannt inGLUON_WLAN_MESH
(kann man jetzt aber auch weglassen, 11s ist default)
Man muss für alle Packages eine ev. vorhandene check_site.lua anpassen:
der Config-Pfad wird nicht mehr als String, sondern als Array übergeben jetzt
Beispiele:
Auf Dauer sollte man sich wahrscheinlich Gedanken machen über
in_site()
undin_domain()
, undgluon.site_config
sollte durchgluon.site
ersetzt werden, dagluon.site_config
irgendwann rausfliegt
Noch einer:
- In allen Paketen muss man im Makefile in den Depends:
gluon-config-mode-core-virtual
ingluon-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.
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.
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!
Mit diesem PR könnte man in solchen MoL-Wolken die Reihenfolge festlegen und dann einfach autodaten: