13 Aug
2018
13 Aug
'18
7:36 a.m.
Based on Daniel proposal I created two PRs:
One to add a network profile called libremesh-default which contains the
lime-defaults, which is normally included by lime-system:
https://github.com/libremesh/network-profiles/tree/master/libremesh/default/
The other one removes the lime-defaults from lime-system package. The
chef-ng branch automatically select the libremesh-default network
profile package, so the resulting firmware works just as before.
However, if they install their own network profile, no more conflicts.
https://github.com/libremesh/lime-packages/pull/401
I suggest to create a third PR which makes the lime-sdk fallback to the
libremesh-default profile if no other profile is set.
Anyone doubts?
On 06/08/2018 22.03, Daniel Golle wrote:
On Sun, Aug 05, 2018 at 12:34:41PM +0900, Paul Spooren
wrote:
Hi all,
some time ago I had the (bad) idea to convert network profiles into opkg
packages to automatically re-install them after an sysupgrade. Also
allow upgrading of network-profiles in case something changed. However,
this doesn't work so well as the file `lime-defaults` is provided by
`lime-system` as well as any network package. This results in the
following error:
Collected errors:
* check_data_file_clashes: Package zz-qmp-v1 wants to install file
/home/aparcar/worker/imagebuilder/lime/17.06/ar71xx/generic/build_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/etc/config/lime-defaults
But that file is already provided by package * lime-system
* opkg_install_cmd: Cannot install package zz-qmp-v1.
make[2]: *** [package_install] Error 255
Makefile:120: recipe for target '_call_manifest' failed
make[1]: *** [_call_manifest] Error 2
Makefile:201: recipe for target 'manifest' failed
make: *** [manifest] Error 2
So, what to do? We could introduce yet another
config file, so people
with network-profiles wouldn't fiddle with the `lime-defaults` file but
with `network-profile` or something, which would be "a layer between"
`lime` and `lime-defaults` config. Another approach would be to get rid
of the `lime-defaults` per default, and rely on sane defaults in the
modules. The lime-config module already support a fallback aka default
value, in case the setting is neither found in `lime` nor `lime-defaults`.
Why not
split-off the lime-defaults file into a lime-default-profile
package to not have lime-system overlap with files provided by
profiles?
Lastly, and my favorite, we could convert all
`network-profiles` in (a
single) uci-defaults file. Individual options are set via uci, if
special files like `authorized_keys` are required, it's possible via
`cat EOF <>` magic.
That would kinda put as back to where we've been
before:
profiles being unversioned and builds not being reproducible.
This approach would a) allow to be easy to handle
via the image-server,
which then just stores these single text files, and b) easy to transport
to the image server. An additional field in chef could be added called
"uci-defaults" where the user simply paste in desired uci settings.
Eventually a more sophisticated Chef version would allow to
automatically generate a single "uci-config" containing IPs, SSH keys,
whatever, all set via the web interface and requested via the generic
image server API.
Versioning could be done via a hash of the config file, meaning, if the
hash is different from the upstream version, update.
Hm, that would kinda
work-around, but why introduce an extra
versioning system if we already got one (opkg package versions)?
The `lime` config file would have a new field
called `network-profile`
or something similar, maybe an URL pointing to the latest uci-config,
which is then requested on every build-request. Understandable?
I get the idea,
but network-profiles are also more than just providing
lime-defaults, but also installs extra packages and all sorts of things
by putting files into /etc/uci-defaults and the like...
Instead of having a LibreMesh-specific approach to that (which isolates
us from the rest of OpenWrt users and creates extra work with less
potential contributors), really just have non-overlapping packages and
have them versioned. This canonization/normalization would allow for
much more flexibility/interopratibility with the rest of the non-lime
world.
Cheers
Daniel
> Greetings from Nikko, Japan,
>
> Paul
>