I named all of our computers after characters on the Simpson's cartoon.  It
seems we had one person to pretty much fit every role - from Homer, to the
Comic Book Guy, to Edna the sexy teacher.
Of course most users don't really know what or why their machine names are -
but it's very easy for me to keep track.
Now when a person leaves - I have changed the machine name to "fit" that
person a bit better.  It makes it fun for me - or is it that I have too much
time on my hands? hmmm Maybe.
Now our servers are named after institutions on the show -
springfield_nuclear, moes_tavern ect.... so allot of times I'll see Homer @
moes_tavern... See it works out!?!
computers = fun ............ right?
Chris
----- Original Message -----
From: "Jay West" <jwest(a)classiccmp.org>
To: <cctalk(a)classiccmp.org>
Sent: Tuesday, October 22, 2002 11:32 AM
Subject: OT Re: Naming Computers (strategy, and WHY)
  I personally don't name machines by "what
they are", for very good reason.
 Plus, no one but the admin group uses the "real" machine names, also for
 very good reason. Here's some illustrative examples...
 If you call an HP K370 "k370.somedomain.com", and then upgrade it to a
K570
  by just adding a few more cpu cards, do you really
want to still call it
 K370.somedomain.com? If not, you have to retrain your user community and
 this is a pain, and kinda defeats the whole idea of using meaningful names
 so people don't need to know IP addresses. As a result, machine names
 generally indicate what they are used for... so a machine that processes
 orders might be "orders.somedomain.com". However, this can cause issues
 unless the second point below is heeded...
 If you give machines names that indicate "what they do" rather than "what
 they are", you can then run into problems if you do clustering, or if a
 machine goes down for a while (hardware issues), or more commonly, if for
 load reasons you need to move an application to a different machine. 
Thus -
  (IMHO), machines should have a "real" name
that has nothing to do with 
what
  it is or what it does. These real hostnames are
typically what admin 
people
  will use. Then, define CNAME's for the
applications that the machine 
serves
  up...this is what "users" use.
 Here's a realworld example. A particular webserver is named "joe" (at this
 place, the naming scheme is baseball related, so machines get names like
 hank, cy, willie, mark, sandy, ozzie, etc.). It serves up images via the 
web
  for bulk email that is sent out to subscribers that
has links in it back 
to
  images on "joe". However, users inside the
company who put up these images
 via sftp go to the cname for the machine which is "image". The benefit of
 this is, if joe ever gets too heavily loaded, or goes down or whatever, I
 can easily change the "image" cname to point to a different webserver here
 and move the content to it (in the case of a web server cluster, the 
content
  is already there). Thus, the admin group knows
"joe" is down, it doesn't
 respond at "joe". But the emails sent out reference
 
http://image.somedomain.com, and that is what the users inside the company
 sftp to, so to them, everything still works as it did before while some
 other machine is doing that task.
 The big benefit is admins know the machines by their real name, as their 
job
  focus is machine-centric. However, we can shuffle
applications and 
services
  around to other machines whilly-nilly, and we
don't have to tell the users
 anything because they still use the other name that is "service" specific.
 After all, admins should be spending their time watching system resources
 generally. If one machine starts getting sluggish, they need to be able to
 move one or a few of the services that machine provides to a less loaded
 machine - and they should be able to do this virtually instantaneously,
 without the users having to do anything different or know a different
 machine name. Heck, most users have the "machine name" stored in their
 terminal emulation software, and dont even know what it's called". And
half
  of them don't know how to change it themselves.
 This becomes especially important (and required) when you do clustering. 
The
  most common example is web farms, but it applies
equally to any service. 
If
  you have 30 machines that ALL serve up content for the
single URL
 
http://www.bigcorp.com you certainly can't name them all the same name. 
And
  if one of the machines in the cluster dies, you also
can't have a 1/30th
 "hole" in your services. The above paradigm addresses this nicely.
 To take it one step further, we use "wackamole" - a free unix program that
 assures certain IP addresses are always available. It will shuffle the 
group
  of addresses amongst multiple machines on the fly. If
a machine goes down,
 it moves it's ip addresses equally among the remaining machines in the
 cluster. Most people accomplish "clustering" with round robin DNS, which
is
  great, but you run into the problem of if one machine
in the round robin
 list dies, anyone who gets the address of the down machine resolved gets
 nothing. wackamole solves this problem very nicely. And as you might 
guess,
  doing things like this doesn't work well if you
are using machine names
 unique to each machine.
 Jay West
 ---
 [This E-mail scanned for viruses by Declude Virus]