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 <[EMAIL PROTECTED]> 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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
