On 10/18/2018 6:19 PM, Federico Capoano wrote:
Nice discussion here guys, sorry for my late reply, I was away and
busy at the Google Mentor Summit.
On Sunday, October 14, 2018 at 11:12:18 AM UTC+2, Pim Janssen wrote:
Hi everyone,
I am looking and playing with Openwisp and Netjson. I hope i can
ask u
some questions.
Currently i am trying to automate a managed switch. I came to the
horrible conclusion it only allows for changes using web-ui. I made a
very basic webscraper that is able to do some very basic things like
enabling / disabling network ports or enabling / disabling Power over
Ethernet (POE)
For managed switch on OpenWRT do we mean the "switch", "switch_vlan"
and "switch_port" sections in /etc/config/network?
If yes, you may have tried to manage those via OpenWISP without
success, is this the case?
If that's the case, it was because those type of configurations were
flagged as "unmanaged" by default in openwisp-config (the openwrt
agent which updates the configuration) and hence were being ignored by
the agent.
We changed this recently (thanks to
Oliver): https://github.com/openwisp/openwisp-config/commit/c8e333089b62c5afe19ccd5268f00fb6d267cfe1
I have not yet tried to connect it to openwisp. After reading the
project documentation i had the feeling this could be part of OpenWisp.
But before trying to implement it i first wanted to be sure you all
share part of the idea. I did networking for a few different company's.
I used hardware/software from most big vendors. One of the things that
started to annoy me is that for every serie of devices (even within one
brand) They use a different design for there devices. I think it would
be a advantage if they could be managed from one interface given someone
writes a adapter.
You can update the configuration in /etc/config/openwisp and remove
the unmanaged sections.
It seems also that somebody is working on improving the switch support
in netjsonconfig (the component of OpenWISP which generates the native
router configurations from
NetJSON): https://github.com/peshev/netjsonconfig/commits/master
Would such a module be something u see as being in the scope of
netjson?
I mean having some kind of adapter <Openwisp/configuration
frontend> -
<Adapter script> - <Switch WebUI>. The way i see netjson would be
as a
universal configuration format. Having something like Openwisp
produce a
netjson file and having something else (could be the device itself)
applying it on the device.
Yes, I think it would be useful.
Adding it to the NetJSON spec is a slow process though, but nobody is
holding us to implement it in OpenWISP first.
Infact, that's how I've been doing recently, I'm implementing things
first in OpenWISP and improving the NetJSON spec once things work well.
I have not looked very deep into it. But is there a document where the
endpoint to the OpenWisp controller is documented so i can figure out
how to get the config from the controller?
I think it's a 4 stage process
1. Write a config into OpenWisp
2. Get the netjson from the OpenWisp controller
3. Convert the netjson into actions that need to be applied on the device.
4. Apply the actions on the device by any means needed for this device
(in my case a webui scraper)
Part 4 is implemented. But the other parts i still have to figure out.
I miss somethings in the netjson standard
- encryption. I think there should be a standard way to encrypt
netjson
files on the wire with for example a shared key. U could leave
that to
the transport but i think it would be better to have a way of
doing it
in a standard.
NetJSON is a format, not a protocol.
If you check other similar JSON based formats like GeoJSON, they also
do not specify a standard way to encrypt it.
Additional RFCs may do that, but is it really needed right now?
There's so many other things to improve in OpenWISP and NetJSON that I
think we can leave this to users and developers, let them encrypt
NetJSON and send it how they want.
At the moment as Edoardo said, encryption of NetJSON is not even
important because the configuration is sent in native format to
routers via HTTPs.
I was/am thinking about sending the NetJSON files over MQTT. If u do it
properly i don't think u need encryption. I saw encryption somewhere in
the netjson docs without telling how. Never mind :)
- push vs pull:
Now all openwisp device do a configuration pull every x minutes. I
think
that's a waste of resources on the controller side. What it your
vision
on using MQTT/AMQP or another open protocol to push configurations to
devices. Advantage in this case would also be that u don't need to
pull
config that often or not at all. The configuration can be applied
within
seconds after the are changed on the server no matter where the
device
is located (behind NAT/Firewall).
This does not concern NetJSON but rather OpenWISP (an implementation
of NetJSON).
Correct
First of all let me clarify that openwisp-config (the OpenWRT agent)
does not pull the entire configuration but an md5 checksum, it will
download the entire configuration only if the stored checksum is
different from the checksum sent by the server. Hence the resources
used are really minimal.
Lets say a controller handles 1000 devices. U can chose to have a delay
of 5 minutes. But that still means u get ~3 hits per second. It's not
that heavy. But still feels like a waste of resources. And still u have
a delay of 5 minutes before the configuration gets applied.
Most people will not get to that device count. But if it is possible to
add a lot of different devices on different sites. Things could add up
quickly.
In the connections branch of openwisp-controller we have an
implementation that allows to push configuration updates via SSH:
https://github.com/openwisp/openwisp-controller/tree/connections
This will require either a VPN or port forwarding. I don't want to
forward ports to the public internet and a VPN could be a option in some
cases.
Using other protocols is possible, I've been thinking of using MQTT
over websocket for quite a while now but haven't got around starting
this because the current mechanism is working quite well and hence
this rewrite is not as urgent as other things we are working on now,
but sooner or later we will get there.
This would also allow for a new possibility of having a easy way
to get
data from the device. And also integration in home-automation systems
would be a lot easier.
Agreed, I think allowing OpenWISP to be used in other contexts will be
a win for the project.
I've seen many network controllers and dashboards being created from
scratch in different contexts: each network hardware vendor makes its
own controller (eg: Ubiquiti, Engenius, Mikrotic) which only works
with their own hardware, a new technology comes out (eg: SDN, LoRa)
and new controllers are created with very similar feature sets (the
ones OpenWISP also has or aims to have). That's a waste of human
resources and time. It would be like having different groups of people
re-implementing a different operating system kernel (like the linux
kernel) from scratch, each kernel doing only a limited number of
things and never achieving any breakthrough.
If we can help to fix that problem with OpenWISP by creating an open,
generic, modular, reusable, robust and well documented network
controller and dashboard we'll have achieved one of the goals of the
project.
But to get there we will need time, great development effort and a lot
of patience from our users which will have to deal with bugs, filing
bug reports and sending feedback (as you are doing now, which is very
helpful BTW) to us developers so we can keep improving the project.
A bit more notes:
- Edoardo mentioned SMTP, but I think he meant SNMP (Simple Network
Management Protocol)
- NetJSON is aimed at easing the development and improving
interoperability in networking software, its focus is not only WISPs,
it can be any type of network (eg: ISPs, public wifi, mesh, LoRa, IoT)
I hope this clarifies things a bit.
It does thanks.
Best regards
Federico
--
You received this message because you are subscribed to the Google
Groups "OpenWISP" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"OpenWISP" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
