
A couple neat things about using chemical elements as hostnames - arundelo
http://geoff.greer.fm/2009/06/17/hostnames/
======
lsc
Naming is a classic bikeshed. Sure, a good naming system is a good thing, and
helps you recognize what box is where. But once you hit between 20 and 200
hosts (depending on your memory) you are going to need to stick 'em in a
database and sort 'em into groups to manage them in a sane manner anyhow, and
at that point, naming schemes won't mean much anyhow.

The problem is that as a bikeshed, /everyone/ has an opinion and everyone
wants to have that opinion heard. I've been places where we spent more effort
arguing about naming schemes than it would have taken to write the database
and tools for retrieving groups of hosts.

So generally, when this comes up in situations where I'm in charge, I loudly
declare it a bikeshed, and we choose the scheme essentially at random.

~~~
ErrantX
We have several very very large clusters - as you say, the names become
problematic.

Currently we are using a "code" to ID servers.

\- 2 letter geographical location code

\- 2 letter building code

\- 4 number computer ID

(e.g. LIMB0001)

This was after someone had to spend nearly a whole day working out where
computer CU2043 was located :)

~~~
theBobMcCormick
Couldn't they have just used the IP address of the computer to figure out what
subnet the computer was on?

~~~
lsc
many people have big, flat layer two networks... e.g. one subnet might span
locations. Now, personally, I think this is a bad idea in nearly all cases,
but many other people disagree with me.

The thing is, vendors of expensive MPLS gear like to sell this idea of
'location independent subnets' to upper management as a way to 'simplify' the
network.

Now maybe it's just 'cause I don't know layer two well, but god damn it is so
much easier to troubleshoot layer three problems than to troubleshoot layer
two problems, so I strongly favor making the subnets location and/or rack
dependent.

~~~
theBobMcCormick
The very idea makes the network engineer in me cringe. There are _so_ many
good reasons to establish layer 3 boundaries before crossing any relatively
low speed or high latency connections.

------
mikedmiked
I like to use Pokemon names, as the numbers of those first 151 have stuck in
my head for many years for some reason. You can subdivide them in many
memorable ways too, e.g. the author could say: "On my network, pikachu is my
router, rack-mount servers are fire-type pokemon, embedded devices are water,
gaming consoles are dragon, and laptops are ground type."

It would also has the advantage that you could use redily available pokemon
stickers to attach to each device, and is a nice way to personify devices if
you are so inclined - "Ivysaur is playing up again; time for a trip to the
pokecentre"

~~~
graywh
Laptops should be flying type. Then embedded devices can be ground type.

------
js2
The last sentence should be the first: “If you have more than about 20
machines, just give them numbered hostnames and be done with it.”

~~~
theBobMcCormick
The problem with numbered hostnames is that it's very difficult to remember
which host is which, even in the course of very short projects (was that
ser0483 or ser0438 that needed rebooted?) etc. Although I'll grant you that
numbered hostnames is probably the only workable alternative for a large farm
of otherwise identical servers (VMWare server farm, rendering farm, etc.)

~~~
ghshephard
I've never found numeric names to be a problem. And there is _never_ a problem
with how to spell the name. I will take "ssh m435.local.domain" over (real
world example, ARGH) "ssh Vanaheimr.local.domain." and "ssh
Muspellheim.local.domain" - I want to shoot people who think that's clever.

------
nnutter
I like that there is consistency in naming them when considering the periodic
table. However, most people don't know the table well enough to know their
atomic number, their classification (noble gas, halogen, etc.) nor would there
be any connection between name and purpose. Rather you must know the meta-
information about the element to know the purpose which makes this a well-
suited convention for chemists but few others.

~~~
js2
Usually the hostname should be disconnected from the machine's purpose.
Instead, use a generic name and then use aliases (either cnames or additional
A records) for mapping services to the machine.

~~~
spiffytech
I don't think nnutter meant naming machines by their purpose like
"mail.localdomain", "www.localdomain", etc. Rather, for example, I once named
a QA build-testing machine "yaeger" after the test pilot that broke the sound
barrier. Hostnames whose namesake has similar traits (even vaguely) to the
machine's purpose can help you remember which machine performs what task on
your network, or recall what a machine's purpose is by it's hostname. Careful
selection of such names provides these benefits without causing any more
problems when you move a service to another machine than using any other
naming scheme.

------
Goladus
Numbered hostnames are fine if you've got a cluster of identical machines such
that there's not much value in differentiation.

'xyz241' is a test router

'xyz211' is a second test router

'xyz262' is a production webserver

'xyz546' is a production webserver

'xyz33' is a development database server

'xyz411' is a development database server for a temporary contract dev team.

'xyz101' is the corporate file server

If you have hundreds of devices to track, the weaknesses of using numbers
should be apparent. The only advantage of that naming scheme is organization
of the entire monolithic collection. It's easy to select new names and it is
easy to enumerate the entire collection at once. Those are definitely
advantages, but there are some obvious drawbacks, too. There's no obvious way
to tell, short of committing it to memory, that "546" is a webserver.

To track of any other pattern, you'll have to encode some sort of information
into the names. For example, you could organize the numbers, like most
colleges do for classes. <subj> <level-number> * 100 + <course-number>. eg:
MUSC 211.

~~~
jeffbarr
I always figured that names are good if you treat your servers like pets --
unique, long-lived individuals with personalities and quirks.

Otherwise, you use numbers, and you treat them like farm animals -- anonymous,
members of a species, with shorter lives.

You can get attached to pets, but you shouldn't bond to livestock.

~~~
eli
You also should never have hundreds of pets at once.

~~~
gxti
Lest you become a crazy cat lady. I like this metaphor.

------
poundy
This gives purpose to all the years of Chemistry I learned at school.. Thank
you!

------
mhd
At my current job, we've switched from Star Wars characters to colors. While I
can understand that having a testing machine called "jarjar" is a bit, well,
jarring to those with less geeky proclivities. But mentally associating colors
to certain servers is a bit too bland. Maybe that's just the way my brain
works…

(Worst sin I've commited, name-wise: Naming my desktop PC dunsinane and my
laptop birnham)

------
jcapote
Just refer to the RFC: <http://www.faqs.org/rfcs/rfc1178.html>

------
tahu
Yes, this is the PERFECT plan.

But how do I name my router at 192.168.1.254?

~~~
wrs
I believe that would be "bipentquadium".
(<http://en.wikipedia.org/wiki/Systematic_element_name>)

~~~
tahu
Very good. Now I can safely append

192.168.1.254 bipentquadium bpq

Thanks.

------
jm3
we do this as well; the inspiration came from the engineering machine names at
umich.edu.

Edit: umich had a lot of funny machine names. The login servers were named for
console video games (galaga, moonpatrol, galaxian), while the kerberos servers
were (inexplicably) named for schwarzenegger movies: terminator, redheat,
lastactionhero, etc.

------
Hoff
Overloading the names? Classifications as functional groups?

Um. Ok. That's, um, interesting.

If you start with chemical names and hit the limits of the complexity that
permits, are you going to move onward to molecules? Wait for Ununbium to be
renamed Copernicium? What's next, molecular host names within the hydroxyl
group are assigned to management?

If you're going to use a "corporate-style" naming scheme for your hosts, then
just encode whatever it is you want to convey into the host name. Location or
whatever.

Or just select random names.

Having the IP address encoded in the name strikes me as particularly
problematic, too. Hosts and subnets and VLANs tend to come and go, and names
and VLANs and address assignments tend to shift.

And naming based on physical locality is an increasingly quaint concept in the
era of virtualization and client mobility.

After a while, most any naming scheme will prove insufficient or will unravel,
so why not just have an eye toward the likelihood of distributed management
and (increasing) complexity from the onset?

Seems better to spend your time getting (for instance) SNMP and DNS records
configured and working for all your boxes, and less time making (more) work
for yourself with explaining and maintaining complex host name schemes.

~~~
JoeAltmaier
Seems like this extends to domain names too. SO why even have an address bar
at the top of the browser? What will replace it?

~~~
Hoff
Many browsers have two text input boxes.

In more than a few places, a Google search string (or the browser's search
input box) is the already the preferred contact path; not the URL.

What might replace URL-based navigation more widely, I don't know. We went
from ARPA not all that long ago to the Big Seven to however many dozens of
TLDs we have now. We'll certainly find out, as the URLs are increasingly
hideous, and we're just a few years into this current naming structure.

There are certainly potential business opportunities here, too. Approaches to
better solve a distributed planetary-scale address book than "just" based on a
domain name, and better than a brute-force search engine.

~~~
JoeAltmaier
Yes, I've wanted an "authoritative" directory of web pages for some time.
Every since Yahoo gave up on it, I've had to learn clever ways to tease the
right pages out of google.

How about a search engine that ALWAYS returns the canonical page for any
techinical/commercial/copyright/patented term FIRST! Instead of somebody's dog
named "rfq" or a car for sale by a gal from Concordance, OR.

------
socksy
In my household, we've found that place names can be useful for memorable and
informative hostnames. Servers in the garage: Japanese cities. Upstairs
northern places (being English we use Scottish cities), basement Australian,
and the central computer is Rome. After all, all roads lead to Rome!

------
noonespecial
We've solved it by having the actual hostname be the mac address from the
machines first NIC preceded by a 2 character code for what type of machine it
is (DT for desktop, VM for virtual etc) and then allowing for the assignment
of an "administrative" name that goes in the internal DNS and is shown in
green on the command line when logged in.

This lets the suits pick goofy names for their boxes based on whatever they've
seen on tv recently and allows us to automatically generate unique hostnames
based on physical properties of the actual machines.

The sweet lack of multiple "Gimli's" and "Gandalf's" on my network warms my
geek heart.

~~~
ghshephard
This becomes somewhat more problematic (but not impossible) when you need to
start replacing NICs, and moving MAC addresses over to new servers. Some linux
IPv6 stacks (RHEL) tend to work better in autoconf mode (EUI-64 promotion of
their MAC address) - particularly across multiple versions of the kernel
(Static addressing has given us problem) - so we tend to do the migration of
IPv6 addressing by changing the MAC address on the NIC, which, ironically,
offers more straightforward and predictable behavior across multiple RHEL 5
releases than trying to force a particular static IPv6 address onto the host.

If you end up having to play games with your MAC addresses, basing hostnames
on them is a suboptimal strategy.

Asset tags, on the other hand.....

------
mprovost
This is great for highly connected devices like routers and switches because
each element has an unambiguous abbreviation which makes labeling cables much
easier.

------
floodfx
naming servers is so BAWS (before AWS). :)

------
chrismealy
I did this back in 1995. I still remember the first three hosts: mercury,
carbon, helium ...

------
dnsworks
Cute hostnames are pretty obnoxious. My preferred method of building out
datacenters is more self-documenting, and I've done it on 4 rack colo
buildouts and 100 rack colo build-outs.

I just use a naming format of Loc-Cabinet-Rackspace.

In my Seattle datacenter I know that sea-c01-s1 is a server thats in my
seattle datacenter, cabinet 1, slot 1. I know it's PDUs are plugged into port
1 of PDU-LEFT and PDU-RIGHT in that cabint. I know it's two ethernet ports are
plugged into Port 1 sea-c01-sw-left and sea-c02-sw-right. I know it's LOM
cable is plugged into port 1 of sea-c01-sw-mgmt.

(I handle multi-U spaces by naming the server based on the bottom most
rackspace it uses, and I stay consistent. If Sea-c01-s1 takes 10 rackspaces,
then the server above it is sea-c01-s11. Beyond that, my configuration
management tools tag spare resources when needed, and release them when
unneeded. Cute hostnames are of no use to me, or anybody building out a
datacenter that they'd like somebody else to be able to manage without months
of knowledge dump.

~~~
chime
What happens when you have to move a server for some reason? Has that never
happened?

~~~
spc476
My guess: logical names (like www or db or ns) are CNAMES, so that when the
server moves and gets a new named based on location, the CNAME is adjusted as
well.

~~~
gaius
You shouldn't need to rename a server when you move it, esp. since you might
not know where its hostname is used (e.g. at least one major database vendor
at software installation time embeds the hostname in various generated config
files).

Machines should have sequential names, services should be VIPs (or CNAMEs if
you must) and everything else should be in a configuration management
database.

------
daniel-cussen
"I admit this naming convention is more for the massive nerd factor than
practicality."

Epic.

