[RFC] Node and community assets and generic configs

[spiccinini]

After spliting the settings into lime-node and lime-community there are still some loose ends. This proposal tries to tie them up :)
What do you think?

Guidelines

1. It should be easy to setup (and reason about) community-wise and node only configurations for any software in the firmware, not only the configurations already supported in LibreMesh.
2. It should be easy to upgrade the firmware by keeping the community/node configurations.
3. Configuration changes that are backwards incompatible should be doable without manual intervention and without loosing the current configuration.

Proposal

Currently there are package configurations that cannot be specified without being for the community or for the node only.
The same applies to uci-defaults and hotplug hooks.
The idea is to be able to include all these use cases under the lime-node, lime-community paradigm.

• For package configurations that do not yet have their integration (option in lime config + hook) we add the type of section in the lime config called generic_uci_config that specifies generic configurations of type uci set to modify those of another package.
• For the uci-defaults and hotplug.d/lime-config hooks, we added the directories, node-assets and community-assets. And the following section types:
  • copy_asset copy an asset into a specified path.
  • run_asset_on_firstboot executes at first boot (using a uci-default for that end, eg: uci-defaults/90_lime_generic).
  • run_asset executes an asset at each lime-config run

This way not longer need to maintain other configuration files during an upgrade that are not exactly those specified by the lime-node/lime-community and the corresponding assets.

It is important to clarify then (in the documentation) that these unforseen configurations are a trigger to development and eventually have to end up as internal libre-mesh integrations.
And so hacker communities don't have to be maintaining these extra configurations that require maintenance.

Pros:

• Allows for flexibility in node configuration and easy firmware upgrade by maintaining that configuration.
• Allows to make an adhoc configuration through the generic_uci_config, and at the same time not to get lost when someone else comes and runs lime-config.
• If a firmware does not have custom packages you can just use a vanilla libremesh firmware and just add the lime-node and lime-community files.

Example:
(based on the quintanalibre network-profile https://github.com/libremesh/network-profiles/tree/master/quintanalibre.org.ar/generic/files/etc)

config generic_uci_config libremap
    list uci_set "libremap.settings.community=quintana.libre.org.ar"
    list uci_set "libremap.settings.community_lat=-31.80461"
    list uci_set "libremap.settings.community_lon=-64.41609"

config copy_asset collectd
    option asset 'collectd.conf'
    option path '/etc/collectd.conf'

config run_asset_on_firstboot cron-workaround-tasks
    option asset 'cron-workaround-tasks'

config run_asset dropbear
    option asset 'dropbear'
    option run_once '0' # once per upgrade

Random notes:

• Config asset directories may be something like /etc/lime-assets/{node, community}
• We may use the files convention (/etc/lime-assets/community/files/usr/bin/foo) instead of copy_asset. I have mixed feelings, prefer the copy_asset because of it being explicit.
• We should integrate more configs into lime, like the libremap/location, etc.
• This proposal allows to to not keep any configuration beside lime-node / lime-community and its assets. So the recommended way of upgrading will be to use lime-sysupgrade (that internally uses sysupgrade -f with the lime.system.keep_on_upgrade config )

[ilario]

+1
To be able to modify /etc/config/* from lime-* is very useful!

[ilario]

And (if I got the function generic_uci_config correctly) maybe we can de-implement some settings which currently are in lime-* and just get translated to /etc/config/* file without much manipulation, for example:

lime-packages/packages/lime-docs/files/lime-example

Lines 31 to 32 in 29131e2

option anygw_dhcp_start '2' # First IP in the subnet to be used for DHCP for clients. For example, if the subnet is 10.x.0.0/16 and you want the clients to get an IPv4 from a DHCP pool starting from 10.x.100.2, the start parameter will have to be 100 * 256 + 2 = 25602.

option anygw_dhcp_limit '0' # Number of IPs available for DHCP. Use zero for having the DHCP pool ranging from anygw_dhcp_start up to the end of the subnet. For example, if the subnet is 10.x.0.0/16, the start of the DHCP pool is at 10.x.100.2 and you want the DHCP pool to finish at 10.x.127.254, the limit parameter will have to be (127 - 100) * 256 + (254 - 2) + 1 = 7165. Instead, if you want the DHCP pool to go from 10.x.100.2 up to 10.x.255.254 (last valid IPv4 in the /16 subnet) you can just set the limit to zero.

could be de-implemented in anygw and added to lime-defaults as something like:

config generic_uci_config dhcp
    list uci_set "dhcp.lm_net_br_lan_anygw_if_dhcp.start=2"
    list uci_set "dhcp.lm_net_br_lan_anygw_if_dhcp.limit=65533"

meh, I'm not sure, opinions?

[spiccinini]

meh, I'm not sure, opinions?

I would not use this generic configs for libremesh itself as I see it more dificult to understand at least for me (if the dhcp options is needed for anygw then it is easier for me if the options are changed directly in the anygw code).

I have the generic_uci_config and copy_asset fatures almost ready. I will push when ready.