Hi Karl, On Fri, May 27, 2016 at 1:55 PM, Karl Palsson <ka...@tweak.net.au> wrote: > > David Lang <da...@lang.hm> wrote: >> On Thu, 26 May 2016, Delbar Jos wrote: >> >> > We are conscious of the fact that together with the proposals made by >> > Felix, >> > Luka and Wojtek we are now looking at many "competing" proposals. As a next >> > step, we recommend to organize a workshop, at a practical location and >> > time, >> > where we put everything on the table and define the most appropriate path >> > forward to the benefit of OpenWrt as a whole. >> >> nothing wrong with supporting many different remote management >> daemons. >> >> > TR-069 is a complicated remote management system and in order to make this >> > initiative a success, we must ensure that the complexity is handled in an >> > elegant way and with respect for OpenWrt's core architecture. More than on >> > the >> > protocol itself, we believe that we should focus on the architectural >> > enhancements required to support remote management in general. >> >> What is it that you think is needed to "support remote >> management in general"? >> >> It's worth pointing out that many people are remotely managing >> OpenWRT devices, Ansible/Salt/Puppet/Chef/etc are all common >> tools for the job. > > Really? python, python, ruby, ruby. None of those are really fun enjoyable > tasks on _my_ openwrt/leded devices. > >> now, those are all tools aimed at managing Linux Servers, not >> networking gear, but OpenWRT is a server. >> >> So I'd suggest starting off by creating a daemon that talks >> <your protocol> and just stores the stuff it's sent in some >> simple files so that it can return the info when queried. > > Did you read the intro to Delbar's mail, describing that they > already have a complete tr069 project, for managing openwrt > devices, that they want to open source, and want to collaborate > on making it more useful for all, and perhaps see if there are > common pain points that can be resolved by handling things > differently on the lede/openwrt side, rather than working around > on the tr069 side? > > I think it's exciting and I'd love to hear more about it. > ansible/salt/puppet/chef have been far too heavy to run, and > openvpn servers granting remote shell access is far too tedious > for daily use.
I am very interested to see TR-069 solution. IMHO what is really useful in it is Amendment 5, NAT traversal based on XMMP. Both AllJoyn and Iotivity seem to push this approach to managing CPEs - naturally, it has been proven and widely used. For the reference, here is an interesting discussion I had with Thiago Macieira from Iotivity: https://lists.linuxfoundation.org/pipermail/iotivity-dev/2015-October/002867.html However, I would personally look more at OMA LwM2M - it would be much lighter and more fun to implement ;). NAT traversal is not so straightforward, but it would be interesting to investigate it. Then clients will be ultra-light. BR, Drasko _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
