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 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 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. - 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). 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. 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 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. 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]. For more options, visit https://groups.google.com/d/optout.
