Last mail of 3 [to understand context please see the first one]

What if we created a “unified configuration” file for LiMe?

Example that perfectly explains my POV: I see quintanalibre has a script in uci-defaults that overwrites /etc/config/libremap with just the details it wants to overwrite, and nothing else, without, for instance, conflicting with the most recent update from upstream that introduces the freifunk libremap details, which instead would never have made it in their images if they had included the actual /etc/config/libremap file itself.

We could make one file, once and for all, that cleanly substitutes variables all over where needed, leaving every line of every file open for updates from upstream.

As more variables become available over time, the maintainer of that community can simply pull the new “LiMe-UCF” file from upstream, merge in his or her variables from his or her /network-profiles/ community, define the new ones that have become available [such as the freifunk libremap contact name and email, which just showed up recently], and know that any SDK build will be as bleeding-edge as any other.

This would also reduce fragmentation between communities, which is already a problem when we introduce “hard forks” such as adhoc-to-802.11s changes. Let’s try and reduce all other incompatibilities to zero by having everyone be one click away from the latest version.

Don’t you think? And if so, what do you think of this idea?

Thanks!

Nk


On June 28, 2017 at 2:53:09 PM, Nk (nk@os.vu) wrote:

A quick update: I’ve recreated our config files [https://github.com/libremesh/network-profiles/tree/master/openNET.io/1144-W2PA-LIME-XXXX/] by only porting the required details [SSID Name, libremap lat, long, etc…] in the new /etc/config/lime-defaults AND in /etc/lime-config-firstboot/lime-defaults, so that both lime-defaults and libremap files are both in /etc/config/ AND /etc/lime-config-firstboot/.

I don’t think this is correct however, as I’m having issues with devices meshing but not reaching eachother and DHCP from ISP router passing through the 10. LAN created by the LiMe router, overwriting the LiMe router’s DHCP on both wired and wireless clients.

What files do I need to edit and what should I not be touching? Could anyone take a look at the link above to see if everything looks good?

Thank you!

Nk


On June 28, 2017 at 11:41:34 AM, Nk (nk@os.vu) wrote:

Hi

In order to understand how to start using 802.11s from SDK, I’ve downloaded a pre-built image from http://repo.libremesh.org/lime-17.04/ [downloads.libremesh.org isn’t responding at least for me - I think I need a 17.02 version to compare with an SDK output, no?].

I’ve noticed a few changes such as the directory /etc/config/ becoming /etc/lime-config-firstboot/ and more in luci-defaults and so on.

Do you have a list of changes?

How do I maintain a https://github.com/libremesh/network-profiles/ community in a way that is future-consistent?

I’d like to be able to have details in there that really only override things I’ll always want to override, such as the SSID, but allow for all other file changes [like adhoc becoming 802.11s for instance] from upstream to pour down into my SDK images, with no interference at all and no risk of having conflicts. Also because images I’m building now, once flashed, don’t work at all, so there is a big risk in upstream changes conflicting with network-profiles, don’t you think?

I know this means a line-based granularity and not a file-based one such as now, but there must be a way, no?

In any event, for now, what changes do I have to make to my community files in order to get SDK to cook valid and up-to-date in every way images?

Thank you!


Nk
_______________________________________________
lime-users mailing list
lime-users@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
_______________________________________________
lime-users mailing list
lime-users@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users