[RFC PATCH v1 3/4] fff-hoods: call reload_config after uci commit
Tim Niemeyer
tim at tn-x.org
So Jun 10 12:07:53 CEST 2018
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_triggers_on
> > _config_filenetwork_interface_changes
> >
> > Hier ist die Funktion beschrieben:
> > https://github.com/openwrt-mirror/openwrt/blob/master/package/syste
> > 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.
> 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.
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/0997f890/attachment.sig>
Mehr Informationen über die Mailingliste franken-dev