Wednesday, July 13, 2005

what's in a name? part deux OR look ma, i'm 133t!

facing a potential domain rename.

i'm not happy about it.

especially now that i'm getting an idea of what's involved.

why oh why is there no rfc clearly delineating (and perhaps forever reserving) a universally accepted namespace for internal/private networks, as was done for ip addressing?

my personal view is that hardcore wireheads just don't get one simple truth...

folks who wouldn't be caught dead in a "there are 10 types of people in this world" t-shirt from thinkgeek don't give two sneezes about numeric addresses and how quick and nifty everything is when you use them, or how goshdarned close using them makes you feel to the machine.

even worse are techno-snob dingbats who think that rattling off "dot blah numbers blah dot numbers blah" in the presence of the easily impressed qualifies for a bonus, stock options and foot massages at lunch.

most folks have no idea what dns is, what it does, nor how crucial it is to the smooth and efficient functioning of the intarweb. more importantly, they don't care.

they just want their favorite mouse-training application to come up when they type the magic word into their web-a-thingy.

any time i'm training new techs, i drill into their heads the importance of the simple act of naming. i truly believe naming is something that takes as much thought and planning as any aspect of network & system design.

an effective naming scheme can make your life as an admin much easier. a bad one can make you start drinking heavily.

if that isn't enough...decisions made way in the past can come back to bite you in a hurry.

true story: yours truly formulated and mapped out a naming scheme by which i wanted all user workstations named. a bit of dissent arose about my scheme, and in a shocking display of passive-aggressive insubordination, the field techs decided to name the workstations according to what they thought was a better idea...which was including the os version installed on the machine as part of the new machine name.

for a time, they thought they had hung the moon. much high-fiving, gloating and swaggering commenced.

while i waited...

then, a year or so later, a new application (which requires local database installs on all the workstations) was rolled out. as you might guess, when os updates were then about to be installed onto those workstations a short time after that...the field techs discovered that they were not able to change the machine names without breaking the app. as in, major data/time loss per user break. as in, even after two years since we discovered that "issue," the vendor still doesn't support renaming workstations.

now, of course, we...that is, they...are stuck with those names, none of which match the current os on the machines. so when we need to pull together info about our deployed os counts, they get to relive their grand little moment of shortsighted hubris all over again.

still, they follow my instructions to the letter now, so i'm apt to call it even...

btw: for ms' suggestions on naming, particularly for sbs installs, click here.

btw2: if you want to see what the picture at the top is all about, click here.

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home