We are working to support server use cases better. That will enable users to set different defaults on various settings (via the conf file).
I guess we could add ignore-auto-dns to that too. Dan Winship is working on that so he may have more info on this option.

(In reply to comment #1)
> I guess we could add ignore-auto-dns to that too. Dan Winship is working on
> that so he may have more info on this option.

That is not enough. AFAIK he wants to have a default list of DNS servers for connections that don't have specific ones.

(In reply to comment #2)
> (In reply to comment #1)
> > I guess we could add ignore-auto-dns to that too. Dan Winship is working on
> > that so he may have more info on this option.
> 
> That is not enough. AFAIK he wants to have a default list of DNS servers for
> connections that don't have specific ones.

So I want to have ignore-auto-dns to be true by default for all connections, except for specific ones, where I want ignore-auto-dns to be false.

The default dns = 127.0.0.1 is OK for all connections, since it's appended and not prepended, so if the current connection has ignore-auto-dns=false, I will use the network provided DNS servers anyway (if they are up).

Having a configurable default makes sense.


It seems "having default values" only works for picking configuration options individually. I mean, I don't see how we can have "default values for a connection", but I see that we can have a default value for "ipv6.ignore-auto-routes", "ipv6.may-fail", etc. -- on a one-by-one basis.


Let's say, we want to support that for property "<type>.<property-name>" (such as ipv6.ignore-auto-dns).

Then first that property must support to indicate a fallback to the default setting. For example, "ipv6.ignore-auto-dns" currently is only "yes|no". But we would need a new value "default" (think of it as "global").


Then we could have settings in NetworkManager.conf such as

[default-setting-<type>]
<property-name>=


e.g.
[default-setting-ipv6]
ignore-auto-dns=yes|no




If we like that pattern, I could do it for bug 721200 (ipv6.ip6-privacy)

Pushed an attempt to th/connection-defaults-bgo695383

As a proof of concept, I implemented default-value for ipvx.route-metric.


to quote the commit message:
    
    I think this has great potential. Only downside is that when
    the user looks at a connection value, it will see that it is
    unspecified. But the actually used value depends on the device
    type and might not be obvious.

Yeah, unfortunately like you say overrides will only work for properties that have an "undefined" value without a bunch of hacks.  One possible hack here would be a new 'default-override' (as) property added to NMSetting (thus each setting would have it) into which would be put the names of every property that the connection wanted explicitly set.  Thus if ignore-auto-dns was the setting-default value (false) but ipv4.default-override=[ignore-auto-dns] then the setting value (false) would be used and the global override would be ignored.  The issue with that is how you keep default-override in sync when setting the individual properties.

That at least would also deal with array and string properties too.  If we ever did convert to tri-state for stuff, that only works for integer & boolean, but doesn't work for strings and arrays.  Does a zero-length array mean "use the global default" or does it mean "really, no value here"?  So while it would be nice to use tristate I don't think that works for a lot of the properties we have that are array/string-based.

One thing I also looked at was hacking the GParamSpec default value on-the-fly, but it looks like we'd be messing around with GObject internals here (eg, casting the (const GValue*) return value from g_param_spec_get_default_value() to a non-const and changing the internal value) and that's not very nice to do nor is it very robust.

(In reply to Dan Williams from comment #6)
> Yeah, unfortunately like you say overrides will only work for properties
> that have an "undefined" value without a bunch of hacks.  One possible hack
> here would be a new 'default-override' (as) property added to NMSetting
> (thus each setting would have it) into which would be put the names of every
> property that the connection wanted explicitly set.  Thus if ignore-auto-dns
> was the setting-default value (false) but
> ipv4.default-override=[ignore-auto-dns] then the setting value (false) would
> be used and the global override would be ignored.  The issue with that is
> how you keep default-override in sync when setting the individual properties.

having default values doesn't make sense for every property. E.g. connection.id, connection.type, ipv4.method(?), ipv4.addresses. That doesn't mean the concept isn't useful for many cases.

Yes, that it doesn't work easily for old options that don't have an explicit "default" value, it doesn't mean it's not useful for some/many cases.


Right now,

  - bug 735052 adds a config option main.master-autoconnects-slaves for 
    connection.autoconnect-slave
  - bug 721200 added in a earlier version a property main.ip6-privacy for 
    ipv6.ip6-privacy.
  - I was long thinking about how to best make ipvx.route-metric configurable per device.


This new scheme allows for

[connection]
connection.autoconnect-slaves=yes
ipv6.ip6-privacy=2

[connection.wifi]
match-device=type:wifi
ipv4.route-metric=50
ipv6.route-metric=50


This seems a very sensible configuration behavior. Something relatively easy to explain, and yet powerful.


> That at least would also deal with array and string properties too.  If we
> ever did convert to tri-state for stuff, that only works for integer &
> boolean, but doesn't work for strings and arrays.  Does a zero-length array
> mean "use the global default" or does it mean "really, no value here"?  So
> while it would be nice to use tristate I don't think that works for a lot of
> the properties we have that are array/string-based.

a good candidate could be bg/dns-options-rh1200131
For a new property it's simple to distinguish between "empty array" and "defaulting to system-configuration".

Again, for old properties this distinction cannot be differentiated.



(In reply to Dan Williams from comment #7)
> One thing I also looked at was hacking the GParamSpec default value
> on-the-fly, but it looks like we'd be messing around with GObject internals
> here (eg, casting the (const GValue*) return value from
> g_param_spec_get_default_value() to a non-const and changing the internal
> value) and that's not very nice to do nor is it very robust.

I don't think you can do this blindly, without knowing which parameter you want to fallback to system-default. I think this must be a hand-picked, one-by-one action.

Also, you must also proviade some context a NMDevice to nm_config_data_get_connection_default(). And in the future we might have a

  match-wifi=except:ssid:HOME
  ipv6.ip6-privacy=2

or

  match-connection=type:bond
  connection.autoconnect-slaves=no

Contains now also patches from bug 721200

2455994 device: add global configuration default for ip6-privacy (use_tempaddr, 
31d3658 libnm/doc: document behavior of setting ip6-privacy in /etc/sysctl.conf

> device: add nm_device_get_type_description() function

+static const char *
+get_type_description (NMDevice *self)
+{
+       NMDevicePrivate *priv= NM_DEVICE_GET_PRIVATE (self);

missing space here           ^


> device: add device-spec "type:"

 NMMatchSpecMatchType
+nm_match_spec_device_type (const GSList *specs, const char *device_type)
+{
+       const GSList *iter;
+       NMMatchSpecMatchType match = NM_MATCH_SPEC_NO_MATCH;
+
+       if (!device_type || *device_type)
+          return NM_MATCH_SPEC_NO_MATCH;

Shouldn't the condition be " if (!device_type || !*device_type) " ?


>  device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941)

         <varlistentry>
+          <term><varname>ipv6.ip6-privacy</varname></term>
+          <listitem><para>If this value is unset, NetworkManager will always first check "/etc/sysctl.conf" and "/etc/sysctl.d/sysctl.conf" whether
+            they contain "net.ipv6.conf.default.use_tempaddr". This value is then preferred over any per-connection
+            setting. That step is omited when setting the global configuration value <literal>ipv6.ip6-privacy</literal>

s/omited/omitted/

(In reply to Beniamino Galvani from comment #10)
> > device: add nm_device_get_type_description() function
> 

All 3 points fixed and repushed.

Thanks!

LGTM

I am especially wondering two things:

- is this a suitable, powerful, comprehensible way how we can provide default-values for connections? (I think it is, opinions? suggestions?)

- the special handling in ipv6.privacy is hard to understand (for a user who reads the manual page). Maybe we should just change behavior and drop reading the old sysctl files? I dunno... changing behavior is bad, convoluted behavior is also bad...

(In reply to Thomas Haller from comment #13)
> I am especially wondering two things:
> 
> - is this a suitable, powerful, comprehensible way how we can provide
> default-values for connections? (I think it is, opinions? suggestions?)
> 
Seems fine in general, but I'd like to test it and think it over.

> - the special handling in ipv6.privacy is hard to understand (for a user who
> reads the manual page). Maybe we should just change behavior and drop
> reading the old sysctl files? I dunno... changing behavior is bad,
> convoluted behavior is also bad...

I was going to suggest that the description is hard to follow and that is not easily understandable what options are being talked about and how they relate.
Well, maybe, we should change the behaviour ...

Rebased and pushed again.

Now with a new commit:

  device: remove reading ipv6 privacy setting from sysctl

(In reply to Thomas Haller from comment #13)
> I am especially wondering two things:
> 
> - is this a suitable, powerful, comprehensible way how we can provide
> default-values for connections? (I think it is, opinions? suggestions?)

IMHO this lookup logic is quite flexible and should cover most use cases, we only have to start adding more supported options and maybe other device specifiers.

> - the special handling in ipv6.privacy is hard to understand (for a user who
> reads the manual page). Maybe we should just change behavior and drop
> reading the old sysctl files? I dunno... changing behavior is bad,
> convoluted behavior is also bad...

I find that the old handling was too complex and thus I'm in favor of the last commit that you pushed, even if there's the risk of changing the behavior. And if we're changing behavior we might also consider fixing this:

  https://bugzilla.redhat.com/show_bug.cgi?id=1187525

and make IPv6 privacy extensions enabled by default.

(In reply to Beniamino Galvani from comment #16)
> (In reply to Thomas Haller from comment #13)
> > I am especially wondering two things:
> > 
> > - is this a suitable, powerful, comprehensible way how we can provide
> > default-values for connections? (I think it is, opinions? suggestions?)
> 
> IMHO this lookup logic is quite flexible and should cover most use cases, we
> only have to start adding more supported options and maybe other device
> specifiers.

thanks.


> > - the special handling in ipv6.privacy is hard to understand (for a user who
> > reads the manual page). Maybe we should just change behavior and drop
> > reading the old sysctl files? I dunno... changing behavior is bad,
> > convoluted behavior is also bad...
> 
> I find that the old handling was too complex and thus I'm in favor of the
> last commit that you pushed, even if there's the risk of changing the
> behavior. And if we're changing behavior we might also consider fixing this:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1187525
> 
> and make IPv6 privacy extensions enabled by default.

Maybe not. Now the last fallback is /proc/sys/net/ipv6/conf/default/use_tempaddr. So we actually unburden us from defining a default value and leave it to other system components.

(In reply to Thomas Haller from comment #17)
> (In reply to Beniamino Galvani from comment #16)

> > > - the special handling in ipv6.privacy is hard to understand (for a user who
> > > reads the manual page). Maybe we should just change behavior and drop
> > > reading the old sysctl files? I dunno... changing behavior is bad,
> > > convoluted behavior is also bad...
> > 
> > I find that the old handling was too complex and thus I'm in favor of the
> > last commit that you pushed, even if there's the risk of changing the
> > behavior. And if we're changing behavior we might also consider fixing this:
> > 
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1187525
> > 
> > and make IPv6 privacy extensions enabled by default.
> 
> Maybe not. Now the last fallback is
> /proc/sys/net/ipv6/conf/default/use_tempaddr. So we actually unburden us
> from defining a default value and leave it to other system components.

I mean, rh1187525 would be fixed by this branch; in the meaning that we make use of what is configured as default by other system components.
I like that!

(In reply to Thomas Haller from comment #18)
> I mean, rh1187525 would be fixed by this branch; in the meaning that we make
> use of what is configured as default by other system components.

Reading again the description of bug rh1187525, the problem appears to be that the ip6-privacy value set in the connection by clients (nm-applet?) is by default "Disabled". So at a second glance maybe it's not much related to this bug.

Anyway, the branch LGTM.

merged to master as http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=18ecf48d7a9d03194db1b65ef46e386284426f89

Now there is an infrastructure/best-practice to define default values for connections.


As for:

(In reply to Gergely Risko from comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > I guess we could add ignore-auto-dns to that too. Dan Winship is working on
> > > that so he may have more info on this option.
> > 
> > That is not enough. AFAIK he wants to have a default list of DNS servers for
> > connections that don't have specific ones.
> 
> So I want to have ignore-auto-dns to be true by default for all connections,
> except for specific ones, where I want ignore-auto-dns to be false.
> 
> The default dns = 127.0.0.1 is OK for all connections, since it's appended
> and not prepended, so if the current connection has ignore-auto-dns=false, I
> will use the network provided DNS servers anyway (if they are up).

this specific issue about configuring default-value for dns-option is still open. I update the subject of the patch.

See also bug 750727 which proposes how to extend the default-configuration-scheme.

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).