From owner-freebsd-rc@FreeBSD.ORG Sat Jan 4 10:29:14 2014 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86AEB383; Sat, 4 Jan 2014 10:29:14 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4CC7E158B; Sat, 4 Jan 2014 10:29:13 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id s04ATB7N020074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 4 Jan 2014 04:29:12 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Sat, 4 Jan 2014 04:29:11 -0600 From: "Teske, Devin" To: Jason Hellenthal Subject: Re: network.subr _aliasN handling Thread-Topic: network.subr _aliasN handling Thread-Index: AQHPBE3NCNy+IhmEZ0eModIwDB4CDw== Date: Sat, 4 Jan 2014 10:29:10 +0000 Message-ID: <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> In-Reply-To: <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-04_01:2014-01-03,2014-01-04,1970-01-01 signatures=0 Cc: "rc@freebsd.org" , Devin Teske , "net@freebsd.org" X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Devin Teske 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, 04 Jan 2014 10:29:14 -0000 On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: > Alright something is a little off about this from a running standpoint it= did what it is meant to do. >=20 > Bug1: it seems to have looped back over itself reissuing two addresses fr= om the top of the list. >=20 > Test case: > I have aliases 0-14 used numbered as such. > Aliases 0-7 are ipv6 > Aliases 8-14 are ipv4 >=20 > I commented out alias 2 and 6 to break up consecutive order. >=20 > Alias 8 & 9 appeared to have been run after alias 14. >=20 >=20 > Something is awry but I can't quite pick out what it is yet. >=20 Sounds like I need to add some numerical sorting. --=20 Devin >=20 > On Dec 28, 2013, at 23:24, "Teske, Devin" wro= te: >=20 >>=20 >> On Dec 27, 2013, at 9:53 PM, wrote: >>=20 >>> Curious what everyone's opinion would be on modifying the handling of _= aliasN functions or providing a wrapper around it to handle non-sequential = ordering. >>>=20 >>> My goal on this is simple and based around groupings similiar to that o= f the way user id(1)'s in passwd and group are handled or denoted for use o= n modern systems. >>>=20 >>> I.e.: I would like to achieve this... >>>=20 >>> *_alias[1-99] =3D System type addresses "Importand addresses or interna= l" >>> *_alias[100-199] =3D Aliases for interface 1 >>> *_alias[200-299] =3D Aliases for interface 2 >>> etc... >>>=20 >>> NOt looking to achieve some sort of prefered naming convention for the = interface aliases, but loosen them so they may be defined by the user in wh= atever means neccesary to their benefit. >>>=20 >>> In a scheme similiar to above I attempted to set an address on every ot= her 4th alias leaving 3 space rule room for insertion of further addresses = but was surprised when the processing of the aliases ceased at the first no= n-sequential space. >>>=20 >>> So why not just grab every _aliasN no matter of what it is for the inte= rface and shove them into an arrary to be processed by a "for" statement ? = the order would still be kept without having to inspect every defintion of = alias and incrementing prehistorically. >>>=20 >>> As well this could provide early loading of the addresses into their re= spective arrays so they may be processed and provided to any other function= s that may need to access them earlier on in script fallthrough. >>>=20 >>> Looking at _alias'N' sequentialy feels like a neucense. >>=20 >> You mean something like the attached? >> --=20 >> Devin >>=20 >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message= and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. >> _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.