We're not going to do anyhting to specifically get NM to stop touching resolv.conf, but we do want to create a more flexible plugin-type interface like the dispatcher where scripts provided by the various DNS services (dnsmasq, unbound, dnssec-trigger, whatever) can drop a script into eg /etc/NetworkManager/dns.d where NM calls those scripts with the DNS configuration and they can do what they want with it.

The script would return a certain value to indicate that the script has handled resolv.conf; another value would indicate that NM should write "127.0.0.1" to resolv.conf to make it easier to write local-caching-nameserver plugins.  eg, the dnsmasq plugin might send the information to dnsmasq over dbus, and then return "please put 127.0.0.1 into resolv.conf for me" since NM already has the code to handle resolv.conf, the script doesn't have to do it.

Additionally, later, we may create a pull-based dbus interface as well, based on the current secret agent model, where dbus-based servers can register with NetworkManager, and NM then pushes DNS information out to those services when it changes.  This allows us to watch the lifeitme of those services and ensure that  if they crash, connectivity is not interrupted.

The rationale is to allow the administrator to choose to *not* use networkmanager for local DNS configuration but instead use another tool.

Although it would be nice to have D-Bus interfaces for the complicated use cases.

In the most basic use case, the administrator is already using something with a static configuration and wants to keep doing that. For that he needs a simple way to disable networkmanager's handling of DNS. A simple one, in this case means one that is not much more difficult that the above 'chattr' call.

The syntax for it could simply be:

dns=none

We already have the dns directive to support stuff like dns=dnsmasq, so this is not a new API and therefore is almost for free.

A short summary of an IRC discussion:

* Possibility of a dispatcher-style scripted solution as an alternative to the C code handling resolv.conf, resolvconf, netconfig, etc.
* Possibility of moving more stuff into C plugins.
* A DNS plugin (e.g. for a specific DNS server) still wants to write /etc/resolv.conf. Plugins could share code or resolv.conf writing can stay in the core.
* There may be issues with resolvconf/netconfig synchronicity.
* A dbus interface could broadcast the name service configuration.
* /etc/resolv.conf handling in an *.so might according to dcbw result in a more fragile system.

*** Bug 682995 has been marked as a duplicate of this bug. ***

So what I'm currently thinking (after some discussion on IRC):

the dns= key will become a string instead of a list of strings; this is backward-compatible, because there is currently only one valid value for it anyway.

The values are:

  (unset) or "dns=auto": the same thing as the default behavior now,
    which is: use resolvconf if built with resolvconf support, or
    netconfig if built with netconfig support, or else modify
    /etc/resolv.conf directly

  "dns=dnsmasq": same as now: send the real DNS configuration to dnsmasq,
    and then do resolvconf/netconfig/direct modification as above, but
    using 127.0.0.1 as the only nameserver.

  "dns=none": don't modify resolv.conf at all, by any means

  "dns=/path/to/script": run that script, with details of the current DNS
    configuration passed in via environment variables, and don't do
    anything else

This is simple, and lets you do anything (via a script), and is backwards-compatible, and doesn't cause any existential angst about "well should we still call resolvconf if the previous script did X". The fact that the script needs to magically know whether to call netconfig or resolvconf is not a problem, because such scripts are expected to be just for the machine that they're on, to implement arbitrary one-off requests like "I want the VPN nameservers after the local ones not vice versa" (bug 673793), not to be portable means of implementing generically useful behavior (which would be implemented as additional built-in plugins if they were needed).

(In reply to comment #6)
> The values are:
> 
>   (unset) or "dns=auto": the same thing as the default behavior now,
>     which is: use resolvconf if built with resolvconf support, or
>     netconfig if built with netconfig support, or else modify
>     /etc/resolv.conf directly
> 
>   "dns=dnsmasq": same as now: send the real DNS configuration to dnsmasq,
>     and then do resolvconf/netconfig/direct modification as above, but
>     using 127.0.0.1 as the only nameserver.
> 
>   "dns=none": don't modify resolv.conf at all, by any means
> 
>   "dns=/path/to/script": run that script, with details of the current DNS
>     configuration passed in via environment variables, and don't do
>     anything else

Agreed.

(In reply to comment #6)
> So what I'm currently thinking (after some discussion on IRC):
> 
> the dns= key will become a string instead of a list of strings; this is
> backward-compatible, because there is currently only one valid value for it
> anyway.
> 
> The values are:
> 
>   (unset) or "dns=auto": the same thing as the default behavior now,
>     which is: use resolvconf if built with resolvconf support, or
>     netconfig if built with netconfig support, or else modify
>     /etc/resolv.conf directly
> 
>   "dns=dnsmasq": same as now: send the real DNS configuration to dnsmasq,
>     and then do resolvconf/netconfig/direct modification as above, but
>     using 127.0.0.1 as the only nameserver.
> 
>   "dns=none": don't modify resolv.conf at all, by any means
> 
>   "dns=/path/to/script": run that script, with details of the current DNS
>     configuration passed in via environment variables, and don't do
>     anything else
> 
> This is simple, and lets you do anything (via a script), and is
> backwards-compatible, and doesn't cause any existential angst about "well
> should we still call resolvconf if the previous script did X". The fact that
> the script needs to magically know whether to call netconfig or resolvconf is
> not a problem, because such scripts are expected to be just for the machine
> that they're on, to implement arbitrary one-off requests like "I want the VPN
> nameservers after the local ones not vice versa" (bug 673793), not to be
> portable means of implementing generically useful behavior (which would be
> implemented as additional built-in plugins if they were needed).

Also agreed; though I'd love to spin the resolvconf and netconfig support out to their own plugins and not have special logic in nm-dns-manager for them.  Then, if you configured with --enable-resolvconf=yes, we'd install an /etc/NEtworkManager/conf.d/10-resolvconf file with "dns=resolvconf" that would run resolvconf or netconfig, that the user could delete if they wished to turn that behavior off.

Basically, I'd liek to  make nm-dns-manager.c just an engine for prioritizing the DNS information and pushing it out to whatever scripts/plugins have been configured, instead of doing a lot of logic on its own.

pushed this to danw/dns=none

The current code does not implement external scripts; it just (a) makes the dns key single-valued, and (b) implements dns=none. Other stuff can happen later.

(I think if we want to do this:

> though I'd love to spin the resolvconf and netconfig support out
> to their own plugins and not have special logic in nm-dns-manager for them. 
> Then, if you configured with --enable-resolvconf=yes, we'd install an
> /etc/NEtworkManager/conf.d/10-resolvconf file with "dns=resolvconf" that would
> run resolvconf or netconfig, that the user could delete if they wished to turn
> that behavior off.

we should do it by deprecating the main/dns key and adding a new dns-plugins key or something like that, so we don't have to worry about backward compatibility (eg, "dns=resolvconf" actually means "dns=resolvconf,netconfig" if you're on SUSE). And the right way to do the above would actually be 90-resolvconf.conf containing "dns-plugins+=resolvconf", so that if you had 50-dnsmasq.conf too, they'd merge together correctly.)

* danw/dns=none
 - I can't see _PATH_RESCONF defined enywhere.
 - Update [main] dns= in man/NetworkManager.conf for the new syntax

(In reply to comment #10)
> * danw/dns=none
>  - I can't see _PATH_RESCONF defined enywhere.

Yeah, I was like "what?" but then:

/include/resolv.h:#ifndef _PATH_RESCONF
/usr/include/resolv.h:#define _PATH_RESCONF        "/etc/resolv.conf"

apparently there's a system macro for that :)


Besides the manpage update jklimes mentioned, the rest of the patches look good to me.

committed