Tips from our experience living with the NamesGivenToComputers
- Possession -- Don't name your computer after yourself (as in "Bobs-Pc"). This can be amazingly disruptive when you transfer and the rest of the team is still depending on resources you hosted.
- Location -- Don't name a computer after where it is (as in Front-Office). Because the front office computer is now in the warehouse...
- Use -- Don't name a computer after what it's used for (as in Accounting). Because the accounting box is now used for CVS, and the CVS box is now a Samba server...
- Specificity -- Don't give a computer a too-generic name like "server", "workstation", "laptop", "nt", "development", "database", "test", etc.
- Spelling -- Don't use names that are hard for people to spell. Don't use words with alternate spellings or homonyms. And spell the words correctly--avoid clever or playful misspellings.
- Capitalization -- One must have some standard convention if the things aren't to be hopelessly hard to remember. I suppose many people believe that it's best to use all lowercase, because it's easier to type.
- Hyphenation -- One can elect to keep them in, to leave them out, to map them to underscores, ... It's all good as long as it's consistent. This comes up with ie "Obi-Wan" and "Pac-Man" from the systems above. However, note that RFC 952 disallows underscores in hostnames; some services enforce this restriction.
- Weird Characters -- Every so often, one will run across a proper noun with a really weird character, such as "Q*Bert". Probably the best one can do is to strip it out or map it to a hyphen.
- Spaces -- Strip them or map them to something. Lean toward stripping them.
- Finite Sets -- Don't choose names from sets which are distinctly bounded, ie "moons of Jupiter", as you will likely run out. There is also the reverse problem of having all the moons except Metis and so getting a new computer just to fill the gap. (What's wrong with this? It's my main excuse each year for buying a new computers. I'm working on characters from Arthurian mythology.)
- Numbers -- Don't, because numbers that don't look like IP addresses probably are. Name a computer 7100, for example, and try ping-ing 7100 from another machine. (Special case in numbers. They once put a machine named "xb" on my network (being the Xenix Build host). Nobody could reach it. Finally, I attempted to ping it, and was told that I couldn't reach 0.0.0.13--the command had translated "xb" as an IP address in hexadecimal! --RobMandeville)
- Length -- Long system names are fine for use with a mouse click but cumbersome if people must type them in. Three to seven characters seems optimal. "Backupmasterserver" is fine for a website but rough to type over and over again. If a long name is requried consider providing a DNS alias, such as "BMS" for this example.
See also RFC-1178 (http://www.faqs.org/rfcs/rfc1178.html
) for advice; RFC-2100 (http://www.faqs.org/rfcs/rfc2100.html
) for a nifty poem; NameSpace
and the not so applicable SystemOfNames
One very common name I found searching through an old dns cache is OEMCOMPUTER.
At an American subsidiary of a French company, the main servers were named after French cities, causing no end of confusion when someone would say they couldn't reach Paris and it was assumed to be an external problem.
These guidelines don't help in deciding how to name a computer; they only suggest what not
Q: The above guidelines seem to preclude the assignment of a "meaningful" name to a machine. If you can't name the machine based upon who owns it, where it is, or what it is used for, then it seems that you have to just choose a random word and make people guess which machine goes with which name. Is that right, and does that make sense?
A1: Pick simple names from a large set of familiar objects. Animals (giraffe, lion, etc.) are one such set. For new installs on workstations, let the owner pick a name from the set. Humans seem to be able to remember the association between familiar objects and the a computer's purpose, location, and owner far better than one might suppose.
One corp. I worked at used musical instruments. That worked well. On the other hand I worked for a small dept. whose manager was a Classics PhD dropout. Agamemnon and Menelaus don't work well.
A2: In some places, when a machine's owner changes or when it is put into service in a new role, the machine's hard drives get wiped and the operating system gets re-installed. It is easy to assign it a new name and a new IP address at this time. In those places, renaming computers when their roles change is usually not a big deal.
A3: Yes. The point is to avoid giving a machine a canonical
name that has meaning because that meaning probably won't stay with that machine. Humans, however, do not
have to guess what names goes with what computer because humans shouldn't be using the canonical names. Instead, you set up meaningful aliases
, which the humans use. (Each machine has a physical label with its conanical name for those times when you really need
to know which name goes with which machine.)
e.g.: A small company has three servers: huey, duey, and luey. They have the aliases mail, cvs, intranet, and devdb assigned appropriately. When IT decides to move CVS from duey to luey, it doesn't cause a hassle because everyone configured CVSROOT to point to "cvs" instead of "duey". IT merely moves the alias along with the repository and the change is transparent. Coming up with millions of other scenarios of how such a scheme can make life easier is left as an exercise for the reader.
On naming from possession: I started at a company, using a computer named Don, which Don had used but Don had left so it was easy to remember that AnonymousCoward
's machine was Don. No one was sure what would break if we renamed it.
Of course, Don came back to work. So his new machine was not named Orange or Panda or Neptune, but of course Donald.
Some of the assumptions of RFC 1178 (see reference at page bottom) are invalid in some environments.
In our datacenter we have about 1000 servers used by at least a dozen other groups. Our naming policy is [mode][group][role][number][interface], where mode is an optional tag indicating the status of the server (test/dev/qa/...), the next three are required, and interface is optional. This leads to ugly names like tsecsreg01f. However, we rebuild servers from scratch whenever anything their names refer to change, so it makes sense for us.
Most of the advice here is good, but it's also important to pick a standard and implement it consistantly.
At my previous job, our servers were named after constellations. So we had Taurus and Orion and Aquarius and Gemini etc.
Remember that, at least in DNS, you have canonical names and aliases. Aliases are a lot easier to change. I suggest having a "silly name" as the canonical name, and using aliases for functions or services. Imagine a small office with an animal naming scheme. Your mailserver has the canonical name "snail", and the alias "mail". You have everyone's mail clients pointing to "mail", not "snail". Now, if you bring in a bigger system ("hippo") and want to move the mail service over there, you can set it up, tell DNS that "mail" is now an alias for "hippo" rather than "snail", and everybody automatically starts going to hippo for mail rather than snail. Similarly, Joe Schmo has a machine canonically named "barracuda", aliased to "jschmo". When Joe leaves and you hand the computer to new hire Debbie Wayne, you drop the "jshmo" alias and make "dwayne" a new alias for "barracuda". Taken to the extreme, this allows users to publish their own services, hosted on their own machines, and eventually transfer them to dedicated servers.
(humorous and otherwise)
Libes, D., "Choosing a Name for Your Computer", Communications
of the ACM, Vol. 32, No. 11, Pg. 1289, November 1989.
RFC 1178 - Choosing a name for your computer
There is a full wiki containing all sorts of naming schemes and tips for naming computers and networked equipment.
Network Naming Schemes (http://namingschemes.com