[OpenWrt-Devel] Re: "UCI overlay" proposal

[David Lang]

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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel