Änderungen an gluon beim Wechsel zu v2018.1.x


#1

Zur Info, dies kam über die Mailingliste von Neoraider:

we have recently pushed a new Lua library for site access. This new library
allows more convenient access to nested optional values:

gluon-core: add new gluon.site library for convenient access to optional values

The new gluon.site lua library will eventually replace gluon.site_config
(which is hereby deprecated, but will continue to be supported for a
while).

The new gluon.site library will wrap all values to allow traversing
non-existing tables without errors.

    site = require 'gluon.site'
    c = site.a.b.c -- doesn't fail even if a or a.b don't exist

The wrapped values must be unwrapped using call syntax:

    site_name = site.site_name()

Using the call syntax on a non-existing value will return nil. An
alternative default value may be passed instead:

    mac = site.next_node.mac('16:41:95:40:f7:dc')

At the moment, both libaries are available for use in custom packages, but
the old gluon.site_config library will be removed soon.

Site i18n files that access the site configuration from Lua code in the
gluon-config-mode:reboot, gluon-config-mode:pubkey or
gluon-config-mode:novpn messages need to be adjusted, as the config mode
wizard now uses the new site library.

Dies betrifft allerdings erst Gluon 2017.2.x


Einsteiger: Master ("2018.x") bauen auf Grundlage einer 2016.x(?)-config
Gluon wechselt zu LEDE
SSID-Changer: Fehler beim Bauen vom Master
#3

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)


#10

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!


#12

„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“


#15

Update: As we are preparing the addition of multi-domain support to Gluon,
site_seed has been renamed to domain_seed in the latest master. – @NeoRAider


#16

Soweit ich das sehe, sind nur folgende Änderungen nötig:

  • site_seed in domain_seed umbenennen
  • GLUON_ATH10K_MESH in site.mk umbenannt in GLUON_WLAN_MESH (kann man jetzt aber auch weglassen, 11s ist default)

#21

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:


Howto (in Erstellung): Erstellung von Gluon-Packages (mit v2018.1.x kompatibel)
#22

Auf Dauer sollte man sich wahrscheinlich Gedanken machen über in_site() und in_domain(), und gluon.site_config sollte durch gluon.site ersetzt werden, da gluon.site_config irgendwann rausfliegt


#23

Noch einer:

  • In allen Paketen muss man im Makefile in den Depends: gluon-config-mode-core-virtual in gluon-config-mode-core ändern

#24

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() durch pkg_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.


#25

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:

Geänderte Funktionalität:

  • Sofern eine Passwortanmeldung per LuCi konfigurierbar sein soll: gluon-web-admin — Gluon 2017.1+ documentation
  • VXLAN ersetzt standardmäßig das klassische LAN-Mesch. Ggfs. abschalten. Wie das beim Kompilieren geht, weiß ich noch nicht.

#26

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 :wink:


#27

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?


#28

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.


#29

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?


#30

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. :frowning:

major, of course :wink:
und nicht in Stein gemeißelt.


#31

selective auto-update geht übrigens immer remote, auch ohne SSH-Zugriff.


#32

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…


#33

#34

Das war mein Punkt: Kein Autoupdate möglich!