From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 02:47:22 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 114B3106566B for ; Mon, 6 Feb 2012 02:47:22 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id CCB3F8FC0A for ; Mon, 6 Feb 2012 02:47:20 +0000 (UTC) Received: from alph.allbsd.org (p1012-ipbf2105funabasi.chiba.ocn.ne.jp [114.148.160.12]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q162ksLW062016; Mon, 6 Feb 2012 11:47:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q162kpUf097471; Mon, 6 Feb 2012 11:46:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 06 Feb 2012 11:46:22 +0900 (JST) Message-Id: <20120206.114622.2214566196455293098.hrs@allbsd.org> To: erdgeist@erdgeist.org From: Hiroki Sato In-Reply-To: <4F2F3459.3090401@erdgeist.org> References: <4F2F209F.90309@erdgeist.org> <20120206.101800.1389796154758679137.hrs@allbsd.org> <4F2F3459.3090401@erdgeist.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Feb__6_11_46_22_2012_834)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 06 Feb 2012 11:47:09 +0900 (JST) X-Spam-Status: No, score=-100.8 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-rc@FreeBSD.org Subject: Re: Proposal ipv6_addrs_common X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 02:47:22 -0000 ----Security_Multipart(Mon_Feb__6_11_46_22_2012_834)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dirk Engling wrote in <4F2F3459.3090401@erdgeist.org>: er> > I also looked into an ipv6 counterpart of the ipv4_addrs_common, er> > and your patch looks good, but I am a bit concerned about adding er> > another independent knob to configure IPv6 addresses to rc.conf. I er> > feel this range specification can be integrated into er> > ifconfig_IF_aliasN and it will be simpler than adding another knob. er> > What do you think about it? er> er> Personally I do not like the fragile way of enumerating variables with er> the aliasN functions at all. It clutters the rc.conf with gazillion er> lines of config code, you always have to renumber the whole list when er> adding or removing one. It also broke and locked me out of my system er> in the past when I was just commenting out one IP address up in the er> address list, other users of systems with a lot of jails - and thus a er> lot of IP addresses - reported the same. er> er> The ipv4_addrs_common patch was a relief back then. But now v6 er> addresses start becoming common, so my configs fill up again. er> er> Since ipv6_addrs_common and ipv4_addrs_common share some code, er> especially handling v6 mapped v4 addresses, I could imagine just er> having one variable providing both v6 and v4 addresses and have an er> ip_addrs_common figure out which are which. er> er> There's other code in the rc system that uses the same enumeration er> scheme - the jail script and its _exec_afterstartN variables. My plans er> for the near future are proposing a new way of managing your jails, er> avoiding these error prone constructions. Yes, I agree that aliasN is fragile and renumbering is annoying. I am using a patch to allow the following syntax for a while: ifconfig_tap0_aliases=" inet6 2001:db8:8888:2::1/64 inet6 2001:db8:9990-9999:3::1/64 inet 10.8.1.1/24 inet 10.8.0.1-10/24 " and about to send this as a proposal. This integrates ifalias_up(), ipv4_addrs_common(), and ipv6_prefix_hostid_addr_common() into one variable. The existing code for them are reused actually and introducing this does not break backward compatibility. In my patch IPv6-mapped IPv4 address is not supported, but your patch can be merged easily. One thing in my mind is whether allowing a variable which contains multiple lines is reasonable or not. Is the above idea acceptable for us? Other rc.conf variables involving enumeration can be converted in the same way, I think. -- Hiroki ----Security_Multipart(Mon_Feb__6_11_46_22_2012_834)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8vPv4ACgkQTyzT2CeTzy2sbQCfaz7SZNETX8N1r88bSyWKqIwv ghkAnA5i7+KtZWDx46B2FXoDumP4cdpI =iFhY -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Feb__6_11_46_22_2012_834)----