[RFC] resolvconf(8) interface id

[Bjoern A. Zeeb]

On Jun 15, 2011, at 4:53 PM, Hiroki Sato wrote:

Hi,
> ...
> My proposal is adding a string representing the information source to
> the interface id which is used for resolvconf(8).  Specifically, I
> would like to propose to use the following syntax throughout
> utilities that update /etc/resolv.conf via resolvconf(8):
> 
>  ifname:origin[:unique]
> 
> "em0:dhcpv4" for dhclient, "em0:slaac" for rtsold, for example.
> Using this string as an interface id, resolvconf(8) can handle
> multiple RDNSS entries on a single interface without overwriting each
> other.  Furthermore, priority control can be done with
> resolvconf.conf and "origin" and/or "unique" keyword in the string.
> 
> To adopt this naming scheme, patches are needed for dhclient(8),
> rtsold(8), and all of other resolvconf(8)-aware utilities.  There is
> almost no user-visible change; the difference is that multiple RDNSS
> entries on a single interface are aggregated and added into
> /etc/resolv.conf after patching them.
> 
> Any objections to this?  I am working on the necessary changes for
> utilities in the base system and planning to commit them if there is
> no strong objection.

having helped some friends running penguin OS in the past I have been
confronted with what OpenSuse does.  Apart from a completely over
engineered framework they have the ability to sort entries by ifname
or regex at least, which I am not sure our current openresolv.conf
provides.  I think all policy should go into that one config file as
in order of interfaces and order of programs.

I am not entirely sure I like "slaac" or "dhcp4".  I wonder if progname
would be sufficient in call cases either (I could well see a "dhclient"
or another "fooapp" that can handle both v4 and v6) but in that case it
would probably be a matter of third order -- address family.

Example:

prefer v6
intorder "tun* gre* gif* wlan* em*"  or similar (maybe classes lik
       "wired" or similar.  not sure how easily we could do that). 
progorder "dhcp* rt*"

But then we also have the static manual config which would always go in
from the config file.

In short:  yes I like the general idea.  Details can be shaken out later.
Priority more likely in the config file eventually rather than coded into
programs.

Have you discussed that with $upstream vendor as well or do we consider
further changes to be simple enough to merge them in?

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.