[2008.09] resolv.conf

roguemoko at roguewrt.org roguemoko at roguewrt.org
Thu Sep 25 10:45:32 CEST 2008

Joel Newkirk wrote:
> On Thu, 25 Sep 2008 11:21:08 +1000, "Sarton O'Brien"
> <roguemoko at roguewrt.org> wrote:
>> On Thursday 25 September 2008 10:32:00 Joel Newkirk wrote:
>>> On Thu, 25 Sep 2008 02:01:24 +0300, Flyin_bbb8 <flyin.bbb8 at gmail.com>
>>> wrote:
>>>>>  In 2008.8 resolvconf didn't populate it
>>>>> with the nameserver supplied by dhcp when the wifi interface was
>> brought
>>>>> up.
>>>>> I don't know if this is still the case in 2008.9.
>>>> hmm actually it always filled it in for me from DHCP when connectin to
>>>> wifi
>>>> using "ifdown eth0 && ifup eth0"  both in 2008.8 and in 2008.9
>>> Both correct, actually, as it DOES fill it in from DHCP (if used)
>>> connecting wifi with 'ifup eth0', but IIRC resolvconf isn't used to do
>> it,
>>> it just overwrites resolv.conf.  The idea behind resolvconf (the bin) is
>>> that IT manages changes to the resolv.conf file, doing things like
>> removing
>>> eth0-related DNS nameservers when eth0 goes down, going back to
>>> usb0-related nameservers automatically.  ifup should feed DNS info to
>>> resolvconf and let it manage.
>>> Right now, I think DNS and default route changes when interfaces change
>>> up/down need some attention from the 'just-works' dept.
>> I still don't quite understand this confusion.
>> udhcpc modifies /var/run/resolv.conf, as do I when needed. Any
> continually
>> changing value/file should reside in volatile, in my opinion.
>> /etc/resolv.conf has, for as long as I've been playing, symlinked to
>> /var/run/resolv.conf.
>> Except for the backend stuff not agreeing on this location, I have no
>> issues,
>> so long as udhcpc is used and an 'ip r d default' is issued prior to
>> invocation.
>> If the plan is that these values will be written to the filesystem, I'd
>> say
>> I'll be modifying mine to the contrary.
>> Sarton
> The program "resolvconf" is intended to work as follows: When an interface
> comes up, resolvconf should be called to "-a" add new nameserver(s)
> associated with the network connection on that interface.  When an
> interface goes down resolvconf should get a "-d" delete nameserver(s) for
> the specified interface.  
> The program resolvconf itself is supposed to make any/all changes to
> resolv.conf (wherever the actual file resides - the debian standard
> location is /etc/resolvconf/run/resolv.conf, actually) NOT the script or
> subsystem or network manager or whatever handles the up/down.  Based on its
> configuration (notably /etc/resolvconf/interface-order - debian location)
> it uses whatever nameserver settings are needed, but remembers the others.
> So for example, usb0 coming up stuffs in as nameserver, but
> does it by executing resolvconf.  Then eth0 comes up and tells resolvconf
> its nameserver(s) - resolvconf decides which to use, likely eth0 will be
> set a higher priority than usb0.  Later eth0 goes down.  Now resolvconf
> automatically restores the nameserver settings from usb0.  (presuming it is
> still up)  If usb0 went down already, but ppp0 over gprs came up in the
> meantime, nameservers for ppp0 go live.

OK, so this resolvconf thing is inherited from debian and has been 
implented obviously without much thought to general functionality. I say 
this in the context of normal (non-debian) services functioning as 
expected when not massaged by resolvconf.

I understand the intention, don't get me wrong, and it is indeed a nice 
idea. But when all people want to do is gain connectivity with their 
chosen method, this resolvconf facility seems to be more of a hinderence 
and is unlike a lot of linux distros. Shouldn't this, at least 
currently, be optional?

If something as fundamental as _core_ network services are going to be 
overlayed with something like this, it should really be working first, 
rather thaan people editing files left and right without understanding why.

This is just what I think, take it as you will. In the end I am the 
master of my device ;)

I've actually just done a bit of research before posting and it 
_appears_ this was implemented with good intention, just without the 
required software support. It seems to be very much of debian origins 
and a little bit of overkill for managing the facilities on the 
freerunner, but that's just my opinion. If I was currently using usb0, 
eth0 and a tun/tap interface simultaneously, that all flapped or had 
dynamic dns requirments (sounds more like a router) it would make sense 
to me. I imagine the end goal is to consolidate gprs and wifi dns but 
currently no resolvconf is going to teach people how to get that going.
When om2008 is mature and these kind of connections can be made easily, 
without much knowledge, this utility would be a godsend ... as it stands 
you currently need basic linux knowledge to understand why things don't 
work and then you need to know how to manipulate resolvconf.

Maybe it's my BSD upbringing, thanks for the clarification however. :)


More information about the community mailing list