Configuration management

[benhylau]

There is more info in the scrollback leading up to that bookmark, but the path decided starts from this message onwards:
https://riot.im/app/#/room/!yzLpKcnymfPsdJyjnB:tomesh.net/$1493263569668182qcLJZ:matrix.org

[benhylau]

Configs are read between start_userspace and systemd. All custom configs are defined as TAR archives in the /conf.d directory in the FAT partition. For example:

/conf.d/00_tomesh.tar
        01_tomesh_orangepizero_node.tar
        15_benhylau_custom_config.tar

The TAR archives are alphabetically arranged and processed sequentially. "Process" in here simply means during this init step, each TAR archive is extracted into /etc on the ramdisk filesystem. Conflicting files will always overwrite, such that if both 00_tomesh.tar and 15_benhylau_custom_config.tar contain a file called /systemd/networks/85-wlan-mesh.link, the one from the latter archive will overwrite the former before systemd uses the file.

This allows Toronto Mesh to distribute images with:

/conf.d/00_tomesh.tar
        01_tomesh_orangepizero_node.tar

and

/conf.d/00_tomesh.tar
        01_tomesh_raspberrypi3_node.tar

while Phillymesh distributes a fork:

/conf.d/00_phillymesh.tar
        01_phillymesh_base.tar
        02_phillymesh_tplink_meshpoint.tar
        03_phillymesh_ubiquiti_hostap.tar

as an example.

There may be some properties that are unique to a particular node and are unknown prior to first run of the ramdisk, for example, MAC address of a wireless adapter needs to be included in the config file. There can be a config_save command that will take the current /etc in the ramdisk, TAR it up, and write it to the SD card as 99_user_custom_config.tar. On next boot, this is the last set of config files applied and will overwrite everything before it.

@hamishcoleman The above is what I my understanding of what you described today. Please verify.

[Famicoman]

+1 from me, I think this is a great idea.

[darkdrgn2k]

i LOVE the idea of sandwiching the config but i was thinking about it and i dont know if there is a need for it!

I guess the big question is HOW do we see these nodes working, or more specifically how much "power" does the end user have over their node.

Right now the concept is to split it into 3 layers that get compressed into 1 set of "settings"

A Device Config
A Network Config
A Custom/User Config

Now looking at "configurable" things

1. Currently there are really not much device related things that are needed, realistically most of the device based configs would need to happen at firmware layer anyway. Otherwise the config may need to be VERY VERY extensive and frankly tedious.

2. network config are really just a hand full of "defaults" that need to be set when configuring
   Country Code
   Default frequency for Mesh Point (24 and 5 ghz?)
   Default frequency for Access point (24 and 5 ghz?)
   Maybe naming template the node template or something
   This again can be done at firmware creation cause it will "never change"

3. User config
   Realistically this is the config that would actually run everything,
   and we can do a "first run" to configure it basically based on some rules
   Each active interface - what's it do and how is it configured

Am i missing something?