On Fri, 2007-12-07 at 13:09 -0500, Simo Sorce wrote: > 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, ... What I'm thinking of, here, is that each Connection will have associated DHCP-type information, provided either by the DHCP server, or the VPN, or whatever (maybe even statically configured DNS and such). Since NM advertises the list of active connections, each client that wants information can listen for signals when the connection comes up or goes down, and get the config info pretty easily. Parts of this are not implemented yet though. But I think it's conceptually the right place for this sort of thing. > > > 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, ...) Right; since VPNs and such are _also_ Connection objects, they would get their own config info in the plan outlined above as well. Dan > 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
