> 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) > > 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. >
Hi Pimmetje, this was something that Federico was working on some time ago but I haven't seen it working yet. The concept of backend in netjsonconfig is a transformer from netjson to something else the device can understand. You can make a new backend[0] that does exactly this, output the NetJSON from NetJSON and put it into an archive for your devices to fetch. As you can't always have a process on the device to check there was exploratory work on a connector that could connect and apply configurations on devices that do not run OpenWRT, such as your managed switch. > > 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. > > Also something that is backend specific as the backend should generate an archive that can be encrypted if needed. You should ask yourself what you want form encryption - confidentiality, connections from device to controller should be secure - authenticity, the device can authenticate the controller payload - secrecy, the controller payload can only be read by those with the key and then implement it in the backend and configuration process - 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). > Rigth now the configuration is not sent a NetJSON over the wire and it will remain like this as it's easier to debug things on the server than on the device. Another question you should ask is how you should send the updates as this drives the configuration update procedure and you may have to implement some update logic in the new backend to prevent stupid things from happening (add wireless without radio). This is all new work without anything done yet. > 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. > > Yes it's true but the focus should always be on WISP, wireless internet providers. For network managements there are already protocols like NETCONF and SMTP so maybe it's better to look into them before reinventing the wheel Kind regards, > > Pimmetje > > Cheers edoput [0]: http://netjsonconfig.openwisp.org/en/stable/backends/create_your_backend.html -- 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.
