Date: Sat, 4 Jan 2014 01:36:24 -0500 From: Jason Hellenthal <jhellenthal@dataix.net> To: Devin Teske <dteske@freebsd.org> Cc: "rc@freebsd.org" <rc@freebsd.org>, Devin Teske <dteske@freebsd.org>, "net@freebsd.org" <net@freebsd.org> Subject: Re: network.subr _aliasN handling Message-ID: <F51E15B7-35E6-4454-BB7D-BB3B022AC7FE@dataix.net> In-Reply-To: <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> References: <20131228055324.GA72764@aim7400.DataIX.local> <A7699871-A170-4AD5-B740-ED8BE17C7107@fisglobal.com> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Also I'm not using ipv6_ifconfig_int0_aliasN syntax vars here on stable/9 Strictly without ipv6_ since the original aliasing with "inet6 . . . " works and leaves for a nice clean list. -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 4, 2014, at 1:28, Jason Hellenthal <jhellenthal@dataix.net> wrote: > > Alright something is a little off about this from a running standpoint it did what it is meant to do. > > Bug1: it seems to have looped back over itself reissuing two addresses from the top of the list. > > Test case: > I have aliases 0-14 used numbered as such. > Aliases 0-7 are ipv6 > Aliases 8-14 are ipv4 > > I commented out alias 2 and 6 to break up consecutive order. > > Alias 8 & 9 appeared to have been run after alias 14. > > > Something is awry but I can't quite pick out what it is yet. > > -- > Jason Hellenthal > Voice: 95.30.17.6/616 > JJH48-ARIN > >> On Dec 28, 2013, at 23:24, "Teske, Devin" <Devin.Teske@fisglobal.com> wrote: >> >> >>> On Dec 27, 2013, at 9:53 PM, <jhellenthal@dataix.net> wrote: >>> >>> 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. >>> >>> My goal on this is simple and based around groupings similiar to that of the way user id(1)'s in passwd and group are handled or denoted for use on modern systems. >>> >>> I.e.: I would like to achieve this... >>> >>> *_alias[1-99] = System type addresses "Importand addresses or internal" >>> *_alias[100-199] = Aliases for interface 1 >>> *_alias[200-299] = Aliases for interface 2 >>> etc... >>> >>> 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 whatever means neccesary to their benefit. >>> >>> In a scheme similiar to above I attempted to set an address on every other 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 non-sequential space. >>> >>> So why not just grab every _aliasN no matter of what it is for the interface 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. >>> >>> As well this could provide early loading of the addresses into their respective arrays so they may be processed and provided to any other functions that may need to access them earlier on in script fallthrough. >>> >>> Looking at _alias'N' sequentialy feels like a neucense. >> >> You mean something like the attached? >> -- >> Devin >> >> _____________ >> The information contained in this message is proprietary and/or confidential. 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 aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. >> <patch.txt> [-- Attachment #2 --] 0 *H 01 0 + 0 *H 90000 *H 01 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 130518085048Z 140519220947Z0H1 0 U jhellenthal@dataix.net1%0# *H jhellenthal@dataix.net0"0 *H 0 '`TmfkܨJ5u +c'Upb`zv)&ȸXZ*VN6JvLoVoh}g pQDŽKf/tZA˳( "4Ԅ˻'d2h| IBl' ^v^;'e8S99ۿVm|k8_UQtC"5l!kjZ]އQGn \Bh!F TsD%pV^Eӑd¨x"9 г" f 00 U 0 0 U 0 U %0++0 U ڔfmVʢ$䟓0 U #0Sr풜\|~5NԸQ0!U 0jhellenthal@dataix.net0LU C0?0; +70*0.+"http://www.startssl.com/policy.pdf0+00' StartCom Certification Authority0This certificate was issued according to the Class 1 Validation requirements of the StartCom CA policy, reliance only for the intended purpose in compliance of the relying party obligations.06U /0-0+)'%http://crl.startssl.com/crtu1-crl.crl0+009+0-http://ocsp.startssl.com/sub/class1/client/ca0B+06http://aia.startssl.com/certs/sub.class1.client.ca.crt0#U 0http://www.startssl.com/0 *H {0Ӹ,52W{Ey8b [ {7 _+P"n["-,@ŽpJ-W$ݍjWA-6z( RdIZ. KzXє[ K6}{s+v.Qh0PͅK hTw 0I73lz*K v4Kkگ63;p1:ױ@)]ok>:W%XwC1þL/o8~#oP040 0 *H 0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0 071024210155Z 171024210155Z01 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0"0 *H 0 -).2AUGo#G B|NDRpM-B=o -we5JQpa>O.#._<V [~**pz~3WG .ᘟMlr[<Ce6fqO"uxfWN#uicgkv$Lb%y`_{`xK'GN 00U 00U 0 U Sr풜\|~5NԸQ0 U #0N @[i04hCA0f+Z0X0'+0http://ocsp.startssl.com/ca0-+0!http://www.startssl.com/sfsca.crt0[U T0R0'%#!http://www.startssl.com/sfsca.crl0'%#!http://crl.startssl.com/sfsca.crl0U y0w0u +70f0.+"http://www.startssl.com/policy.pdf04+(http://www.startssl.com/intermediate.pdf0 *H }x,\c^ #wMq}>UK/^yX֏y frMIŲB61ymQҨݬZ0& ;@#13qۑ& ̢o 6r_;GO>*I( 74XS1r3)!LJy6Kotˆ# _wSr ;B ADp(fs 䰷6%.W0J3:bC<8t X1<Cn=t==wST~\wkBf|15zUP)(IjVB!OfI=bb\4-*em/нSJm7N[]'@ڽ D9Kr>R7/|o^I@ټ'Pa $ z9a'L)( I}vcH]۸D*W} m>Q|C.(,lQ000 *H 0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0 060917194636Z 360917194636Z0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0"0 *H 0 lF|x{3rb6 "$^wC d̎68#nm<r =3+/AYg} tyL7z9RYFC҅qub4, 4ǖR=3M ;JK&/ r5w<]&6v\t%x- 0-ryF*I cSb:̵fkt+v>mDsb ;ľSV%lQ ʿvmۿ=f VH:KߧXP8u[C lMp[)eݪ]̯1 ҍ{n'f HnB?!>{ pclT\%zɢɋ,~^MXn 2n6IHiMi y"H{ipz7 vOW`g:ԋr"Ɵƶ\R<*s `z/ۣn&0݉W=+ŷv+*r3] KtRK R0N0 U 00 U 0 U N @[i04hCA0dU ]0[0,*(&http://cert.startcom.org/sfsca-crl.crl0+)'%http://crl.startcom.org/sfsca-crl.crl0]U T0P0L +70;0/+#http://cert.startcom.org/policy.pdf05+)http://cert.startcom.org/intermediate.pdf0+00' Start Commercial (StartCom) Ltd.0Limited Liability, read the section *Legal Limitations* of the StartCom Certification Authority Policy available at http://cert.startcom.org/policy.pdf0 `HB 08 `HB +)StartCom Free SSL Certification Authority0 *H lf 4Ѕ^} N8 ^ߦ%K2;=D [I)f% <6+Kh9f=&9 Q{~ZWpi^X ߌE8 ^Wbz )n(DÐ8<CMdE(\s{諱.\dns1:}Q;Mf{<Ӛ ePu/CiyCFrd6% 8w~kjDKx, KD4R' ]xS2݀fuٵh(a.8 gd./pǖ|eCTݥ9`4ɖp, H{ ~k";*RKU"4N&",uJ} d6/# ;sIjWxřCcMw-eriG V$ yX. ~m >J9+u U77Cb VKel$$4"}?eQ 0j r^1o0k001 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 + 0 *H 1 *H 0 *H 1 140104063627Z0# *H 1Qhb2 'd/0 +71001 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 *H 101 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 *H 6sK-Bh`iD]iEiϣQKâw~ E([]m9]G<A)1F QfvKƸ`VjD#+tv|KɁtlV zom.mS;'-o*.p{bx t5Zac?vY"N[$D WWV@xyWL)EƒpvKNɫFXVJD \k}vr_qIWJgx*[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F51E15B7-35E6-4454-BB7D-BB3B022AC7FE>