-
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
-
My friend uses names of celtic gods.
My company uses names of wild animals for terminals and drug names for servers.
I use names from Tolkiens Silmarillion.
-
There are a number of existing questions about this Subject
-
Lovecraftian Great Old Ones and Outer Gods.
-
We have a similar system to colby.
- Airport code or other unique 3 letter abbreviation
- vm if it is virtual
- cl if it is a cluster
- function
- unique number
- and optionally a -n1,2,... if it is a cluster memeber
so PHLVMCLDEV01 would be the first development cluster in Philadelphia and it's nodes are virutal
it would consist of
PHLVMDEV01-N1 and PHLVMDEV01-N2, etc
-
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" :)).
-
We currently use a mixture of a frivious naming scheme (London Underground stations) and functional names. The latter happened when it started becoming tricky to remember which 11 servers were in the webserver cluster. Remembering victoria, euston, paddington, oval, cockfosters, angel, bank etc is a little harder than w000, w001, w002 etc.
-
Great list of network and server naming schemes.
-
We have tried two flavors of server naming conventions for our mid-size intity:
- "Location"-"Server Type"-"Number":
- "Main-DB-01"
- "Main-FW-01"
- "Wing2-FS-01"
- "Wing2-FS-02", etc..
AND
- City Names:
- "NewYork"
- "Miami"
- "Portland"
- "Seattle", etc..
Out of these two conventions, 80% of the techs (including myself) like the City name convention more than the "Loc-Serv-#" one.
-
There was an excellent Slashdot thread about this a while back:
http://ask.slashdot.org/story/08/07/06/2014237/Best-DNS-Naming-Scheme-For-SmallMedium-Businesses?art_pos=1
-
It should probably be noted that RFC 1178 is devoted to this topic:
http://www.faqs.org/rfcs/rfc1178.html
(even if I disagree with a lot of it, and much in there is out of date).
-
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.
-
I use unique names to describe unique machines. For instance in my current project, 200+ servers, I used the list of star names from Wikipedia. The reasoning is that actual names have more redundancy than super compact indices, such as srv-05-92. It's important for one thing: it affords a small error rate when transcribing, typing or talking over the phone in a loud server room.
Descriptive information is stored in TXT fields in the DNS, so are Mac addresses and so on. You can also request the name based on the mac address:
$ host 00-12-34-56-78.mac.fr.dom
00-12-34-56-78.mac.fr.dom is an alias for arcturus.eqx.vl304.fr.dom
arcturus.eqx.vl304.fr.its has address 10.21.4.30
One thing you absolutely want to avoid is to name the machines according to their function. This is going to bite you in the ass sooner or later. Just use aliases (CNAME or additionnal A records) for that purpose.
Note: This is all generated with an XSLT from a custom XML file:
<?xml version="1.0" standalone="yes"?>
<domain suffix="dom" xmlns:h="http://www.w3.org/1999/xhtml">
<vlans>
<vlan name="vl304" value="4" />
</vlans>
<country code="fr" prefix="10.21">
<datacenter name="eqx" desc="Equinix">
<host name="arcturus" lso="30">
<vlan name="vl300" if="eth0" mac="00:12:34:56:78" />
<txt type="loc">rack 5</txt>
<txt type="sn">99A0632</txt>
<txt type="model">xSeries x3350</txt>
<doc>Load balancer</doc>
<rsa ip="192.168.101.30" />
<role type="loadbalancer1" />
</host>
</datacenter>
</country>
</domain>
Several aliases are generated:
- arcturus.eqx.vl306.fr.dom (canonical name)
- arcturus.vl306.fr.dom
- arcturus.fr.dom
- 00-12-34-56-78.mac.fr.dom
- arcturus-rsa.fr.dom
- loadbalancer1.eqx.vl306.fr.dom
- loadbalancer1.vl306.fr.dom
- loadbalancer1.fr.dom
... as well as a number of TXT records
-
There is no "good" answer to this question:
- in my current job, I manage a small set of servers (10/15) but have a lot of appliances located at our customers. We use names of island for our offshore servers, names of Canadian provinces for our internal servers and name of Canadian cities for the workstations (yes, my boss is from Canada). The appliances have a generic name that include the customer number.
- I used to work for a bigger international firm with a lot of server (around 3k). Each server was dedicated to his task and was in a cluster. The host name included the country (Uk, Be, NL) the server role (DC, SQL), the Datacenter in which the server was stored and the rank in the cluster. We also include the environement (Production, Development, Test) because every environement was enclosed and could not interact with each others.
- In my previous job, I was working for a bank with something like 100k servers. The host name included the city where the server was located, the name, version and editor of the Operating System, the hardware platform (i386, ..) and the number of the server on 5 digit.
If your servers are clustered, you may need to identify the others members of the cluster to be able to switch on them.
If your server are multi-role, there's no way you can have their roles as part of the name...
In fact your hostnames must contain informations that are valuable for you and the people that will work on a computer breakdown.
-
Naming servers based on location and/or function can lead to security problems. If you publish your DNS externally you are giving the bad guys a map of where all the good stuff is. Security through obscurity is not something to rely on but I wouldn't make it easy for the script kiddies.
Also you don't need to describe all the details of the device in the hostname. Instead use the hostname as a key into your configuration management database. (You can buy a CMDB, use open source solutions, or refer to an excel spreadsheet).
Personally I like device names that are:
- Short
- Easy to spell
- Funny
Example: We used to call one of our backup servers - sloth.
Unfortunately, this only works for smaller sites. If you manage larger installations you are going to want the clearest naming convention possible so that all of your staff can quickly and easily identify what all these hosts do. In this case will probably want to implement split DNS so that you are not advertising all these hostnames in the wild.
If your internal naming convention is private then it really doesn't matter what kind of harebrained naming scheme you use. But here is an idea. Get the technical leads from your support staff and ask them if they have any suggestions. It will make them feel important.
-
I can't believe you guys really have all these long and complicated names. Do you type it all the time? Do you know how much information you are leaking (including location of the physical servers???).
The approach we use is to give simple names to the servers based on cartoons, movies, etc. Internally we keep a database linking the funny names to their locations, purposes, etc.
*With all these longs hostnames it is easy to remember the ips instead :)
-
At my previous job, I named all of the workstations/servers in a new build after Star Wars planets/moons - Tatooine, Hoth, Endor, Dantooine etc. At my current job, the local servers/workstations were named after Star Wars characters, but are slowly being phased out to more generic names. In our production environment, servers are named after characters in Greek Mythology.
At home, all of my physical/virtual servers are named after their use - fileserver, mailserver, ftpserver, webserver, mssqlserver etc. However, this is now proving difficult as I'm building additional webservers. I'm contemplating moving over to the naming convention of my previous job, for nostalgic reasons.
