Naming Conventions [duplicate]

Depends very much on the environment you work in.

First and foremost - drop any references to (pop-)culture, stick with meaningful & descriptive names.

You might know that "zeus" is the proxy server, because you installed it. But any future colleague would pretty much like to refer to the server by what it does, not what his given name is.

If you accept that, I'd suggest you do a brainstorming session and write down what different kinds of networked entities ("hosts") you have, how they can be grouped together and what information is important enough to get encoded in the hostname. Your naming convention should be able to unambigiously name all existing devices and give an user a rough idea of what the host does. Be sure to leave enough room for growth to adapt to future developments, so that you don't need to throw your naming convention over board in a few months.

Document your naming convention (not only how, but why), make sure that everybody who needs to work with it on a regular basis understands how it's laid out, be open to comments/suggestions and don't tout it as a holy grail, adapt it when needed.

Example

As food for thought, here's the schema we used at one of my former employers:

Web service provider, doing development and operations for web projects. Mostly LAMP-stuff, although on a larger scale (size of projects, not quantity).

For physical devices:

<SITE>-<RACK>-<DEVICE>.in.<DOMAIN>.<TLD>

• SITE was an unique site identifier, mostly three letters
• RACK was an identifier either assigned by us or taken over from the hosting facility, should be able to uniquely identify the rack at SITE
• DEVICE was a "device class" with a counter after it, e.g. vnodeXX for OpenVZ nodes, swge for Gigabit switches, etc.
• DOMAIN/TLD was the domain of the owner of the given devices.

For logical entities:

Logical entities might be anything that has an IP address which wasn't strongly coupled to a given physical device/location. This was mostly IP addresses of guest OS (OpenVZ or ESX in our case)..

<PROJECT>-<ENVIRONMENT>-<SERVICE>.in.<DOMAIN>.<TLD>

• PROJECT was a project identifier, which grouped the various services of a project together.
• ENVIRONMENT could be production, staging or development, 4-letter-abbrevation
• SERVICE was relatively freeform, though the common cases were standardized, like web, db, mailout, etc.
• DOMAIN was the primary domain of the project in question.

For IP-addresses:

All of our services were only reachable from a private network, we had NAT and/or load balancers with "Service IP-addresses" which were used by internet facing hosts to access our services. For those we used something like this:

<PROJECT>-<ENVIRONMENT>-vip-<IDENTIFIER>.<DOMAIN>.<TLD>

• IDENTIFIER was something that uniquely identified the use for the IP address, e.g. an address which was used exclusively as the Web VirtualHost for the projects german domain might be called "wwwde".

Summing it up

The naming convention worked fine for us, some (like - our developers ;) ) might call it overblown. Keep in mind that it is completely overblown if you only maintain a single site and have servers which are assigned to a single project. But for us it fulfilled a few very important things.

When dealing with a hostname of a logical entity we always knew:

• Which project was involved:
  The various projects were of varying importance with different responsible development teams. A quick glance at the hostname told you how you need to prioritize tasks and whom you need to ask on management/development side
• What environment the host was in:
  Issues in development environments cause slowdowns for the developers. Problems in staging environments cause pain for testers and can jeopardize product presentations. And if something is affected in production, the company looses money.
• What subsystem is affected:
  Mail spoolers, batch workers, etc. weren't that important, but if web- or database servers are down things get dirty pretty fast.

And for physical devices the exact location was always deducible from the hostname.

The weak coupling between physical devices and logical servers might be a turn-off for some people (e.g. how do I know what projects are going to be affected when I pull the plug of switch x/server y), but this was a must in our environment since our projects had a high turn-around-rate and more often than not we didn't even know what projects were going to be hosted on fresh hardware we just provisioned.

For servers, I like the standard currently used at my office <3 letter location code>-<2 digit incrementing number to avoid duplicate names>

An example would be: PHOU-DMOSQL01

• Physical
• Houstonm
• Demo Environment
• SQL Server
• 01

For Desktops/Laptops I usually use a type designator and the user's name (assuming machines are assigned to a specific user) (LT|DT)- for instance my laptop is LT-KCOLBY

The real answer is that there is no answer.

I tried a number of conventions for both server and computer names. My conclusion is that the name itself is meaningless, as long as you have a readily available, easily and non-consequentially modifiable description field.

Therefore, my take on this is - go nuts. Fantasy heroes, StarWars icons, mythology - whatever suits your fancy and has enough scope to include all your existing hosts and expansions. (and doesn't tick off your management's often-lacking sense of humor, bosses can be picky about a server named "pointyhaireddimwit" :)).