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 <[email protected]> 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" <[email protected]> wrote: >> >> >>> On Dec 27, 2013, at 9:53 PM, <[email protected]> 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>
smime.p7s
Description: S/MIME cryptographic signature
