Slashdot Mirror


Server Naming Conventions?

Some random reader sent in: "Hi, I'm wondering what others out there use for server naming conventions. Our data centre right now houses a little under 200 servers, with plans to grow up to 4000 servers within the next five years. We'd like to pick something flexible and easy to manage with any tracking system. The servers we'll be implementing include SUN, HPUX, and AIX servers, in addition to existing Compaq and HP Intel servers, so we'll have to adhere to limitations placed on hostnames by manufacturers (ie HPUX lets you have an 8 character hostname)." We had a similar story a few years ago.

The reader continues:

"Here's a few ideas we've been tossing around, using Joe's Deli as an example:

- [four letter "name"][two letter service type][2 numbers] eg) jdelwb03.domain.com
+ easy to determine the function and name
- hard to remember and pronounce, once you run out of four character servers, determining the name and function will be difficult. Joe's Deli and John's Delivery will have conflicting names

- [random combination of numbers and letters]
eg) ak1jop3d.domain.com
+ none really
- confusing.. really confusing. Can you imagine saying to someone "log on to alpha kappa one john omikron peter three delta?"

- [theme based name]
name servers based on a theme, eg Gundam
eg) zaku.domain.com, gelgoog.domain.com
+ easily identifiable - all Gundam names belong to Joe's Deli, easy to pronounce and remember
- hard for a new tech or management (why would they need to know?) to associate to a server

"I'd like to know what others in the tech community use for server naming policies when planning large scale data centres. Also, with data centres located nationally, does the naming convention pose any problems? Thanks."

7 of 959 comments (clear)

  1. Check the RFC by wiredog · · Score: 5, Informative

    RFC 1178, Choosing a Name for Your Computer

    1. Re:Check the RFC by mmontour · · Score: 5, Informative

      Also see RFC2100, "The Naming of Hosts"

    2. Re:Check the RFC by storem · · Score: 3, Informative
      Check your DNS history:

      The accessibility of distributed resources carried with it the need for an information service (either centralized or distributed) that enables users to learn about those resources. This was recognized at the PI [ed. Primary Instigators] meeting in Michigan in the spring of 1967. At the time, Doug Engelbart and his group at the Stanford Research Institute were already involved in research and development to provide a computer-based facility to augment human interaction. Thus, it was decided that Stanford Research Institute would be a suitable place for a "Network Information Center" (NIC) to be established for the ARPANET. With the beginning of implementation of the network in 1969, construction also began on the NIC at SRI."

      The Stanford Research Institute's Network Information Center (SRI-NIC) became the responsible authority for maintaining unique host names for the Internet. The SRI-NIC maintained a single file, called hosts.txt, and sites would continuously update SRI-NIC with their host name to IP address mappings to add to, delete from, or change in the file.

      This was the first semi-distributed name resolution on the Internet. You all understand that eventually the hosts file became too big and led to the development of BIND (DNS Service).

  2. Sheesh people, use subdomains by defile · · Score: 5, Informative

    The LIRR homepage is http://www.mta.nyc.ny.us/lirr/. The LIRR is run by the MTA, which is located in NYC, which is a city in NY, which is located in the US. Perfect scheme, and a suprisingly decent application of DNS. Especially for government.

    So why suffer with jdeli342.domain.com? Why not a.jdeli.domain.com, b.jdeli.domain.com, etc? In addition to allowing for easier delegation of services, you can set search orders in /etc/resolv.conf so you can simply type ``ssh b'' to hop from host a to host b. That's just golden.

    Some other examples..

    Mail Exchangers

    a.mx.domain.com
    b.mx.domain.com

    Nameservers

    c.ns.fudge.domain.com
    d.ns.fudge.domain.com

    Web servers

    e.web.domain.com
    f.web.domain.com

    And so on. If you get to z, make the next one aa, and then ab, etc.

    Also, functional names should not replace cute names. DNS allows you to assign more than one name to a machine. If a machine is repurposed for another ask, it should still be known by its unique cute name no matter where it goes. At the same time, a single host can have more than one functional name.

    No reason barney.domain.com can't also be bc.web.domain.com and e.porn.domain.com. :)

    A source of cute names? Oh, uhm, right now I use Roman empererors. There were tons of them.

  3. Re:That's what CNAMES are for by DeathBunny · · Score: 4, Informative

    However you can have multiple "A" records for the same host. Assign the hosts "real" name (norm, etc) in on A record. Create another A record for smtp.yourdomain.org.

    Problem solved.

  4. Re:Naming Conventions. by JabberWokky · · Score: 4, Informative
    Yeah, but that leads to phrases like "Sal just went down!" yelled across the office. Bad times. Of course, back in '93, we named the Novell Digi-something modem servers in the Palm Beach Courthouse "Shafey" and "Twan" because they kept going down on each other. The "Political Officer" (read: Elected Offical's Yes Man) calmly asked us to remove the tags and not explain why they were named that during the audit.

    Personally, I named my home servers "riffraff", "columbia", my laptop "eddie", my palmtop "sadie", and so on. My work servers are "ritz", "tim", "susan", etc. For those of you who get it, it's a pretty simple naming scheme, and for those who don't, the work ones are respectable, non-geeky at a glance, and easy to remember.

    For large numbers of computers, name them by department and number. Or location and number. Room/cube numbers seem like a good idea until you start swaping offices and cubes. Best off keeping the numbers semi-random so you don't expect anything, and just log where they are/their name in your asset management software. A system moving inter-department/location will have to be wiped. Period. Easier to track software licenses anyway (especially if each department has a seperate software budget). If you've set up your users correctly, all their files are on the server, anyway. Don't use "Four character and number" or something like that. No reason to say MKEC4711 when it can just be marketingeastcoast-4711. YMMV depending on legacy systems you have to chat with or through.

    --
    Evan "Back in my day, we walked around the office looking at the back of each computer for the ring that fell out of the token network. And we *liked* it".

    --
    "$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
  5. One Way Naming by pryan · · Score: 3, Informative

    Our naming convention is simple:

    The canonical name of a machine is assigned by the person who is setting up the machine at the time a name is needed. That name stays with that machine throughout its "lifetime." More on a machine's lifetime later. The only three constraints on the name are as follows:

    1. It must be something that most people can spell if they heard the name.
    2. It must be a name which can be published in a newspaper without embarassing us.
    3. The name may not be duplicated.

    Notice that this is the canonical name for a machine. We never call one of our machines smtp or www. We alias those standard names to the canonical name.

    We define a lifetime for a machine as the time from which it is named to when it has lost its essence. In turn, we define a machine's essence as that which fundamentally separates it from other machines. In our current business, a machine's essence almost always is defined as the machine's purpose in life, which typically includes its OS and the servers running on the machine. There are times where we have converted a machine from Linux to OpenBSD, for example, but kept the name. If the machine is retasked, then it usually gets a fresh OS and new name; the old machine "dies" and a new machine is "born."

    That name is added to a database via a record which also contains the machine's hardware configuration, its MAC address, the OS, its maintainer's email address, and its intended purposes in life (smtp, http, file server, compute server, etc.). From that point on, it is the responsibility of the maintainer to update that record. The hostname is considered the database key, and is therefore not supposed to change.

    Every six months, however, clean out the database, looking for cruft and abandoned machines. We also try to identify machines that didn't make it into the database and add them. This also provides a quick way to inventory our equipment, since we primarly own computers and network gear.