On Fri, 26 Sep 2008 10:24:18 +1000, "Sarton O'Brien" <[EMAIL PROTECTED]> wrote: > On Thursday 25 September 2008 22:06:29 Joel Newkirk wrote:
>> IMHO the "simplest effective solution" should always head the list. In >> this instance I think that is to run dnscache or a similar service on > the >> Freerunner itself, pointing somewhere like opendns.com's servers. (ok, >> maybe not simplest, though the local cache has various benefits. > Pointing >> resolv.conf at opendns.com or wherever is simplest, assuming no network >> connection actually requires use of it's own DNS - corporate intranet > wifi >> might, to reach 'private' records for example) If needed, > newly-connected >> network connections that come equipped with new DNS servers (IE, wifi > with >> DHCP) can insert/remove their DNS servers from the list used by > dnscache, >> while resolv.conf permanently points at 127.0.0.1. This is what I've > had >> running for a few weeks, but I hadn't yet attempted to get ifup/ifdown >> manipulating /etc/dnscache/root/servers/@. (which will essentially > require >> a resolvconf-like manager ;) > > That all makes sense. Typically I've seen dnsmasq fulfill this function. > > My point was merely that the current solution is added complexity to a > rather > neat base filesystem. If this was a package I wouldn't have the same > gripe. > > Using dnsmasq, pointing at localhost, including opendns and using helper > scripts to insert and remove dns servers sounds less complex and less > confusing, with the added benefit of caching and less modification to the > base > system. It also means not having to incorporate something that doesn't > appear > to have had the modifications needed _to_ incorporate it. > > I don't like the requirement that all the software modifying network > settings > needs to be resolvconf aware. If we had a generic central solution people > could use whatever they want and not incur breakage ... > > Worst case, something like a resolv.conf pipe to a daemon that updates > resolv.conf.auto for dnsmasq would be better. Something central! > > Looking at the way resolvconf works, it almost seems like we should be > patching libc :S ...so we have a generic interface. > > Anyway ... I can feel fork coming on :P > > Sarton hmmm. I've been thinking on the situation, and have a proposal, as yet incomplete but IMHO promising - and it's nowhere near as drastic as forking. I see basically two approaches: One is an overarching network manager directly handling all the details, the other (my preferred) is to let DNS take care of itself independently, and address the multiple-default-route issue - probably with route metrics, though more advanced routing setup (requiring full "ip" binary instead of busybox) with multiple routing tables and rules is probably the "better" solution there. It starts with dnscache. Postinst in dnscache ipk removes the symlink /etc/resolv.conf and replaces it with a real file, pointing always at nameserver 127.0.0.1. (what I had going already) On my Ubuntu desktop, there's a possibly-useful file: /etc/resolvconf/update.d/dnscache - its purpose is to alter /etc/dsncachce/root/servers/@ (the list of servers dnscache is to query for anything uncached) automatically whenever resolvconf is triggered. This would be the way to hook in if resolvconf were working on the Freerunner as intended, which currently appears not to be the case. Alternately (or additionally), /etc/network/if-up.d/ and /etc/network/if-post-down.d/ allow us to perform the same changes automatically whenever an interface is brought up or taken down using ifup and ifdown. I've altered my /etc/init.d/dnscache script to include a 'refresh' feature, that first wipes /etc/dnscache/root/servers/@, then stuffs in any non-localhost nameservers presently listed in /etc/resolv.conf, then adds any nameservers found in /etc/resolvconf/run/resolv.conf, finishing up with any IPs listed in /etc/default/dnscache (default contents opendns.com IPs), wipes /etc/resolv.conf back to localhost only, then finally kicks dnscache so it uses the new servers/@ contents. Once my freerunner is back in front of me I'll test the init script changes - if it works as I hope, I can add a script to the ipk in each of /etc/network/if-up.d/ and /etc/network/if-post-down.d/ that simply call "/etc/init.d/dnscache refresh", and/or in /etc/resolvconf/update.d/. That makes the whole thing "just work" as a single ipk installing dnscache and all the support to override resolvconf AND 'manual' nameserver updates implemented by ifup/ifdown. If resolvconf is discarded it will work fine, just need added logic in the postrm script in the dnscache ipk to recognize resolvconf's absence and restore a basic /etc/resolv.conf instead of trying to restore the symlink. BTW: dnscache vs dnsmasq. I'm far more familiar with dnscache, so I'd lean toward it for that reason, but additionally dnsmasq incorporates a dhcp server - seems a waste for a more-or-less default setup. If dhcp server on the Freerunner is actually desired, it would likely be accompanying support for use of the Freerunner as a gateway router, so IMHO dhcp-server can be dealt with in that specific context. (until DJ Bernstein recently recanted the license on dnscache/djbdns it wasn't an option, but now distributing binaries is permitted) Comments? Suggestions? Flames? j _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
