[RFC PATCH v1 3/4] fff-hoods: call reload_config after uci commit
Tim Niemeyer
tim at tn-x.org
So Jun 10 12:17:02 CEST 2018
Am Sonntag, den 10.06.2018, 12:12 +0200 schrieb Christian Dresel:
>
> On 10.06.2018 12:07, Tim Niemeyer wrote:
> > Am Sonntag, den 10.06.2018, 12:02 +0200 schrieb Christian Dresel:
> > > hi
> > >
> > > On 10.06.2018 11:44, Tim Niemeyer wrote:
> > > > Am Sonntag, den 10.06.2018, 08:31 +0200 schrieb Christian
> > > > Dresel:
> > > > > Hallo
> > > > >
> > > > > ich werde nicht schlau was reload_config macht, kannst du das
> > > > > evtl.
> > > > > genauer erklären?
> > > >
> > > > Am besten du schaust mal kurz die beiden Links an:
> > > >
> > > > Hier wird erklärt, wieso das wichtig ist:
> > > > https://wiki.openwrt.org/inbox/procd-init-scripts#procd_trigger
> > > > s_on
> > > > _config_filenetwork_interface_changes
> > > >
> > > > Hier ist die Funktion beschrieben:
> > > > https://github.com/openwrt-mirror/openwrt/blob/master/package/s
> > > > yste
> > > > m/procd/files/reload_config
> > > >
> > > > Zusammenfassend:
> > > > Wenn ein procd-Init-Script angemeldet hat, dass es gerne bei
> > > > config-
> > > > Änderung benachrichtigt wird, dann wird das durch reload_config
> > > > erst
> > > > ausgelöst. Die Änderung der Dateien reicht nicht.
> > > > Im original OpenWRT mit LUCI kennt man das auch, weil es dort
> > > > ein
> > > > Speichern und separat ein Übernehmen gibt.
> > > >
> > > > Generell sollten wir mMn überall auf diesen Mechanismus setzen
> > > > und
> > > > nirgends die Init-Scripte selber reloaden/restarten.
> > >
> > > Kurzgefasst:
> > >
> > > uci -q set "blabla="
> > > -> ändert es im RAM (nach reboot ist die Änderung futsch)
> > >
> > > uci -q commit
> > > -> schreibt es auf die "Platte" (die Änderung steht auf der
> > > "Platte",
> > > ein Programm dahinter hat das aber u.U. nicht übernommen)
> > >
> > > reload_config
> > > -> startet das dazugehörige Programm neu bzw. sagt ihm das es die
> > > config
> > > neu laden soll (oder wie auch immer...)
> > >
> > > Beispiel DHCP Server:
> > >
> > > uci set dhcp.mesh.start='10.50.138.128'
> > > jetzt ist im RAM mal festgehalten das ab diesen IP Bereich
> > > gestartet
> > > wird. dnsmasq weiß davon noch nix und ein reboot setzt es auch
> > > wieder
> > > zurück. Es bringt also erstmal gar nichts.
> >
> > Ich bin mir nicht ganz sicher, was passiert, wenn man hier schon
> > ein
> > reload_config einbaut. Vermutlich werden die Services dann
> > neugeladen,
> > aber die Daten sind trotzdem nicht auf der Platte. Im Fall einer
> > Misskonfiguration könnte dies als "Regeschirm" dienen, denn nach
> > einem
> > Reboot wäre alles wieder wie vorher.
>
> darüber hab ich tatsächlich beim schreiben auch nachgedacht und kam
> zu
> den gleichen Schluss. Man kann es hier einbauen, config testen, wenn
> alles gut noch ein uci commit drüber und fertig. Wenn es kracht und
> man
> sich auf einmal wegen Missconfig selbst rausgesperrt hat, Stecker
> ziehen, neu starten wieder alles wie zuvor. Ähnliches vorgehen
> verwendet
> Fabian ja auch in seiner Gatewayfirmware (nur das er die Services
> einzeln neu startet, /etc/init.d/bla restart wenn ich mich jetz
> tnicht
> gerade gewaltig täusche)
>
> >
> > > uci commit
> > > jetzt ist es zwar fest gespeichert, nach einem reboot würde es
> > > sogar
> > > übernommen werden (da die config neu eingelesen wird) und fest
> > > behalten
> > > werden. Aber dnsmasq weiß hier auch noch nix davon und verteilt
> > > weiterhin IPs so, wie es zuvor eingestellt war.
> > >
> > > reload_config
> > > jetzt übernimmt auch der dnsmasq diese Änderung und fängt mit der
> > > neuen
> > > IP Range an -> Selber "Effekt" wie /etc/init.d/dnsmasq restart
> > > nur
> > > schöner?
> >
> > Ja. Es setzt allerdings vorraus, dass der Dienst angemeldet hat,
> > dass
> > er bei Änderungen (und auch welche Änderungen) neugestartet werden
> > möchte.
> >
> > > Hab ich das so richtig verstanden?
> >
> > Joar.
>
> wollen wir das dann wirklich überall einbauen? Bei sowas wie
>
> uci -q set "system. at system[0].hood="
> uci -q commit system
> +reload_config
>
> macht es ja irgendwie absolut gar keinen Sinn oder?
Doch, machts. Wenn z.B. ein Dienst von der Hood-Information abhängt,
dann müsste dieser neugestartet werden.
Tim
>
> mfg
>
> Christian
>
> >
> > Tim
> >
> > >
> > > mfg
> > >
> > > Christian
> > >
> > > >
> > > >
> > > > > Kleinigkeit noch Inline:
> > > > >
> > > > > On 03.04.2018 21:27, Tim Niemeyer wrote:
> > > > > > Signed-off-by: Tim Niemeyer <tim at tn-x.org>
> > > > > > ---
> > > > > >
> > > > > > src/packages/fff/fff-hoods/files/usr/sbin/configurehood |
> > > > > > 4
> > > > > > ++++
> > > > > > 1 file changed, 4 insertions(+)
> > > > > >
> > > > > > diff --git a/src/packages/fff/fff-
> > > > > > hoods/files/usr/sbin/configurehood b/src/packages/fff/fff-
> > > > > > hoods/files/usr/sbin/configurehood
> > > > > > index a825eea..2672cfa 100755
> > > > > > --- a/src/packages/fff/fff-
> > > > > > hoods/files/usr/sbin/configurehood
> > > > > > +++ b/src/packages/fff/fff-
> > > > > > hoods/files/usr/sbin/configurehood
> > > > > > @@ -56,6 +56,7 @@ if [ -s "$hoodfilecopy" ] &&
> > > > > > isGatewayAvailable ;
> > > > > > then
> > > > > > uci set network.${iface}.proto='static'
> > > > > > uci set
> > > > > > network.${iface}.ip6addr='fe80::1/64'
> > > > > > uci commit network
> > > > >
> > > > > wir haben überall -q nur hier nicht. Hat das einen Grund? Ist
> > > > > mir
> > > > > hier
> > > > > beim drüber schauen das erste mal aufgefallen. Eventuell
> > > > > können
> > > > > wir
> > > > > das
> > > > > gleich mit anpassen (falls es eine v2 bzw. ein nicht-RFC
> > > > > geben
> > > > > sollte)
> > > > > oder wegen mir auch in nen extra Patch.
> > > >
> > > > Vermutlich ja. Aber das ist vermutlich ein Teil, den Fabian in
> > > > seinem
> > > > Patchset verschiebt. Wenn ich das jetzt anpasse, gibts wieder
> > > > Ärger
> > > > beim Fabian. Also lieber erst ändern, wenn die beiden Patchsets
> > > > durch
> > > > sind. Sollten wir aber im Hinterkopf behalten.
> > > >
> > > > Tim
> > > >
> > > > >
> > > > > mfg
> > > > >
> > > > > Christian
> > > > >
> > > > > > + reload_config
> > > > > > if ! wifiAddAP "$radio"
> > > > > > "config.franken.freifunk.net" "$iface" "configap" "1"; then
> > > > > > echo "Can't add Config interface
> > > > > > on
> > > > > > $radio."
> > > > > > exit 1
> > > > > > @@ -101,6 +102,7 @@ else
> > > > > >
> > > > > > uci -q set "system. at system[0].hood
> > > > > > ="
> > > > > > uci -q commit system
> > > > > > + reload_config
> > > > > >
> > > > > > sleep 30 # Wait for the config AP,
> > > > > > which
> > > > > > may be created at the same time as this script has started
> > > > > >
> > > > > > @@ -127,6 +129,7 @@ else
> > > > > > uci -q set
> > > > > > network.configSta=interface
> > > > > > uci -q set
> > > > > > network.configSta.proto='static'
> > > > > > uci -q commit
> > > > > > network
> > > > > > + reload_config
> > > > > > fi
> > > > > > done
> > > > > >
> > > > > > @@ -232,6 +235,7 @@ if [ -s "$hoodfile" ]; then
> > > > > > echo "Setting hood name: $hood"
> > > > > > uci -q set "system. at system[0].hood=$hood"
> > > > > > uci -q commit system
> > > > > > + reload_config
> > > > > >
> > > > > > if ! wifiDelIface; then
> > > > > > echo "Can't delete current wifi
> > > > > > setup"
> > > > > >
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 488 bytes
Beschreibung: This is a digitally signed message part
URL : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20180610/ec38a2eb/attachment.sig>
Mehr Informationen über die Mailingliste franken-dev