From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 20:21:19 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D36C1065672; Wed, 15 Jun 2011 20:21:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE6E8FC08; Wed, 15 Jun 2011 20:21:19 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 56BF425D3860; Wed, 15 Jun 2011 20:21:18 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9D14115A1BFA; Wed, 15 Jun 2011 20:21:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id prR8FTr3jDFK; Wed, 15 Jun 2011 20:21:16 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3ADDA15A0DB5; Wed, 15 Jun 2011 20:21:16 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110616.015317.781291617533474654.hrs@allbsd.org> Date: Wed, 15 Jun 2011 20:21:15 +0000 Content-Transfer-Encoding: 7bit Message-Id: <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1084) Cc: net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 20:21:19 -0000 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.