From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 16:07:27 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 D24AD106564A; Mon, 6 Feb 2012 16:07:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 75C468FC0A; Mon, 6 Feb 2012 16:07:27 +0000 (UTC) Received: by ghbg15 with SMTP id g15so3380802ghb.13 for ; Mon, 06 Feb 2012 08:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=eE7b4LhREJPGc5VhkARwwF6ryl1kBEYJJ6k6hOFozxo=; b=xniWQww96uZHCa7lUK6f3vtmuqwGLj+D2103Ugyullt1DS79dlPi5CoOO0o3UsIxPq p3H7Yodni8MTXVbt9ycg6OmBgIlmttPzE+s4wcof5MDZo8QN+mOyl1ICwTeodV96qKv9 hfLTfEOj1NhZ/Ed+unxGpXpvx6Ri3qPhHvx8s= Received: by 10.50.194.199 with SMTP id hy7mr11039607igc.26.1328544446669; Mon, 06 Feb 2012 08:07:26 -0800 (PST) Received: from DataIX.net (adsl-99-181-135-57.dsl.klmzmi.sbcglobal.net. [99.181.135.57]) by mx.google.com with ESMTPS id z22sm27276609ibg.5.2012.02.06.08.07.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Feb 2012 08:07:24 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q16G7Kef038928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 11:07:20 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q16G7Jl8038849; Mon, 6 Feb 2012 11:07:19 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Mon, 6 Feb 2012 11:07:19 -0500 From: Jason Hellenthal To: Hiroki Sato Message-ID: <20120206160719.GA71408@DataIX.net> References: <4F2F209F.90309@erdgeist.org> <20120206.101800.1389796154758679137.hrs@allbsd.org> <4F2F3459.3090401@erdgeist.org> <20120206.114622.2214566196455293098.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120206.114622.2214566196455293098.hrs@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 16:07:28 -0000 On Mon, Feb 06, 2012 at 11:46:22AM +0900, Hiroki Sato wrote: > 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 > " If only we had a shell that could do arrays properly. Beit ksh or an adjustment to /bin/sh it certainly would be helpful in these cases. > > 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 -- ;s =;