Re: NetworkManager on Debian

[Dan Williams <dcbw redhat com>]

On Fri, 2008-05-30 at 13:23 +0200, Alban Browaeys wrote:
> Le mardi 27 mai 2008 à 20:26 +0200, Vincent Bernat a écrit :
> > OoO  En ce  début d'après-midi  ensoleillé du  mardi 27  mai  2008, vers
> > 15:59, Dan Williams <dcbw redhat com> disait:
> > 
> > > Even if the resolvconf binary is installed, how do you know it's
> > > actually in use?
> > 
> > You   should  also   check   if  /etc/resolv.conf   is   a  symlink   to
> > /etc/resolvconf/run/resolv.conf.
> 
> Thanks a lot for this hint.
> Here what I currently use .
> As you can see there is one dirty "guess". That is that there is only
> one ip4config when removing happens : well I don't expect it to be true
> but right now I don't know how to handle more than one to find out if
> the interace is "down". One (I ?) need to spend time deciphering this
> one out.

There can be at least one IP4 config per device, plus one for VPN.
However, at a given time, only one IP4 config is actually relevant for
DNS.  But NM does merge a VPN's IP4 config with the device's IP4 config
when writing out resolv.conf if the VPN didn't pass along any DNS
servers.

But I'm not quite sure what you mean here.  Can you explain a bit more?

> Also the interface name may be missing as the code shows in
> NetworkManagerSystem.c nm_system_vpn_device_set_from_ip4_config :
>  if (!iface || !strlen (iface))
>                 goto out;
> this is not handled at all as I don't understand the vpn code yet.

I just took a look at that code, and I don't think that the interface
name will ever be NULL when calling into nm-named-manager.c.  The IP4
config will only get removed when the VPN goes down, at which point if
we don't have the interface name then there's a bug somewhere, or if a
device goes down, at which point we also better have the interface name
or there's a bug somewhere.  So I think it's OK to assume that the
interface name will be valid when nm_named_manager_remove_ip4_config()
is called.

Am I correct in thinking that resolvconf uses interface names as the key
to managing multiple resolv.conf files?  At least that's what it looked
like from my look at your patch.  Should be fine though, since we'll
always have the interface name available.

> Second a not so pretty usage of spawn process with a call to /bin/sh as
> I use echo and a pipe. Seems to me as it is not something new to NM to
> send data over a pipe to a program instead of using a file though I need
> to find an example or learn more about pipe usage with nm_process_spawn
> before fixing this one.

Yeah, that code isn't pretty.  Best thing to do would be to just spawn
resolvconf with g_spawn_async_with_pipes() and then write the necessary
bits to it's stdin, then monitor the process and ensure it exits with a
good return code.  There's process monitoring code pretty much everwhere
in NM, see src/dnsmasq-manager/nm-dnsmasq-manager.c for a pretty simple
example.  I guess we should probably block on resolvconf finishing
before proceeding.

> I also find it unpretty to duplicate the code from rewrite_resolv_conf
> in src/named-manager/nm-named-manager.c into compute_resolv_conf.
> Factorizing it would require a change in the way rewrite_resolv_conf
> works so I was not ready to do it.

What we should do here is kill the named DBus bits entirely, since they
aren't being used any more, and that would make the named-manager a lot
simpler for you.

> And the most critical part is well to find out if this approach to the
> issue at stake is bitrotten . Should I switch to another approach and
> what could it be ?

Hard to tell.  If we just need to call resolvconf every time we change
resolv.conf instead of writing out resolv.conf itself, I think that
should be pretty easy to do.

I can remove the named dbus bits for you, then you could clean up the
patch to use g_spawn_async_with_pipes() and we'll just iterate until it
looks ok.  Sound good?

Thanks!
Dan

> I also attached part of the debian patches for NM available in Michael
> Biebl repository. This chunk prevent NM from overwritting resolvconf
> version of /etc/resolv.conf . Maybe it should also check for the
> symlink ?
> 
> To Michael : I have not followed Hristo track as he told me via private
> email that he would take care of it though not right now (that is use
> the dispatcher). And also because Dan told he was not keen with the use
> of the dispatcher for it. I don't know what is best and I don't want to
> predate his work (his talks on this ML are the genesis of my own work).
> Though I believe it cannot hurt to follow different tracks.
> 
> 
> Thanks for all your comments
> Alban