On Friday, March 6, 2015 11:11:07 PM PDT, Matthias Schiffer wrote:
On 03/05/2015 08:25 PM, David Lang wrote:
On Thu, 05 Mar 2015 13:36:10 +0100, Matthias Schiffer wrote: ...
At the moment we use scripts to edit /etc/config/* to our needs. There
are multiple reasons why we'd like to get rid of this:
* Changing specific parts of meta-configuration may change large parts
of network and firewall configuration. We'd like to avoid writing to the
flash more than necessary.
the metaconfiguration needs to be stored somewhere, remember that I/O is done
in fairly large chunks, it doesn't matter if you write a 5 byte file or a 1k
file (possibly even larger), it will generate the same flash usage.
besides, how frequently do you expect the configs to change? Even if they
change daily, that's not going to cause significant wear on the flash until you
start talking about lifetimes on the order of decades. (and hopefully we will
have major upgrades being pushed out much more frequently than that)
* As long as the UCI config is written to files, admins think they can
change them, not anticipating that parts of the config may be rewritten,
leading to all kinds of funny misconfigurations. Not actually having the
config written out, but generated on the fly, is also an attempt to make
the configuration more fool-proof, by leaving the meta-config as the
only way to make changes to the configuraion (in the case of read-only
overlays)
the typical way to address this is to have your generated files have a header
saying that they are generated and that manual edits will disappear.
/etc/resolv.conf on my laptop has:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
I can understand your concerns, I'd also like to avoid having to change
UCI more than necessary (and more often than necessary). The minimal
solution (which is the option 1 I'd proposed) would be just adding
support for dlopen-based backend loading and making the default backend
configurable (in /etc/uciconf or something like that).
I don't like making it so that the admin can't easily see what the config is.
Breaking every post on the Internet about troubleshooting and changing settings
in OpenWRT is also a problem. Having the config that's in use not show up in
the configs will cause these sorts of problems.
Option 2 would be nicer in my opinion. I can see other usecases besides
ours which would benefit from a way to combine configuration from
different sources, so having a generic way to do that in the UCI core
could facilitate maintaining such solutions.
I agree that we want a good way to combine data from multiple sources, we're
just discussing the how.
I've also though about just calling this multi-backend support instead
of overlays. While that would be very nice and generic for the config
consumer, not having a single actual backend would complicate the config
write case a lot...
with the conf.d approach for each current file, I don't think that the
confusion is significant. There will be a little bit, but not much. With a
header in /etc/config/wireless telling people not to edit it, but instead make
changes in /etc/config/wireless.d the confusion is minimal
As to the desire to directly support scripts generating configs. How about
extending the normal confd approach so that in addition to combining all files
into one, it allowed executables and took whatever was output on stdout and
used that as the config text?
That would let you put in your scripts to generate the config, but still allow
admins to drop in a chunk of text config to override your settings if they
wanted to? An admin can trivially see what the script would create by running
it (and scripts should have a header giving instructions on how to do this,
especially at the start)
There is still the question of the granularity of this.
The easy way to go is to have it act as if the contents of all the files we
combined with cat * and let the normal uci rules for handling duplicates take
place (and I'm not sure what those rules are), this would let you override an
entire definition, but not override a specific parameter.
If we want to have a smarter combination, we will have to define the rules for how the
combinations are made (for example, /etc/config/wireless config wifi-iface, how do you
tell if a new clause is supposed to override a single parameter on an existing clause vs
defining a new interface), and how you white out an existing parameter (make
it as if it wasn't defined)
what granularity were you thinking of?
David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
