[2008.09] resolv.conf

[Sarton O'Brien]

On Wednesday 15 October 2008 15:36:40 Joel Newkirk wrote:

[...snip....]

> Interesting - I've been approaching it from the other end, trying to alter
> base configuration instead of adding a 'network manager'-like layer
> wrapping it all.  When I look at the default behavior of the various
> interfaces, and various means of bringing them up/down, I see differing
> approaches where some use /etc/resolv.conf, some use resolvconf (the
> binary), some do their own thing, but none of them really cooperating.  I
> feel if they're all brought in tune (all handling route and DNS
> additions/removals centrally, instead of each handling route & DNS
> replacements as though they're king) that everything else becomes much
> simpler.

Same thought. The main reason for our approach was due to the varying systems 
we maintain. More often than not they are *BSD, well for me anyway. This 
approach should function regardless of the underlying system, so long as it 
uses, say, udhcpc.

> I've been working on resolv.conf plus default routes lately, though most of
> the time I've been under Raster+FSO. (so frameworkd doing setup for GPRS,
> and requires it's own fixes to do what I want instead of within /etc/ppp)
> I've reached the conclusion that it will require changes to udhcpcd config
> (which currently does a blind replacement of /etc/resolv.conf) and
> ppp/ip-up.d/08setupdns (which currently creates /var/run/ppp/resolv.conf,
> then forces a symlink to it from /var/run/resolv.conf).  /etc/resolv.conf
> is a symlink to /var/run/resolv.conf, and if udhcpcd works with it at
> /var/run/resolv.conf, (which might be better done via resolvconf bin
> instead, which works with /var/run/resolv.conf itself) then breaking that
> link is trivial, and the default behaviors would affect only that file, NOT
> /etc/resolv.conf which could be under new management, or a static 127.0.0.1
> if dns caching is installed.  And changing udhcpcd and ppp config is needed
> to address default route headaches as well.

Yep, which is why we thought making the required changes as an afterthought or 
delayed event at least, would mitigate the effect of any existing networking 
changes being made by the OS facilities.

I really like the idea of a cache. I also like /etc/resolv.conf being a 
symlink. In our possible approach, a config file specifying primary and 
secondary resolv.conf files, with a 127.0.0.1 + opendns override for the 
primary and the secondary containing whatever was last pushed to 
/etc/resolv.conf would address static and dynamic dns assignment.

Metric per interface would be a config file option aswell.

> I currently have my Freerunner /almost/ working as I want, which is as
> follows: Local DNS cache with default upstream caches of opendns.org for
> unchanging simplicity (any static DNS would behave identically at this
> point in my setup), use Wifi if it's up for default route (metric 20),
> usbnet if wifi is down but usbnet is up (metric 30), and demand-dialed GPRS
> if usbnet is unavailable (metric 40).  As I've got it, it should handle DNS
> changes properly, (subsystems are altering /var/run/resolv.conf) but that's
> untested since I'm running local caching.  Once that's working fully
> automatically (getting close) I will check non-cached DNS and probably
> rewrite it to utilize resolvconf bin, then write the support script to tell
> dnscache to use dhcp-provided DNS servers as upstream caches, and finally
> look at VPN and a few more exotic possibilities.  (I've got two USB
> ethernet adapters on a hub here that I've tested as a packet-sniffing
> bridge on the Freerunner, for example ;)

Nice ... and now I can grasp why you might be utilising multiple routing 
tables :)

I can definitely see your work  filling the gap that currently exists, as much 
as I don't like the look of resolvconf, I'm all for something that works and 
this fits within the existing framework.

> I figured the rule for priority should be VPN first, followed by wifi, then
> any USB networking device (if in host mode) or usbnet to host (if in gadget
> mode), and finally (if desired) GPRS.  For myself, I have the old T-Mobile
> unlimited (really, so far) internet3 'VPN' service, so my only concern with
> GPRS is avoiding its slowness when something faster is available - I
> realize other people who use GPRS may want to be more "in control" of it
> than I.  (I've made a desktop icon to enable/disable it, which currently
> starts up the interface and leaves it in demand-dial waitstate, I'll
> eventually test it in direct up/down control)

Well I guess metric is a personal matter :) ... and I guess that if the VPN is 
being added as a default route then the possibility of wanting it to be used 
is highly likely. If it's a dedicated route then metric is moot.

OK, so mine should have gone VPN -> Wired -> Wireless -> GPRS.

Assuming usb can outperform wireless that is.

> My goal is to achieve everything without requiring a network manager of any
> significance. After that I'd like to have a widget in the top shelf to show
> status and interface in use, and let me turn GPRS or wifi on or off, select
> AP, etc, but the basic DNS and routing I want handled within the base
> networking configs and scripts, not within the manager.

Similar goal. With what we are suggesting you simply need request an IP via 
dhcp. The activation of the device and deactivation would all be controlled 
outside of the automated metric/dns shuffle.

> I'm hoping to have it all working smoothly by this weekend, but I keep
> getting sidetracked with other interests... (like playing with Qi and
> kernel 2.6.27, poking around dbus in FSO, developer environment vmware
> appliance, etc etc etc - not to mention my network admin day job, webapp
> developer night job, and single parent full-time job ;)

Drink coffee much? :)

You're making me feel awfully lazy!

> I'm working on documenting everything and will post it to my blog and/or
> the ML and/or the wiki, depending on complexity and how far it deviates
> from the present default arrangement.  Hopefully by the weekend.  I'd be
> interested to compare notes, and to see if my approach might simplify your
> own efforts - IE, having more consistent and (hopefully) sensible default
> behavior than we presently see 'out of the box'.

I still need the right prod to get me started. After having hashed over this a 
few times I'm thinking, if the new features being added to dhcpc on netbsd can 
facilitate this, maybe that's a better place to start. It does, after all, add 
IPs, DNS servers and routes. If we can make this supremely configurable, 
there'd be less need to modify, well, anything. It also eliminates the 
assumption that 'I am king' unless you configure it so :)

I think I'll pose this question to a few more people and a few more mailling 
lists. In the meantime, you are fixing and extending on what is currently 
broken, which I for one, am appreciative of.

I look forward to seeing what you have, at the very least it will give me more 
insight and if I can help in any way I will.

Sarton