connman.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Unification to connman configuration? Now it 3 separated places.
@ 2022-01-26 22:40 Piotr Karbowski
  2022-01-30 14:51 ` Daniel Wagner
  0 siblings, 1 reply; 6+ messages in thread
From: Piotr Karbowski @ 2022-01-26 22:40 UTC (permalink / raw)
  To: connman

Hi,

I'd like to discuss the possibility to unify the configuration of connman.

Currently there are three places where one configure connman:

- Command line arguments to deamon
- /etc/connman/main.conf file
- /var/lib/connman/settings

Which is quite a hassle to maintain.

To go with actual examples

- disable dns proxy -- only via command line argument.
- disable hostname updates via dhcp -- /etc/connman/main.conf file
- disable NTP client -- /var/lib/connman/settings file

Would it be possible to unify those into a single interface?

-- Piotr.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Unification to connman configuration? Now it 3 separated places.
  2022-01-26 22:40 Unification to connman configuration? Now it 3 separated places Piotr Karbowski
@ 2022-01-30 14:51 ` Daniel Wagner
  2022-01-30 21:50   ` Piotr Karbowski
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel Wagner @ 2022-01-30 14:51 UTC (permalink / raw)
  To: Piotr Karbowski; +Cc: connman

Hi Piotr,

On Wed, Jan 26, 2022 at 10:40:19PM +0000, Piotr Karbowski wrote:
> 
> Currently there are three places where one configure connman:
> 
> - Command line arguments to deamon
> - /etc/connman/main.conf file
> - /var/lib/connman/settings
> 
> Which is quite a hassle to maintain.

Yes, indeed. Let's start with the simplest one:

- /var/lib/connman/settings

This is file is under control of ConnMan. The user is not supposed to
edit. But it keeps the default settings how ConnMan should behave when
started for the first time. I suppose we could add those defaults
settings to /etc/connman/main.conf.

- /etc/connman/main.conf file

This contains the more 'static' configuration bits for ConnMan. I think
we need a config file for the defaults. Don think we get away without one.

> To go with actual examples
> 
> - disable dns proxy -- only via command line argument.

This should go into the /etc/connman/main.conf. This should be fairly
simple to do as well.

> - disable hostname updates via dhcp -- /etc/connman/main.conf file
> - disable NTP client -- /var/lib/connman/settings file
> 
> Would it be possible to unify those into a single interface?

Yes sure. 

For any global default setting we should add/move it to main.conf. The
difficult bits are the dynamic bits for newly discovered services.

Daniel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Unification to connman configuration? Now it 3 separated places.
  2022-01-30 14:51 ` Daniel Wagner
@ 2022-01-30 21:50   ` Piotr Karbowski
  2022-02-14  7:45     ` Daniel Wagner
  0 siblings, 1 reply; 6+ messages in thread
From: Piotr Karbowski @ 2022-01-30 21:50 UTC (permalink / raw)
  To: Daniel Wagner; +Cc: connman

On 30/01/2022 15.51, Daniel Wagner wrote:
> Hi Piotr,
>
> On Wed, Jan 26, 2022 at 10:40:19PM +0000, Piotr Karbowski wrote:
>>
>> Currently there are three places where one configure connman:
>>
>> - Command line arguments to deamon
>> - /etc/connman/main.conf file
>> - /var/lib/connman/settings
>>
>> Which is quite a hassle to maintain.
>
> Yes, indeed. Let's start with the simplest one:
>
> - /var/lib/connman/settings
>
> This is file is under control of ConnMan. The user is not supposed to
> edit. But it keeps the default settings how ConnMan should behave when
> started for the first time. I suppose we could add those defaults
> settings to /etc/connman/main.conf.
>
> - /etc/connman/main.conf file
>
> This contains the more 'static' configuration bits for ConnMan. I think
> we need a config file for the defaults. Don think we get away without one.
>
>> To go with actual examples
>>
>> - disable dns proxy -- only via command line argument.
>
> This should go into the /etc/connman/main.conf. This should be fairly
> simple to do as well.
>
>> - disable hostname updates via dhcp -- /etc/connman/main.conf file
>> - disable NTP client -- /var/lib/connman/settings file
>>
>> Would it be possible to unify those into a single interface?
>
> Yes sure.
>
> For any global default setting we should add/move it to main.conf. The
> difficult bits are the dynamic bits for newly discovered services.

If you were to move the /var/lib/connman/<SERVICE_NAME>/settings to
perhaps subdirectory in /etc/connman/networks/ it could work. One of the
example could be NetworkManager that actually dynamically create files
in /etc.

perhaps the 'data' files could stay in /var/lib/connman/<SERVICE_NAME>/data.

That would be pretty clean interface to configure connman. Especially if
you need to pre-create some configs for services manually like 802.1X
that I think is not supported by any userspace utils that ships with
connman.

-- Piotr.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Unification to connman configuration? Now it 3 separated places.
  2022-01-30 21:50   ` Piotr Karbowski
@ 2022-02-14  7:45     ` Daniel Wagner
  2023-01-31 11:29       ` Piotr Karbowski
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel Wagner @ 2022-02-14  7:45 UTC (permalink / raw)
  To: Piotr Karbowski; +Cc: connman

On Sun, Jan 30, 2022 at 09:50:31PM +0000, Piotr Karbowski wrote:
> If you were to move the /var/lib/connman/<SERVICE_NAME>/settings to
> perhaps subdirectory in /etc/connman/networks/ it could work. One of the
> example could be NetworkManager that actually dynamically create files
> in /etc.

/var/lib/connman/* are not configuration files. These files contain the
state. The are under control of ConnMan and will be overwritten.

That means these files need to live in space where ConnMan can write to
(/etc will not work). Furthermore, embedded devices tend to be vary
cautions about write updates and often move such things to a tmpfs.

Another problem is the id used to apply to a newly discovered
services. The path is constructed using the MAC. In my opinion not very
convenient and not really future proof.

All this is solvable but it is a bit more work than just moving the dirs
around. I think we would need to introduce a new configuration logic here.

> That would be pretty clean interface to configure connman. Especially if
> you need to pre-create some configs for services manually like 802.1X
> that I think is not supported by any userspace utils that ships with
> connman.

Yes, I do understand the need for something like this. Ideally we
wouldn't come up with yet another config file format. Maybe we could
reuse the one from systemd-networkd? No idea if this would work, just an
idea.

Daniel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Unification to connman configuration? Now it 3 separated places.
  2022-02-14  7:45     ` Daniel Wagner
@ 2023-01-31 11:29       ` Piotr Karbowski
  2023-02-27  7:09         ` Daniel Wagner
  0 siblings, 1 reply; 6+ messages in thread
From: Piotr Karbowski @ 2023-01-31 11:29 UTC (permalink / raw)
  To: Daniel Wagner; +Cc: connman

Hi,

On 14/02/2022 08.45, Daniel Wagner wrote:
> On Sun, Jan 30, 2022 at 09:50:31PM +0000, Piotr Karbowski wrote:
>> If you were to move the /var/lib/connman/<SERVICE_NAME>/settings to
>> perhaps subdirectory in /etc/connman/networks/ it could work. One of the
>> example could be NetworkManager that actually dynamically create files
>> in /etc.
>
> /var/lib/connman/* are not configuration files. These files contain the
> state. The are under control of ConnMan and will be overwritten.
>
> That means these files need to live in space where ConnMan can write to
> (/etc will not work). Furthermore, embedded devices tend to be vary
> cautions about write updates and often move such things to a tmpfs.
>
> Another problem is the id used to apply to a newly discovered
> services. The path is constructed using the MAC. In my opinion not very
> convenient and not really future proof.
>
> All this is solvable but it is a bit more work than just moving the dirs
> around. I think we would need to introduce a new configuration logic here.
>
>> That would be pretty clean interface to configure connman. Especially if
>> you need to pre-create some configs for services manually like 802.1X
>> that I think is not supported by any userspace utils that ships with
>> connman.
>
> Yes, I do understand the need for something like this. Ideally we
> wouldn't come up with yet another config file format. Maybe we could
> reuse the one from systemd-networkd? No idea if this would work, just an
> idea.

I recently had to do another round of connman configuration which
reminded me about this thread.

Wanted to ask if you still consider this a feature that's worth getting
into? I kind of got used to the current way but still believe it would
benefit many to have it unified. I am all into being the tested if you
ever decide to introduce some new interfaces to configure connman.

-- Piotr.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Unification to connman configuration? Now it 3 separated places.
  2023-01-31 11:29       ` Piotr Karbowski
@ 2023-02-27  7:09         ` Daniel Wagner
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Wagner @ 2023-02-27  7:09 UTC (permalink / raw)
  To: Piotr Karbowski; +Cc: connman

On Tue, Jan 31, 2023 at 11:29:26AM +0000, Piotr Karbowski wrote:
> Hi,
> 
> On 14/02/2022 08.45, Daniel Wagner wrote:
> > On Sun, Jan 30, 2022 at 09:50:31PM +0000, Piotr Karbowski wrote:
> >> If you were to move the /var/lib/connman/<SERVICE_NAME>/settings to
> >> perhaps subdirectory in /etc/connman/networks/ it could work. One of the
> >> example could be NetworkManager that actually dynamically create files
> >> in /etc.
> >
> > /var/lib/connman/* are not configuration files. These files contain the
> > state. The are under control of ConnMan and will be overwritten.
> >
> > That means these files need to live in space where ConnMan can write to
> > (/etc will not work). Furthermore, embedded devices tend to be vary
> > cautions about write updates and often move such things to a tmpfs.
> >
> > Another problem is the id used to apply to a newly discovered
> > services. The path is constructed using the MAC. In my opinion not very
> > convenient and not really future proof.
> >
> > All this is solvable but it is a bit more work than just moving the dirs
> > around. I think we would need to introduce a new configuration logic here.
> >
> >> That would be pretty clean interface to configure connman. Especially if
> >> you need to pre-create some configs for services manually like 802.1X
> >> that I think is not supported by any userspace utils that ships with
> >> connman.
> >
> > Yes, I do understand the need for something like this. Ideally we
> > wouldn't come up with yet another config file format. Maybe we could
> > reuse the one from systemd-networkd? No idea if this would work, just an
> > idea.
> 
> I recently had to do another round of connman configuration which
> reminded me about this thread.
> 
> Wanted to ask if you still consider this a feature that's worth getting
> into? I kind of got used to the current way but still believe it would
> benefit many to have it unified. I am all into being the tested if you
> ever decide to introduce some new interfaces to configure connman.

Yes, it still makes sense to me. Though I become a very poor maintainer and I
think it is high time to hand over the project to someone else. Without someone
looking over contributions the bit rotting continues and new feature are
certain not going to be implemented by me.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-02-27  7:14 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-26 22:40 Unification to connman configuration? Now it 3 separated places Piotr Karbowski
2022-01-30 14:51 ` Daniel Wagner
2022-01-30 21:50   ` Piotr Karbowski
2022-02-14  7:45     ` Daniel Wagner
2023-01-31 11:29       ` Piotr Karbowski
2023-02-27  7:09         ` Daniel Wagner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).