I noticed that the subdomain dev.libre-mesh.org runs with a self-signed
certificate, which is annoying because casual people browsing (and
security paranoid) won't accept to add an exception in order to read
more and will leave...
A free browser-accepted certificate can be obtained from StartSSL [1]
(for that specific domain, wildcards and extended verification certs are
not for free of course, but we there is no need for them).
[1] https://www.startssl.com/
We should endorse too!
What do you think?
---------- Forwarded Message ----------
Subject: [Battlemesh] V8 Current Endorsements
Date: Sunday, February 15, 2015, 05:38:25 PM
From: Nemesis <nemesis(a)ninux.org>
To: Battle of the Mesh Mailing List <battlemesh(a)ml.ninux.org>
This is the current endorsers list:
* Wlan Slovenia (host)
* Batman
* Openwrt
* Freifunk
* Ninux
* Wireless Leiden
* Wirelesspt.nethttp://battlemesh.org/BattleMeshV8#Endorsements
So far we already have all the logos of these from last year.
Somebody else wants to come on board right now and save us some time
needed to reach?
Federico
-----------------------------------------
As to sort raw intormation about the lime systems, we did start a dokuwiki
at http://goo.gl/l23aks
If things go well this might be transfered to any official libremesh docu
site.
We would appreciate any form of ideas,help or cooperation.
Thank you
3zl(Reinhard)
>Did you already read this ?
>https://github.com/libre-mesh/lime-packages/blob/develop/packages/lime-syst…>>/etc/config/lime
yes, we took this as a start for the analysis
>btw lime-default options are readed in case of something missing from lime
Questions :
1.is there any "override" mechanism to stop lime-config touching
original config files or params within ?
2. overall view of the design "/usr/bin/lime-config" ( lua script
with no "lua" extension ?)
3. list of keywords used in "/usr/bin/lime-config" and respective
scripts / files
4. there is some "mingle" between lime and lime-defaults - whats the
meaning of "missing" compared to what.
Next halt : Parsing of lime / lime-defauls and the respective list of
keywords with their actions have to be carved out of the source
btw : we have been really surprised by the numbers of interfaces been
generated and digging deep to find out to which extent they are
necessary and to what use
No organised site to store the documentation to ?
regards
3zl(Reinhard)
Yesterday I tested the current implementation of the web interface LUCI2
[1] (which will replace LUCI in the future). The basic administration
menu (Network, WiFi, System, Status, etc.) is already implemented and
works fine.
LUCI2 is a 100% rewritten web interface and it does not use lua anymore.
It is just a small uhttpd plug-in which communicates Javascript with
ubus via standard JSON. So it is quite more flexible and less resources
aggressive for the router (since the JS is executed in the client side).
I would recommend to start thinking in LUCI2 instead of LUCI, so we
should base the future LiMe web interface in LUCI2. Would be nice to
have some JavaScript expert into the team :)
Cheers.
[1] http://wiki.openwrt.org/doc/techref/luci2
--
./p4u
/usr/bin/lime-config resp. /usr/lib/lua/lime:
as far we do understand these programs affect uci-config files in
/etc/config/ related to data in /etc/config/lime AND/OR
/etc/config/lime-defaults
list of keywords and their lime-configuration-action ( complete list ?? )
config lime <lime config class>
system
option
hostname
network
option
primary_interface <phys-interface>
list
protocols
lan ->
anygw ->
batman-adv
bmx
resolvers
<DNS ip ipv4>
<DNS-ip ipv6>
wifi
option
channel_2ghz
channel_5ghz
ap_ssid
adhoc_bssid
adhoc_mcast_rate
mesh_mesh_fwding
mesh_mesh_id
list
modes
ap
adhoc
override / prevail preset config-values
manual ?????
autogenerable ???
it would be very helpful for us and the project if anyone can shed a
profound light on this.
To trace the sourcecode for informations is too time-consuming, so we
wonder if there are any more documentation hidden somewhere.
We do believe, that a project like lime cannot survive without proper
system and user dokumentations and we are willing to start this.
Any kind of help is welcome
regards
3zl(Reinhard)
It is not trunk neither stable, it is just "LUCI", the repository
"http://git.openwrt.org/project/luci.git". We are using it in all LiMe
Branches.
On 29/01/15 14:32, Gioacchino wrote:
> On Thursday, January 29, 2015 05:13:40 AM Pau wrote:
>> Assigned #7 to @G10h4ck.
>>
>> ---
>> Reply to this email directly or view it on GitHub:
>> https://github.com/libre-mesh/lime-packages/issues/7#event-226805821
>
> Is this bug present in last stable or just in trunk?
> If it is just in trunk i would wait that trunk stabilize a little before
> changing stuff in libre-mesh to fix stuff like this
>
> P.S. please keep dev(a)lists.libre-mesh.org in CC
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/libre-mesh/lime-packages/issues/7#issuecomment-72023720
>
--
./p4u
