After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755995 - [RFE] allow provisioning connections as factory-default
[RFE] allow provisioning connections as factory-default
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: general
1.0.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-10-02 18:17 UTC by Tobias Hunger
Modified: 2020-11-12 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tobias Hunger 2015-10-02 18:17:56 UTC
I am running with /etc mounted read-only and in that setup Network Manager does not remember any wifi passwords or anything. This is due to trying to save that data in /etc/Network-Manager/system-connections, which is of course not possible, even for root.

In my opinion this data is state and not configuration. So it should go into /var/lib/Network-Manager/system-connections instead, where it incidentally would work just great, even in my kind of setup;-)
Comment 1 Thomas Haller 2015-10-09 15:50:57 UTC
The system-connection are ~configuration~, not state.
As such, the do belong to /etc. State we put either to /var/lib/NetworkManager (permanent) or /var/run/NetworkManger (temporary).

Something like http://0pointer.net/blog/projects/stateless.html talks about.


But we do want to run with /etc mounted as ro. Obviously, then you cannot add/modify any connections, but apart from that it should work just. (otherwise, please Bug report :) ).



IMO there are two things we want to do here:



(1) What we also want is to have read-only connections that an Admin can provision in /lib/NetworkManager. Such connections can be modified, but we will write the modification to /etc/NetworkManger/system-settings. That way, a user can again purge /etc to reset to the provisioned configuration.




(2) To help your special case, it would be enough to make the /etc path configurable in NetworkManager.conf, like:

  [keyfile]
  etc-path=/var/lib/NetworkManager/system-connections
Comment 2 Tobias Hunger 2015-10-09 16:15:51 UTC
To me configuration is static and the system connections are (somewhat) dynamic. But I can see why you might arrive at a differently conclusion. Hardcoding the system connections to be in /var/lib/NetworkManager would not work on completely stateless systems (no /etc, no /var) anyway, so it was probably not the best idea I had:-)

1. seems to be nice in the interest of "etc only has my overrides", but I do not think this is urgent: For the time being you can just have systemd populate /etc with the necessary information by adding a tmpfiles.d snippet.

I would appreciate 2 a lot though. But "system-connection-path" would be a more intuitive name for this setting than "etc-path".

In the meantime I did just create a symlink from /etc/NetworkManager/system-connections to some persistent, writable directory with the appropriate permissions. That works well enough for now.
Comment 3 Thomas Haller 2015-10-09 16:38:42 UTC
(In reply to Tobias Hunger from comment #2)

> I would appreciate 2 a lot though. But "system-connection-path" would be a
> more intuitive name for this setting than "etc-path".

How about "path" instead?

Patch for review is at th/keyfile-path-bgo755995.

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=th%2Fkeyfile-path-bgo755995
Comment 4 Tobias Hunger 2015-10-09 16:49:31 UTC
"path" seems very generic... But apart from that the patch seems fine to me, based on my very limited understanding of the code base.
Comment 5 Dan Williams 2015-10-09 20:38:01 UTC
Instead of making it a keyfile configuration option, why not just make it an NM build time flag?  It's not something that's ever going to change once you've built NM, or at least I don't see a good case for doing that.  If not a build-time flag, then a runtime one like "--system-connections-dir" or something like that.  Then people can put it wherever they want.
Comment 6 Thomas Haller 2015-10-09 20:55:47 UTC
(In reply to Dan Williams from comment #5)
> Instead of making it a keyfile configuration option, why not just make it an
> NM build time flag?  It's not something that's ever going to change once
> you've built NM, or at least I don't see a good case for doing that.  If not
> a build-time flag, then a runtime one like "--system-connections-dir" or
> something like that.  Then people can put it wherever they want.

that would be possible too.

IMO the runtime configuration is more flexible, with minimal additional complexity.

Having it a runtime option, allows the user to use the binary shipped with the distribution. Otherwise, such a user has to rebuild NM on its own, just to configure the directory.
Comment 7 Tobias Hunger 2015-10-09 21:15:28 UTC
I definitely prefer a runtime option over a build-time option: My distribution (arch) does not support /etc being read-only out of the box, so I would have to rebuild NetworkManager. That would be annoying:-)

Having said so: A command line parameter would work fine for me. Those are really easy to override in a systemd unit after all.
Comment 8 Beniamino Galvani 2015-10-14 16:02:21 UTC
I'm for runtime configuration and th/keyfile-path-bgo755995 looks good to me.
Comment 10 Thomas Haller 2015-10-14 18:27:12 UTC
(In reply to Thomas Haller from comment #1)


This leaves one thing to do here:

> (1) What we also want is to have read-only connections that an Admin can
> provision in /lib/NetworkManager. Such connections can be modified, but we
> will write the modification to /etc/NetworkManger/system-settings. That way,
> a user can again purge /etc to reset to the provisioned configuration.



Updating subject.
Comment 11 André Klapper 2020-11-12 14:33:36 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).