Date: Mon, 06 Feb 2012 11:46:22 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: erdgeist@erdgeist.org Cc: freebsd-rc@FreeBSD.org Subject: Re: Proposal ipv6_addrs_common Message-ID: <20120206.114622.2214566196455293098.hrs@allbsd.org> In-Reply-To: <4F2F3459.3090401@erdgeist.org> References: <4F2F209F.90309@erdgeist.org> <20120206.101800.1389796154758679137.hrs@allbsd.org> <4F2F3459.3090401@erdgeist.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Mon_Feb__6_11_46_22_2012_834)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dirk Engling <erdgeist@erdgeist.org> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120206.114622.2214566196455293098.hrs>