Re: [PATH] Support resolvconf

[Dan Williams <dcbw redhat com>]

On Wed, 2008-08-27 at 06:34 +0100, Roy Marples wrote:
> On Tue, 2008-08-26 at 22:20 -0400, Dan Williams wrote:
> > On Wed, 2008-08-27 at 03:49 +0200, Michael Biebl wrote:
> > > Roy Marples wrote:
> > > > On Sun, 2008-08-24 at 01:01 +0200, Alexander Sack wrote:
> > > 
> > > >> For the domain/search tweakage: I feel unsure about this (though I kept
> > > >> this part of your patch untouched for now). This is quite a specific
> > > >> feature you want to implicitly entrench here. Maybe we can push
> > > >> that back until we know if and how we want to implement such a
> > > >> feature?
> > > > 
> > > > There's no real need to push it back.
> > > > NM currently folds domain into searches, so there's no need to actually
> > > > use domain at all.
> > > 
> > > Hi Roy,
> > > 
> > > I agree with Alex here.
> > > Could you please split up the patch into two, so we can address those
> > > two issues separately.
> > > I think the resolvconf part is fine.
> > > Dan, if you are ok with it also, I'd be going to commit this, unless you
> > > beat me to it ;-)
> > 
> > It looks OK, except for one change.  Not sure where we left the
> > conversation last, but I'm not sure if just because resolvconf is
> > installed means that it's actually being used.  Most of the time you can
> > have a package installed, but you don't have to enable it.  For the
> > moment, I'd suggest either (1) #ifdef-ing the resolvconf specific stuff
> > with #ifdef DEBIAN, or (2) adding a configure switch for
> > --with-resolv-conf=yes which would #define USE_RESOLVCONF, and then
> > protect the resolvconf stuff with #ifdef USE_RESOLVCONF.
> 
> Would you like the path hardcoded instead of iterating through PATH at
> runtime?

I don't really care whether it's searched for or hardcoded, but
hardcoding sounds a bit better to me at the moment.  Configure-time
--with-resolvconf=/path/to/resolvconf would be my preference for now,
since it allows distros and users to know exactly where NM will look for
the binary.  Either that or put together a short list of paths
(/usr/bin, /usr/local/bin, /usr/sbin, /usr/local/sbin, etc) to look in.
I think there's just too many games things can play with PATH that will
screw us up here.

> USE_RESOLVCONF would be better as there are implementation on systems
> other than Debian ;)

Yep, fine by me.

> > 
> > > For the domain/search changes, I'd like to take a separate look.
> > 
> > Agreed, though I think the behavior change here is just to make searches
> > > domain, while right now it's the other way around.  I'm not exactly
> > sure whether that's the right thing to do but we should probably be
> > following the current standards and doing backwards-compat as the
> > fallback unless there's a major problem.
> 
> That's fair enough. Still, I don't know of a single libc implemention
> that allows both domain and searches in resolv.conf

Right, they are mutually exclusive an NM isn't honoring that.  My
comment was more about the code in rewrite_resolv_conf() that sets
searches from the domains list when there isn't anything in the searches
list.  But here's how it _should_ be going:

1) Kill the 'domain' list in NMIP4Config
2) Split DHCP-provided "domain_search" and add to NMIP4Config's searches
list
3) Split DHCP-provided "domain_name" and add to NMIP4Config's searches
list, ignoring duplicates that are already there from "domain_search"
4) Always write out 'searches' in resolv.conf, never write out 'domain'

Sound good?  That should be a separate patch to the resolvconf changes.

Dan