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 673537 - device whitelisting: add global autoconnect configuration variable
device whitelisting: add global autoconnect configuration variable
Status: RESOLVED DUPLICATE of bug 688857
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Pavel Simerda
NetworkManager maintainer(s)
Depends on:
Blocks: nm-0.9.10 695213
 
 
Reported: 2012-04-04 23:46 UTC by greearb
Modified: 2013-05-06 14:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description greearb 2012-04-04 23:46:34 UTC
For instance, we want to create lots of virtual wireless interfaces.  If we leave NewtworkManager enabled, it automatically tries to mess with those interfaces as soon as they are created.

Since black-listing all possible MACs we might use for virtual interfaces is
not possible, we would instead like to just white-list the few interfaces
that we want NM to deal with by editing the NetworkManager config file
or similar.
Comment 1 Pavel Simerda 2012-07-26 12:53:07 UTC
Confirming that disabling auto-managing/auto-connection would be a great feature.
Comment 2 Pavel Simerda 2012-08-16 21:35:02 UTC
Just adding that many use cases (virtualization included) will actually REQUIRE this feature with NetworkManager. This feature would also enable a rather passive way of running NetworkManager that would make traditional scenarios with explicit networking possible.
Comment 3 Chris Hiestand 2012-08-16 23:41:52 UTC
+1 on disabling automatic management of new interfaces.
Comment 4 Pavel Simerda 2012-09-02 12:54:59 UTC
My proposal is to add new 'autoconnect' key to /etc/NetworkManager.conf with the following autoconnect levels:

1) autoconnect=none

Turn of all connection's autoconnect option.

2) autoconnect=configured

Don't generate default connection configurations and only
activate configured connections with autoconnect enabled
(it's enabled by default).

3) autoconnect=all (the default)

Connect any autoconnect connections and generate connections
for devices that don't have a configured connection.

Note: The third value could be replaced by a generic network
configuration in system-connections. But it's probably easier
to avoid it due to possible problems with configuration plugins.
Comment 5 greearb 2012-09-02 14:31:29 UTC
With regard to the 'autoconnect' option:

1)  Does this mean NM would effectively do nothing at all?

2)  How does NM determine which connections are configured or not?
Comment 6 Pavel Simerda 2012-09-02 22:46:35 UTC
> 1)  Does this mean NM would effectively do nothing at all?

Exactly. It would just observe the network configuration and export its dbus
API waiting for you to activate connections by hand (nmcli or D-Bus).

This is not a mode intended for general use. This is good for testing
and might be also handy in some specific environments where NM is just
a part of a bigger machinery.

But I could live without that, it's just a convenient option to avoid the need
to disable autoconnection individually on all connections.

> 2)  How does NM determine which connections are configured or not?

By default it looks at /etc/NetworkManager/system-connections for keyfile connection configuration files. These also determine whether the connection
is 'autoconnect' or not. On some system, different configuration plugins
are used.
Comment 7 Pavel Simerda 2012-09-02 22:49:53 UTC
Just a sidenote, for some devices, e.g. wireless, NetworkManager IMO does something even when there's no configured connection for them.
Comment 8 greearb 2012-09-02 22:54:05 UTC
I'm fine with option one disabling NM..better than existing ways, but should
make sure it really does nothing (ie, fix what Pavel is talking about).

As for 3):  What creates/edits the system-connnections file(s)?  If it
is anything other than NM, then the whitelisting won't really work until
yet more tools have been hacked.  If only NM ever edits/creates these files,
and setting option 3 disables that, then it would seem fine to me.
Comment 9 Pavel Simerda 2012-09-02 23:01:12 UTC
> As for 3):  What creates/edits the system-connnections file(s)?  If it
> is anything other than NM, then the whitelisting won't really work until
> yet more tools have been hacked.  If only NM ever edits/creates these files,
> and setting option 3 disables that, then it would seem fine to me.

They can be edited with a text editor or through NetworkManager's D-Bus
interface. The D-Bus interface can be used through CLI and GUI tools or
can be used by other tools.

There's no reason to run NM if you don't want it to do anything. Of course
if another tool does something wrong, it must be fixed, stopped or removed.
Comment 10 Dan Winship 2012-11-08 18:49:03 UTC
(In reply to comment #4)
> My proposal is to add new 'autoconnect' key to /etc/NetworkManager.conf with
> the following autoconnect levels:
> 
> 1) autoconnect=none
> 
> Turn of all connection's autoconnect option.

I'm not sure we really need that... if there's an option to not automatically create autoconnect connections, then the admins can just set the right options on their own connections themselves. (At some point they'll probably end up wanting "don't autoconnect on most interfaces, but do autoconnect this one" anyway.)

> 2) autoconnect=configured
> 
> Don't generate default connection configurations and only
> activate configured connections with autoconnect enabled
> (it's enabled by default).
> 
> 3) autoconnect=all (the default)
> 
> Connect any autoconnect connections and generate connections
> for devices that don't have a configured connection.

So if there's only 2 and 3, it could be a boolean instead. "autogenerate_autoconnect=[yes|no]" or something. Though that's possibly an awful name.

(Found this bug while looking for a bug on carrier-detect behavior, but that's not *quite* the same thing as this...)
Comment 11 Pavel Simerda 2013-05-06 14:42:56 UTC

*** This bug has been marked as a duplicate of bug 688857 ***