How do I add a customised ipk file to the cooker.
I just compiled a slightly modified bmx6-sms plugin with an increased
sms length size for the ar71xx/generic target and I want to cook some
firmware for a few different ar71xx/generic profiles using this
modified ipk file.
Thanks
David
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
Hello! Working with Librenet6 configuration I found a scenario where the
documentation go to an error that at the beginning is hard to understand
why.
In Unix systems "hostname" could be an alphanumeric and accept the
hyphen ('-')[1], but Tinc "Name" accept alphanumeric and the underscore
('_')[2], not the hyphen. So, there is a scenario not much uncommon
where we could have a hostname with hyphens like "virtual-server-1" or
"LiMe-0C9B".
So, those parts in documentation could became in a bug:
In Debian based:
Name = host_$(hostname)
In OpenWrt based:
HOSTNAME=$(uci get system.(a)system[0].hostname)
[0]
I have permissions for change the documentation and fix that issue, but
I want to talk with you about it because my fix proposal change the way
of naming hosts (beginning with an "host_" or "topo_") and it could
affect some of others of your scripts:
As is written in Tinc manual I think that they have knowledge about this
possible collision between to ways of naming hosts. So the manual says:
"If Name starts with a $, then the contents of the environment variable
that follows will be used. In that case, invalid characters will be
converted to underscores. If Name is $HOST, but no such environment
variable exist, the hostname will be read using the gethostname() system
call."[2]
About tinc environment variables[3].
So my proposal is changing from
Name = host_$(hostname) # bash variable
or
Name = topo_$HOSTNAME # bash variable
to
Name = $HOST # tinc environment variable
(And in the file names)
result:
"host_myniceserver" to "myniceserver".
"host_virtual-server-1" (that will fail) to "virtual_server_1"
"topo_LiMe-0C9B" (that will fail) to "LiMe_0C9B"
But in this case we lost info about if the host came from Debian/Ubuntu
manual (host_) or came from OpenWrt manual (topo_).
What do you think?
Also we made an script for my machines that we can share, off course is
in case of an script that this standardization process has sense.
Regards.
[0] http://docs.altermundi.net/LibreNet6/Setup
[1] As wrote in RFC 952 and RFC 1123
[2]
http://www.tinc-vpn.org/documentation-1.1/Main-configuration-variables.html
Name = <name> [required]
This is a symbolic name for this connection. The name must consist
only of alfanumeric and underscore characters (a-z, A-Z, 0-9 and _), and
is case sensitive.
[3]
http://www.tinc-vpn.org/documentation/Scripts.html#index-environment-variab…
($HOST environment variable (and maybe others) are not documented)
