GNOME Bugzilla – Bug 667874
NM writes to its system configuration file (/etc/NetworkManager/NetworkManager.conf)
Last modified: 2013-04-30 13:37:47 UTC
NM tends to write stuff it's own system config file (/etc/NetworkManager/NetworkManager.conf) which complicates handling of shipping updates to these files by a distribution. In particular, I've noticed it writing such entries: no-auto-default=xx:xx:xx:xx:xx:xx, The problem with this is that from that point, the configuration file is considered to have been changed by the user, and (Debian and Ubuntu) upgrades are complicated by showing a prompt to confirm changes. In Ubuntu, we want to start shipping dns=dnsmasq with the NetworkManager package. Doing this right now means that any user who has renamed their auto connection will get a prompt asking to verify changes and optionally see a diff. However, users shouldn't be expected to know about these changes given that they were done in background by NetworkManager. NM should probably write the "no-auto-default" key to some other state file. Other config keys may be affected.
The complication here is that no-auto-default is actually a configuration value that users can change to ensure that NM doesn't create a default wired connection for the given interface. NM writes this value out when the user deletes the default wired connection to ensure that it's not re-created every reboot after the user has decided to kill it. I've also heard of users updating this manually to prevent this from happening. I suppose we could keep this information in /var/lib/ too and make a note in the manpage? It seems odd to have this configuration data in more than one place though. Is there no way with apt/deb to distinguish between programmatic changes and user changes?
I'll need to look more into it. I agree that keeping the same information in multiple places is probably weird. I was thinking more of something like the seen-bssids file where the list could contain just mac addresses; but I guess that doesn't work as well for keyfiles nor really help the users make sure this kind of data is modifyable. This is not something I'm expecting to fix now, but more as something to figure out if we can avoid in the future.
oh, this was fixed a while ago in master; automatically-added no-auto-defaults are now stored in $(NMSTATEDIR)/no-auto-default.state.