Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Dec 2013 04:24:02 +0000
From:      "Teske, Devin" <Devin.Teske@fisglobal.com>
To:        "<jhellenthal@dataix.net>" <jhellenthal@dataix.net>
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:  <A7699871-A170-4AD5-B740-ED8BE17C7107@fisglobal.com>
In-Reply-To: <20131228055324.GA72764@aim7400.DataIX.local>
References:  <20131228055324.GA72764@aim7400.DataIX.local>

next in thread | previous in thread | raw e-mail | index | archive | help
--_002_A7699871A1704AD5B740ED8BE17C7107fisglobalcom_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <167BE959779B3C469BB3E67480BDED94@fisglobal.com>
Content-Transfer-Encoding: quoted-printable


On Dec 27, 2013, at 9:53 PM, <jhellenthal@dataix.net> wrote:

> Curious what everyone's opinion would be on modifying the handling of _al=
iasN functions or providing a wrapper around it to handle non-sequential or=
dering.
>=20
> 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.
>=20
> I.e.: I would like to achieve this...
>=20
> *_alias[1-99] =3D System type addresses "Importand addresses or internal"
> *_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 in=
terface aliases, but loosen them so they may be defined by the user in what=
ever means neccesary to their benefit.
>=20
> In a scheme similiar to above I attempted to set an address on every othe=
r 4th alias leaving 3 space rule room for insertion of further addresses bu=
t was surprised when the processing of the aliases ceased at the first non-=
sequential space.
>=20
> So why not just grab every _aliasN no matter of what it is for the interf=
ace and shove them into an arrary to be processed by a "for" statement ? th=
e order would still be kept without having to inspect every defintion of al=
ias and incrementing prehistorically.
>=20
> As well this could provide early loading of the addresses into their resp=
ective arrays so they may be processed and provided to any other functions =
that may need to access them earlier on in script fallthrough.
>=20
> Looking at _alias'N' sequentialy feels like a neucense.

You mean something like the attached?
--=20
Devin

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

--_002_A7699871A1704AD5B740ED8BE17C7107fisglobalcom_
Content-Type: text/plain; name="patch.txt"
Content-Description: patch.txt
Content-Disposition: attachment; filename="patch.txt"; size=1783;
	creation-date="Sun, 29 Dec 2013 04:24:02 GMT";
	modification-date="Sun, 29 Dec 2013 04:24:02 GMT"
Content-ID: <BEC97A2C0A13D34486AB9B0D64A1007E@fisglobal.com>
Content-Transfer-Encoding: base64

SW5kZXg6IGV0Yy9uZXR3b3JrLnN1YnINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBldGMvbmV0d29yay5zdWJy
CShyZXZpc2lvbiAyNTU3MTIpDQorKysgZXRjL25ldHdvcmsuc3Vicgkod29ya2luZyBjb3B5KQ0K
QEAgLTEwMjcsOSArMTAyNyw4IEBAIGlmYWxpYXNfYWZfY29tbW9uKCkNCiAJX2FjdGlvbj0kMw0K
IA0KIAkjIGlmY29uZmlnX0lGX2FsaWFzTiB3aGljaCBzdGFydHMgd2l0aCAkX2FmDQotCWFsaWFz
PTANCi0Jd2hpbGUgOiA7IGRvDQotCQlpZmNvbmZpZ19hcmdzPWBnZXRfaWZfdmFyICRfaWYgaWZj
b25maWdfSUZfYWxpYXMke2FsaWFzfWANCisJZm9yIGFsaWFzIGluIGBsaXN0X3ZhcnMgaWZjb25m
aWdfJHtfaWZ9X2FsaWFzWzAtOV1cKmA7IGRvDQorCQlldmFsIGlmY29uZmlnX2FyZ3M9XCJcJCRh
bGlhc1wiDQogCQlfaWFmPQ0KIAkJY2FzZSAkaWZjb25maWdfYXJncyBpbg0KIAkJaW5ldFwgKikJ
X2lhZj1pbmV0IDs7DQpAQCAtMTA1MSwxNSArMTA1MCwxMyBAQCBpZmFsaWFzX2FmX2NvbW1vbigp
DQogCQkJd2FybiAiXCRpZmNvbmZpZ18ke19pZn1fYWxpYXMke2FsaWFzfSBuZWVkcyAiIFwNCiAJ
CQkgICAgIlwiaW5ldFwiIGtleXdvcmQgZm9yIGFuIElQdjQgYWRkcmVzcy4iDQogCQllc2FjDQot
CQlhbGlhcz0kKCgkYWxpYXMgKyAxKSkNCiAJZG9uZQ0KIA0KIAkjIGJhY2t3YXJkIGNvbXBhdGli
aWxpdHk6IGlwdjZfaWZjb25maWdfSUZfYWxpYXNOLg0KIAljYXNlICRfYWYgaW4NCiAJaW5ldDYp
DQotCQlhbGlhcz0wDQotCQl3aGlsZSA6IDsgZG8NCi0JCQlpZmNvbmZpZ19hcmdzPWBnZXRfaWZf
dmFyICRfaWYgaXB2Nl9pZmNvbmZpZ19JRl9hbGlhcyR7YWxpYXN9YA0KKwkJZm9yIGFsaWFzIGlu
IGBsaXN0X3ZhcnMgaXB2Nl9pZmNvbmZpZ18ke19pZn1fYWxpYXNbMC05XVwqYDsgZG8NCisJCQll
dmFsIGlmY29uZmlnX2FyZ3M9XCJcJCRhbGlhc1wiDQogCQkJY2FzZSAke19hY3Rpb259OiIke2lm
Y29uZmlnX2FyZ3N9IiBpbg0KIAkJCSo6IiIpDQogCQkJCWJyZWFrDQpAQCAtMTA3MSw3ICsxMDY4
LDYgQEAgaWZhbGlhc19hZl9jb21tb24oKQ0KIAkJCQkgICAgImluc3RlYWQuIg0KIAkJCTs7DQog
CQkJZXNhYw0KLQkJCWFsaWFzPSQoKCRhbGlhcyArIDEpKQ0KIAkJZG9uZQ0KIAllc2FjDQogDQpJ
bmRleDogZXRjL3JjLnN1YnINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBldGMvcmMuc3VicgkocmV2aXNpb24g
MjU1NzEyKQ0KKysrIGV0Yy9yYy5zdWJyCSh3b3JraW5nIGNvcHkpDQpAQCAtNTQsNiArNTQsMjAg
QEAgSklEPWAkUFMgLXAgJCQgLW8gamlkPWANCiAjCWZ1bmN0aW9ucw0KICMJLS0tLS0tLS0tDQog
DQorIyBsaXN0X3ZhcnMgcGF0dGVybg0KKyMJTGlzdCB2YXJzIG1hdGNoaW5nIHBhdHRlcm4uDQor
IyANCitsaXN0X3ZhcnMoKQ0KK3sNCisJc2V0IHwgeyB3aGlsZSByZWFkIExJTkU7IGRvDQorCQl2
YXI9IiR7TElORSUlPSp9Ig0KKwkJY2FzZSAiJHZhciIgaW4NCisJCSIkTElORSJ8KlshYS16QS1a
MC05X10qKSBjb250aW51ZSA7Ow0KKwkJJDEpIGVjaG8gJHZhcg0KKwkJZXNhYw0KKwlkb25lOyB9
DQorfQ0KKw0KICMgc2V0X3JjdmFyX29ic29sZXRlIG9sZHZhciBbbmV3dmFyXSBbbXNnXQ0KICMJ
RGVmaW5lIG9ic29sZXRlIHZhcmlhYmxlLg0KICMJR2xvYmFsIHZhcmlhYmxlICRyY3ZhcnNfb2Jz
b2xldGUgaXMgdXNlZC4NCg==

--_002_A7699871A1704AD5B740ED8BE17C7107fisglobalcom_--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A7699871-A170-4AD5-B740-ED8BE17C7107>