Daniel Wagner <wagi(a)monom.org> writes:
On Mon, Feb 03, 2020 at 04:53:50PM +0300, Sergey Organov wrote:
> Thanks! I've read it already, but it seemed unnatural to me to be forced
> to parse/edit configuration file(s) directly, effectively duplicating
> what connmand does anyway, especially as my actual aim is to do it from
> an application.
The reason why the provisioning is done only by file is that the D-Bus
API lacks a way to create non existing services. You can only modify
currently available services via D-Bus.
I meant that I'd expected I could configure Ethernet without
provisioning. In other words, I don't see why Ethernet with disconnected
cable is to be considered "non-existing" rather than, say,
"disconnected", or something else, keeping the ability to handle it
through D-Bus/connmanctl rather than forcing to use provision config
> I'll obviously do it, as it happens to be the only available way, but
> it's still unclear how does provisioning interoperate with configuration
> through D-Bus/connmanctl? My quick test shows that "connmanctl
> configure" starts to give (rather undescriptive) errors on provisioned
> # connmanctl config ethernet_0018d7677f91_cable ipv4 dhcp
> Error ethernet_0018d7677f91_cable: Not supported
connmanctl config ethernet_0018d7677f91_cable --ipv4 dhcp
It doesn't seem to matter, both give the same error when interface is
provisioned, and both work silently when not, that seems to be perfectly
inline with the design of mutual exclusion of the features. The only woe
here is that error message could have been more informative.
> effectively making provisioning and "connmanctl configure" mutually
> exclusive. Is it how it's designed to behave indeed?
Yes indeed, they are mutually exclusive due it's original use case.
OK, got it, thanks!