From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 00:36:54 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 8661A106564A for ; Mon, 6 Feb 2012 00:36:54 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2018FC0A for ; Mon, 6 Feb 2012 00:36:52 +0000 (UTC) Received: (qmail 67813 invoked from network); 6 Feb 2012 00:40:33 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 6 Feb 2012 00:40:33 -0000 Message-ID: <4F2F209F.90309@erdgeist.org> Date: Mon, 06 Feb 2012 01:36:47 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-rc@freebsd.org References: <4F28B9D7.4010602@erdgeist.org> In-Reply-To: <4F28B9D7.4010602@erdgeist.org> X-Enigmail-Version: 1.3.5 Content-Type: multipart/mixed; boundary="------------000303090400080803030706" 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 00:36:54 -0000 This is a multi-part message in MIME format. --------------000303090400080803030706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01.02.12 05:04, Dirk Engling wrote: > The attached network6.subr is a shell script demonstrating the > ipv6_addrs_common function inside, for playing around one can use some > of the values the supplied get_if_var dummy function returns. Following up my shell script I patched my /etc/network.subr to properly work with the ipv6_addrs_IF variables while also removing some bugs in the interface configuration code. ipv4_addrs_common also has been patched to handle ranges in all octets. The patch at http://erdgeist.org/arts/software/network.subr_9.0.diff has been tested on my FreeBSD 9.0, fixing some bugs introduced in the rewrite of ifalias_up/ifalias_down for 9.0, as well. I also have back ported the code to work under FreeBSD 8.2, the patch against my 8.2-RELEASE's /etc/network.subr can be found here: http://erdgeist.org/arts/software/network.subr_8.2.diff Regards, erdgeist --------------000303090400080803030706 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="network.subr_8.2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network.subr_8.2.diff" --- FreeBSD_8.2/network.subr 2012-01-21 12:52:45.000000000 +0000 +++ network.subr 2012-01-21 12:54:06.000000000 +0000 @@ -45,6 +45,7 @@ ifscript_up ${ifn} && cfg=0 ifconfig_up ${ifn} && cfg=0 ipv4_up ${ifn} && cfg=0 + ipv6_up ${ifn} && cfg=0 ipx_up ${ifn} && cfg=0 childif_create ${ifn} @@ -64,6 +65,7 @@ [ -z "$ifn" ] && return 1 ipx_down ${ifn} && cfg=0 + ipv6_down ${ifn} && cfg=0 ipv4_down ${ifn} && cfg=0 ifconfig_down ${ifn} && cfg=0 ifscript_down ${ifn} && cfg=0 @@ -307,6 +309,32 @@ ifconfig -n $1 > /dev/null 2>&1 } +# ipv6_up if +# add IPv6 addresses to the interface $if +ipv6_up() +{ + local _ret _if + _ret=1 + _if=$1 + ipv6if ${_if} || return 1 + + ipv6_addrs_common ${_if} alias && _ret=0 + return _ret +} + +# ifv6_down if +# remove IPv6 addresses from the interface $if +ifp6_down() +{ + local _ret _if + _ret=1 + _if=$1 + ipv6if ${_if} || return 1 + + ipv6_addrs_common ${_if} -alias && _ret=0 + return _ret +} + # ipv4_up if # add IPv4 addresses to the interface $if ipv4_up() @@ -326,6 +354,9 @@ ifexists ${_if} || return 1 + ifalias_down ${_if} && _ret=0 + ipv4_addrs_common ${_if} -alias && _ret=0 + inetList="`ifconfig ${_if} | grep 'inet ' | tr "\n" "$_ifs"`" oldifs="$IFS" @@ -343,49 +374,150 @@ done IFS="$oldifs" - ifalias_down ${_if} && _ret=0 - ipv4_addrs_common ${_if} -alias && _ret=0 - return $_ret } # ipv4_addrs_common if action -# Evaluate the ifconfig_if_ipv4 arguments for interface $if -# and use $action to add or remove IPv4 addresses from $if. +# Evaluate the ipv4_addrs_IF arguments for interface $if and +# use $action to add or remove IPv4 addresses from $if. ipv4_addrs_common() -{ +{ + local _ret _if _action _cidr _cidr_addr + local _ipaddr _netmask _ipleft _ipright _iplow _iphigh _ret=1 _if=$1 _action=$2 - + # get ipv4-addresses - cidr_addr=`get_if_var $_if ipv4_addrs_IF` - - for _cidr in ${cidr_addr}; do - _ipaddr=${_cidr%%/*} - _netmask="/"${_cidr##*/} - _range=${_ipaddr##*.} - _ipnet=${_ipaddr%.*} - _iplow=${_range%-*} - _iphigh=${_range#*-} - - # clear netmask when removing aliases - if [ "${_action}" = "-alias" ]; then - _netmask="" - fi - - _ipcount=${_iplow} - while [ "${_ipcount}" -le "${_iphigh}" ]; do - eval "ifconfig ${_if} ${_action} ${_ipnet}.${_ipcount}${_netmask}" - _ipcount=$((${_ipcount}+1)) - _ret=0 + _cidr_addr=`get_if_var $_if ipv4_addrs_IF` + + for _cidr in ${_cidr_addr}; do + _ipaddr="${_cidr%%/*}" + + if [ "${_ipaddr}" = "${_cidr}" -o "$_action" = "-alias" ]; then + unset _netmask + else + _netmask="/"${_cidr##*/} + fi + + _ipleft=${_ipaddr%-*} + _ipright=${_ipaddr#*-} - # only the first ipaddr in a subnet need the real netmask - if [ "${_action}" != "-alias" ]; then - _netmask="/32" + _iplow=${_ipleft##*.} + _iphigh=${_ipright%%.*} + _ipleft=${_ipleft%.*} + _ipright=${_ipright#*.} + + if [ "${_iphigh}" = "${_ipright}" ]; then + unset _ipright + else + _ipright=.$_ipright + fi + + if [ -n "${_iplow}" -a -n "${_iphigh}" ]; then + while [ ${_iplow} -le ${_iphigh} ]; do + ifconfig ${_if} ${_ipleft}.${_iplow}${_ipright}${_netmask} \ + ${_action} && _ret=0 + _iplow=$(( ${_iplow} + 1 )) + + # only the first ipaddr in a subnet need the real netmask + if [ "${_action}" != "-alias" ]; then + _netmask="/32" + fi + done + else + # no range or parse error, just pass to ifconfig + ifconfig ${_if} ${_ipaddr}${_netmask} ${_action} && _ret=0 + fi + done + + return $_ret +} + +# ipv6_addrs_common if action +# Evaluate the ipv6_addrs_IF arguments for interface $if and +# use $action to add or remove IPv6 addresses from $if. +ipv6_addrs_common() +{ + local _ret _if _action _cidr _cidr_addr + local _ipaddr _netmask _ipleft _ipright _iplow _iphigh + local _ipv6part _ipv4part + _ret=1 + _if=$1 + _action=$2 + + # get ipv6-addresses + _cidr_addr=`get_if_var $_if ipv6_addrs_IF` + + for _cidr in ${_cidr_addr}; do + _ipaddr="${_cidr%%/*}" + + if [ "${_ipaddr}" = "${_cidr}" -o "$_action" = "-alias" ]; then + unset _netmask + else + _netmask="/"${_cidr##*/} + fi + + # Handle v6 mapped v4 addresses below + if [ "${_ipaddr%:*.*.*.*}" = "${_ipaddr}" ]; then + _ipleft=${_ipaddr%-*} + _ipright=${_ipaddr#*-} + _iplow=${_ipleft##*:} + _iphigh=${_ipright%%:*} + _ipleft=${_ipleft%:*} + _ipright=${_ipright#*:} + + if [ "${_iphigh}" = "${_ipright}" ]; then + unset _ipright + else + _ipright=:$_ipright fi - done + + if [ -n "${_iplow}" -a -n "${_iphigh}" ]; then + while [ $(( 0x$_iplow )) -le $(( 0x$_iphigh )) ]; do + ifconfig ${_if} inet6 ${_ipleft}:${_iplow}${_ipright}\ +${_netmask} ${_action} && _ret=0 + + # Advance counter - in hex + _iplow=`printf %04x $(( 0x$_iplow + 1 ))` + done + else + # no range or parse error, just pass to ifconfig + ifconfig ${_if} inet6 ${_ipaddr}${_netmask} ${_action} && _ret=0 + fi + else + # v6 mapped v4 range + _ipv6part=${_ipaddr%:*} + _ipv4part=${_ipaddr##*:} + _ipleft=${_ipv4part%-*} + _ipright=${_ipv4part#*-} + + _iplow=${_ipleft##*.} + _iphigh=${_ipright%%.*} + _ipleft=${_ipv6part}:${_ipleft%.*} + _ipright=${_ipright#*.} + + if [ "${_iphigh}" = "${_ipright}" ]; then + unset _ipright + else + _ipright=.$_ipright + fi + + if [ -n "${_iplow}" -a -n "${_iphigh}" ]; then + while [ ${_iplow} -le ${_iphigh} ]; do + ifconfig ${_if} inet6 ${_ipleft}.${_iplow}${_ipright}\ +${_netmask} ${_action} && _ret=0 + + # Advance counter - in dec + _iplow=$(( ${_iplow} + 1 )) + done + else + # no range or parse error, just pass to ifconfig + ifconfig ${_if} inet6 ${_ipaddr}${_netmask} ${_action} && _ret=0 + fi + fi done + return $_ret } --------------000303090400080803030706 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="network.subr_9.0.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network.subr_9.0.diff" --- /usr/share/examples/etc/network.subr 2011-12-04 10:11:10.000000000 +0100 +++ network.subr 2012-01-30 11:49:39.000000000 +0100 @@ -444,6 +444,12 @@ return 0 fi + # True if ipv6_addrs_IF is defined. + _tmpargs=`get_if_var $_if ipv6_addrs_IF` + if [ -n "${_tmpargs}" ]; then + return 0 + fi + # backward compatibility: True if $ipv6_ifconfig_IF is defined. _tmpargs=`get_if_var $_if ipv6_ifconfig_IF` if [ -n "${_tmpargs}" ]; then @@ -538,7 +544,6 @@ fi fi ifalias_up ${_if} inet && _ret=0 - ipv4_addrs_common ${_if} alias && _ret=0 return $_ret } @@ -575,6 +580,10 @@ _ifs="^" _ret=1 + # remove all ip addresses configured by network.subr + ifalias_down ${_if} inet && _ret=0 + + # remove the rest inetList="`ifconfig ${_if} | grep 'inet ' | tr "\n" "$_ifs"`" oldifs="$IFS" @@ -586,15 +595,12 @@ _inet=`expr "$_inet" : '.*\(inet \([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}\).*'` IFS="$oldifs" - ifconfig ${_if} ${_inet} delete + ifconfig ${_if} ${_inet} delete && _ret=0 IFS="$_ifs" _ret=0 done IFS="$oldifs" - ifalias_down ${_if} inet && _ret=0 - ipv4_addrs_common ${_if} -alias && _ret=0 - return $_ret } @@ -636,43 +642,144 @@ } # ipv4_addrs_common if action -# Evaluate the ifconfig_if_ipv4 arguments for interface $if and +# Evaluate the ipv4_addrs_IF arguments for interface $if and # use $action to add or remove IPv4 addresses from $if. ipv4_addrs_common() { local _ret _if _action _cidr _cidr_addr - local _ipaddr _netmask _range _ipnet _iplow _iphigh _ipcount + local _ipaddr _netmask _ipleft _ipright _iplow _iphigh _ret=1 _if=$1 _action=$2 # get ipv4-addresses - cidr_addr=`get_if_var $_if ipv4_addrs_IF` + _cidr_addr=`get_if_var $_if ipv4_addrs_IF` + + for _cidr in ${_cidr_addr}; do + _ipaddr="${_cidr%%/*}" + + if [ "${_ipaddr}" = "${_cidr}" -o "$_action" = "-alias" ]; then + unset _netmask + else + _netmask="/"${_cidr##*/} + fi + + _ipleft=${_ipaddr%-*} + _ipright=${_ipaddr#*-} - for _cidr in ${cidr_addr}; do - _ipaddr=${_cidr%%/*} - _netmask="/"${_cidr##*/} - _range=${_ipaddr##*.} - _ipnet=${_ipaddr%.*} - _iplow=${_range%-*} - _iphigh=${_range#*-} - - # clear netmask when removing aliases - if [ "${_action}" = "-alias" ]; then - _netmask="" - fi - - _ipcount=${_iplow} - while [ "${_ipcount}" -le "${_iphigh}" ]; do - eval "ifconfig ${_if} ${_action} ${_ipnet}.${_ipcount}${_netmask}" - _ipcount=$((${_ipcount}+1)) - _ret=0 - - # only the first ipaddr in a subnet need the real netmask - if [ "${_action}" != "-alias" ]; then - _netmask="/32" + _iplow=${_ipleft##*.} + _iphigh=${_ipright%%.*} + _ipleft=${_ipleft%.*} + _ipright=${_ipright#*.} + + if [ "${_iphigh}" = "${_ipright}" ]; then + unset _ipright + else + _ipright=.$_ipright + fi + + if [ -n "${_iplow}" -a -n "${_iphigh}" ]; then + while [ ${_iplow} -le ${_iphigh} ]; do + ifconfig ${_if} ${_ipleft}.${_iplow}${_ipright}${_netmask} \ + ${_action} && _ret=0 + _iplow=$(( ${_iplow} + 1 )) + + # only the first ipaddr in a subnet need the real netmask + if [ "${_action}" != "-alias" ]; then + _netmask="/32" + fi + done + else + # no range or parse error, just pass to ifconfig + ifconfig ${_if} ${_ipaddr}${_netmask} ${_action} && _ret=0 + fi + done + + return $_ret +} + +# ipv6_addrs_common if action +# Evaluate the ipv6_addrs_IF arguments for interface $if and +# use $action to add or remove IPv6 addresses from $if. +ipv6_addrs_common() +{ + local _ret _if _action _cidr _cidr_addr + local _ipaddr _netmask _ipleft _ipright _iplow _iphigh + local _ipv6part _ipv4part + _ret=1 + _if=$1 + _action=$2 + + # get ipv6-addresses + _cidr_addr=`get_if_var $_if ipv6_addrs_IF` + + for _cidr in ${_cidr_addr}; do + _ipaddr="${_cidr%%/*}" + + if [ "${_ipaddr}" = "${_cidr}" -o "$_action" = "-alias" ]; then + unset _netmask + else + _netmask="/"${_cidr##*/} + fi + + # Handle v6 mapped v4 addresses below + if [ "${_ipaddr%:*.*.*.*}" = "${_ipaddr}" ]; then + _ipleft=${_ipaddr%-*} + _ipright=${_ipaddr#*-} + _iplow=${_ipleft##*:} + _iphigh=${_ipright%%:*} + _ipleft=${_ipleft%:*} + _ipright=${_ipright#*:} + + if [ "${_iphigh}" = "${_ipright}" ]; then + unset _ipright + else + _ipright=:$_ipright fi - done + + if [ -n "${_iplow}" -a -n "${_iphigh}" ]; then + while [ $(( 0x$_iplow )) -le $(( 0x$_iphigh )) ]; do + ifconfig ${_if} inet6 ${_ipleft}:${_iplow}${_ipright}\ +${_netmask} ${_action} && _ret=0 + + # Advance counter - in hex + _iplow=`printf %04x $(( 0x$_iplow + 1 ))` + done + else + # no range or parse error, just pass to ifconfig + ifconfig ${_if} inet6 ${_ipaddr}${_netmask} ${_action} && _ret=0 + fi + else + # v6 mapped v4 range + _ipv6part=${_ipaddr%:*} + _ipv4part=${_ipaddr##*:} + _ipleft=${_ipv4part%-*} + _ipright=${_ipv4part#*-} + + _iplow=${_ipleft##*.} + _iphigh=${_ipright%%.*} + _ipleft=${_ipv6part}:${_ipleft%.*} + _ipright=${_ipright#*.} + + if [ "${_iphigh}" = "${_ipright}" ]; then + unset _ipright + else + _ipright=.$_ipright + fi + + if [ -n "${_iplow}" -a -n "${_iphigh}" ]; then + while [ ${_iplow} -le ${_iphigh} ]; do + ifconfig ${_if} inet6 ${_ipleft}.${_iplow}${_ipright}\ +${_netmask} ${_action} && _ret=0 + + # Advance counter - in dec + _iplow=$(( ${_iplow} + 1 )) + done + else + # no range or parse error, just pass to ifconfig + ifconfig ${_if} inet6 ${_ipaddr}${_netmask} ${_action} && _ret=0 + fi + fi done return $_ret @@ -685,15 +792,18 @@ # ifalias_up() { - local _ret + local _ret _if _ret=1 + _if=$1 case "$2" in inet) - _ret=`ifalias_ipv4_up "$1"` + ifalias_ipv4_up ${_if} && _ret=0 + ipv4_addrs_common ${_if} alias && _ret=0 ;; inet6) - _ret=`ifalias_ipv6_up "$1"` + ifalias_ipv6_up ${_if} && _ret=0 + ipv6_addrs_common ${_if} alias && _ret=0 ;; esac @@ -776,15 +886,18 @@ # ifalias_down() { - local _ret + local _ret _if _ret=1 + _if=$1 case "$2" in inet) - _ret=`ifalias_ipv4_down "$1"` + ifalias_ipv4_down ${_if} && _ret=0 + ipv4_addrs_common ${_if} -alias && _ret=0 ;; inet6) - _ret=`ifalias_ipv6_down "$1"` + ifalias_ipv6_down ${_if} && _ret=0 + ipv6_addrs_common ${_if} -alias && _ret=0 ;; esac --------------000303090400080803030706-- From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 01:19:33 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 9D580106564A for ; Mon, 6 Feb 2012 01:19:33 +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 89C188FC17 for ; Mon, 6 Feb 2012 01:19:32 +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 q161J6cb040508; Mon, 6 Feb 2012 10:19:16 +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 q161J3NE095890; Mon, 6 Feb 2012 10:19:06 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 06 Feb 2012 10:18:00 +0900 (JST) Message-Id: <20120206.101800.1389796154758679137.hrs@allbsd.org> To: erdgeist@erdgeist.org From: Hiroki Sato In-Reply-To: <4F2F209F.90309@erdgeist.org> References: <4F28B9D7.4010602@erdgeist.org> <4F2F209F.90309@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_10_18_00_2012_289)--" 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 10:19:21 +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 01:19:33 -0000 ----Security_Multipart(Mon_Feb__6_10_18_00_2012_289)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dirk Engling wrote in <4F2F209F.90309@erdgeist.org>: er> On 01.02.12 05:04, Dirk Engling wrote: er> er> > The attached network6.subr is a shell script demonstrating the er> > ipv6_addrs_common function inside, for playing around one can use some er> > of the values the supplied get_if_var dummy function returns. er> er> Following up my shell script I patched my /etc/network.subr to properly er> work with the ipv6_addrs_IF variables while also removing some bugs in er> the interface configuration code. ipv4_addrs_common also has been er> patched to handle ranges in all octets. er> er> The patch at er> er> http://erdgeist.org/arts/software/network.subr_9.0.diff er> er> has been tested on my FreeBSD 9.0, fixing some bugs introduced in the er> rewrite of ifalias_up/ifalias_down for 9.0, as well. er> er> I also have back ported the code to work under FreeBSD 8.2, the patch er> against my 8.2-RELEASE's /etc/network.subr can be found here: er> er> http://erdgeist.org/arts/software/network.subr_8.2.diff I also looked into an ipv6 counterpart of the ipv4_addrs_common, and your patch looks good, but I am a bit concerned about adding another independent knob to configure IPv6 addresses to rc.conf. I feel this range specification can be integrated into ifconfig_IF_aliasN and it will be simpler than adding another knob. What do you think about it? -- Hiroki ----Security_Multipart(Mon_Feb__6_10_18_00_2012_289)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8vKkgACgkQTyzT2CeTzy0/XACeKixaxXGyN19ev72N2Yi3TsDC newAoJKI9Q+LeeY7HxOitle9mDi4iS+A =0JYX -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Feb__6_10_18_00_2012_289)---- From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 02:01:01 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 B74F7106564A for ; Mon, 6 Feb 2012 02:01:01 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id E25318FC0C for ; Mon, 6 Feb 2012 02:01:00 +0000 (UTC) Received: (qmail 77625 invoked from network); 6 Feb 2012 02:04:43 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 6 Feb 2012 02:04:43 -0000 Message-ID: <4F2F3459.3090401@erdgeist.org> Date: Mon, 06 Feb 2012 03:00:57 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Hiroki Sato References: <4F28B9D7.4010602@erdgeist.org> <4F2F209F.90309@erdgeist.org> <20120206.101800.1389796154758679137.hrs@allbsd.org> In-Reply-To: <20120206.101800.1389796154758679137.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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:01:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06.02.12 02:18, Hiroki Sato wrote: > I also looked into an ipv6 counterpart of the ipv4_addrs_common, > and your patch looks good, but I am a bit concerned about adding > another independent knob to configure IPv6 addresses to rc.conf. I > feel this range specification can be integrated into > ifconfig_IF_aliasN and it will be simpler than adding another knob. > What do you think about it? Personally I do not like the fragile way of enumerating variables with the aliasN functions at all. It clutters the rc.conf with gazillion lines of config code, you always have to renumber the whole list when adding or removing one. It also broke and locked me out of my system in the past when I was just commenting out one IP address up in the address list, other users of systems with a lot of jails - and thus a lot of IP addresses - reported the same. The ipv4_addrs_common patch was a relief back then. But now v6 addresses start becoming common, so my configs fill up again. Since ipv6_addrs_common and ipv4_addrs_common share some code, especially handling v6 mapped v4 addresses, I could imagine just having one variable providing both v6 and v4 addresses and have an ip_addrs_common figure out which are which. There's other code in the rc system that uses the same enumeration scheme - the jail script and its _exec_afterstartN variables. My plans for the near future are proposing a new way of managing your jails, avoiding these error prone constructions. Regards and that you for your feedback, erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8vNFkACgkQuN1wFypsMNPrHQCeIDMIHeLVTbfR9MsSRpVjXOtc FnMAn3nB7053Rlt9G0GDbBiH6tO7fTQi =C0fE -----END PGP SIGNATURE----- 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)---- From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 03:08:34 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 052D2106566C for ; Mon, 6 Feb 2012 03:08:34 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id 5209C8FC17 for ; Mon, 6 Feb 2012 03:08:32 +0000 (UTC) Received: (qmail 86145 invoked from network); 6 Feb 2012 03:12:17 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 6 Feb 2012 03:12:17 -0000 Message-ID: <4F2F442F.3030509@erdgeist.org> Date: Mon, 06 Feb 2012 04:08:31 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Hiroki Sato References: <4F2F209F.90309@erdgeist.org> <20120206.101800.1389796154758679137.hrs@allbsd.org> <4F2F3459.3090401@erdgeist.org> <20120206.114622.2214566196455293098.hrs@allbsd.org> In-Reply-To: <20120206.114622.2214566196455293098.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 03:08:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06.02.12 03:46, Hiroki Sato wrote: > 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 " Why on earth didn't you come forward with that earlier? Would've saved me a lot of trouble. ;) The bugs in /etc/network.subr, function ifalias_up I would like to see fixed, anyway: _ret=`ifalias_ipv4_up "$1"` just does not work the way you imagined it. The return code is not passed when using _ret=`` but the command substituted by it's output on stdout, it should read: ifalias_ipv4_up ${_if} && _ret=0 as shown in my patch. > In my patch IPv6-mapped IPv4 address is not supported, but your > patch can be merged easily. I like the idea of configuring a router or DNS server for several subnets with one range as well, i.e. "inet 10.8.2-16.1/24", do you think this makes sense? > One thing in my mind is whether allowing a variable which contains > multiple lines is reasonable or not. I do not understand the problem there, does your code actually DEPEND on new lines? If not, it's just a matter of taste how to arrange your variables in your rc.conf, if it doesn't fit in 80 chars, you can either overflow, add backslashes or use the style above. The rc's author does not FORCE the user into one style, does he? erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8vRC8ACgkQuN1wFypsMNN1IgCeOo5OleODoIY6gS9SMO5p5uw1 n7cAn1k4CAnlcbHBhF2hppN+SDew7483 =54g5 -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 11:07:11 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 634FC106566B for ; Mon, 6 Feb 2012 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 46AE18FC29 for ; Mon, 6 Feb 2012 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q16B7BVF007927 for ; Mon, 6 Feb 2012 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q16B7AQS007925 for freebsd-rc@FreeBSD.org; Mon, 6 Feb 2012 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Feb 2012 11:07:10 GMT Message-Id: <201202061107.q16B7AQS007925@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org 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 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/164393 rc [rc.d] restarting netif with static addresses doesn't o conf/163508 rc [rc.subr] [patch] Add "enable" and "disable" commands o conf/163488 rc Confusing explanation in defaults/rc.conf o conf/163321 rc [rc.conf] [patch] allow _fib syntax in rc.conf o conf/162642 rc .sh scripts in /usr/local/etc/rc.d get executed, not s o conf/161107 rc [rc] stop_boot in mountcritlocal usage is incorrect. o conf/160403 rc [rc] [patch] concurrently running rc-scripts during bo o conf/160240 rc rc.d/mdconfig and mdconfig2 should autoset $_type to v o conf/159846 rc [rc.conf] routing_stop_inet6() logic doesn't handle ip o conf/158557 rc [patch] /etc/rc.d/pf broken messages o conf/158127 rc [patch] remount_optional option in rc.initdiskless doe o conf/154554 rc [rc.d] [patch] statd and lockd fail to start o conf/153666 rc [rc.d][patch] mount filesystems from fstab over zfs da o conf/153200 rc post-boot /etc/rc.d/network_ipv6 start can miss neighb o conf/153123 rc [rc] [patch] add gsched rc file to automatically inser o conf/150474 rc [patch] rc.d/accounting: Add ability to set location o o conf/149867 rc [PATCH] rc.d script to manage multiple FIBS (kern opti o conf/149831 rc [PATCH] add support to /etc/rc.d/jail for delegating Z o conf/148656 rc rc.firewall(8): {oip} and {iip} variables in rc.firewa o conf/147685 rc [rc.d] [patch] new feature for /etc/rc.d/fsck o conf/147444 rc [rc.d] [patch] /etc/rc.d/zfs stop not called on reboot o conf/146053 rc [patch] [request] shutdown of jails breaks inter-jail o conf/145445 rc [rc.d] error in /etc/rc.d/jail (bad logic) o conf/145399 rc [patch] rc.d scripts are unable to start/stop programs o conf/145009 rc [patch] rc.subr(8): rc.conf should allow mac label con o conf/144213 rc [rc.d] [patch] Disappearing zvols on reboot o conf/143637 rc [patch] ntpdate(8) support for ntp-servers supplied by o conf/143085 rc [patch] ftp-proxy(8) rc(8) with multiple instances o conf/142973 rc [jail] [patch] Strange counter init value in jail rc o conf/142434 rc [patch] Add cpuset(1) support to rc.subr(8) o conf/142304 rc rc.conf(5): mdconfig and mdconfig2 rc.d scripts lack e o conf/141909 rc rc.subr(8): [patch] add rc.conf.d support to /usr/loca o conf/141907 rc [rc.d] Bug if mtu (maybe others?) is set as first argu o conf/141678 rc [patch] A minor enhancement to how /etc/rc.d/jail dete o conf/141275 rc [request] dhclient(8) rc script should print something o conf/140440 rc [patch] allow local command files in rc.{suspend,resum o conf/140261 rc [patch] Improve flexibility of mdconfig2 startup scrip o conf/138208 rc [rc.d] [patch] Making rc.firewall (workstation) IPv6 a o conf/137629 rc [rc.d] background_dhclient rc.conf option causing doub o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/137271 rc [rc.d] Cannot update /etc/host.conf when root filesyst o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/135338 rc [rc.d] pf startup order seems broken [regression] o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped p bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/123119 rc [patch] rc script for ipfw does not handle IPv6 o conf/122968 rc [rc.d] /etc/rc.d/addswap: md swapfile multiplication a o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/109272 rc [request] increase default rc shutdown timeout o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 92 problems total. From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 11:48:15 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 59C501065673 for ; Mon, 6 Feb 2012 11:48:15 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm18.bullet.mail.bf1.yahoo.com (nm18.bullet.mail.bf1.yahoo.com [98.139.212.177]) by mx1.freebsd.org (Postfix) with SMTP id AD87C8FC0A for ; Mon, 6 Feb 2012 11:48:14 +0000 (UTC) Received: from [98.139.212.151] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2012 11:35:02 -0000 Received: from [98.139.213.9] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2012 11:35:02 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 06 Feb 2012 11:35:02 -0000 X-Yahoo-Newman-Id: 793959.29966.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gHXM8HoVM1nlH13ZPSn1PdkC5s_l00Qa_YImt0d1LKR9GWg qtWIdqGkxUddQtkJfBESeUFtf.FIE2RfFmGjr1KVc0gpMz0_7cqrhMNU1IDy DG36MHVAmu0DBoT2UmcAaOuFbqqyIZ6Qou3hYTUmToiFtcLMK0PzetL7KWAE 7Cqv0ABbs5Fx7mw2m5.WYf0vjjOdoa0mrFeupKK8YclnwrMIpLPGxLKT3QJC z6a5UfcphDxNndrty2cQxIvsDJmWUv9bHMlZdWVdrIxN1qnI9lqQvyW46Qbo AC5BPmcMqFkUkQRXKw.Dl82AQ7eApPI6a8fnGrVh0AUTLcNn3vC0mgDuB3sU Y9RQ9fM.2nF_qgROL4rjtqN_sKDq8eyWp_oyWehreSB8Fap3PUBbN8sIPuT_ YF1rcX7_fipkX61XX6Ezbv2Mx3ThM3ukz5jcUJIehBPpfp6HtYGIKTDFWok5 JlpqlQ1iEkdb1x6cJNfErqfs45DZVld3TXVSOrRG.qDbdzs4- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.22] (se@81.173.149.150 with plain) by smtp109.mail.bf1.yahoo.com with SMTP; 06 Feb 2012 03:35:02 -0800 PST Message-ID: <4F2FBAE4.1090901@freebsd.org> Date: Mon, 06 Feb 2012 12:35:00 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Hiroki Sato References: <4F2F209F.90309@erdgeist.org> <20120206.101800.1389796154758679137.hrs@allbsd.org> <4F2F3459.3090401@erdgeist.org> <20120206.114622.2214566196455293098.hrs@allbsd.org> In-Reply-To: <20120206.114622.2214566196455293098.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 11:48:15 -0000 Am 06.02.2012 03:46, schrieb Hiroki Sato: > 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 > " I like this, but it does not seem to be compatible with David Teske's sysrc script. And even though that script has not been made part of the FreeBSD sources (yet), I consider it to provide valuable service, that should be preserved. So you should find another separator than new-line, IMHO. [-,:/.] are already used to express addresses (IPv4 or IPv6), so a candidate might be "|" since it does not conflict with any ifconfig parameter. > 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. A general syntax for this purpose is useful, but I'd rather not see new-lines used for this purpose. For example, I have used "sort" to prepare rc.conf files from different hosts for easy comparison with each other. This will be broken, if entries cover more than one line. There may be other breakage of that kind. So please choose a separator character that keeps lines intact ... Regards, STefan 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 =; From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 16:17:19 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 03016106566B for ; Mon, 6 Feb 2012 16:17:19 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id 37C978FC13 for ; Mon, 6 Feb 2012 16:17:17 +0000 (UTC) Received: (qmail 99851 invoked from network); 6 Feb 2012 16:21:07 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 6 Feb 2012 16:21:07 -0000 Message-ID: <4F2FFD0B.3040203@erdgeist.org> Date: Mon, 06 Feb 2012 17:17:15 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 CC: freebsd-rc@freebsd.org References: <4F2F209F.90309@erdgeist.org> <20120206.101800.1389796154758679137.hrs@allbsd.org> <4F2F3459.3090401@erdgeist.org> <20120206.114622.2214566196455293098.hrs@allbsd.org> <20120206160719.GA71408@DataIX.net> In-Reply-To: <20120206160719.GA71408@DataIX.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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:17:19 -0000 On 06.02.12 17:07, Jason Hellenthal wrote: >> 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. This is not necessary. None of the parameters contains spaces, so the syntax is left regular and can easily be parsed in sh. I also do not think that the newlines are necessary to separate tokens the form 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" would be just fine. erdgeist From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 21:48:54 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 266961065670 for ; Mon, 6 Feb 2012 21:48:54 +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 1AFCD8FC12 for ; Mon, 6 Feb 2012 21:48:52 +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 q16LmRZ9039505; Tue, 7 Feb 2012 06:48:37 +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 q16LmPZf009200; Tue, 7 Feb 2012 06:48:27 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 07 Feb 2012 06:47:01 +0900 (JST) Message-Id: <20120207.064701.1809281571072237708.hrs@allbsd.org> To: erdgeist@erdgeist.org From: Hiroki Sato In-Reply-To: <4F2F442F.3030509@erdgeist.org> References: <4F2F3459.3090401@erdgeist.org> <20120206.114622.2214566196455293098.hrs@allbsd.org> <4F2F442F.3030509@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(Tue_Feb__7_06_47_01_2012_164)--" 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]); Tue, 07 Feb 2012 06:48:42 +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 21:48:54 -0000 ----Security_Multipart(Tue_Feb__7_06_47_01_2012_164)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dirk Engling wrote in <4F2F442F.3030509@erdgeist.org>: er> The bugs in /etc/network.subr, function ifalias_up I would like to see er> fixed, anyway: er> er> _ret=`ifalias_ipv4_up "$1"` er> er> just does not work the way you imagined it. The return code is not er> passed when using _ret=`` but the command substituted by it's output er> on stdout, it should read: er> er> ifalias_ipv4_up ${_if} && _ret=0 er> er> as shown in my patch. Thanks for the report. I will take a look into it. er> > In my patch IPv6-mapped IPv4 address is not supported, but your er> > patch can be merged easily. er> er> I like the idea of configuring a router or DNS server for several er> subnets with one range as well, i.e. "inet 10.8.2-16.1/24", do you er> think this makes sense? Sounds good to me. er> > One thing in my mind is whether allowing a variable which contains er> > multiple lines is reasonable or not. er> er> I do not understand the problem there, does your code actually DEPEND er> on new lines? If not, it's just a matter of taste how to arrange your er> variables in your rc.conf, if it doesn't fit in 80 chars, you can er> either overflow, add backslashes or use the style above. The rc's er> author does not FORCE the user into one style, does he? It actually depends on the newline because the following code is used: --- foo=" foo bar baz " echo "$foo" | while read L; do echo $L; done --- -- Hiroki ----Security_Multipart(Tue_Feb__7_06_47_01_2012_164)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8wSlUACgkQTyzT2CeTzy23WQCeIple7SFNeBRL/iuPV/sppalA lXYAoJLtfPvoRYs1TTo06mSLyf1GJPYv =WNrT -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Feb__7_06_47_01_2012_164)---- From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 21:48:55 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 08DBA106564A; Mon, 6 Feb 2012 21:48:55 +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 CFACF8FC16; Mon, 6 Feb 2012 21:48:53 +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 q16LmRS2039504; Tue, 7 Feb 2012 06:48:37 +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 q16LmPZe009200; Tue, 7 Feb 2012 06:48:26 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 07 Feb 2012 06:38:43 +0900 (JST) Message-Id: <20120207.063843.67168667989898285.hrs@allbsd.org> To: se@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F2FBAE4.1090901@freebsd.org> References: <4F2F3459.3090401@erdgeist.org> <20120206.114622.2214566196455293098.hrs@allbsd.org> <4F2FBAE4.1090901@freebsd.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(Tue_Feb__7_06_38_44_2012_931)--" 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]); Tue, 07 Feb 2012 06:48:43 +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 21:48:55 -0000 ----Security_Multipart(Tue_Feb__7_06_38_44_2012_931)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefan Esser wrote in <4F2FBAE4.1090901@freebsd.org>: se> Am 06.02.2012 03:46, schrieb Hiroki Sato: se> > Yes, I agree that aliasN is fragile and renumbering is annoying. I se> > am using a patch to allow the following syntax for a while: se> > se> > ifconfig_tap0_aliases=" se> > inet6 2001:db8:8888:2::1/64 se> > inet6 2001:db8:9990-9999:3::1/64 se> > inet 10.8.1.1/24 se> > inet 10.8.0.1-10/24 se> > " se> se> I like this, but it does not seem to be compatible with David Teske's se> sysrc script. And even though that script has not been made part of I tried sysrc for a variable with multiple lines, but it looks working. What is the compatibility issue more specifically? se> A general syntax for this purpose is useful, but I'd rather not see se> new-lines used for this purpose. For example, I have used "sort" to se> prepare rc.conf files from different hosts for easy comparison with se> each other. This will be broken, if entries cover more than one line. se> There may be other breakage of that kind. se> se> So please choose a separator character that keeps lines intact ... Hmm, sorting rc.conf does not work in many cases because it can contains shell script statements other than variable definitions. I am using a for loop to define multiple vlan interfaces, for example. If we need a feature for comparison, some kind of normalization to extract variables and their values is needed just like sysrc does. I admit 1-line-for-1-variable would be simple and that is a way we have used and expected and I will not rush into an idea with multiple lines. However, it is also true that enumeration like aliasN, more-or-less caused by the 1-line policy, has caused annoying issues and created similar knobs whose functionality is almost the same as each other. I will try to create another patch to support a separator other than a newline, anyway. -- Hiroki ----Security_Multipart(Tue_Feb__7_06_38_44_2012_931)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8wSGQACgkQTyzT2CeTzy02wQCg32Us38ynZGp1253FFFDev6gy 1BUAoJEBNYDVGspTkHvG6xrB0+IEyjI9 =cFYD -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Feb__7_06_38_44_2012_931)---- From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 22:08:42 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 69E42106566B; Mon, 6 Feb 2012 22:08:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F0548153A7C; Mon, 6 Feb 2012 22:08:20 +0000 (UTC) Message-ID: <4F304F54.4020802@FreeBSD.org> Date: Mon, 06 Feb 2012 14:08:20 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Hiroki Sato References: <4F2F3459.3090401@erdgeist.org> <20120206.114622.2214566196455293098.hrs@allbsd.org> <4F2F442F.3030509@erdgeist.org> <20120207.064701.1809281571072237708.hrs@allbsd.org> In-Reply-To: <20120207.064701.1809281571072237708.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigCFA516CE2933821963744664" 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 22:08:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCFA516CE2933821963744664 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/06/2012 13:47, Hiroki Sato wrote: > It actually depends on the newline That's way too fragile, as users are likely to put them all in one line since shell syntax doesn't differentiate (assuming non-wacky values of IF= S). > because the following code is used: >=20 > --- > foo=3D" > foo > bar > baz > " >=20 > echo "$foo" | while read L; do echo $L; done Yeah, don't do that. Aside from the useless fork that you'll cause, you can just as easily write: for L in $foo; do (Note that $foo is *not* quoted there ...) Doug --=20 It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------enigCFA516CE2933821963744664 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPME9UAAoJEFzGhvEaGryEIi8IALSZ7KgJkbf4b60oRMSL4ZxA 265NY3zLTgYx75UsJZVYz6qDQYvFBBk91npFmwezqPtEuYt59Y92EDw4KK8LoGzz uofmaCyTzfXZrZZzfbOJiu0H5PFvKcIqN2gXnZp9ECYTJibIM+YehRN0pKa216lS y3Y+UNxIUYeDdTZamt49q6gzQHbnoCj6FlIoD+ARouXptDPfybqNVl0QUPAi2/9+ S6Eu2QLnRCnVyOoiPFMiAF7Ny/scWPlRjLfS6PtlqgT7h6woY6fOCBgYco/Nnk+v vmGyOZXfrQzmOUUZmBlQFqCFupmX/75x6+4LcSOmgk0jbNPGMbYKrSiZemeq1zA= =DpzH -----END PGP SIGNATURE----- --------------enigCFA516CE2933821963744664-- From owner-freebsd-rc@FreeBSD.ORG Mon Feb 6 22:30:08 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 29DC9106564A; Mon, 6 Feb 2012 22:30:08 +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 77DC78FC0C; Mon, 6 Feb 2012 22:30:07 +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 q16MTfn6049185; Tue, 7 Feb 2012 07:29:51 +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 q16MTfnu009503; Tue, 7 Feb 2012 07:29:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 07 Feb 2012 07:29:25 +0900 (JST) Message-Id: <20120207.072925.1861639312875773760.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F304F54.4020802@FreeBSD.org> References: <4F2F442F.3030509@erdgeist.org> <20120207.064701.1809281571072237708.hrs@allbsd.org> <4F304F54.4020802@FreeBSD.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(Tue_Feb__7_07_29_25_2012_068)--" 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]); Tue, 07 Feb 2012 07:29:57 +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 22:30:08 -0000 ----Security_Multipart(Tue_Feb__7_07_29_25_2012_068)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4F304F54.4020802@FreeBSD.org>: do> On 02/06/2012 13:47, Hiroki Sato wrote: do> > It actually depends on the newline do> do> That's way too fragile, as users are likely to put them all in one line do> since shell syntax doesn't differentiate (assuming non-wacky values of IFS). I don't think so. In this syntax a newline character is a separator distinguished from normal white spaces by read statement. do> > echo "$foo" | while read L; do echo $L; done do> do> Yeah, don't do that. Aside from the useless fork that you'll cause, you do> can just as easily write: do> do> for L in $foo; do do> do> (Note that $foo is *not* quoted there ...) No, my intention is grouping multiple words by a newline. By using "for", lines cannot be separated from each other in the following case: foo=" foo foo2 bar bar2 baz " -- Hiroki ----Security_Multipart(Tue_Feb__7_07_29_25_2012_068)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8wVEUACgkQTyzT2CeTzy279QCgjtlDs5xDJIYsx5SXFBbw6e7c G9kAnjG80yxjGmc5u8TxBsABD9Uoe/hn =wg/A -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Feb__7_07_29_25_2012_068)---- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 02:13:33 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 DDCE71065676 for ; Tue, 7 Feb 2012 02:13:33 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id 20D908FC18 for ; Tue, 7 Feb 2012 02:13:32 +0000 (UTC) Received: (qmail 79079 invoked from network); 7 Feb 2012 02:17:25 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 7 Feb 2012 02:17:25 -0000 Message-ID: <4F3088C8.9090505@erdgeist.org> Date: Tue, 07 Feb 2012 03:13:28 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 References: <4F2F442F.3030509@erdgeist.org> <20120207.064701.1809281571072237708.hrs@allbsd.org> <4F304F54.4020802@FreeBSD.org> <20120207.072925.1861639312875773760.hrs@allbsd.org> In-Reply-To: <20120207.072925.1861639312875773760.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2012 02:13:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06.02.12 23:29, Hiroki Sato wrote: > No, my intention is grouping multiple words by a newline. By > using "for", lines cannot be separated from each other in the > following case: > > foo=" foo foo2 bar bar2 baz " - From my understanding all that's to do is to match the ifconfig parameter syntax and expand ip addresses. There's several ways to do that. You can just accept them as positional paramters in a function, and then shift them out one by one, matching inet and inet6, switching state and returning an expanded string to be executed by the caller. You can also match [ ${foo#inet} = ${foo} ] || foo=`expand_ipv4 ${foo}` or case ${foo} in "inet *") ... ; case "inet6 *") ;; to do the actual work. What exactly is the newline for in that case? To make it clearer where single invocations of ifconfig need to be separated? There is no need to introduce any split characters, as inet and inet6 by themself act as such. In fact, they're not even needed as from the parameter itself the address family should become clear. I never understood why the code insist so heavily on the user to specify the inet and inet6 keywords. Any particular reason? erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8wiMgACgkQuN1wFypsMNO6ugCfVPEwqZ2aO1ITzWYJdIGkCdLL jRQAn3S5ySaInmgv+Soc5Id0sXfpQhbB =//k2 -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 08:09:09 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 9832C106566B for ; Tue, 7 Feb 2012 08:09:09 +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 93B1A8FC15 for ; Tue, 7 Feb 2012 08:09:08 +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 q1788e6r089302; Tue, 7 Feb 2012 17:08:50 +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 q1788bGP013888; Tue, 7 Feb 2012 17:08:40 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 07 Feb 2012 17:02:55 +0900 (JST) Message-Id: <20120207.170255.161251905285915806.hrs@allbsd.org> To: erdgeist@erdgeist.org From: Hiroki Sato In-Reply-To: <4F3088C8.9090505@erdgeist.org> References: <4F304F54.4020802@FreeBSD.org> <20120207.072925.1861639312875773760.hrs@allbsd.org> <4F3088C8.9090505@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(Tue_Feb__7_17_02_55_2012_310)--" 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]); Tue, 07 Feb 2012 17:08:56 +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: Tue, 07 Feb 2012 08:09:09 -0000 ----Security_Multipart(Tue_Feb__7_17_02_55_2012_310)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dirk Engling wrote in <4F3088C8.9090505@erdgeist.org>: er> - From my understanding all that's to do is to match the ifconfig er> parameter syntax and expand ip addresses. There's several ways to do that. er> er> You can just accept them as positional paramters in a function, and er> then shift them out one by one, matching inet and inet6, switching er> state and returning an expanded string to be executed by the caller. er> er> You can also match er> er> [ ${foo#inet} = ${foo} ] || foo=`expand_ipv4 ${foo}` er> er> or er> er> case ${foo} in "inet *") ... ; case "inet6 *") ;; Ah, I see. This looks good. I will give it a try and investigate corner cases. er> to do the actual work. What exactly is the newline for in that case? er> To make it clearer where single invocations of ifconfig need to be er> separated? er> er> There is no need to introduce any split characters, as inet and inet6 er> by themself act as such. In fact, they're not even needed as from the er> parameter itself the address family should become clear. I never er> understood why the code insist so heavily on the user to specify the er> inet and inet6 keywords. Any particular reason? This is because it is unclear that which address family will be used to recognize an address without AF keyword. In most cases network-related utilities/scripts assume IPv4 by default and require a modifier or option for the others. It works, but sometimes it requires a complex and inconsistent address handling in utilities/scripts. Appending AF keyword burdens users a bit but simplifies multiple address family support in more consistent manner. -- Hiroki ----Security_Multipart(Tue_Feb__7_17_02_55_2012_310)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8w2q8ACgkQTyzT2CeTzy0jawCgjOqNhzK2ew7kjUbm42KCdJGA MdUAoJM8WLQ5/Pk/Ysu1LScDMOX2ynGJ =L1Gh -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Feb__7_17_02_55_2012_310)---- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 10:58:18 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 843E010656AE for ; Tue, 7 Feb 2012 10:58:18 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm11.bullet.mail.sp2.yahoo.com (nm11.bullet.mail.sp2.yahoo.com [98.139.91.81]) by mx1.freebsd.org (Postfix) with SMTP id 62B2B8FC1B for ; Tue, 7 Feb 2012 10:58:18 +0000 (UTC) Received: from [98.139.91.62] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 07 Feb 2012 10:45:25 -0000 Received: from [208.71.42.202] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 07 Feb 2012 10:45:25 -0000 Received: from [127.0.0.1] by smtp213.mail.gq1.yahoo.com with NNFMP; 07 Feb 2012 10:45:25 -0000 X-Yahoo-Newman-Id: 430501.33179.bm@smtp213.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WVPNTP4VM1mjgMjXYdQlcZ5gbTUGpmUWzRw6f6ZB1Q_VbYe MNUJhQadXsijBBZ0uO_eVcG4LhHkQRbuvg9av1t2mM78D6OXtn7KCtUizArV N6vJZLWA.1Xka126v19qMa.Wj3ScBuWtcHGeyztKhyXCidteBx6Cx1NpYzIz bOZwN_01WqEbRayuAjzn0QWcU9ec7xrWA3AI0xcEt8eYx.A5vh.6rguhgBzH pYeVu8YLo0M_GhmSiaqaCfGkPUoPSjvxavRyyT2EFtiWArYYJX8fp3FC4Jed BL_LN_af1SpUT4EfNF2AHYs5yNdffktNwHhIqouaOlnvgGDk.2kOKaaMMGVt RgV5Oj1dA7SdsSJOp5RarJxXl9XpNvLVXzjCKzO23Zx83LvqoiDcFpYMaedR mrKOi0NDszz6Q6P.izzMut8ozTPb87fYHQd16YkzZiCKabA7GkdXPW7z5yTn 2tGFgUOlhpkBuck8i7vQ- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.22] (se@81.173.147.65 with plain) by smtp213.mail.gq1.yahoo.com with SMTP; 07 Feb 2012 02:45:24 -0800 PST Message-ID: <4F3100C3.4040700@freebsd.org> Date: Tue, 07 Feb 2012 11:45:23 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Hiroki Sato References: <4F2F3459.3090401@erdgeist.org> <20120206.114622.2214566196455293098.hrs@allbsd.org> <4F2FBAE4.1090901@freebsd.org> <20120207.063843.67168667989898285.hrs@allbsd.org> In-Reply-To: <20120207.063843.67168667989898285.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2012 10:58:18 -0000 Am 06.02.2012 22:38, schrieb Hiroki Sato: > Stefan Esser wrote > in <4F2FBAE4.1090901@freebsd.org>: > > se> Am 06.02.2012 03:46, schrieb Hiroki Sato: > se> > Yes, I agree that aliasN is fragile and renumbering is annoying. I > se> > am using a patch to allow the following syntax for a while: > se> > > se> > ifconfig_tap0_aliases=" > se> > inet6 2001:db8:8888:2::1/64 > se> > inet6 2001:db8:9990-9999:3::1/64 > se> > inet 10.8.1.1/24 > se> > inet 10.8.0.1-10/24 > se> > " > se> > se> I like this, but it does not seem to be compatible with David Teske's > se> sysrc script. And even though that script has not been made part of > > I tried sysrc for a variable with multiple lines, but it looks > working. What is the compatibility issue more specifically? Sorry, I had just assumed that it did not work, while in fact sysrc deals with multi-line values just fine. > se> A general syntax for this purpose is useful, but I'd rather not see > se> new-lines used for this purpose. For example, I have used "sort" to > se> prepare rc.conf files from different hosts for easy comparison with > se> each other. This will be broken, if entries cover more than one line. > se> There may be other breakage of that kind. > se> > se> So please choose a separator character that keeps lines intact ... > > Hmm, sorting rc.conf does not work in many cases because it can > contains shell script statements other than variable definitions. I > am using a for loop to define multiple vlan interfaces, for example. > If we need a feature for comparison, some kind of normalization to > extract variables and their values is needed just like sysrc does. Sorting works just fine for this purpose, at least on my rc.conf files. But I do not use loops or other control structures, just simple variable initializations in them. And I do not use the sorted file as actual rc.conf file, just look for differences between files. A utility that compares rc.conf files might be very useful and I think that should be a valuable addition to sysrc. E.g. a function to compare /etc./rc.conf with a template file, to compare two rc.conf files and to list differences in diff style, or to "grep" lines selected by a template file out of rc.conf, etc. > I admit 1-line-for-1-variable would be simple and that is a way we > have used and expected and I will not rush into an idea with multiple > lines. However, it is also true that enumeration like aliasN, > more-or-less caused by the 1-line policy, has caused annoying issues > and created similar knobs whose functionality is almost the same as > each other. IMHO the semantics of rc.conf files should not be complicated by multi-line entries. Any other separator would be preferable, IMO. > I will try to create another patch to support a separator other than > a newline, anyway. Dirk Engling suggested to use white space as separator and to interpret "inet" and "inet6" as (optional) AF indicators. I like this idea a lot! You could omit inet/inet6 for all numeric addresses (any parameter with a colon is an IPv6 address) and just use inet/inet6 if an address is specified by name (e.g. a host name that can be resolved during system start and for which IPv4 and IPv6 addresses exist, e.g. in /etc/hosts). Such a syntax would restrict use of ip*_addrs_common, but I think that's not a bug but a feature ;-) Regards, STefan From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 14:27:00 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 0ADA410656D3; Tue, 7 Feb 2012 14:27:00 +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 744958FC19; Tue, 7 Feb 2012 14:26:58 +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 q17EQULt081347; Tue, 7 Feb 2012 23:26:40 +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 q17EQRQn017341; Tue, 7 Feb 2012 23:26:30 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 07 Feb 2012 23:24:17 +0900 (JST) Message-Id: <20120207.232417.487789017555472392.hrs@allbsd.org> To: erdgeist@erdgeist.org, se@FreeBSD.org From: Hiroki Sato In-Reply-To: <20120207.170255.161251905285915806.hrs@allbsd.org> <4F3100C3.4040700@freebsd.org> References: <20120207.072925.1861639312875773760.hrs@allbsd.org> <4F3088C8.9090505@erdgeist.org> <20120207.170255.161251905285915806.hrs@allbsd.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_Multipart0(Tue_Feb__7_23_24_17_2012_986)--" 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]); Tue, 07 Feb 2012 23:26:45 +0900 (JST) X-Spam-Status: No, score=-99.9 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,FAKEDWORD_ZERO,QENCPTR1,QENCPTR2,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: Tue, 07 Feb 2012 14:27:00 -0000 ----Security_Multipart0(Tue_Feb__7_23_24_17_2012_986)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Feb__7_23_24_17_2012_022)--" Content-Transfer-Encoding: 7bit ----Next_Part(Tue_Feb__7_23_24_17_2012_022)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dirk Engling wrote in <4F3088C8.9090505@erdgeist.org>: er> You can just accept them as positional paramters in a function, and er> then shift them out one by one, matching inet and inet6, switching er> state and returning an expanded string to be executed by the caller. Stefan Esser wrote in <4F3100C3.4040700@freebsd.org>: se> Dirk Engling suggested to use white space as separator and to interpret se> "inet" and "inet6" as (optional) AF indicators. I like this idea a lot! se> se> You could omit inet/inet6 for all numeric addresses (any parameter with se> a colon is an IPv6 address) and just use inet/inet6 if an address is se> specified by name (e.g. a host name that can be resolved during system se> start and for which IPv4 and IPv6 addresses exist, e.g. in /etc/hosts). The attached patch is my first shot for this direction. This includes a new variable, $ifconfig_IF_aliases, but not includes the address range expansion yet. This is because I would like to get it reviewed first and go forward step-by-step. The goals are: - Keep backward compatibility. $ifconfig_IF_aliasN and $ipv6_ifconfig_IF_aliasN should work as before. - When an AF keyword is missing in ifconfig_IF_aliasN, try to recover by prepending "inet" automatically. Display a warning message only when adding an alias. - Remove duplicate code in network.subr as mush as possible. - Two bugfixes: return status of ifalias_up() and alias removal order in ipv4_down(). Configuration for testing is the following: ---- cloned_interfaces="tap0" ifconfig_tap0="up" ifconfig_tap0_alias0="10.9.1.1/24" ifconfig_tap0_alias1="10.9.2.1/24" ifconfig_tap0_alias3="10.9.3.1/24" ipv6_prefix_tap0="2001:db8:6666:2 2001:db8:7777:0" ipv6_ifconfig_tap0_alias0="2001:db8:7707:1::1 prefixlen 64" ipv6_ifconfig_tap0_alias1="2001:db8:7717:1:: prefixlen 64 eui64" ipv6_ifconfig_tap0_alias3="2001:db8:7737:1:: prefixlen 64 eui64" ifconfig_tap0_aliases="inet6 2001:db8:8888:2::1/64 inet6 2001:db8:9999:3::1/64 inet 10.8.1.1/24" ---- The results were: ---- hrs@dev1 % sudo /etc/rc.d/netif start tap0 /etc/rc.d/netif: WARNING: $ifconfig_tap0_alias0 needs "inet" keyword for an IPv4 address. /etc/rc.d/netif: WARNING: $ifconfig_tap0_alias1 needs "inet" keyword for an IPv4 address. /etc/rc.d/netif: WARNING: $ipv6_ifconfig_tap0_alias0 is obsolete. Use ifconfig_tap0_aliasN instead. /etc/rc.d/netif: WARNING: $ipv6_ifconfig_tap0_alias1 is obsolete. Use ifconfig_tap0_aliasN instead. Starting Network: tap0. tap0: flags=8843 metric 0 mtu 1500 options=80000 ether 00:bd:bf:28:00:00 inet6 fe80::2bd:bfff:fe28:0%tap0 prefixlen 64 scopeid 0xb inet 10.8.1.1 netmask 0xffffff00 broadcast 10.8.1.255 inet 10.9.1.1 netmask 0xffffff00 broadcast 10.9.1.255 inet 10.9.2.1 netmask 0xffffff00 broadcast 10.9.2.255 inet6 2001:db8:8888:2::1 prefixlen 64 inet6 2001:db8:9999:3::1 prefixlen 64 inet6 2001:db8:7707:1::1 prefixlen 64 inet6 2001:db8:7717:1:2bd:bfff:fe28:0 prefixlen 64 inet6 2001:db8:6666:2:2bd:bfff:fe28:0 prefixlen 64 inet6 2001:db8:7777:0:2bd:bfff:fe28:0 prefixlen 64 nd6 options=23 hrs@dev1 % sudo /etc/rc.d/netif stop tap0 Stopping Network: tap0. tap0: flags=8842 metric 0 mtu 1500 options=80000 ether 00:bd:bf:28:00:00 nd6 options=23 ---- Comments are welcome. I am moving onto implementing address range expansion to this framework. -- Hiroki ----Next_Part(Tue_Feb__7_23_24_17_2012_022)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="network.subr.20120207-1.diff" Index: etc/network.subr =================================================================== --- etc/network.subr (revision 231128) +++ etc/network.subr (working copy) @@ -553,7 +553,7 @@ ifconfig ${_if} inet 127.0.0.1/8 alias fi fi - ifalias_up ${_if} inet && _ret=0 + ifalias ${_if} inet alias && _ret=0 ipv4_addrs_common ${_if} alias && _ret=0 return $_ret @@ -571,7 +571,7 @@ return 0 fi - ifalias_up ${_if} inet6 && _ret=0 + ifalias ${_if} inet6 alias && _ret=0 ipv6_prefix_hostid_addr_common ${_if} alias && _ret=0 ipv6_accept_rtadv_up ${_if} && _ret=0 @@ -587,6 +587,9 @@ _ifs="^" _ret=1 + ifalias ${_if} inet -alias && _ret=0 + ipv4_addrs_common ${_if} -alias && _ret=0 + inetList="`ifconfig ${_if} | grep 'inet ' | tr "\n" "$_ifs"`" oldifs="$IFS" @@ -604,9 +607,6 @@ done IFS="$oldifs" - ifalias_down ${_if} inet && _ret=0 - ipv4_addrs_common ${_if} -alias && _ret=0 - return $_ret } @@ -625,7 +625,7 @@ ipv6_accept_rtadv_down ${_if} && _ret=0 ipv6_prefix_hostid_addr_common ${_if} -alias && _ret=0 - ifalias_down ${_if} inet6 && _ret=0 + ifalias ${_if} inet6 -alias && _ret=0 inetList="`ifconfig ${_if} | grep 'inet6 ' | tr "\n" "$_ifs"`" @@ -690,191 +690,101 @@ return $_ret } -# ifalias_up if af -# Configure aliases for network interface $if. +# ifalias if af action +# Configure or remove aliases for network interface $if. # It returns 0 if at least one alias was configured or -# 1 if there were none. +# removed, or 1 if there were none. # -ifalias_up() +ifalias() { local _ret _ret=1 + afexists $2 || return $_ret + case "$2" in - inet) - _ret=`ifalias_ipv4_up "$1"` + inet|inet6) + ifalias_af_common $1 $2 $3 && _ret=0 ;; - inet6) - _ret=`ifalias_ipv6_up "$1"` - ;; esac return $_ret } -# ifalias_ipv4_up if -# Helper function for ifalias_up(). Handles IPv4. +# ifalias_af_common if af action +# Helper function for ifalias(). # -ifalias_ipv4_up() +ifalias_af_common() { - local _ret alias ifconfig_args + local _ret alias ifconfig_args _aliasn _L _tmpargs _if _af _action _ret=1 + _aliasn= + _if=$1 + _af=$2 + _action=$3 - # ifconfig_IF_aliasN which starts with "inet" + # ifconfig_IF_aliasN which starts with ${_af} alias=0 while : ; do - ifconfig_args=`get_if_var $1 ifconfig_IF_alias${alias}` - case "${ifconfig_args}" in - inet\ *) - ifconfig $1 ${ifconfig_args} alias && _ret=0 + ifconfig_args=`get_if_var ${_if} ifconfig_IF_alias${alias}` + case ${_af}:${_action}:"${ifconfig_args}" in + ${_af}:*:${_af}\ *) + _aliasn="${_aliasn} ${ifconfig_args}" ;; - inet6\ *) - ;; - "") + ${_af}:*:"") break ;; - *) - warn "\$ifconfig_$1_alias${alias} needs " \ + inet:alias:*) + _aliasn="${_aliasn} inet ${ifconfig_args}" + warn "\$ifconfig_${_if}_alias${alias} needs " \ "\"inet\" keyword for an IPv4 address." - ifconfig $1 ${ifconfig_args} alias && _ret=0 - ;; esac alias=$((${alias} + 1)) done - return $_ret -} - -# ifalias_ipv6_up if -# Helper function for ifalias_up(). Handles IPv6. -# -ifalias_ipv6_up() -{ - local _ret alias ifconfig_args - _ret=1 - - # ifconfig_IF_aliasN which starts with "inet6" - alias=0 - while : ; do - ifconfig_args=`get_if_var $1 ifconfig_IF_alias${alias}` - case "${ifconfig_args}" in - inet6\ *) - ifconfig $1 ${ifconfig_args} alias && _ret=0 - ;; - "") - break - ;; - esac - alias=$((${alias} + 1)) - done - # backward compatibility: ipv6_ifconfig_IF_aliasN. - alias=0 - while : ; do - ifconfig_args=`get_if_var $1 ipv6_ifconfig_IF_alias${alias}` - case "${ifconfig_args}" in - "") - break + case ${_af} in + inet6) + alias=0 + while : ; do + ifconfig_args=`get_if_var ${_if} ipv6_ifconfig_IF_alias${alias}` + case ${_action}:"${ifconfig_args}" in + *:"") + break ;; - *) - ifconfig $1 inet6 ${ifconfig_args} alias && _ret=0 - warn "\$ipv6_ifconfig_$1_alias${alias} is obsolete." \ - " Use ifconfig_$1_aliasN instead." + alias:*) + _aliasn="${_aliasn} inet6 ${ifconfig_args}" + warn "\$ipv6_ifconfig_${_if}_alias${alias} " \ + "is obsolete. Use ifconfig_$1_aliasN " \ + "instead." ;; - esac - alias=$((${alias} + 1)) - done - - return $_ret -} - -# ifalias_down if af -# Remove aliases for network interface $if. -# It returns 0 if at least one alias was removed or -# 1 if there were none. -# -ifalias_down() -{ - local _ret - _ret=1 - - case "$2" in - inet) - _ret=`ifalias_ipv4_down "$1"` - ;; - inet6) - _ret=`ifalias_ipv6_down "$1"` - ;; + esac + alias=$((${alias} + 1)) + done esac - return $_ret -} - -# ifalias_ipv4_down if -# Helper function for ifalias_down(). Handles IPv4. -# -ifalias_ipv4_down() -{ - local _ret alias ifconfig_args - _ret=1 - - # ifconfig_IF_aliasN which starts with "inet" - alias=0 - while : ; do - ifconfig_args=`get_if_var $1 ifconfig_IF_alias${alias}` - case "${ifconfig_args}" in - inet\ *) - ifconfig $1 ${ifconfig_args} -alias && _ret=0 + # Handle both ifconfig_IF_aliases and ifconfig_IF_aliasN + _tmpargs= + for _L in `get_if_var ${_if} ifconfig_IF_aliases` ${_aliasn}; do + case ${_L} in + inet|inet6|ipx) + case ${_tmpargs} in + ${_af}\ *) + eval ifconfig $1 ${_tmpargs} ${_action} && _ret=0 ;; - "") - break - ;; - esac - alias=$((${alias} + 1)) - done - - return $_ret -} - -# ifalias_ipv6_down if -# Helper function for ifalias_down(). Handles IPv6. -# -ifalias_ipv6_down() -{ - local _ret alias ifconfig_args - _ret=1 - - # ifconfig_IF_aliasN which starts with "inet6" - alias=0 - while : ; do - ifconfig_args=`get_if_var $1 ifconfig_IF_alias${alias}` - case "${ifconfig_args}" in - inet6\ *) - ifconfig $1 ${ifconfig_args} -alias && _ret=0 - ;; - "") - break - ;; - esac - alias=$((${alias} + 1)) - done - - # backward compatibility: ipv6_ifconfig_IF_aliasN. - alias=0 - while : ; do - ifconfig_args=`get_if_var $1 ipv6_ifconfig_IF_alias${alias}` - case "${ifconfig_args}" in - "") - break - ;; + esac + _tmpargs=${_L} + ;; *) - ifconfig $1 inet6 ${ifconfig_args} -alias && _ret=0 - warn "\$ipv6_ifconfig_$1_alias${alias} is obsolete." \ - " Use ifconfig_$1_aliasN instead." - ;; + _tmpargs="${_tmpargs} ${_L}" esac - alias=$((${alias} + 1)) done + # ifconfig_IF_aliases: last component + case ${_tmpargs} in + ${_af}\ *) + eval ifconfig $1 ${_tmpargs} ${_action} && _ret=0 + ;; + esac return $_ret } ----Next_Part(Tue_Feb__7_23_24_17_2012_022)---- ----Security_Multipart0(Tue_Feb__7_23_24_17_2012_986)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8xNBEACgkQTyzT2CeTzy1+ZACgr4Q/qKXH8LdEx6VzU+mhwkxR TqcAoJQDShk40wFz/vX21FUBbsjqS+OZ =7xWP -----END PGP SIGNATURE----- ----Security_Multipart0(Tue_Feb__7_23_24_17_2012_986)---- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 14:27:01 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 3D829106568B; Tue, 7 Feb 2012 14:27:01 +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 9F4EE8FC0A; Tue, 7 Feb 2012 14:26:59 +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 q17EQUG2081348; Tue, 7 Feb 2012 23:26:40 +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 q17EQRQo017341; Tue, 7 Feb 2012 23:26:30 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 07 Feb 2012 23:25:28 +0900 (JST) Message-Id: <20120207.232528.1678394612793537394.hrs@allbsd.org> To: se@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F3100C3.4040700@freebsd.org> References: <4F2FBAE4.1090901@freebsd.org> <20120207.063843.67168667989898285.hrs@allbsd.org> <4F3100C3.4040700@freebsd.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(Tue_Feb__7_23_25_29_2012_419)--" 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]); Tue, 07 Feb 2012 23:26:46 +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: Tue, 07 Feb 2012 14:27:01 -0000 ----Security_Multipart(Tue_Feb__7_23_25_29_2012_419)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefan Esser wrote in <4F3100C3.4040700@freebsd.org>: se> Sorting works just fine for this purpose, at least on my rc.conf files. se> But I do not use loops or other control structures, just simple variable se> initializations in them. And I do not use the sorted file as actual se> rc.conf file, just look for differences between files. se> se> A utility that compares rc.conf files might be very useful and I think se> that should be a valuable addition to sysrc. E.g. a function to compare se> /etc./rc.conf with a template file, to compare two rc.conf files and to se> list differences in diff style, or to "grep" lines selected by a se> template file out of rc.conf, etc. Agreed. I received the same kind of requests from a company that I am working with. To compare rc.conf variables between two machines is difficult because the configurations come from various sources. It is also difficult to know which is the default value and which is configured. I am working on this issue in parallel, so another proposal will be posted separately later. se> > I will try to create another patch to support a separator other than se> > a newline, anyway. se> se> Dirk Engling suggested to use white space as separator and to interpret se> "inet" and "inet6" as (optional) AF indicators. I like this idea a lot! Okay. I do not stick to a way with multiple lines. Thank you for your feedback. -- Hiroki ----Security_Multipart(Tue_Feb__7_23_25_29_2012_419)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8xNFkACgkQTyzT2CeTzy0c7wCfQt78q9mD7gzOWS4YRy3o9Ons 69EAn3KNfKM1MN7hmbQWvkQiPvrz5yls =Unrt -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Feb__7_23_25_29_2012_419)---- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 14:47:11 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 8BC2E106567B for ; Tue, 7 Feb 2012 14:47:11 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id F27948FC18 for ; Tue, 7 Feb 2012 14:47:10 +0000 (UTC) Received: (qmail 84608 invoked from network); 7 Feb 2012 14:51:10 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 7 Feb 2012 14:51:10 -0000 Message-ID: <4F31396C.2060507@erdgeist.org> Date: Tue, 07 Feb 2012 15:47:08 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Hiroki Sato References: <4F304F54.4020802@FreeBSD.org> <20120207.072925.1861639312875773760.hrs@allbsd.org> <4F3088C8.9090505@erdgeist.org> <20120207.170255.161251905285915806.hrs@allbsd.org> In-Reply-To: <20120207.170255.161251905285915806.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2012 14:47:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.02.12 09:02, Hiroki Sato wrote: > Ah, I see. This looks good. I will give it a try and investigate > corner cases. I did not want to put the burden of implementation on you. I'm doing shell scripting for a living and can surely help with that. I just need some directions, pitfalls that have been found earlier and that I should avoid. > This is because it is unclear that which address family will be > used to recognize an address without AF keyword. In most cases > network-related utilities/scripts assume IPv4 by default and > require a modifier or option for the others. It works, but > sometimes it requires a complex and inconsistent address handling > in utilities/scripts. Appending AF keyword burdens users a bit > but simplifies multiple address family support in more consistent > manner. So to put that in the grand perspective, the ifconfig_IF_aliases knob is solely to configure additional aliases to the interface as opposed to the ifconfig_IF knob which can contain other more complex parameters to pass to ifconfig? Do we need to handle more cases than plain ipv4, hex ipv4, plain ipv6 addresses, ipv6 mapped v4 and hostnames? - From the ifconfig's man page I take at least "ether", "ipx" and "atalk". It does not make sense to support re-setting link level addresses in the ifconfig_IF_aliases knob. For the atalk address family ifconfig recognises "range" modifiers that work like netmasks, but it looks not very common to configure additional atalk address to a single interface. Maybe someone with IPX knowledge can comment if we need to take special care. To sum it up: the handler for the ifconfig_IF_aliases knob should just pass each space separated value to ifconfig $IF $v (-)alias , unless a) it is prefixed with any of the address family names know to ifconfig, in that case the family should be remembered and next value be parsed and passed to ifconfig $IF $family $v (-)alias b) it matches RANGE.RANGE.RANGE.RANGE(/\d{1-2})? for RANGE in \d{1-3}(-\d{1-3})? with at least one dash. In that case it is expanded and each expansion passed to ifconfig $IF $family $expansion/$mask (-)alias with mask set to 32 after the first address in each subnet. For an address family already specified we could check for conflicts here or leave that to ifconfig. c) it matches *-*:*:*(/\d{3})?, *:*-*:*(/\d{3})?, *:*:*-*(/\d{3})? (So we're sure not to interfere with link level addresses.) In that case it is expanded and each expansion passed to ifconfig $IF inet6 $expansion/$mask (-)alias here we should check for collision of the address family. Also I am not sure if you have to alter the netmask. d) it matches ::ffff:RANGE.RANGE.RANGE.RANGE(/\d{1-2})? with at least one dash. In that case it is expanded and each expansion passed to ifconfig $IF inet6 $expansion/$mask (-)alias with mask reset 128 after the first address in each subnet. Done ;) erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8xOWwACgkQuN1wFypsMNN9XgCeIKx2nk9sQvcTuQEMRYxhk82G Wi4An3XPssuX/+eQpaz1uOkOlsBME3vv =sI94 -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 15:17:03 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 B79DF1065676 for ; Tue, 7 Feb 2012 15:17:03 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id F03528FC19 for ; Tue, 7 Feb 2012 15:17:02 +0000 (UTC) Received: (qmail 89052 invoked from network); 7 Feb 2012 15:21:03 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 7 Feb 2012 15:21:03 -0000 Message-ID: <4F31406D.5020304@erdgeist.org> Date: Tue, 07 Feb 2012 16:17:01 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 References: <20120207.072925.1861639312875773760.hrs@allbsd.org> <4F3088C8.9090505@erdgeist.org> <20120207.170255.161251905285915806.hrs@allbsd.org> <20120207.232417.487789017555472392.hrs@allbsd.org> In-Reply-To: <20120207.232417.487789017555472392.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2012 15:17:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.02.12 15:24, Hiroki Sato wrote: > Comments are welcome. I am moving onto implementing address range > expansion to this framework. Before looking deeper into your patch I'd suggest that we also consollidate the handler for ipv4_addrs_IF into ifalias_af_common and deprecate it. Makes sense? erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8xQG0ACgkQuN1wFypsMNMakACeIJMHh3EpW8pQTeMurchnhiLP 4e8AnRHplBGVw6putTVovkPuVIHm2JMG =vX8l -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 15:55:20 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 C0D33106566B for ; Tue, 7 Feb 2012 15:55:20 +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 1E3DC8FC16 for ; Tue, 7 Feb 2012 15:55:19 +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 q17FstbL002108; Wed, 8 Feb 2012 00:55:05 +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 q17FsrNr018169; Wed, 8 Feb 2012 00:54:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 08 Feb 2012 00:54:41 +0900 (JST) Message-Id: <20120208.005441.344732308200260953.hrs@allbsd.org> To: erdgeist@erdgeist.org From: Hiroki Sato In-Reply-To: <4F31406D.5020304@erdgeist.org> References: <20120207.170255.161251905285915806.hrs@allbsd.org> <20120207.232417.487789017555472392.hrs@allbsd.org> <4F31406D.5020304@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(Wed_Feb__8_00_54_41_2012_006)--" 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]); Wed, 08 Feb 2012 00:55:10 +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: Tue, 07 Feb 2012 15:55:20 -0000 ----Security_Multipart(Wed_Feb__8_00_54_41_2012_006)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dirk Engling wrote in <4F31406D.5020304@erdgeist.org>: er> -----BEGIN PGP SIGNED MESSAGE----- er> Hash: SHA1 er> er> On 07.02.12 15:24, Hiroki Sato wrote: er> er> > Comments are welcome. I am moving onto implementing address range er> > expansion to this framework. er> er> Before looking deeper into your patch I'd suggest that we also er> consollidate the handler for ipv4_addrs_IF into ifalias_af_common and er> deprecate it. Makes sense? Yes, after integrating address range expansion it is possible and it should be. -- Hiroki ----Security_Multipart(Wed_Feb__8_00_54_41_2012_006)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8xSUEACgkQTyzT2CeTzy2M6gCghFxjU/2sJMzJVjPJB6R11qKN xVoAoIf06+VHUOVjWHYtTsoMAW7RAbPK =ed55 -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Feb__8_00_54_41_2012_006)---- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 18:24:09 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 8C555106566C for ; Tue, 7 Feb 2012 18:24:09 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id C307A8FC16 for ; Tue, 7 Feb 2012 18:24:08 +0000 (UTC) Received: (qmail 13466 invoked from network); 7 Feb 2012 18:28:09 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 7 Feb 2012 18:28:09 -0000 Message-ID: <4F316C45.2090907@erdgeist.org> Date: Tue, 07 Feb 2012 19:24:05 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 References: <20120207.170255.161251905285915806.hrs@allbsd.org> <20120207.232417.487789017555472392.hrs@allbsd.org> <4F31406D.5020304@erdgeist.org> <20120208.005441.344732308200260953.hrs@allbsd.org> In-Reply-To: <20120208.005441.344732308200260953.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2012 18:24:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.02.12 16:54, Hiroki Sato wrote: > Yes, after integrating address range expansion it is possible and > it should be. I am sorry to keep bugging you, is there any chance to have the patches back ported to 8.x as well (of course with me volunteering to do the porting)? I noticed that in 9.0 network.subr got a neat cleanup and I wonder what the policies regarding back porting changes are. Whom to petition to? erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8xbEUACgkQuN1wFypsMNNSyQCdFDMNdiES0QmoJTnEd3O3cvwv TPoAoJVE++FOuRYyvhIgmlqGFORkhy7b =9eYn -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 18:57:05 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 3B612106564A for ; Tue, 7 Feb 2012 18:57:05 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id 72B588FC17 for ; Tue, 7 Feb 2012 18:57:04 +0000 (UTC) Received: (qmail 18233 invoked from network); 7 Feb 2012 19:01:06 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 7 Feb 2012 19:01:06 -0000 Message-ID: <4F3173FE.4020901@erdgeist.org> Date: Tue, 07 Feb 2012 19:57:02 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 References: <20120207.072925.1861639312875773760.hrs@allbsd.org> <4F3088C8.9090505@erdgeist.org> <20120207.170255.161251905285915806.hrs@allbsd.org> <20120207.232417.487789017555472392.hrs@allbsd.org> In-Reply-To: <20120207.232417.487789017555472392.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2012 18:57:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.02.12 15:24, Hiroki Sato wrote: > Comments are welcome. I am moving onto implementing address range > expansion to this framework. I noticed that in ipv4_down and ipv6_down first the aliases are taken down from the interface with the ifalias and ipv4_addrs_common function. Afterwards every single ip address is deleted in the loop calling ifconfig ${_if} ${_inet} delete Actually the order first was reversed: every address was taken down in the loop and only then did the code try to remove the addresses it configured with the _alias functions. Why first remove them chirurgical before killing the whole patient? Did I miss anything? erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8xc/4ACgkQuN1wFypsMNPTuwCghycrPZryDFF5AhjWINTJNHTF kocAniZ08A7+BUtobjt01AhKc35HcSMW =5YfA -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 21:32:42 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 6AA4B106566C for ; Tue, 7 Feb 2012 21:32:42 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id A617A8FC18 for ; Tue, 7 Feb 2012 21:32:41 +0000 (UTC) Received: (qmail 36702 invoked from network); 7 Feb 2012 21:36:43 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 7 Feb 2012 21:36:43 -0000 Message-ID: <4F319876.3040303@erdgeist.org> Date: Tue, 07 Feb 2012 22:32:38 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Hiroki Sato , freebsd-rc@FreeBSD.org References: <20120207.072925.1861639312875773760.hrs@allbsd.org> <4F3088C8.9090505@erdgeist.org> <20120207.170255.161251905285915806.hrs@allbsd.org> <20120207.232417.487789017555472392.hrs@allbsd.org> <4F3190E6.6010405@erdgeist.org> In-Reply-To: <4F3190E6.6010405@erdgeist.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: Tue, 07 Feb 2012 21:32:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.02.12 22:00, Dirk Engling wrote: > Now about your loop in ifalias_af_common: if your ever encounter > an entry with no value in inet|inet6|ipx), you will keep building > up your _tmpargs forever, without any chance of ever breaking out > of this state. Ahh, now I see where this is going... you plan on collecting even more parameters to support statements like this: inet 192.168.2.1 netmask 0xffffff00 inet6 ::4 prefixlen 64 while I had constructs in mind that speak for themselves: 192.168.2.1/24 ::4/64 or maybe more verbose 192.168.2.1/24 inet6 ::4/64 ... So: is there anything besides the netmask you expect to appear in the ipv4_addrs_IF and ifconfig_IF_alias* variables? If not, we should just parse them appropriately. erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8xmHYACgkQuN1wFypsMNPGMACfV8F77kZGo9jVlLybz/kzHuzn QcUAnA+1gRsAtLyNqk1Zs/QURGSWYhML =5zUD -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 02:28:11 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 E5E7F106567E for ; Wed, 8 Feb 2012 02:28:11 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id CB5568FC1B for ; Wed, 8 Feb 2012 02:28:11 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 97A6B5EAF; Tue, 7 Feb 2012 18:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1328668091; bh=fUCZmwvaDJwbFpxFtBvwEKmFO8JeA/8MJ+WAjD4Alvs=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: Content-Type; b=q7fBU5ludYGTX5v2cb2+kc7Gj3tnIBe/FHAVhWVfMUgPFrG4OBKA8RMtrUBbJg57l Ij6ygMcGaxgG9vPInW8TqO9gCLCprJha3MTbwbwTXoDa8GsimECnH3YUK8yq8lQyUC ElqrHnflNobrI+3bwGg49L+uW5yFGOR8FfBy5OBk= Message-ID: <4F31DDB8.3020809@delphij.net> Date: Tue, 07 Feb 2012 18:28:08 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-rc@FreeBSD.org X-Enigmail-Version: 1.3.5 Content-Type: multipart/mixed; boundary="------------030707080703060506090202" Cc: d@delphij.net Subject: base system rc.d dependencies as of 231173 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net 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: Wed, 08 Feb 2012 02:28:12 -0000 This is a multi-part message in MIME format. --------------030707080703060506090202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, This may be useful for rc.d people so I've decided to post it here. I created these graphs with the NetBSD rcorder-visualize script with some changes to adapt with our needs (e.g. some scripts would provide multiple services, etc, attached). I think the script is useful for FreeBSD as well, should we import it? Generated graph can be found at: http://people.freebsd.org/~delphij/misc/rcorder-r231173.svg Or, https://www.delphij.net/rcorder-r231173.svg (people.freebsd.org would serve the .svg as a download). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPMd24AAoJEG80Jeu8UPuzflgIAKtj2mPkwQbdGRPV8ywBYLLa faOacHpgJ0nmbLdfpjXFCx/gN4092MJ+xdYm8uOGH8H1S0ZjAE4NJSRdzpv8SGWE I0hR0h2m9BvqxSJ5sPYHLSwJ32ro/DdlPrXYpYP0lzDt8eZjJpcCz2+5xQF1Iz/c MX2jostyCDG5ShuT0R/FjT6UeWEdlHla1ZcBHZX+yYw7Lm5wij2rgLARG8v/qUj9 FvGzNVoGtEQpP5x2W1QYtX+dUaGxyN8yifGkOFKvuTZWwoaW77z0lGlsDrEEV15e MCgatzlJIQRsF2zHZi15Gw8OYp60OgekpHrJvFIfespGIVwtXuu1MfGc2NQzE2c= =xWxM -----END PGP SIGNATURE----- --------------030707080703060506090202 Content-Type: text/plain; name="rcorder-visualize.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rcorder-visualize.sh" #!/bin/sh # $NetBSD: rcorder-visualize.sh,v 1.5 2009/08/09 17:08:53 apb Exp $ # # Written by Joerg Sonnenberger. You may freely use and redistribute # this script. # # Simple script to show the dependency graph for rc scripts. # Output is in the dot(1) language and can be rendered using # sh rcorder-visualize | dot -T svg -o rcorder.svg # dot(1) can be found in graphics/graphviz in pkgsrc. rc_files=${*:-/etc/rc.d/*} { echo ' digraph {' for f in $rc_files; do < $f awk ' /# PROVIDE: / { for (i = 3; i <= NF; i++) provides[$i] = $i } /# REQUIRE: / { for (i = 3; i <= NF; i++) requires[$i] = $i } /# BEFORE: / { for (i = 3; i <= NF; i++) befores[$i] = $i } END { for (provide in provides) { print " \"" provide "\";" for (x in requires) print " \"" x "\"->\"" provide "\";" for (x in befores) print " \"" provide "\"->\"" x "\";" } } ' done echo '}' } --------------030707080703060506090202-- From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 02:44:04 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9B07010656D3 for ; Wed, 8 Feb 2012 02:44:04 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 91672151E06; Wed, 8 Feb 2012 02:44:03 +0000 (UTC) Message-ID: <4F31E172.8080807@FreeBSD.org> Date: Tue, 07 Feb 2012 18:44:02 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: d@delphij.net References: <4F31DDB8.3020809@delphij.net> In-Reply-To: <4F31DDB8.3020809@delphij.net> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF2F06CA8C128ED78567FE059" Cc: freebsd-rc@FreeBSD.org, Xin Li Subject: Re: base system rc.d dependencies as of 231173 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: Wed, 08 Feb 2012 02:44:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2F06CA8C128ED78567FE059 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/07/2012 18:28, Xin Li wrote: > This may be useful for rc.d people so I've decided to post it here. I > created these graphs with the NetBSD rcorder-visualize script with > some changes to adapt with our needs (e.g. some scripts would provide > multiple services, etc, attached). I think the script is useful for > FreeBSD as well, should we import it? I wouldn't have any objection to it being included in tools/ somewhere. That said, please don't take this as a criticism of your work, but I don't see what we're supposed to get from this. It's an interesting graphic, but there is too much data, of too much complexity, for the graphic to be absorbed in one view. .... or maybe I'm just too stupid to see the value. Doug --=20 It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------enigF2F06CA8C128ED78567FE059 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPMeFyAAoJEFzGhvEaGryEzmcH/jZmsz+KtvVEjuojQCRfpnxy 1jG06ovgMwtE7PtqfhFQDqvcKzaOeR0QUZZyCRe4WvN18hULDSp2o4UIZ5Wz+lU1 McaZcK46Tt/OE0VUOIE8KcxCO/MCSrBoncXWW+f9awTAaLqai7ihpgchFiE59I3z wXwmCXOhUMq33cLhVQdJbyPxRsWX783qOO9JTQA0/16RNNwsSWbdwY6tP6mhB2oJ g7bpiUkf6bHpfh3CKbLSZ+OsowhQwi8DfhtsJO4YsbhwrVWfKILZv+CybWPT8hyE PwywM8FUxyBINsA90y6mpwmc2tRh5e1I0sJkgtNPEXDFYBtj5eE92J7FqwUETAc= =Qa7V -----END PGP SIGNATURE----- --------------enigF2F06CA8C128ED78567FE059-- From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 03:11:54 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 8F436106570D; Wed, 8 Feb 2012 03:11:54 +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 865568FC0A; Wed, 8 Feb 2012 03:11:53 +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 q183BHgS067751; Wed, 8 Feb 2012 12:11:27 +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 q183BCJl025083; Wed, 8 Feb 2012 12:11:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 08 Feb 2012 12:09:34 +0900 (JST) Message-Id: <20120208.120934.253399498479271956.hrs@allbsd.org> To: d@delphij.net, delphij@delphij.net, dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F31E172.8080807@FreeBSD.org> References: <4F31DDB8.3020809@delphij.net> <4F31E172.8080807@FreeBSD.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(Wed_Feb__8_12_09_34_2012_322)--" 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]); Wed, 08 Feb 2012 12:11:33 +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: base system rc.d dependencies as of 231173 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: Wed, 08 Feb 2012 03:11:54 -0000 ----Security_Multipart(Wed_Feb__8_12_09_34_2012_322)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4F31E172.8080807@FreeBSD.org>: do> On 02/07/2012 18:28, Xin Li wrote: do> > This may be useful for rc.d people so I've decided to post it here. I do> > created these graphs with the NetBSD rcorder-visualize script with do> > some changes to adapt with our needs (e.g. some scripts would provide do> > multiple services, etc, attached). I think the script is useful for do> > FreeBSD as well, should we import it? do> do> I wouldn't have any objection to it being included in tools/ somewhere. do> do> That said, please don't take this as a criticism of your work, but I do> don't see what we're supposed to get from this. It's an interesting do> graphic, but there is too much data, of too much complexity, for the do> graphic to be absorbed in one view. .... or maybe I'm just too stupid to do> see the value. Interesting, but I agree that this flow chart is too complex to understand. Before importing this, how about refining the output in some way? Useful information we can get from this kind of chart is order and dependency. Off the top of my head, but I would say that roughly grouping the dependencies by uppercase scripts using the subgraph statement and placing nodes for the uppercase scripts in alignment with each other from top to bottom (forcing alignment is difficult in GraphViz though) would make something better. -- Hiroki ----Security_Multipart(Wed_Feb__8_12_09_34_2012_322)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8x524ACgkQTyzT2CeTzy1k+wCgjd4+2txXDzUu9hRgIetIUv6Q vXQAoN9KSeezUPoB5gyEMk3XYV9nAnCo =jkzA -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Feb__8_12_09_34_2012_322)---- From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 07:29:06 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8C6651065686 for ; Wed, 8 Feb 2012 07:29:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5C256151080; Wed, 8 Feb 2012 07:28:56 +0000 (UTC) Message-ID: <4F322437.5030100@FreeBSD.org> Date: Tue, 07 Feb 2012 23:28:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-rc@FreeBSD.org X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------080809080101040000050201" Cc: Subject: Bringing sanity to the RPC/NFS related scripts 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: Wed, 08 Feb 2012 07:29:06 -0000 This is a multi-part message in MIME format. --------------080809080101040000050201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Howdy, Over the years I've been bothered by miscellaneous little "issues" with the NFS and RPC related scripts, but lately I've seen some real operational problems that have caused me to poke harder, and I think I've made some progress. So first the operational problem. I have a lot of systems for which NFS is mission-critical, and that includes lockd. However, we're seeing lockd fail to start because statd didn't start successfully (all the right knobs are there, but sometimes statd fails for unrelated reasons). Currently rc.d/lockd has this: if ! checkyesno rpcbind_enable && \ ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 then force_depend rpcbind || ret=1 fi which seems to be going the right direction, but a) doesn't include statd, and b) the test for "is it running?" is conditional on it not being _enable'd, which is counterproductive for a couple of reasons. (I can elaborate if necessary, but hopefully it's obvious?) So I'd like to propose removing the _enable check from all the relevant scripts that have this force_depend capability. For users who already have _enable for these services it will cause one extra call to forcestatus for them, but given that rc.d currently has no other way to ensure that required dependencies are running, I think it's worth it. The other thing about the status quo is the fact that statd and lockd check that either nfs_server or nfs_client is _enable'd before they run start or stop. This was added almost 5 years ago by mtm, but it creates a variety of problems, not the least of which is that it prevents users from using forcestart or onestart to start these services. Worse is the stop_precmd that also checks these knobs before proceeding. The attached patch does the following: 1. Makes force_depend conditional only on the forcestatus checks for the relevant services, as described above. 2. Removes the tests for nfs_{client|server}_enable from lockd and statd, described above. 3. Adds a check that statd is running to rc.d/lockd 4. Simplifies/standardizes various elements of the shell syntax. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------080809080101040000050201 Content-Type: text/plain; name="nfs-rpc-rcd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="nfs-rpc-rcd.diff" Index: mountd =================================================================== --- mountd (revision 231185) +++ mountd (working copy) @@ -19,9 +19,7 @@ mountd_precmd() { - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then + if ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1; then force_depend rpcbind || return 1 fi @@ -49,7 +47,6 @@ rm -f /var/db/mountdtab ( umask 022 ; > /var/db/mountdtab ) - return 0 } load_rc_config $name Index: nfsd =================================================================== --- nfsd (revision 231185) +++ nfsd (working copy) @@ -61,18 +61,13 @@ fi fi - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then + if ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1; then force_depend rpcbind || return 1 fi - if ! checkyesno mountd_enable && \ - ! /etc/rc.d/mountd forcestatus 1>/dev/null 2>&1 - then + if ! /etc/rc.d/mountd forcestatus 1>/dev/null 2>&1; then force_depend mountd || return 1 fi - return 0 } run_rc_command "$1" Index: amd =================================================================== --- amd (revision 231185) +++ amd (working copy) @@ -23,9 +23,7 @@ force_depend nfsclient || return 1 fi - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then + if ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1; then force_depend rpcbind || return 1 fi @@ -49,7 +47,6 @@ command_args="> /var/run/amd.pid 2> /dev/null" ;; esac - return 0 } load_rc_config $name Index: lockd =================================================================== --- lockd (revision 231185) +++ lockd (working copy) @@ -15,7 +15,6 @@ rcvar=rpc_lockd_enable command="/usr/sbin/rpc.${name}" start_precmd='lockd_precmd' -stop_precmd='checkyesno nfs_server_enable || checkyesno nfs_client_enable' status_precmd=$stop_precmd # Make sure that we are either an NFS client or server, and that we get @@ -23,20 +22,13 @@ # lockd_precmd() { - local ret - ret=0 - - if ! checkyesno nfs_server_enable && ! checkyesno nfs_client_enable - then - ret=1 + if ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1; then + force_depend rpcbind || return 1 fi - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || ret=1 + if ! /etc/rc.d/statd forcestatus 1>/dev/null 2>&1; then + force_depend statd || return 1 fi rc_flags=${rpc_lockd_flags} - return ${ret} } load_rc_config $name Index: statd =================================================================== --- statd (revision 231185) +++ statd (working copy) @@ -15,7 +15,6 @@ rcvar=rpc_statd_enable command="/usr/sbin/rpc.${name}" start_precmd='statd_precmd' -stop_precmd='checkyesno nfs_server_enable || checkyesno nfs_client_enable' status_precmd=$stop_precmd # Make sure that we are either an NFS client or server, and that we get @@ -23,20 +22,10 @@ # statd_precmd() { - local ret - ret=0 - - if ! checkyesno nfs_server_enable && ! checkyesno nfs_client_enable - then - ret=1 + if ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1; then + force_depend rpcbind || return 1 fi - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || ret=1 - fi rc_flags=${rpc_statd_flags} - return ${ret} } load_rc_config $name --------------080809080101040000050201-- From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 09:21:10 2012 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 031EE106566C; Wed, 8 Feb 2012 09:21:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C97AF8FC15; Wed, 8 Feb 2012 09:21:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q189L964065064; Wed, 8 Feb 2012 09:21:09 GMT (envelope-from dougb@freefall.freebsd.org) Received: (from dougb@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q189L8Uv064977; Wed, 8 Feb 2012 09:21:08 GMT (envelope-from dougb) Date: Wed, 8 Feb 2012 09:21:08 GMT Message-Id: <201202080921.q189L8Uv064977@freefall.freebsd.org> To: fabian@thorns.it, dougb@FreeBSD.org, freebsd-rc@FreeBSD.org, dougb@FreeBSD.org From: dougb@FreeBSD.org Cc: Subject: Re: conf/120431: [patch] devfs.rules are not initialized under certain (default) circumstances 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: Wed, 08 Feb 2012 09:21:10 -0000 Synopsis: [patch] devfs.rules are not initialized under certain (default) circumstances State-Changed-From-To: open->closed State-Changed-By: dougb State-Changed-When: Wed Feb 8 09:20:21 UTC 2012 State-Changed-Why: I added a different solution to this problem in HEAD, and will MFC soon Responsible-Changed-From-To: freebsd-rc->dougb Responsible-Changed-By: dougb Responsible-Changed-When: Wed Feb 8 09:20:21 UTC 2012 Responsible-Changed-Why: I'm going to handle this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=120431 From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 09:23:48 2012 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 520991065670; Wed, 8 Feb 2012 09:23:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 24B418FC17; Wed, 8 Feb 2012 09:23:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q189Nmce066812; Wed, 8 Feb 2012 09:23:48 GMT (envelope-from dougb@freefall.freebsd.org) Received: (from dougb@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q189Nlei066808; Wed, 8 Feb 2012 09:23:47 GMT (envelope-from dougb) Date: Wed, 8 Feb 2012 09:23:47 GMT Message-Id: <201202080923.q189Nlei066808@freefall.freebsd.org> To: jeremie@le-hen.org, dougb@FreeBSD.org, freebsd-rc@FreeBSD.org, dougb@FreeBSD.org From: dougb@FreeBSD.org Cc: Subject: Re: conf/109562: [rc.d] [patch] [request] Make rc.d/devfs usable from command-line 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: Wed, 08 Feb 2012 09:23:48 -0000 Synopsis: [rc.d] [patch] [request] Make rc.d/devfs usable from command-line State-Changed-From-To: open->closed State-Changed-By: dougb State-Changed-When: Wed Feb 8 09:22:37 UTC 2012 State-Changed-Why: No one has expressed interest in this solution for 6 years, and setting the rc.conf variable is not that egregious. Responsible-Changed-From-To: freebsd-rc->dougb Responsible-Changed-By: dougb Responsible-Changed-When: Wed Feb 8 09:22:37 UTC 2012 Responsible-Changed-Why: I'm closing this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=109562 From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 13:55:34 2012 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0587106566B; Wed, 8 Feb 2012 13:55:34 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B31378FC1B; Wed, 8 Feb 2012 13:55:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q18DtY9m022790; Wed, 8 Feb 2012 13:55:34 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q18DtYJ7022786; Wed, 8 Feb 2012 13:55:34 GMT (envelope-from glebius) Date: Wed, 8 Feb 2012 13:55:34 GMT Message-Id: <201202081355.q18DtYJ7022786@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-rc@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/161899: [route] ntpd(8): Repeating RTM_MISS packets causing high CPU load for ntpd 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: Wed, 08 Feb 2012 13:55:35 -0000 Synopsis: [route] ntpd(8): Repeating RTM_MISS packets causing high CPU load for ntpd Responsible-Changed-From-To: freebsd-net->freebsd-rc Responsible-Changed-By: glebius Responsible-Changed-When: Wed Feb 8 13:55:07 UTC 2012 Responsible-Changed-Why: I think, that solution to the problem lives somewhere in th rc-land. http://www.freebsd.org/cgi/query-pr.cgi?pr=161899 From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 13:56:04 2012 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDEC51065672; Wed, 8 Feb 2012 13:56:04 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 905BF8FC13; Wed, 8 Feb 2012 13:56:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q18Du4ka022841; Wed, 8 Feb 2012 13:56:04 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q18Du4HF022837; Wed, 8 Feb 2012 13:56:04 GMT (envelope-from glebius) Date: Wed, 8 Feb 2012 13:56:04 GMT Message-Id: <201202081356.q18Du4HF022837@freefall.freebsd.org> To: killing@multiplay.co.uk, glebius@FreeBSD.org, freebsd-rc@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/161899: [route] ntpd(8): Repeating RTM_MISS packets causing high CPU load for ntpd 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: Wed, 08 Feb 2012 13:56:04 -0000 Synopsis: [route] ntpd(8): Repeating RTM_MISS packets causing high CPU load for ntpd State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Wed Feb 8 13:55:37 UTC 2012 State-Changed-Why: Not an issue on head/, however I don't know which revision needs to be merged :) http://www.freebsd.org/cgi/query-pr.cgi?pr=161899 From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 23:08:55 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 737721065670; Wed, 8 Feb 2012 23:08:55 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 10D7D8FC1E; Wed, 8 Feb 2012 23:08:55 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 38BA91E1076; Thu, 9 Feb 2012 00:08:53 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 2028D28468; Thu, 9 Feb 2012 00:08:53 +0100 (CET) Date: Thu, 9 Feb 2012 00:08:53 +0100 From: Jilles Tjoelker To: Doug Barton Message-ID: <20120208230852.GA83950@stack.nl> References: <4F322437.5030100@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F322437.5030100@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-rc@FreeBSD.org Subject: Re: Bringing sanity to the RPC/NFS related scripts 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: Wed, 08 Feb 2012 23:08:55 -0000 On Tue, Feb 07, 2012 at 11:28:55PM -0800, Doug Barton wrote: > Over the years I've been bothered by miscellaneous little "issues" with > the NFS and RPC related scripts, but lately I've seen some real > operational problems that have caused me to poke harder, and I think > I've made some progress. > So first the operational problem. I have a lot of systems for which NFS > is mission-critical, and that includes lockd. However, we're seeing > lockd fail to start because statd didn't start successfully (all the > right knobs are there, but sometimes statd fails for unrelated reasons). > Currently rc.d/lockd has this: > if ! checkyesno rpcbind_enable && \ > ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 > then > force_depend rpcbind || ret=1 > fi > which seems to be going the right direction, but a) doesn't include > statd, That part makes sense. The lockd depends on statd and cannot work without it. > and b) the test for "is it running?" is conditional on it not > being _enable'd, which is counterproductive for a couple of reasons. (I > can elaborate if necessary, but hopefully it's obvious?) So I'd like to > propose removing the _enable check from all the relevant scripts that > have this force_depend capability. For users who already have _enable > for these services it will cause one extra call to forcestatus for them, > but given that rc.d currently has no other way to ensure that required > dependencies are running, I think it's worth it. This was discussed in August 2011 but no patch was committed. See http://lists.freebsd.org/pipermail/freebsd-rc/2011-August/002412.html The existing code makes a lot of sense for the case [ -n "${rc_fast}" ] (avoiding unnecessary slow checks for processes at boot) but may be less convenient for starting such services manually. The patch appears to fix the manual start case without slowing down boot, unlike bluntly removing checkyesno which will slow down boot. > The other thing about the status quo is the fact that statd and lockd > check that either nfs_server or nfs_client is _enable'd before they run > start or stop. This was added almost 5 years ago by mtm, but it creates > a variety of problems, not the least of which is that it prevents users > from using forcestart or onestart to start these services. Worse is the > stop_precmd that also checks these knobs before proceeding. That makes sense. > The attached patch does the following: > 1. Makes force_depend conditional only on the forcestatus checks for the > relevant services, as described above. > 2. Removes the tests for nfs_{client|server}_enable from lockd and > statd, described above. > 3. Adds a check that statd is running to rc.d/lockd > 4. Simplifies/standardizes various elements of the shell syntax. If you're touching the code anyway, it would make sense to change 1>/dev/null to >/dev/null. > Index: mountd > =================================================================== > --- mountd (revision 231185) > +++ mountd (working copy) > [snip] > @@ -49,7 +47,6 @@ > > rm -f /var/db/mountdtab > ( umask 022 ; > /var/db/mountdtab ) > - return 0 > } > > load_rc_config $name Note that this changes the return value of mountd_precmd if /var/db/mountdtab cannot be created. Is this deliberate? -- Jilles Tjoelker From owner-freebsd-rc@FreeBSD.ORG Wed Feb 8 23:19:59 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CA359106564A for ; Wed, 8 Feb 2012 23:19:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 21062156F03; Wed, 8 Feb 2012 23:19:58 +0000 (UTC) Message-ID: <4F33031E.7000507@FreeBSD.org> Date: Wed, 08 Feb 2012 15:19:58 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Jilles Tjoelker References: <4F322437.5030100@FreeBSD.org> <20120208230852.GA83950@stack.nl> In-Reply-To: <20120208230852.GA83950@stack.nl> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org Subject: Re: Bringing sanity to the RPC/NFS related scripts 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: Wed, 08 Feb 2012 23:19:59 -0000 Thanks for the review, comments below, with snipping. On 02/08/2012 15:08, Jilles Tjoelker wrote: > On Tue, Feb 07, 2012 at 11:28:55PM -0800, Doug Barton wrote: >> and b) the test for "is it running?" is conditional on it not >> being _enable'd, which is counterproductive for a couple of reasons. (I >> can elaborate if necessary, but hopefully it's obvious?) So I'd like to >> propose removing the _enable check from all the relevant scripts that >> have this force_depend capability. For users who already have _enable >> for these services it will cause one extra call to forcestatus for them, >> but given that rc.d currently has no other way to ensure that required >> dependencies are running, I think it's worth it. > > This was discussed in August 2011 but no patch was committed. See > http://lists.freebsd.org/pipermail/freebsd-rc/2011-August/002412.html > > The existing code makes a lot of sense for the case [ -n "${rc_fast}" ] > (avoiding unnecessary slow checks for processes at boot) but may be less > convenient for starting such services manually. The patch appears to fix > the manual start case without slowing down boot, unlike bluntly removing > checkyesno which will slow down boot. I understand the motivation not to slow down the boot, however the problems we're seeing with "random" statd failures are at boot time. So perhaps the right answer is to include the fast_depend idea but with an override to always do the check. Also, I've only taken a cursory glance at the patch (I'll have more time to review it later) but it seems to me that rather than introducing a new function it would be better to have force_depend test for $rc_fast (and it could then also test for the override knob I'd like to add). Any objections to that? > If you're touching the code anyway, it would make sense to change > 1>/dev/null to >/dev/null. Agreed, that one slipped by when I was folding the lines, thanks for catching it. >> Index: mountd >> =================================================================== >> --- mountd (revision 231185) >> +++ mountd (working copy) >> [snip] >> @@ -49,7 +47,6 @@ >> >> rm -f /var/db/mountdtab >> ( umask 022 ; > /var/db/mountdtab ) >> - return 0 >> } >> >> load_rc_config $name > > Note that this changes the return value of mountd_precmd if > /var/db/mountdtab cannot be created. Is this deliberate? Yes, since mountd relies on that. Do you think it's overkill? Perhaps it would be better to add an '|| err ...' to explain the failure? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Fri Feb 10 11:03:59 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 19D0A106564A; Fri, 10 Feb 2012 11:03:59 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id A2CAE8FC14; Fri, 10 Feb 2012 11:03:58 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id B864F1DEABA; Fri, 10 Feb 2012 12:03:56 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 943BA28468; Fri, 10 Feb 2012 12:03:56 +0100 (CET) Date: Fri, 10 Feb 2012 12:03:56 +0100 From: Jilles Tjoelker To: Doug Barton Message-ID: <20120210110356.GA6723@stack.nl> References: <4F322437.5030100@FreeBSD.org> <20120208230852.GA83950@stack.nl> <4F33031E.7000507@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F33031E.7000507@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-rc@FreeBSD.org Subject: Re: Bringing sanity to the RPC/NFS related scripts 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: Fri, 10 Feb 2012 11:03:59 -0000 On Wed, Feb 08, 2012 at 03:19:58PM -0800, Doug Barton wrote: > Thanks for the review, comments below, with snipping. > On 02/08/2012 15:08, Jilles Tjoelker wrote: > > On Tue, Feb 07, 2012 at 11:28:55PM -0800, Doug Barton wrote: > >> and b) the test for "is it running?" is conditional on it not > >> being _enable'd, which is counterproductive for a couple of reasons. (I > >> can elaborate if necessary, but hopefully it's obvious?) So I'd like to > >> propose removing the _enable check from all the relevant scripts that > >> have this force_depend capability. For users who already have _enable > >> for these services it will cause one extra call to forcestatus for them, > >> but given that rc.d currently has no other way to ensure that required > >> dependencies are running, I think it's worth it. > > This was discussed in August 2011 but no patch was committed. See > > http://lists.freebsd.org/pipermail/freebsd-rc/2011-August/002412.html > > The existing code makes a lot of sense for the case [ -n "${rc_fast}" ] > > (avoiding unnecessary slow checks for processes at boot) but may be less > > convenient for starting such services manually. The patch appears to fix > > the manual start case without slowing down boot, unlike bluntly removing > > checkyesno which will slow down boot. > I understand the motivation not to slow down the boot, however the > problems we're seeing with "random" statd failures are at boot time. So > perhaps the right answer is to include the fast_depend idea but with an > override to always do the check. Hmm, so statd sometimes does not feel like starting the first time, but is willing the second time? That would be a bug that should not be worked around with that extra check. > Also, I've only taken a cursory glance at the patch (I'll have more time > to review it later) but it seems to me that rather than introducing a > new function it would be better to have force_depend test for $rc_fast > (and it could then also test for the override knob I'd like to add). Any > objections to that? No objection. > >> Index: mountd > >> =================================================================== > >> --- mountd (revision 231185) > >> +++ mountd (working copy) > >> [snip] > >> @@ -49,7 +47,6 @@ > >> > >> rm -f /var/db/mountdtab > >> ( umask 022 ; > /var/db/mountdtab ) > >> - return 0 > >> } > >> > >> load_rc_config $name > > Note that this changes the return value of mountd_precmd if > > /var/db/mountdtab cannot be created. Is this deliberate? > Yes, since mountd relies on that. Do you think it's overkill? Perhaps it > would be better to add an '|| err ...' to explain the failure? That's probably safer, since a subsequent modification may not take into account that the redirection is deliberately last. If this change is conscious, that's fine. -- Jilles Tjoelker From owner-freebsd-rc@FreeBSD.ORG Fri Feb 10 23:42:39 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 981A9106567C for ; Fri, 10 Feb 2012 23:42:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1443BB4462; Fri, 10 Feb 2012 23:41:55 +0000 (UTC) Message-ID: <4F35AB43.9020704@FreeBSD.org> Date: Fri, 10 Feb 2012 15:41:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Jilles Tjoelker References: <4F322437.5030100@FreeBSD.org> <20120208230852.GA83950@stack.nl> <4F33031E.7000507@FreeBSD.org> <20120210110356.GA6723@stack.nl> In-Reply-To: <20120210110356.GA6723@stack.nl> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org Subject: Re: Bringing sanity to the RPC/NFS related scripts 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: Fri, 10 Feb 2012 23:42:39 -0000 On 02/10/2012 03:03, Jilles Tjoelker wrote: > Hmm, so statd sometimes does not feel like starting the first time, but > is willing the second time? That would be a bug that should not be > worked around with that extra check. It seems to be related to the first random port that statd chooses being in use, and statd not being very smart about recovering from that. (And yes, I know about the -p option .... not really the point.) I'd like to be able to thoroughly test that all required services are running when the next thing on the list is starting. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Sat Feb 11 02:00:21 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 77CED106564A; Sat, 11 Feb 2012 02:00:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B3F4D14D86F; Sat, 11 Feb 2012 02:00:20 +0000 (UTC) Message-ID: <4F35CBB3.2040501@FreeBSD.org> Date: Fri, 10 Feb 2012 18:00:19 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Hiroki Sato References: <4F2F442F.3030509@erdgeist.org> <20120207.064701.1809281571072237708.hrs@allbsd.org> <4F304F54.4020802@FreeBSD.org> <20120207.072925.1861639312875773760.hrs@allbsd.org> In-Reply-To: <20120207.072925.1861639312875773760.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4B9430026FBF171FCB60DC28" 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: Sat, 11 Feb 2012 02:00:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B9430026FBF171FCB60DC28 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/06/2012 14:29, Hiroki Sato wrote: > Doug Barton wrote > in <4F304F54.4020802@FreeBSD.org>: >=20 > do> On 02/06/2012 13:47, Hiroki Sato wrote: > do> > It actually depends on the newline > do> > do> That's way too fragile, as users are likely to put them all in one = line > do> since shell syntax doesn't differentiate (assuming non-wacky values= of IFS). >=20 > I don't think so. In this syntax a newline character is a separator > distinguished from normal white spaces by read statement. >=20 > do> > echo "$foo" | while read L; do echo $L; done Ok, I was looking only at what you wrote in your last message, I forgot what you're trying to accomplish. Having thought more about this I still think that using rc.conf variables for this is too fragile. Rather than introducing a new format for rc.conf stuff what do you think about putting the new mechanism in its own file? That way you can still use while/read to easily suck in the free-form configuration stuff without creating something new for rc.conf itself. I'm thinking something along the lines of a default name of /etc/ifconfig.$if, and the network.subr bits could do something like this= : if [ -n "$ifconfig_$IF" ]; then elif [ -s "/etc/ifconfig.$IF" ]; then while read line ... fi You can add refinements such as if ifconfig_$IF contains a path name that you use that file instead. Doug --=20 It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------enig4B9430026FBF171FCB60DC28 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPNcuzAAoJEFzGhvEaGryEgZwH/AuktusEmp/4qi7QAUCXSA8L gamwZi9r2tJuhFkaOYR27s4ExRvtl/KyOOX2LiJ2Snr0HLbgFT54f9ugDOf+8Z0R l0rSKWzGansmuyM2WIlstG90IrsWztD71szJWeIRiMEApHtpfkLy4nkItObDpVvR V6zyKtyrqDNQCfZd1+3N6JutAge+rKo+BrdOF8wSLYhnDfWQrVizgKjoTZxPB4dP 78ztZfWPNoXG0gHRBD5erIw3uo9EbuZGM4jTwof2ui0KehOVDiv3cL4g63VMhuk7 o52D2YQn0muji03FAaISF+j8VmLEVdl/HfBLs8+HJi4ObEOPW6YeGX1zxkCsiVU= =zC1s -----END PGP SIGNATURE----- --------------enig4B9430026FBF171FCB60DC28-- From owner-freebsd-rc@FreeBSD.ORG Sat Feb 11 09:38:22 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E6D4B1065670 for ; Sat, 11 Feb 2012 09:38:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0719314E475; Sat, 11 Feb 2012 09:38:21 +0000 (UTC) Message-ID: <4F36370D.7@FreeBSD.org> Date: Sat, 11 Feb 2012 01:38:21 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Jilles Tjoelker References: <4F322437.5030100@FreeBSD.org> <20120208230852.GA83950@stack.nl> <4F33031E.7000507@FreeBSD.org> <20120210110356.GA6723@stack.nl> In-Reply-To: <20120210110356.GA6723@stack.nl> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------030303010403040105070906" Cc: Xin LI , freebsd-rc@FreeBSD.org Subject: Re: Bringing sanity to the RPC/NFS related scripts 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: Sat, 11 Feb 2012 09:38:23 -0000 This is a multi-part message in MIME format. --------------030303010403040105070906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm copying delphij since this is in part related to the patch he posted back in August. I had a chance to review that in detail (thanks Jilles for the pointer) and I agree that his approach is the right one, it just doesn't go far enough. :) The attached patch encompasses his work (with modifications as described below), my previous patch, the idea I had for the always_force_depends knob, and the change requested by Jilles. I also sorted the first few vars in the yp* scripts ... they were in various weird orders, with the problem being that rcvar was often set after load_rc_config. The idea of putting the logic for testing whether or not the service is enabled and the forcestatus bit into a function is definitely the right way to go. delphij's original patch cut out a lot of code from the rc.d scripts, and this patch cuts out even more. Hopefully making force_depend both more useful and easier to use will encourage more use of it. I did take one slightly different choice with the syntax for overloading force_depend .... rather than having to feed it the full rcvar (like foo_bar_enable) I changed it to leave off the _enable bit in the argument since it's redundant to include it every time. Doug On 02/10/2012 03:03, Jilles Tjoelker wrote: > On Wed, Feb 08, 2012 at 03:19:58PM -0800, Doug Barton wrote: >> Thanks for the review, comments below, with snipping. > >> On 02/08/2012 15:08, Jilles Tjoelker wrote: >>> On Tue, Feb 07, 2012 at 11:28:55PM -0800, Doug Barton wrote: > >>>> and b) the test for "is it running?" is conditional on it not >>>> being _enable'd, which is counterproductive for a couple of reasons. (I >>>> can elaborate if necessary, but hopefully it's obvious?) So I'd like to >>>> propose removing the _enable check from all the relevant scripts that >>>> have this force_depend capability. For users who already have _enable >>>> for these services it will cause one extra call to forcestatus for them, >>>> but given that rc.d currently has no other way to ensure that required >>>> dependencies are running, I think it's worth it. > >>> This was discussed in August 2011 but no patch was committed. See >>> http://lists.freebsd.org/pipermail/freebsd-rc/2011-August/002412.html > >>> The existing code makes a lot of sense for the case [ -n "${rc_fast}" ] >>> (avoiding unnecessary slow checks for processes at boot) but may be less >>> convenient for starting such services manually. The patch appears to fix >>> the manual start case without slowing down boot, unlike bluntly removing >>> checkyesno which will slow down boot. > >> I understand the motivation not to slow down the boot, however the >> problems we're seeing with "random" statd failures are at boot time. So >> perhaps the right answer is to include the fast_depend idea but with an >> override to always do the check. > > Hmm, so statd sometimes does not feel like starting the first time, but > is willing the second time? That would be a bug that should not be > worked around with that extra check. > >> Also, I've only taken a cursory glance at the patch (I'll have more time >> to review it later) but it seems to me that rather than introducing a >> new function it would be better to have force_depend test for $rc_fast >> (and it could then also test for the override knob I'd like to add). Any >> objections to that? > > No objection. > >>>> Index: mountd >>>> =================================================================== >>>> --- mountd (revision 231185) >>>> +++ mountd (working copy) >>>> [snip] >>>> @@ -49,7 +47,6 @@ >>>> >>>> rm -f /var/db/mountdtab >>>> ( umask 022 ; > /var/db/mountdtab ) >>>> - return 0 >>>> } >>>> >>>> load_rc_config $name > >>> Note that this changes the return value of mountd_precmd if >>> /var/db/mountdtab cannot be created. Is this deliberate? > >> Yes, since mountd relies on that. Do you think it's overkill? Perhaps it >> would be better to add an '|| err ...' to explain the failure? > > That's probably safer, since a subsequent modification may not take into > account that the redirection is deliberately last. > > If this change is conscious, that's fine. > -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------030303010403040105070906 Content-Type: text/plain; name="etc-rpc-nfs.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="etc-rpc-nfs.diff" Index: share/man/man5/rc.conf.5 =================================================================== --- share/man/man5/rc.conf.5 (revision 231503) +++ share/man/man5/rc.conf.5 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 8, 2012 +.Dd February 11, 2012 .Dt RC.CONF 5 .Os .Sh NAME @@ -149,6 +149,19 @@ adequate provisions to recover from a failed boot (such as physical contact with the machine, or reliable remote console access). +.It Va always_force_depends +.Pq Vt bool +Various +.Pa rc.d +scripts use the force_depend function to check whether required +services are already running, and to start them if necessary. +By default during boot time this check is bypassed if the +required service is enabled in +.Pa /etc/rc.conf[.local] . +Setting this option will bypass that check at boot time and +always test whether or not the service is actually running. +Enabling this option is likely to increase your boot time if +services are enabled that utilize the force_depend check. .It Va swapfile .Pq Vt str If set to Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 231503) +++ etc/defaults/rc.conf (working copy) @@ -29,6 +29,8 @@ # stages of the boot process. Make sure you know # the ramifications if you change this. # See rc.conf(5) for more details. +always_force_depends="NO" # Set to check that indicated dependencies are + # running during boot (can increase boot time). swapfile="NO" # Set to name of swapfile if aux swapfile desired. apm_enable="NO" # Set to YES to enable APM BIOS functions (or NO). Index: etc/rc.d/ypset =================================================================== --- etc/rc.d/ypset (revision 231503) +++ etc/rc.d/ypset (working copy) @@ -11,25 +11,20 @@ name="ypset" rcvar="nis_ypset_enable" + +load_rc_config $name + command="/usr/sbin/${name}" -start_precmd="ypset_precmd" -load_rc_config $name command_args="${nis_ypset_flags}" +start_precmd="ypset_precmd" + ypset_precmd() { local _domain - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi - if ! checkyesno nis_client_enable && \ - ! /etc/rc.d/ypbind forcestatus 1>/dev/null 2>&1 - then - force_depend ypbind || return 1 - fi + force_depend rpcbind || return 1 + force_depend ypbind nis_client || return 1 _domain=`domainname` if [ -z "$_domain" ]; then Index: etc/rc.d/mountd =================================================================== --- etc/rc.d/mountd (revision 231503) +++ etc/rc.d/mountd (working copy) @@ -19,11 +19,7 @@ mountd_precmd() { - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi + force_depend rpcbind || return 1 # mountd flags will differ depending on rc.conf settings # @@ -48,8 +44,8 @@ fi rm -f /var/db/mountdtab - ( umask 022 ; > /var/db/mountdtab ) - return 0 + ( umask 022 ; > /var/db/mountdtab ) || + err 1 'Cannot create /var/db/mountdtab' } load_rc_config $name Index: etc/rc.d/yppasswdd =================================================================== --- etc/rc.d/yppasswdd (revision 231503) +++ etc/rc.d/yppasswdd (working copy) @@ -11,27 +11,22 @@ . /etc/rc.subr name="yppasswdd" -command="/usr/sbin/rpc.${name}" -start_precmd="yppasswdd_precmd" +rcvar="nis_yppasswdd_enable" load_rc_config $name -rcvar="nis_yppasswdd_enable" + +command="/usr/sbin/rpc.${name}" command_args="${nis_yppasswdd_flags}" +start_precmd="yppasswdd_precmd" + yppasswdd_precmd() { local _domain - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi - if ! checkyesno nis_server_enable && \ - ! /etc/rc.d/ypserv forcestatus 1>/dev/null 2>&1 - then - force_depend ypserv || return 1 - fi + force_depend rpcbind || return 1 + force_depend ypserv nis_server || return 1 + _domain=`domainname` if [ -z "$_domain" ]; then warn "NIS domainname(1) is not set." Index: etc/rc.d/ypupdated =================================================================== --- etc/rc.d/ypupdated (revision 231503) +++ etc/rc.d/ypupdated (working copy) @@ -11,6 +11,9 @@ name="ypupdated" rcvar="rpc_ypupdated_enable" + +load_rc_config $name + command="/usr/sbin/rpc.${name}" start_precmd="rpc_ypupdated_precmd" @@ -18,16 +21,8 @@ { local _domain - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi - if ! checkyesno nis_server_enable && \ - ! /etc/rc.d/ypserv forcestatus 1>/dev/null 2>&1 - then - force_depend ypserv || return 1 - fi + force_depend rpcbind || return 1 + force_depend ypserv nis_server || return 1 _domain=`domainname` if [ -z "$_domain" ]; then @@ -36,5 +31,4 @@ fi } -load_rc_config $name run_rc_command "$1" Index: etc/rc.d/nfsd =================================================================== --- etc/rc.d/nfsd (revision 231503) +++ etc/rc.d/nfsd (working copy) @@ -48,31 +48,15 @@ if checkyesno nfsv4_server_enable; then sysctl vfs.nfsd.server_max_nfsvers=4 > /dev/null - if ! checkyesno nfsuserd_enable && \ - ! /etc/rc.d/nfsuserd forcestatus 1>/dev/null 2>&1 - then - if ! force_depend nfsuserd; then - err 1 "Cannot run nfsuserd" - fi - fi + force_depend nfsuserd || err 1 "Cannot run nfsuserd" else echo 'NFSv4 is disabled' sysctl vfs.nfsd.server_max_nfsvers=3 > /dev/null fi fi - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi - - if ! checkyesno mountd_enable && \ - ! /etc/rc.d/mountd forcestatus 1>/dev/null 2>&1 - then - force_depend mountd || return 1 - fi - return 0 + force_depend rpcbind || return 1 + force_depend mountd || return 1 } run_rc_command "$1" Index: etc/rc.d/ypbind =================================================================== --- etc/rc.d/ypbind (revision 231503) +++ etc/rc.d/ypbind (working copy) @@ -11,22 +11,20 @@ . /etc/rc.subr name="ypbind" -command="/usr/sbin/${name}" -start_precmd="ypbind_precmd" +rcvar="nis_client_enable" load_rc_config $name -rcvar="nis_client_enable" + +command="/usr/sbin/${name}" command_args="${nis_client_flags}" +start_precmd="ypbind_precmd" + ypbind_precmd() { local _domain - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi + force_depend rpcbind || return 1 _domain=`domainname` if [ -z "$_domain" ]; then Index: etc/rc.d/ypserv =================================================================== --- etc/rc.d/ypserv (revision 231503) +++ etc/rc.d/ypserv (working copy) @@ -11,21 +11,20 @@ name="ypserv" rcvar="nis_server_enable" -command="/usr/sbin/${name}" -start_precmd="ypserv_prestart" load_rc_config $name + +command="/usr/sbin/${name}" command_args="${nis_server_flags}" +start_precmd="ypserv_prestart" + ypserv_prestart() { local _domain - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi + force_depend rpcbind || return 1 + _domain=`domainname` if [ -z "$_domain" ]; then warn "NIS domainname(1) is not set." Index: etc/rc.d/ypxfrd =================================================================== --- etc/rc.d/ypxfrd (revision 231503) +++ etc/rc.d/ypxfrd (working copy) @@ -11,25 +11,20 @@ name="ypxfrd" rcvar="nis_ypxfrd_enable" + +load_rc_config $name + command="/usr/sbin/rpc.${name}" -start_precmd="ypxfrd_precmd" -load_rc_config $name command_args="${nis_ypxfrd_flags}" +start_precmd="ypxfrd_precmd" + ypxfrd_precmd() { local _domain - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi - if ! checkyesno nis_server_enable && \ - ! /etc/rc.d/ypserv forcestatus 1>/dev/null 2>&1 - then - force_depend ypserv || return 1 - fi + force_depend rpcbind || return 1 + force_depend ypserv nis_server || return 1 _domain=`domainname` if [ -z "$_domain" ]; then Index: etc/rc.d/amd =================================================================== --- etc/rc.d/amd (revision 231503) +++ etc/rc.d/amd (working copy) @@ -19,16 +19,9 @@ amd_precmd() { - if ! checkyesno nfs_client_enable; then - force_depend nfsclient || return 1 - fi + force_depend nfsclient nfs_client || return 1 + force_depend rpcbind || return 1 - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi - case ${amd_map_program} in [Nn][Oo] | '') ;; @@ -49,7 +42,6 @@ command_args="> /var/run/amd.pid 2> /dev/null" ;; esac - return 0 } load_rc_config $name Index: etc/rc.d/keyserv =================================================================== --- etc/rc.d/keyserv (revision 231503) +++ etc/rc.d/keyserv (working copy) @@ -19,13 +19,7 @@ keyserv_prestart() { - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || return 1 - fi - - return 0 + force_depend rpcbind || return 1 } load_rc_config $name Index: etc/rc.d/apmd =================================================================== --- etc/rc.d/apmd (revision 231503) +++ etc/rc.d/apmd (working copy) @@ -19,24 +19,18 @@ { case `${SYSCTL_N} hw.machine_arch` in i386) - # Enable apm if it is not already enabled - if ! checkyesno apm_enable && \ - ! /etc/rc.d/apm forcestatus 1>/dev/null 2>&1 - then - force_depend apm || return 1 - fi + force_depend apm || return 1 # Warn user about acpi apm compatibility support which # does not work with apmd. if [ ! -e /dev/apmctl ]; then - warn "/dev/apmctl not found; kernel is missing apm(4)" + warn "/dev/apmctl not found; kernel is missing apm(4)" fi ;; *) return 1 ;; esac - return 0 } load_rc_config $name Index: etc/rc.d/lockd =================================================================== --- etc/rc.d/lockd (revision 231503) +++ etc/rc.d/lockd (working copy) @@ -15,28 +15,16 @@ rcvar=rpc_lockd_enable command="/usr/sbin/rpc.${name}" start_precmd='lockd_precmd' -stop_precmd='checkyesno nfs_server_enable || checkyesno nfs_client_enable' -status_precmd=$stop_precmd # Make sure that we are either an NFS client or server, and that we get # the correct flags from rc.conf(5). # lockd_precmd() { - local ret - ret=0 - - if ! checkyesno nfs_server_enable && ! checkyesno nfs_client_enable - then - ret=1 - fi - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || ret=1 - fi + force_depend rpcbind || return 1 + force_depend statd rpc_statd || return 1 + rc_flags=${rpc_lockd_flags} - return ${ret} } load_rc_config $name Index: etc/rc.d/statd =================================================================== --- etc/rc.d/statd (revision 231503) +++ etc/rc.d/statd (working copy) @@ -15,28 +15,15 @@ rcvar=rpc_statd_enable command="/usr/sbin/rpc.${name}" start_precmd='statd_precmd' -stop_precmd='checkyesno nfs_server_enable || checkyesno nfs_client_enable' -status_precmd=$stop_precmd # Make sure that we are either an NFS client or server, and that we get # the correct flags from rc.conf(5). # statd_precmd() { - local ret - ret=0 - - if ! checkyesno nfs_server_enable && ! checkyesno nfs_client_enable - then - ret=1 - fi - if ! checkyesno rpcbind_enable && \ - ! /etc/rc.d/rpcbind forcestatus 1>/dev/null 2>&1 - then - force_depend rpcbind || ret=1 - fi + force_depend rpcbind || return 1 + rc_flags=${rpc_statd_flags} - return ${ret} } load_rc_config $name Index: etc/rc.subr =================================================================== --- etc/rc.subr (revision 231503) +++ etc/rc.subr (working copy) @@ -71,22 +71,29 @@ } # -# force_depend script +# force_depend script [rcvar] # Force a service to start. Intended for use by services -# to resolve dependency issues. It is assumed the caller -# has check to make sure this call is necessary +# to resolve dependency issues. # $1 - filename of script, in /etc/rc.d, to run +# $2 - name of the script's rcvar (minus the _enable) # force_depend() { + local _depend _dep_rcvar + _depend="$1" + _dep_rcvar="${2:-$1}_enable" + [ -n "$rc_fast" ] && ! checkyesno always_force_depends && + checkyesno $_dep_rcvar && return 0 + + /etc/rc.d/${_depend} forcestatus >/dev/null 2>&1 && return 0 + info "${name} depends on ${_depend}, which will be forced to start." if ! /etc/rc.d/${_depend} forcestart; then warn "Unable to force ${_depend}. It may already be running." return 1 fi - return 0 } # --------------030303010403040105070906-- From owner-freebsd-rc@FreeBSD.ORG Sat Feb 11 19:51:25 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 3EE14106564A for ; Sat, 11 Feb 2012 19:51:25 +0000 (UTC) (envelope-from jpaetzel@freebsd.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 0155A8FC08 for ; Sat, 11 Feb 2012 19:51:24 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 805D120AA4 for ; Sat, 11 Feb 2012 14:32:59 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Sat, 11 Feb 2012 14:32:59 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type; s=smtpout; bh=AIFe DRlCfCERJL03R4ut0EGhVGE=; b=YbQHgba1aSC0+nDAs8QIg0QREH+3UKanb0F+ gPo71Rcyz8ROx+LKN0yvoiTE/5HnRCQgSOOZPiUDiitLUrSpq0+KlkgTRRj/zenS BRNLb2s3wsjJibcgtS5L30RJmcBW2v6R8b7+5wiQRZHebD+s/YsNYyh4U2OSdLq7 1Iskm94= X-Sasl-enc: /Bu8vGZY7yZYOJQ+KYsDsypZjc9bjRPD0mVIkExoxxdI 1328988778 Received: from roadrash.tcbug.org (unknown [216.139.7.151]) by mail.messagingengine.com (Postfix) with ESMTPSA id A1E7B8E00D9; Sat, 11 Feb 2012 14:32:58 -0500 (EST) Message-ID: <4F36C269.9060201@freebsd.org> Date: Sat, 11 Feb 2012 11:32:57 -0800 From: Josh Paetzel Organization: FreeBSS User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Jilles Tjoelker References: <4E0E1CFA.1080904@freebsd.org> <20110701205529.GA93981@stack.nl> In-Reply-To: <20110701205529.GA93981@stack.nl> X-Enigmail-Version: undefined Content-Type: multipart/mixed; boundary="------------030106020900080405000307" Cc: freebsd-rc@freebsd.org Subject: Re: Fwd: Commit approval requested 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: Sat, 11 Feb 2012 19:51:25 -0000 This is a multi-part message in MIME format. --------------030106020900080405000307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/01/2011 13:55, Jilles Tjoelker wrote: > On Fri, Jul 01, 2011 at 02:16:10PM -0500, Josh Paezel wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 > >> This patch is in production at an organization which uses both single >> and multiple pflog devices on a range of devices. (eg: it doesn't break >> current configurations) > >> It allows multiple pflog devices as well as multiple ftp-proxy instances. > >> The patch was submitted as a PR conf/158181 > >> I've applied the patch to a HEAD svn co and regenerated the patch with >> svn diff from that. > > Comments are inline. Note that I have not tested the patch nor any > proposed changes. > I have applied the changes suggested and am pinging the submitter to give it a try, just mailing it here for a review as well to catch any glaring issues I've caused or missed. -- Thanks, Josh Paetzel FreeBSD -- The power to serve --------------030106020900080405000307 Content-Type: text/plain; name="pflog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pflog.txt" Index: share/man/man5/rc.conf.5 =================================================================== --- share/man/man5/rc.conf.5 (revision 231526) +++ share/man/man5/rc.conf.5 (working copy) @@ -880,6 +880,33 @@ This variable contains additional flags passed to the .Xr pflogd 8 program. +.It Va pflog_instances +.Pq Vt str +If logging to more than one +.Xr pflog 4 +interface is desired, +.Va pflog_instances +is set to the list of +.Xr pflogd 8 +instances that should be started at system boot time. If +.Va pflog_instances +is set, for each whitespace-separated +.Ar element +in the list, +.Ao Ar element Ac Ns Va _dev +and +.Ao Ar element Ac Ns Va _logfile +elements are assumed to exist. +.Ao Ar element Ac Ns Va _dev +must contain the +.Xr pflog 4 +interface to be watched by the named +.Xr pflogd 8 +instance. +.Ao Ar element Ac Ns Va _logfile +must contain the name of the logfile that will be used by the +.Xr pflogd 8 +instance. .It Va ftpproxy_enable .Pq Vt bool Set to @@ -898,6 +925,19 @@ This variable contains additional flags passed to the .Xr ftp-proxy 8 program. +.It Va ftpproxy_instances +.Pq Vt str +Empty by default. If multiple instances of +.Xr ftp-proxy 8 +are desired at boot time, +.Va ftpproxy_instances +should contain a whitespace-seperated list of instance names. For each +.Ar element +in the list, a variable named +.Ao Ar element Ac Ns Va _flags +should be defined, containing the command-line flags to be passed to the +.Xr ftp-proxy 8 +instance. .It Va pfsync_enable .Pq Vt bool Set to Index: etc/rc.d/ftp-proxy =================================================================== --- etc/rc.d/ftp-proxy (revision 231526) +++ etc/rc.d/ftp-proxy (working copy) @@ -12,6 +12,66 @@ name="ftpproxy" rcvar="ftpproxy_enable" command="/usr/sbin/ftp-proxy" +start_postcmd="ftp_proxy_poststart" +stop_postcmd="ftp_proxy_poststop" load_rc_config $name -run_rc_command "$1" + +ftp_proxy_poststart() { + local ps_pid + cmd_string=${procname:-${command}} + cmd_string=${cmd_string##*/} + eval flag_string=\"\$${name}_flags\" + # Determine the pid. + ps_pid=$(pgrep -f "$cmd_string.*$flag_string") + # Write the pidfile depending on $pidfile status. + echo $ps_pid > ${pidfile:-"/var/run/$name.pid"} +} + +ftp_proxy_poststop() { + rm ${pidfile:-"/var/run/$name.pid"} +} + +# Allow ftp-proxy to start up in two different ways. The typical behavior +# is to start up one instance of ftp-proxy by setting ftpproxy_enable and +# ftpproxy_flags. The alternate behavior allows multiple instances of ftp- +# proxy to be started, allowing different types of proxy behavior. To use the +# new behavior, a list of instances must be defined, and a list of flags for +# each instance. For example, if we want to start two instances of ftp-proxy, +# foo and bar, we would set the following vars. +# ftpproxy_enable="YES" +# ftpproxy_instances="foo bar" +# ftpproxy_foo="" +# ftpproxy_bar="" +# +# Starting more than one ftp-proxy? +if [ -n "${ftpproxy_instances}" ]; then + # Iterate through instance list. + for i in $ftpproxy_instances; do + # Set flags for this instance. + eval ftpproxy_flags=\$ftpproxy_${i} + # Define a unique pid file name. + pidfile="/var/run/ftp-proxy.$i.pid" + run_rc_command "$1" + ftp_proxy_poststart + done +else + # Traditional single-instance behavior + run_rc_command "$1" +fi + +# Stopping more than one ftp-proxy? +if [ -n "${ftpproxy_instances}" ]; then + # Iterate through instance list. + for i in $ftpproxy_instances; do + # Set flags for this instance. + eval ftpproxy_flags=\$ftpproxy_${i} + # Define a unique pid file name. + pidfile="/var/run/ftp-proxy.$i.pid" + run_rc_command "$1" + ftp_proxy_poststop + done +else + # Traditional single-instance behavior + run_rc_command "$1" +fi Index: etc/rc.d/pflog =================================================================== --- etc/rc.d/pflog (revision 231526) +++ etc/rc.d/pflog (working copy) @@ -24,25 +24,41 @@ { load_kld pflog || return 1 - # set pflog0 interface to up state - if ! ifconfig pflog0 up; then - warn 'could not bring up pflog0.' + # set pflog_dev interface to up state + if ! ifconfig $pflog_dev up; then + warn "could not bring up $pflog_dev." return 1 fi # prepare the command line for pflogd - rc_flags="-f $pflog_logfile $rc_flags" + rc_flags="-f $pflog_logfile -i $pflog_dev $rc_flags" # report we're ready to run pflogd return 0 } +pflog_poststart() { + # Allow child pflogd to settle + sleep 0.10 + # More elegant(?) method for getting a unique pid + if [ -f /var/run/pflogd.pid ]; then + mv /var/run/pflogd.pid $pidfile + else + warn "/var/run/pflogd.pid does not exist. Too fast." + fi +} + pflog_poststop() { - if ! ifconfig pflog0 down; then - warn 'could not bring down pflog0.' + if ! ifconfig $pflog_dev down; then + warn "could not bring down $pflog_dev." return 1 fi + + if [ -n "$pflog_instances" ]; then + rm $pidfile + fi + return 0 } @@ -53,4 +69,33 @@ } load_rc_config $name -run_rc_command "$1" + +# Check if spawning multiple pflogd +echo "Starting pflogd: $pflog_instances" +if [ -n "$pflog_instances" ]; then + start_postcmd="pflog_poststart" + # Interate through requested instances. + for i in $pflog_instances; do + # Set required variables + eval pflog_dev=\$pflog_${i}_dev + eval pflog_logfile=\$pflog_${i}_logfile + eval pflog_flags=\$pflog_${i}_flags + # Check that required vars have non-zero length, warn if not. + if [ -z "$pflog_dev" ]; then + warn "pflog_dev not set" + continue + fi + if [ -z "$pflog_logfile" ]; then + warn "pflog_logfile not set" + continue + fi + # pflogd sets a pidfile, but the name is hardcoded. Concoct a + # unique pidfile name. + pidfile="/var/run/pflogd.$i.pid" + run_rc_command "$1" + done +else + # Typical case, spawn single instance only. + pflog_dev=${pflog_dev:-"pflog0"} + run_rc_command "$1" +fi --------------030106020900080405000307--