Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Jan 2014 10:29:10 +0000
From:      "Teske, Devin" <Devin.Teske@fisglobal.com>
To:        Jason Hellenthal <jhellenthal@dataix.net>
Cc:        "rc@freebsd.org" <rc@freebsd.org>, Devin Teske <dteske@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com>, "net@freebsd.org" <net@freebsd.org>
Subject:   Re: network.subr _aliasN handling
Message-ID:  <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com>
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

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" <Devin.Teske@fisglobal.com> wro=
te:
>=20
>>=20
>> On Dec 27, 2013, at 9:53 PM, <jhellenthal@dataix.net> 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.
>> <patch.txt>

_____________
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7DBA7D58-E925-47BC-967C-F653348426A6>