Re: BIND will completely drop D-BUS dynamic forwarders table support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux