Hi Guys,
During monthly software updates, /etc/connman.conf is being overwritten. I am not sure if it is being modified or simply being replaced with an exact copy of itself.
However, this is causing problems with my configuration as I have a ‘NetworkInterfaceBlacklist’ command in the file which is being lost each time.
Is it possible to reference a user file in connman.conf in the same way that smb.conf references smb-shares.conf to prevent user specific configuration being overwritten?
I need the NetworkInterfaceBlacklist to ensure ConnMan doesn’t cause issues with the tap interface created by OpenVPN (which is does do if not explicitly blacklisted).
Thanks for your help.
Steve
We have a file called /etc/connman.prefs. We could look at adding the ability to specify a different configuration file as a parameter, or we can investigate marking /etc/connman.conf as a conf file.
Hi Sam,
I suppose the solution would depend on whether your team will ever need to modify connman.conf with the fact that that will overwrite user mods.
I would be happy with either solution 
Thank you.
Steve
We have changed connman.conf a couple of times in the past.
The main reason why it is not marked as a conffile in the package is that our automated update process previously couldn’t handle situations where APT would prompt the user whether they should keep their local customised copy of a conffile that had changed, or to install the new version.
This resulted in the update process hanging indefinitely on a prompt that could not be seen or responded to, which would typically lead a user to pull the plug as the system appeared to have “hung” resulting in a failed upgrade and potentially problems from pulling the power too… Because of this we originally did not mark any files as conffiles specifically to avoid this. (Although installed 3rd party packages that tried to prompt could still cause the same issue)
A few months ago we tweaked the update system to automatically and silently choose to keep the user-customised version of any conffiles during the upgrade process, thus avoiding a hang during upgrading.
In this case, if you have never edited a conf file and we update it, it would be updated to the new version, however if you have ever edited the conf file, the upgrade would not touch your modified file, but create a new filename.confnew file containing our new version of the file for you to look at and consider. (Or something like that, can’t remember the exact extension)
As yet we still haven’t marked any of our configuration files as conffiles but connman.conf was already on my list of potential candidates to be marked as a conffile, we just haven’t had time to thoroughly test it yet to make sure it doesn’t introduce any problems. There are quite a few other config files that might be useful to be marked as conffiles too.