On Fri, 2007-12-07 at 12:55 -0500, Dan Williams wrote: > On Fri, 2007-12-07 at 10:18 -0500, Simo Sorce wrote: > > On Fri, 2007-12-07 at 06:28 -0500, Dan Williams wrote: > > > > > NM shouldn't really care what the caching nameserver implementation is, > > > anything is fine. It just happens that the current bits talked to named > > > because patches for dnsmasq didn't materialize out of thin air. Plus > > > I'd like to rethink how NM interacts with nameservers (ideally, NM waits > > > for pulls, not pushes stuff out). > > > > IMO this is not ideal at all, NM knows when interfaces change, not the > > other way around, *but* if you mean that NM should broadcast a generic > > "an interface has changed" event and then wait for DNS daemons to query > > NM to know what are the specifics, that makes indeed sense. > > The latter, optionally including the changed DHCP parameters in the > D-Bus signal. I am also thinking VPN options here. For example with NM-vpnc I can tell it which ip ranges to route, and get back which DNSs I should use, I'd like both info to be available to the DNS caching daemon. Possibly in a consistent way across all NM managed VPN stuff like vpnc, openvpn, ... > > In this case we already have scripts in NM that get called when an > > interface changes, I guess all we need is to: > > A) make sure this is done for all interfaces including tun0, virt* > > vlan*, whatever so that the thing is consistent and we do not need > > special cases > > Yup. > > > B) each package will make scripts that can tell the appropriate daemon > > in the appropriate way what happened so that it can fetch data out of NM > > Yup, or that can parse the DHCP options pushed out in the change signal, > parse them, and do the right thing with the daemon. For named without > D-Bus, that means using some tool to shove that info into named over > whatever control socket it now has (omapi?). Yes I think it's not the duty of NM to know how to poke on the caching daemon, just please do not limit yourself to eth/wlan network interfaces and dhcp, but make sure we can do the same for other interfaces (vpn, ppp, theNextBigThing, ...) Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
