Einsprung in Config-Mode / upgrade-Skripts

wusel · January 27, 2022, 2:55am

Moin,

an welcher Stelle springt Gluon eigentlich wie in den Configmode und wann und wo werden die /lib/gluon/upgrade-Skripte gestartet? Ich finde in /ect/rc.d/* keine Hinweise, und in der Doku findet sich auch nix konkretes?

blocktrron · January 27, 2022, 11:35pm

Wichtig hier: config-mode → Webinterface ; setup-mode → Der Zustand in dem sich das Gerät im Konfigurationszustand befindet.

Setup mode wird im preinit hier gestartet: gluon/package/gluon-setup-mode/files/lib/preinit/90_setup_mode at master · freifunk-gluon/gluon · GitHub

Hier beim config-mode reboot:

github.com

freifunk-gluon/gluon/blob/master/package/gluon-config-mode-core/luasrc/lib/gluon/config-mode/model/gluon-config-mode/wizard.lua#L25


      
          	section()(f, uci)
          end
          
          function f:write()
          	local fcntl = require 'posix.fcntl'
          	local unistd = require 'posix.unistd'
          
          	uci:set("gluon-setup-mode", uci:get_first("gluon-setup-mode", "setup_mode"), "configured", true)
          	uci:save("gluon-setup-mode")
          
          	os.execute('exec gluon-reconfigure >/dev/null')
          
          	f.template = "wizard/reboot"
          	f.package = "gluon-config-mode-core"
          	f.hidenav = true
          
          	if unistd.fork() == 0 then
          		-- Replace stdout with /dev/null
          		local null = fcntl.open('/dev/null', fcntl.O_WRONLY)
          		unistd.dup2(null, unistd.STDOUT_FILENO)

Und hier beim upgrade:

github.com

freifunk-gluon/gluon/blob/master/package/gluon-core/files/etc/uci-defaults/zzz-gluon-upgrade

#!/bin/sh

# Work around an issue with wifi setup timing by waiting a bit
# while device initialisation is ongoing.
# https://github.com/freifunk-gluon/gluon/issues/2779
sleep 3

gluon-reconfigure

exit 0

wusel · January 31, 2022, 3:39am

Danke für diesen – wichtigen – Hinweis.

Hintergrund: wir haben eine prä-Gluon-, dann lose an Gluon-Entwicklungen weiterentwickelte und nun aufgegebene, Firmware geerbt und möchten eine Gluon-basierte Migrations-FW bauen, die über bestehende Updatemechanismen die knapp 200 Bestandsknoten gen Gluon – und auf gewartete Infrastruktur – befördert.

Gluon soll also per sysupgrade ein ›anderes OpenWrt‹ aktualisieren — an sich relativ easy: Gluon müßte nur alle »Gluon-Firstboot«-Schritte durchführen – das scheint mir in upgrade/* zu geschehen? – und anstatt das formal unkonfigurierte System in den Setup-Mode (und in der Folge ins Config-Mode-Webinterface) zu schicken, setze ich in einem setup-mode/rc.d/S14-migrate-Skript die Parameter skriptgesteuert, die sonst der User eintragen würde; Koordinaten, Community, Knotennamen, Owner, TC-Einstellung sind ja aus der bisherigen Installation vorhanden und es ist auch bekannnt, wo das per UCI gesetzt/geändert werden muß.

Soweit die Theorie.

Die Praxis: setup-mode/rc.d/S14-migrate guckt aktuell, ob die alt-Firmware-Konfigdatei /etc/config/freifunk existiert und falls ja, benennt es diese in /etc/config/freifunk-old um, löscht nicht relevante, übernommene Konfigurationsdateien im Overlay (cd /overlay/upper/etc/config && /bin/rm -rf batman-adv autoupdater alfred dhcp fastd firewall network simple-radvd system wireless gluon*) und rebootet (/etc/init.d/done boot; reboot).

Im nächsten Schritt wird auf /etc/config/freifunk-old getestet und die relevanten Daten werden per uci-Aufruf übertragen, /etc/config/freifunk-old in /root/freifunk.legacy umbenannt (finale Version: gelöscht), gluon-setup-mode.@setup_mode[0].configured auf 1 gesetzt und nochmals rebootet.

Allein: im vorigen Schritt sperrt sich UCI (Ausgabe des Skripts nach »set -x«):

+ uci -q get 'simple-tc.@interface[0].enabled'
+ TCENABLED=1
+ '[' 1 '=' 1 ]
+ uci set 'gluon.mesh_vpn.limit_enabled=1'
uci: Invalid argument
+ :
+ uci -q get 'simple-tc.@interface[0].limit_ingress'
+ uci set 'gluon.mesh_vpn.limit_ingress=50000'
uci: Invalid argument
+ :
+ uci -q get 'simple-tc.@interface[0].limit_egress'
+ uci set 'gluon.mesh_vpn.limit_egress=10000'
uci: Invalid argument
+ :
+ uci -q get 'freifunk-old.@settings[0].name'
+ /bin/pretty-hostname Gluon-Test-3700v1
uci: I/O error
+ uci set 'gluon-setup-mode.@setup_mode[0].configured=1'
+ uci commit
uci: I/O error
uci: I/O error
uci: I/O error

Das ist eher kontraproduktiv; irgendeine Idee, wie man das umschifft?

adorfer · January 31, 2022, 12:01pm

„uci: I/O error“ kenne ich eigentlich nur von angeknackstem (oder vollem Overlay-fs

Alles was in Richtung „invalid argument“ geht: Wenn der „darüberliegende“ Schlüssel (also meist die entsprechende Config-Datei oder der Bereich im Configfile) noch gar nicht existiert, dann gibt es solche „geht nicht“-Meldungen.

wusel · January 31, 2022, 6:26pm

Voll ist es nicht, angeknackst schein’s auch nicht — /etc/config/freifunk kann ich ja umbenennen und auch ein Logfile nach /root schreiben. Aber UCI ist unpäßlich, ich kann Sachen per ucí set setzen und mit uci show bzw. uci export die Daten auch sehen — selbst ein uci export gluon-node-info | grep -v ^package >/tmp/file && cat /tmp/file >/etc/config/gluon-node-info gibt keine Fehler — nach dem Reboot sind die Änderungen aber wieder weg.

Ulkigerweise bin ich dann ja im normalen Setup-Mode ( uci set gluon-setup-mode.\@setup_mode\[0\].configured=1' wird ja nicht gespeichert), und dann zickt UCI nimmer rum. Löse es jetzt mit uci export $i >/root/$i.export in Phase 2 und uci import $i </dev/null ; uci commit $i ; uci import $i </root/$i.export ; uci commit $i in Phase 3. Wahrscheinlich wäre eine ähnliche Schleife (uci import $i </dev/null ; uci delete $i ; uci commit $i) statt des rm -rf in /overlay/upper/etc/config in Phase auch ausreichend und dann würde es in Phase 2 schon funktionieren? Mal testen …