5 Aug
2018
5 Aug
'18
3:34 a.m.
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`.
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.
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.
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?
Greetings from Nikko, Japan,
Paul
6 Aug
6 Aug
1:03 p.m.
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
2 p.m.
On 08/05/2018 05:34 AM, Paul Spooren wrote:
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.
Ah :/
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`.
The option to remove /etc/config/lime-defaults file from lime-system
package sounds good to me.
Some users could be pissed off by the disappearance of lime-defaults
(when not using a network-profile), which was convenient as
configuration example and get the default values. The new place for
finding default values and examples can easily be the
/etc/config/lime-example file (from packages lime-docs and
lime-docs-minimal).
Ciao,
Ilario
--
Ilario Gelmetti
iochesonome(a)gmail.com
igelmetti(a)iciq.es
ilario.gelmetti(a)estudiants.urv.cat
7 Aug
7 Aug
12:28 a.m.
I created a PR, please have a look. I like the name `lime-profile` more
than `lime-defaults-profile`, but thats easy to change.
https://github.com/libremesh/lime-packages/pull/398
Please have a look, this is a dead simple solution for the current
problem. With a treewide PR I'd update all existing network profiles
renaming all `lime-defaults` to `lime-profile`.
Sunshine,
Paul
On 2018-08-06 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
>
9:45 a.m.
On Tue, Aug 07, 2018 at 09:28:38AM +0900, Paul Spooren wrote:
I created a PR, please have a look. I like the name
`lime-profile` more
than `lime-defaults-profile`, but thats easy to change.
^^^
i thought about lime-default-profile or lime-profile-default, so we can
have other similarly named packages for the other profiles, ie.
lime-profile-freifunk-leipzig or the like.
https://github.com/libremesh/lime-packages/pull/398
Please have a look, this is a dead simple solution for the current
problem. With a treewide PR I'd update all existing network profiles
renaming all `lime-defaults` to `lime-profile`.
Why another file?!?!?! I don't get it.
Can't just EVERY of the CONFLICTING lime-profile-* packages ship a
`/etc/config/lime-defaults` and we remove that file from lime-system?
Sunshine,
Paul
On 2018-08-06 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
> 
2:45 p.m.
I have been postponing my participation on this thread becaues of the
complexity of it...
I will top post now, sorry :)
For what I understand, config is splitted in this spaces now:
* lime code: the defaults are there
* lime-defaults: override the code
* lime: override lime
What I believe we need are:
* global config (lime code works)
* network config (lime-defaults works)
* node config (lime could work)
This is also important for firstbootwizard, so the nodes can replicate
their config in a peer2peer fashion instead of having to build an image.
El 07/08/18 a las 04:45, Daniel Golle escribió:
On Tue, Aug 07, 2018 at 09:28:38AM +0900, Paul Spooren
wrote:
I created a PR, please have a look. I like the
name `lime-profile` more
than `lime-defaults-profile`, but thats easy to change.
^^^
i thought about lime-default-profile or lime-profile-default, so we can
have other similarly named packages for the other profiles, ie.
lime-profile-freifunk-leipzig or the like.
https://github.com/libremesh/lime-packages/pull/398
Please have a look, this is a dead simple solution for the current
problem. With a treewide PR I'd update all existing network profiles
renaming all `lime-defaults` to `lime-profile`.
Why another file?!?!?! I don't get it.
Can't just EVERY of the CONFLICTING lime-profile-* packages ship a
`/etc/config/lime-defaults` and we remove that file from lime-system?
Sunshine,
Paul
On 2018-08-06 22:03, Daniel Golle wrote:
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
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
>
13 Aug
13 Aug
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
>
2087
days inactive
2095
days old
6 comments
4 participants
participants (4)
-
Daniel Golle -
Ilario Gelmetti -
Nicolas Pace -
Paul Spooren