[OpenWrt-Devel] ubus: extending ubus over network to allow devices in the same network to exchange messages on a single common bus

[Sukru Senli]

Hi Felix,

Thank you for your interest and nice feedback on centralization.
We are working on preparing a  detailed design proposal which we will share once ready.
That should be a good start point to get into more technical discussions.

/Sukru

________________________________________
From: Felix Fietkau [nbd at nbd.name]
Sent: Wednesday, October 5, 2016 7:14 PM
To: Sukru Senli; openwrt-devel at lists.openwrt.org
Subject: Re: [OpenWrt-Devel] ubus: extending ubus over network to allow devices in the same network to exchange messages on a single common bus

Hi,

On 2016-10-05 15:57, Sukru Senli wrote:
> Dear OpenWrt developers,
>
> We, developers of IOPSYS (an OpenWrt based platform for residential
> gateways) at Inteno, believe that extending ubus over network so that
> multiple devices which are on the same network and running OpenWrt
> could communicate, expose objects and exchange messages on a common
> bus would be a very useful and worthwhile enhancement.
>
> For example, in a network scenario where multiple REPEATERs are
> connected to a MASTER gateway, REPEATERs could create objects, create
> events and listen/subscribe to events on the ubus which is exposed to
> network by MASTER, and that would facilitate: - keeping configuration
> synced between the devices - exchaning information about clients
> between the devices - devices notifying each other about specific
> actions, and so on
Interesting idea.

> So far we have envisioned the networked ubus system having the
> following components and properties:
>
> 1) Advertisement + Discovery: The devices on the same network become
> aware of each other and acknowledge that they support ubus. Here we
> believe a multicast solution is feasible.
>
> 2) Authentication + Connection: The devices choose to connect after
> verifying each other: Trust can be originated from a trusted third
> party such as a cloud service, or there can be a manual secure
> pairing method. Another option could be using TR069 and pushing keys
> down to devices to be used in verifying each other.
>
> 3) Networked ubus communication: ubus clients access remote or local
> ubus objects in a similar fashion: The intention is to either not
> change ubus API at all, or to change it as little as possible.
> However we see changing the ubus API as a better approach than
> changing ubusd daemon or message format significantly. In our initial
> design idea, a proxy component would take care of the communication
> and connection setup.
What kind of API changes do you envision?

> 4) Centralized ubus on MASTER: We believe it is appropriate to
> centralize control, so, for example, REPEATERs would expose (a subset
> of) their own ubus objects on MASTER's ubus.
I don't think you need to explicitly enshrine centralization into the
design. If you simply support a way of defining via policy what ubus
objects a device should be allowed to accept from or expose to other
networked devices, the policy and config files can be used to choose
whether it's a master/slave type of setup or something more distributed
with fine grained control over which objects gets exposed to which device.

> Developing an access control mechanism that operates on ubus directly
> in order to limit both local and remote access using the same method
> would be a good idea. ACL could be based on different parameters such
> as user/group, application, IP address etc.
>
> We will be moving forward with the design and implementation of a
> networked ubus, and we take this opportunity to invite participation
> and discussion so that a better solution where more OpenWrt
> developers/users benefit from can be developed.
I'm looking forward to receiving more information about your design
proposal and working with you in the future.

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel