Date: Wed, 15 Jun 2011 20:21:15 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Hiroki Sato <hrs@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id Message-ID: <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> In-Reply-To: <20110616.015317.781291617533474654.hrs@allbsd.org> References: <20110616.015317.781291617533474654.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6FE95AC6-CCB2-45B0-8347-AB31283EE144>