gluon section misconfiguration should not lead to broken node

[Florian Maurer]

When using something like this (WARNING WRONG CONFIGURATION!):

uci set gluon.iface_lan2=interface
uci set gluon.iface_lan2.name=eth2
uci set gluon.iface_lan2.role=client # with set instead of add_list
uci commit gluon
gluon-reconfigure

gluon-reconfigure complains

/usr/bin/lua: /usr/lib/lua/gluon/util.lua:25: bad argument #1 to 'pairs' (table expected, got string)
stack traceback:
	[C]: in function '?'
	/usr/lib/lua/simple-uci.lua:22: in function 'foreach'
	./021-interface-roles:47: in main chunk
	[C]: ?

but still updates the config to a broken one (with client not attached to bat0 and missing loopback and wan* interfaces).
It would be much better to complain beforehand and do not update the network config in this case.

related forum issue: https://forum.freifunk.net/t/x86-mesh-und-clients-an-lan/23979/4

instead it is needed to use the following (just for people coming by this issue):

uci set gluon.iface_lan2=interface
uci set gluon.iface_lan2.name=eth2
uci add_list gluon.iface_lan2.role=client # with add_list instead of set
uci commit gluon
gluon-reconfigure

[Matthias Schiffer]

Hmm. I'd argue that modifying the UCI configuration incorrectly is not something that Gluon can or should account for.

It might however be nice for Gluon to provide some specialized command line utilities for common tasks that are also possible through the web UI, so using UCI directly is rarely needed anymore.

[Florian Maurer]

I think that creating a config from user input should not lead to broken network configurations - but fail earlier, though I see that it is proably hard to fix this.
The main problem for this is probably #3129 - at which point this would become a UI option where things should only lead to valid choices.

Once this is done, one can say, that "using uci is an advanced task, where we can expect people to know about it" but currently, we sometimes need it for common stuff like this too.