A Server Naming Scheme

http://mnx.io/blog/a-proper-server-naming-scheme/

by mstolisov • 12 years ago

465 199 12 years ago

Goladus• 12 years ago

Just want to highlight one thing:

Essentially, the hostname should not have any indication of the host’s purpose or function, but instead acts as a permanent, unique identifier to reference a particular piece of hardware throughout its lifecycle

It follows that if you are using virtual machines and configuration management, where the lifecycle of a VM or amazon instance is trivial compared to an actual piece of hardware, there is less benefit to separating hostname from functional name.

molf• 12 years ago

Actually, it's still quite nice if the hostname has no relation to the server's purpose – the functional name can then outlive the hostname if you throw away and recreate VMs regularly.

sciurus• 12 years ago

There was a good debate about this on the devops-toolchain mailing list.

https://groups.google.com/d/topic/devops-toolchain/UZzAcEL7K...

TomasEkeli• 12 years ago

Why tst instead of test, prd instead of production?

jnazario• 12 years ago

standard width of 3 characters maybe? makes visual scanning of a list of names easy to do to spot name/purpose, environtment, geo, etc. you don't have to keep moving your eyes left or right with each row.

loudmax2• 12 years ago

If you're regularly typing the names, it's nicer to type something short like

  ssh prd01

rather than

  ssh production-01

On the other hand if you're managing clusters of servers using something like ansible, you may not spend as much time typing in individual server names. I think it may depend on how your workflow is set up.

gnaritas6• 12 years ago

Typing test and prod is likely faster than typing tst and prd because you're not accustomed to leaving out vowels. Short doesn't have to mean no vowels. Short real words are better than abbreviations.

tetha3• 12 years ago

Partially yes. Partially meh. For servers I use a lot, my SSH-config looks like this:

   Host f1
       Hostname foo.bar.baz.qux

So... just use a readable name. I'll shorten that to something like 'a' locally anyway.

Pxtl4• 12 years ago

Somebody's nostalgic over Hungarian Notation?

rplnt• 12 years ago

Because prd means fart in Czech/Slovak (at least).

edwhitesell• 12 years ago

This article, while interesting to repeat occasionally, was previously discussed here: https://news.ycombinator.com/item?id=6796318 And here: https://news.ycombinator.com/item?id=6800935

teddyh• 12 years ago

The subject itself was also discussed here: https://news.ycombinator.com/item?id=6540044

I usually suggest that people read RFC 1178, Choosing a Name for Your Computer: http://tools.ietf.org/html/rfc1178

At least then they will avoid the usual pitfalls worked out over the many years in which networked computers has existed.

jasonkolb• 12 years ago

I kind of like the approach Elasticsearch takes to this, name an instance after a random Marvel superhero. Keeps things interesting.

mitchellh2• 12 years ago

This is cute, but devolves into a maintenance nightmare very quickly. It is much easier to look at a sever list and see "db001" than it is to see "spiderman" and remember if that is a DB or not. Extrapolate that out to hundreds of hosts and you kind of get the picture.

In a modern world where the machines might be homogeneous and VMs/containers above define the actual role, the machine might just be "host123" whereas the higher level services have specific names like "db001."

With service cataloging and discovery tools like Consul (disclaimer: I wrote it), there is an easy way to see a mapping of service name back down to the host it is on. So even if you're yelling to an ops person "hey db001 is having problems," the ops person can quickly map db001 down to host 319.

And with slightly more complex (but worth it, imo) naming, you can determine the rack, datacenter, etc. of a server just by the name.

Xylakant• 12 years ago

This is cute, but devolves into a maintenance nightmare very quickly.

Especially given that the name changes at every startup. It's absolutely not recommended to stick with the auto-assigned names, but a rather good idea to name the node after the machine or the location.

aashishkoirala• 12 years ago

I wish I had this about 5 years ago when I was knee deep in server naming. Good article anyways!

Zolomon2• 12 years ago

I guess there is no actual need to use security by obscurity to protect the servers?

On the other hand, choosing a name for what is running on that server makes it just one step easier for an attacker?

mitchellh2• 12 years ago

Only the web load balancers are likely exposed to the public internet, along with some sort of bastion host. The rest are probably on your internal network and can't be accessed/queried anyways, so the names mean nothing to them.

If attackers ARE in your DC already, you're already hosed, and the few minutes that it would take them to determine that some obscure name like "host-a831f1" is the DB won't matter.

So in general, I believe optimizing for maintainability here (easier names) is more worth it than falsely believing that obscuring the names provides some level of security.

Though, if all your servers are able to be accessed from the public internet, it might be a different story. But that really isn't recommended.

Zolomon2• 12 years ago

Thank you! I totally forgot about not exposing sensitive machines to the outside world.

Yes, I am in total agreement with you. Much appreciated.

tetha3• 12 years ago

Even if you're in our network, you'll still have a lot of fun. There's more ports open, yes, but most ports will just refuse you with an access denied and report to a secure log, which is centrally collected and triggers the admin spawner if necessary.

awalton3• 12 years ago

If attackers ARE in your DC already, you're already hosed,

That's a defeatist attitude, and the reason why security companies get away with only selling perimeter defense products. "Well if they get in they can do whatever they want anyways." If servers are properly insulated from one another, violating a single server won't give them complete access to your infrastructure.

An example of this: Valve was infiltrated by a hacker that managed to exploit an ASP server for a random webpage, and was able to get all the way to Valve's perforce servers and steal a copy of a the tree for Half-Life 2. There's no reason in hell a random web exposed server should be on the same network as their Perforce server, but that's what having poor internal network security does for you.

npsimons• 12 years ago

By that argument, you should be naming servers after Aztec gods (Tlahuixcalpantecuhtli, anyone?)

zx2c4• 12 years ago

I've never seen MNX before. I noticed in their pricing and features that they offer "additional IPs at no extra cost". Has anyone had experience with this? Are there limits?

nwilkens2• 12 years ago

Thanks for checking us out!

We ended up chatting -- but for further clarification for anyone else -- yes, you can have additional IPs if you can justify them. There are practical limits, but we haven't come across a situation where we've needed to enforce a hard limit at this point.

arthursilva• 12 years ago

Good post. Does anyone knows this company? To the company: VERY BAD call requiring users to signup to check custom instances, specially at the beginning, you should prefer new customers to new signups.

nwilkens2• 12 years ago

Thanks for the feedback! We're still optimizing, and this was a mistake not to put the pricing calculator on the main website.. we're working on that and will move it to the main page soon.

kbar134• 12 years ago

service discovery via DNS on top of etcd: https://github.com/skynetservices/skydns

I personally believe that servers should not have names, as naming them just creates the incentive to try to fix broken infra instead of just killing and respawning. I've considered using some kind of short UUID for hostnames instead.

bryanlarsen• 12 years ago

"short UUID" is an oxymoron. If it's short, then it's not universally unique.

Assuming you meant "short ID", how is that any different than the OP's suggestion of randomly choosing from a list of meaningless names?

Alupis3• 12 years ago

I think it would matter what the Universe is for their environment. A UUID may be fine as "server123" if there will never be a collision in their environment (ie. server124, server125, server 126, etc).

aroch• 12 years ago

It only has to be "universally" unique within the DNS servers you query, no?

awalton3• 12 years ago

"Short" is relative. 4 billion IDs is likely Unique within an organization, even one the size of IBM, Google or Microsoft.

peterwwillis5• 12 years ago

"Hey Al, could you go take a look at the drive on the secondary mysql server? I think it might be throwing a fault condition."

"Sure Frank. What's its host tag name?"

"AF84n3Dd2PM."

kbar134• 12 years ago

Not sure your comment is intended on proving a con of naming servers as random strings, but honestly I would consider that a positive. If hostnames are actual words, then people are able (and sometimes incentivized) to transmit them verbally. This can lead to communication issues.

If the hostname is randomized, then the logical thing would be to copy and paste the hostname and send it off over the wire, which would theoretically cut down on human error.

awalton3• 12 years ago

That's taking the "pets" vs "cattle" meme a bit literally. Memorable hostnames can be given to both pets and cattle.

However, I personally question the wisdom of giving a network intruder a roadmap to your internal network via easily predicted DNS names, but that's probably just me being paranoid.

johne20• 12 years ago

I used to go the multiple subdomain approach until I discovered some wildcard SSL certificates do not support more than one level of subdomains. Therefore, I now do something like staging-nyc.example.com

flyt2• 12 years ago

All wildcard SSL certs only support one level of subdomain.

derefr• 12 years ago

You can use a SAN cert to create a multi-level wildcard cert. The cert would be issued for:

    example.com, *.example.com, *.*.example.com, *.*.*.example.com [...]

siliconc0w2• 12 years ago

Use something like a mac address and map them logically (i.e use chef envs/roles/tags). This forces you to stop remembering hostnames and setup automation to ssh/run commands. If you try to encode information into hostnames you head into the deep end pretty quickly and it's probably going to change in six months anyway.

jmtulloss2• 12 years ago

I believe that's why the information is all encoded with CNAMES. That way you can change purposes easily without ever touching the original A record, which refers to the hardware (not its function)

eldavido3• 12 years ago

You should be very careful with this. Even a relatively low TTL of 300 (5 minutes) can be too long to wait during a major outage. Make sure changing CNAMEs is a very rare thing, and be prepared to tolerate inconsistency.

It's also worth noting that some widely-used pieces of software cache DNS lookups in-process (MongoDB), so changing a DNS name is no guarantee that all connected processes will automatically fail-over to the new machine unless restarted.

Moral of the story: distributed systems is hard

tacticus2• 12 years ago

Cnames are really quite poor for this unless the cname information is being driven from some other tool that you can easily do lookups on.

Otherwise you won't be able to get that classifying information on the end host.

brugidou• 12 years ago

Using a deterministic ID for machines is definitely the way to go.

We actually studied this for a while and MAC address is a pretty universal ID that works virtually anywhere. We use the smallest physical non-zero MAC address in case of multiple NICs. We considered using chassis or baseboard serial numbers but it gets too vendor specific.

ghshephard4• 12 years ago

The problem you run into with using the MAC address is what happens when you swap out the NIC?

worklogin• 12 years ago

I'm not following. The whole purpose of naming is to make it easy. I don't want to remember 000a43dbac72.example.com, it's easier to remember "pine" and "oak" and trust me, after working in the environment a while, everyone knows what every keyword is.

tacticus2• 12 years ago

Over a certain size you want your tooling to take care of that knowledge not you. You don't want your sysadmins or developers deriving information from records that can change.

if your developer or sysadmin assumes that the server named castle will always be something special instead of looking in the CMDB or other ENC for that information you will have less fun in the long run.

tl;dr random names with a central ENC forces you to only get meaning or facts from one central repo.

siliconc0w2• 12 years ago

The benefit here is mostly just with larger infrastructures where you're gonna run out of wood names and where agreeing on and enforcing naming standards is a futile and painful process.

With logical mappings, you just use chef/puppet/cmdb to do something like sshnode prod app 1 to connect to the first production app node or sshnode prod app to connect to all the production app nodes. CNAMES can do this too but then you run into potential DNS consistency issues. With this you get the human friendly abstraction and keep the machine friendly determinism.

Of course when your chef server goes down this can be a PITA (I recommend building in some knife search caching!)

Shivetya• 12 years ago

I am still trying to understand their reasoning myself, unless you just have hundreds of servers I can see no reason to resort to numeric naming methods, that might be fine for arrays/sorts/computers but not people. It looks good on racks but for representation to humans, argh.

Ours are named for location and function. There are some large servers which have six character names as they so unique/important to the organization there is never a question. Usually though many fall into <owner+location+environment)

However I can see justifications made in either direction, its no worse than coding conventions that people come up with.

davidw• 12 years ago

That sounds like premature optimization for a lot of people.

danudey2• 12 years ago

Part of the problem is that hostnames are so quickly ingrained into our workflows that when you only have a few servers there's no point, and when you have a bunch it's too late – unless you want to spend a lot of time changing every reference.

If you start building a small cluster which you know is going to grow into a big cluster, then these aren't really premature optimizations so much as laying a proper foundation. It's the difference between rewriting some of your Python in C and making sure all your python code is packaged into sensible objects and grouped into libraries.

oddevan2• 12 years ago

OK, I suppose a list of common, easy-to-pronounce words is ok...

I use Pokemon. What do you use?

Crisco• 12 years ago

I tend to use names from different mythologies, so I usually end up with names like "osiris," "lorien," "cernunnos," etc. Makes for easy to remember names, and I never expect to run out of them.

couradical2• 12 years ago

I used to run a dual stack app, windows was Roman mythology, linux was Greek, that allowed us to keep roles straight across environments - apollo/hermes, athena/minerva, etc.

DmitriRavinoff2• 12 years ago

You...do know that Apollo and Hermes are two entirely different entities, right? Hermes is the counterpart of the Roman Mercury. Apollo has the same names in both pantheons.

tlrobinson2• 12 years ago

Relevant: https://www.youtube.com/watch?v=0Jx8Eay5fWQ

emilecantin2• 12 years ago

I use famous computer scientists. My Macbook is named Woz, and I also have Kernighan, Ritchie, Torvalds, etc.

yzzxy• 12 years ago

Now all I have to do is become a famous computer scientist and accuse you of stealing my hardware!

kijin2• 12 years ago

Do you also match the names with the technologies they're related with? It would be awkward to call a Windows server "Torvalds".

PLenz• 12 years ago

They are all named for the mountains of New York State in decreasing height order.

simonw• 12 years ago

I once used Cthulhu mythos monsters. It turned out to be a bad idea: those things are horribly hard to spell.

gknoy• 12 years ago

I'd be afraid to wake them from hibernation.

ohitsdom• 12 years ago

Star Trek: TNG characters. Excluding Data to avoid confusion, of course.

pndmnm• 12 years ago

To this day, my favorite naming scheme I ever encountered was names of elements, everything CNAMEd to the elemental abbreviation, with the last octet of the IP address as the atomic number. It was for a geophysics group, which probably made it a little more discoverable/easily spellable.

kijin2• 12 years ago

That might work for a private network, but what if you have a /24 and need to use the entire range?

Maybe find molecules with the corresponding molar mass, e.g. glucose = C6H12O6 = 180?

rootbear• 12 years ago

I had that idea ages ago and I'm glad someone actually used it.

Groxx• 12 years ago

Nearby restaurants. Admittedly a shorter list than Pokemon :)

Sir_Cmpwn• 12 years ago

My fairly modest home network uses characters from Madoka Magica.

bottompair• 12 years ago

Porn star names will usually do the "trick".

tlrobinson2• 12 years ago

At 280 North we used exit names along 280... woodside.280n.com, pagemill.280n.com, sandhill.280n.com, etc

https://en.wikipedia.org/wiki/Interstate_280_(California)#Ex...

mehmetemre• 12 years ago

I use a bunch of anime characters when naming the machines. Source of my inspiration is: http://www.phdcomics.com/comics/archive.php?comicid=1467

oddevan2• 12 years ago

Excellent. Somehow I've managed to call a side project server here "Toothless".

thoughtpolice• 12 years ago

We use the names of Final Fantasy characters.

vacri• 12 years ago

Bananaman characters here. In hindsight, they're nice and clear and short, and as a bonus, I get to refer to our staging servers as 'blight' (after General Blight)...

blitzprog• 12 years ago

I second that one :)

Aqua_Geek• 12 years ago

Characters/references from Arrested Development: Gob, Buster, StairCar…

krallja• 12 years ago

During my final internship, the sysadmins gave every intern a Dell named after defunct air carriers. (Mine was PANAM.)

mediaserf• 12 years ago

I generally use hyphens instead of subdomains for SSL certificate purpose and go general-to-specific in the order:

datacenter-application-environment-index.domain.com

example:

ord-web-prod-01.domain.com

For clouds I use the cloud and zone/region:

rs-ord-web-prod-01.domain.com aws-east1-app-stg-01.domain.com

Alupis3• 12 years ago

I really dislike the suggestion of labeling devices by what they are.

fwl, ups, pdu, rtr, swt, etc... all really give away too much info imho.

Yes, someone may discover what the device is on their own via nmap -O or something, but telling someone up front this is a PDU and if you mess with it, it may crash an entire cabinet... is just... silly.

I tend to follow the parent comment's suggestion more, labeling by location and environment (prod, dev, etc).

DmitriRavinoff2• 12 years ago

Assuming you're doing split-horizon DNS, those records should be hidden from the outside. And the only way to detect the CNAMES other than brute force scanning of a DNS zone is to do a zone transfer. And you only have zone transfers allowed from other relevant DNS servers, right? And your monitoring software will catch a brute-force scan, right?

Remember that the reverse dns always resolves to something like orange.example.com, which gives away no information at all.

tetha3• 12 years ago

One thing to consider: .'s cooperate better with graphite, salt-stack and possibly ssh-configs, since in those tools, * matches everything but .; Thus, something like * .foo.* .* .domain.com.metric selects the metric for all datacenters & environments for the application foo. Using hypens, this doesn't work.

(Why can't I escape * 's? ....)

andrewchoi• 12 years ago

2 hours and no reference to the relevant XKCD?

http://xkcd.com/910/

e12e• 12 years ago

Because it's in the top of the page of the story you're commenting on? I'm sure we can keep hn from turning into /. for a couple of more years yet... ;-)

girvo• 12 years ago

Well, it was posted in the article itself, so I'm guessing thats why no-one had reposted it here.

Pxtl4• 12 years ago

Why do they do this? Why do infrastructure people suffer so much pain learning the same lessons software developers learned many years ago?

1) Join the vowel generation. If your tools cannot handle unlimited length names, use different tools.

2) Use descriptive names. Don't name them after your pets.

3) Rigid rules like Hungarian Notation produce cryptic and irrelevant noise.

286c8cb04bda• 12 years ago

Why do they do this?

This short form is "for historical reasons". That's not "they're too lazy to fix it" reasons, rather there is a very large amount of hardware deployed elsewhere which you might have to interact with making assumptions. You have to fit within the lowest common denominator of all those assumptions.

If your tools cannot handle unlimited length names, use different tools.

Because that's not possible. According to the RFC[1], FQDNs are are limited to 255 characters. Individual components (i.e. between the dots) are limited to 64 characters. Having to account for e.g. IDN, means space limits are an active concern.

[1] http://www.ietf.org/rfc/rfc1035.txt

jrochkind1• 12 years ago

The idea proposed by OP is precisely NOT to use a descriptive name as the base A record.

Why? Because the functions served by this machine may change over time -- so any descriptive name you use may become confusingly inaccurate.

But you need a way to refer to the _machine_ itself, whose functions may change over time. The best way to do this is to pick a _non-descriptive_ unique identifier that will always refer to that machine. As the OP mentions, that non-descriptive unique identifier "will mostly be useful to operations engineers, remote hands, and for record keeping."

Then you make a descriptive name as a CNAME. Which, they don't mention, but it might change over time what that CNAME points to etc.

I have found this general principle to be a very good one even in my much smaller shop. When we used descriptive names as the 'main' canonical machine name, this led to huge confusion when roles changed -- you either had descriptive names that were no longer accurate or confusing, or you changed them but still had documentation or notes or tickets referring to the old name, etc.

The rest of the OP goes into a suggested scheme for making the descriptive names (the CNAME's), in a way that will actually _be_ descriptive of what developers and ops will need to know. Their scheme seems pretty decent to me, but definitely depends on the particular context and domain of the shop, including how many machines you have, if they are geographically dispersed, etc.

But the basic concept of using a _non-descriptive_ name as the basic machine name A record, with descriptive names being CNAMES to it -- is I think pretty widely applicable and wise. (And that mnemonic projet list is pretty useful for creating non-descriptive unique identifiers that are still easy to remember and record).

peterwwillis5• 12 years ago

He didn't say to use a functional name, he said descriptive. If the machine is an hp bladecenter 7000 series, reflect that in the name. The functions may change but the silicon will not. If you're paranoid about security, create class names that refer to classes of hardware and number identical/similar ones.

Also it's useful to put the dc and rack number in subnets after the hostname (hpbl7x0001.r55.la.example.com). The next time you're running around the cage reading every single 1U's tag name going "AARRRGHFHH WHERE THE FUCK IS SLIMSHADY.EXAMPLE.COM??", you'll thank me.

(i have no idea why, but it's much easier to get a dns admin to create a new A record than it is to get a NOC employee to update the network inventory database)

(also: good luck using your network inventory db to look up a rack location when the rack/switch that's hosting the network inventory db is down...)

ztnewman• 12 years ago

Get off your high horse and actually read the article - descriptive names should be temporary CNAMEs. There's nothing rigid about an easily changeable pointer. And 'just use different tools' is a naive and reactionary approach.

Pxtl4• 12 years ago

Their "descriptive" names are Hungarian Notation for servers.

tambourine_man• 12 years ago

Thanks for this link: http://namingschemes.com

It's one of the two hard problems, you know. Help is always appreciated.

http://martinfowler.com/bliki/TwoHardThings.html

PieSquared• 12 years ago

I like the suggestion on the first link that these naming schemes should be used for kids. An amusing site :)

chrisweekly• 12 years ago

Wait a minute, I always thought the two hard things were cache invalidation, naming things and off by one errors.

kachnuv_ocasek• 12 years ago

No, those are the four hard things.

mbreese• 12 years ago

In the "expanded" set, there are technically three hard things - you forgot dealing with February 29th.

drivingmenuts3• 12 years ago

I got burned in a tech interview with off-by-one errors. I had signed into a shared editor to do some simple practice stuff for the interviewer.

He noted the off-by-one errors as a concern.

I was thinking: this is untested, unreviewed, 2-minute code that shows I can at least do some sort of problem solving. I'm nervous, don't know you, kinda worried about the tone of this interview and you're worried about off-by-one errors.

Kinda glad I didn't get that one. Wish I'd just hung up on the guy.

tootie2• 12 years ago

Wow, that's interesting. Had a similar thought not too long ago about applying a naming scheme to identifiers in code. Not like this or Hungarian Notation, but more like a controlled vocabulary variables with the same meaning use the same name across your codebase. So no more using "price" here and "amount" there. That would directly address the second hard thing.

weinzierl• 12 years ago

In the aerospace industry there is something called "Simplified Technical English"[1]. Maybe something like that already exists for your domain as well?

From the linked Wikipedia article:

    The approved words can only be used according to their specified meaning. For 
    example, the word "close" can only be used in one of two meanings:

    - To move together, or to move to a position that stops or prevents materials 
      from going in or out
    - To operate a circuit breaker to make an electrical circuit

    The verb can express close a door or close a circuit, but cannot be used in 
    other senses (for example to close the meeting or to close a business).

[1] http://en.wikipedia.org/wiki/Simplified_Technical_English

wpietri2• 12 years ago

Given that thought, you'll likely enjoy Eric Evans' "Domain Driven Design". I love that book: https://www.google.com/search?q=domain-driven+design

corford2• 12 years ago

My naming system is pretty similar. Infrastructure consists of a handful of big beefy machines that then each host anywhere from 4 to 12 single purpose guest vms.

For the beefy host machines, I just go with core-a, core-b, core-c etc plus a geo tag. So: 'core-a.de.domain.local', 'core-b.de.domain.local' etc.

For the vms, they get functional names like 'n0-dbc1.de.domain.local' (for node0, database cluster 1) or 'git.de.domain.local' etc.

Only the last two digits of each guest vms mac address (or addresses if it has multiple eth interfaces) changes. The rest is tied to the underlying host machine. So e.g. 00:50:56:01:01:06 means a mac for a guest on 'core-a', 00:50:56:02:02:03 means a mac for a guest on 'core-b' etc.

All internal non-publicly routable IPs use our domain and the '.local' TLD (with bind serving our internal network). All external, publicly routable IPs use our domain and the .net TLD. Finally, our frontend website IPs use our domain and the .com TLD.

The above wont scale well beyond one or two hundred vms per data centre location but if we ever need more than that, it will be a nice problem to have :)

btgeekboy2• 12 years ago

I'm guessing you don't use live migration of VMs very often?

corford2• 12 years ago

Nope, never. If a vm needs permanently moving from one core to another (which would be unusual for us), we just spin it down and dd the lvm volumes for that guest via ssh and then change the mac.

It helps that we don't filter on mac. The main reason for tieing the addresses to the underlying core is to avoid accidentally allocating the same mac to two different vms (since at the moment vm creation is still a relatively manual process for us - hoping to improve this in the future though!).

Fizzadar• 12 years ago

In what world is `tst` a better part of a hostname than `testing`? All this article seems discuss is a naming scheme for lazy people who don't want to type long and descriptive hostnames.

unfunco• 12 years ago

That was my first thought, the author seems to like three-letters, I don't know why `sql` is better than `db` for database, considering not all databases are based on the SQL standard, and `mta` for mail server? Really?

stonogo• 12 years ago

It is easy for the hacker news crowd to forget this in an age of google apps, but lots of organizations run their own -- possibly substantial -- email services, and in a well-scaled email setup the mta may be a completely separate machine from the mda/msa/mra.

Having a "mail server" might be fine for lots of places, but having disparate machines with specific functions is not invalid.

elasticdog• 12 years ago

Author here...the important thing isn't the abbreviations, but having a standard that you can agree upon and use consistently. The listed items are just an example scheme that tries to keep the length consistent to make scanning though a list visually a little easier.

KaiserPro• 12 years ago

I've been through a number of naming schemes for a few different purposes.

Firstly all VMs are named after their function(AD01, named01 etc) we never re-purpose VMs

Workstations went through a few conventions dependent on size:

o sysXXX

o french revolutionaries

o generals from WW2

o Fellows of the royal society

o Towns of the UK

My favorite is fellows of the RS, as a lot of them have wiki pages.

The key thing is that you don't recycle names. When a machine dies, so does the hostname

mkfifo2• 12 years ago

Thanks for making it so clear what services your machine provides on the public internets. I like advertising on the public internets too and sometimes I even run SSH on port 22 with root access enabled for convenience sake. Also, since I have so many servers, I make sure to run fingerd and include hints to what the root password is in my plan (everybody knows what it's like to forget a pw).

Another good thing to do, I was told that according to RFC1413, always make sure you are using identd service, it's a very helpful protocol.

I just don't get why people are so paranoid on the internet I've been a sys admin since the 90's and never once had a virus or been hacked.

I guess with everything now being a "devops" world, we should just focus entirely on convenience and forget about the old timers annoying speeches on "SPOF" and "Security/Risk Management" that block me from pushing my awesome new codes to production as quickly as possible. We use Chef and CI so I don't ever have to even think about the server itself, other that it is running Ubuntu, which is super fast and a very secure OS.

I love when new software comes out, I just grab the recipe and ship it! Even if it is geared to server farms with hundreds of machines, I probably need to use it for my 5 server cluster.

Anyway, sorry to get off topic.

xenophonf2• 12 years ago

I'm an infosec guy, and I think sometimes we can make things so difficult for attackers that it becomes too difficult for our sysadmins to do their jobs. Using obscure, pseudorandom server names is a good example of this. If I get an alert that says, "uxeprdweb05 is down", I know to immediately check the Mason, OH, production hypervisor cluster/web server rack. If the alert says, "I-2A51DDBCE621 is down", I have to look up that host in my CMDB before starting any troubleshooting. Sure, "uxeprdweb05" leaks information to attackers, but it's nothing they couldn't find out with a port scan. In the meantime, I and my colleagues don't have to go through a lot of unnecessary indirection to do our jobs.

As to the security benefits of configuration management tools, again, speaking as an infosec guy, I love them. I can push a locked-down, default-deny base config out to all of the computers under my care, and I don't have to worry about making a mistake or missing a step or forgetting to document something. I can work with the devops team to set up automated functional and security testing using a continuous integration tool, so that config changes (including security updates!) get vetted automatically in a development or test environment before being pushed to production. I can put the whole config under revision control, so if there is a service or security incident due to a config change, we can figure out how our development and testing processes failed us - and how we can improve them.

And finally, speaking as a ardent FreeBSD user, I wholly agree that Ubuntu is utter rubbish.

;)

mkfifo2• 12 years ago

I am not talking about insane cryptic obfuscation, i am simply stating that advertising services by publicly naming your server what it runs is flat out n3wb stupid.

joeyspn• 12 years ago

tl;dr: Security through obscurity never is the best choice =)

[0] https://en.wikipedia.org/wiki/Security_through_obscurity

Spooky23• 12 years ago

There are different extremes. I've dealt with plenty of security admins whose religous adherence to the cults of compliance and network segmentation make it impossible to get anything done.

thezilch4• 12 years ago

Presumably you'll need to iterate over hosts anyway, so why not move directly towards your automation tools' (ansible, chef, puppet, etc) host inventory and not fuss with DNS...

/etc/ansible/{dev,test,stage,prod}-hosts

  [nyc-dns]
  10.0.1.1
  10.0.2.1

  [nyc-web]
  10.0.1.21
  10.0.2.21

  [nyc-db]
  10.0.1.201
  10.0.2.201

  [nyc:children]
  nyc-dns
  nyc-web
  nyc-db

  [lax-dns]
  10.0.1.1
  10.0.2.1

  [lax-web]
  10.0.1.21
  10.0.2.21

  [lax-db]
  10.0.1.201
  10.0.2.201

  [lax:children]
  lax-dns
  lax-web
  lax-db

  [dns:children]
  nyc-dns
  lax-dns

  [web:children]
  nyc-web
  lax-web

  [db:children]
  nyc-db
  lax-db

e_proxus2• 12 years ago

Just started out with Ansible. How do you efficiently SSH into all these hosts by name instead of IP?

thezilch4• 12 years ago

At the low level, Ansible has the ability to execute ad-hoc [0] modules [1] against any combination of hosts defined. In my host(s) inventory above, you can execute ad-hoc modules against just nyc-web, lax-web, web(against nyc and lax), or whatever suites your needs or you've defined a host group for in your inventory.

Report, using the "command" module, free memory on all "nyc-web" hosts in our "prod-hosts":

  ansible -i prod-hosts nyc-web -m command -a 'free -m'

More often, we'll want to have Ansible playbooks [2] that take our hosts and assign roles. Briefly on the topic, we might have a "common" role that deals with updating our package manager, checking/upgrading packages that every machine should have (eg. ssh, ntp, etc), and ensuring certain processes are running. Second, we might have a "web" role that is similar to "common" but dealing with web-server specific packages, configs, etc. As to keep it brief, we'll skip how the roles are setup, but here's our "web" playbook (web.yml), and find that we've defined the hosts [group] to execute against -- all hosts under our "web" group in the hosts inventory.

  ---
  - hosts: web
    remote_user: web-user
    roles:
      - common
      - web

Which we'll execute with:

  ansible-playbook -i prod-hosts web.yml

Maybe you only want to hit nyc-web and not all web hosts? The following will take the intersection of the playbook's hosts "web" and the "limit" hosts "nyc".

  ansible-playbook -i prod-hosts web.yml --limit nyc

Or maybe you know the one IP you want to hit. The ":&" syntax is a logic AND to find only the nyc 10.0.2.21, because we also have one in LAX. If your IP layout, then simply a "--limit 10.0.2.21" would do.

  ansible-playbook -i prod-hosts web.yml --limit 'nyc:&10.0.2.21'

[0] http://docs.ansible.com/intro_adhoc.html

[1] http://docs.ansible.com/modules.html

[2] http://docs.ansible.com/playbooks_intro.html

kaonashi• 12 years ago

Where do you put the Star Wars references?

drivingmenuts3• 12 years ago

Don't forget to encode the physical location if that's a thing. It might be important to know that web02.prd.nyc.com is in Row D, Cage 4, Slot 5, Front.

ChikkaChiChi• 12 years ago

I found that naming my servers after characters legendary badass mexican Danny Trejo has played to be cathartic and awesome!

Machete, Vega, Jack, Oscar, Angel, Tattoo, Tigre, Carlos, Vic, Reynaldo, Guerrero, etc...

eldavido3• 12 years ago

We used something very similar to this where I work (Crittercism). I designed most of it.

I used five-part DNS CNAMEs exactly how they're specified in the article (a bit shocking, actually) except that mine switch the "group name" (prod, staging, CI, etc.) and the geography, with the rationale that "groups" can span several geographic areas (example: a multi-regional production environment), so they're logically the "containers" of geographic regions.

Example: rtr01.us-west-2.prod.crittercism.com, NOT rtr01.prod.us-west-2.crittercism.com

Great article.

Asparagirl• 12 years ago

I like your way better.

wyc• 12 years ago

I name my servers with names fitting ships so that I may have a proper fleet of boxen.

alpb• 12 years ago

stg or str is better than sto (storage).

jflowers45• 12 years ago

"and yet you settled on Caroline as a name in a few seconds" ... that's a pretty good cartoon

kayoone• 12 years ago

This list of hostnames comes to mind from an older thread: http://seriss.com/people/erco/unixtools/hostnames.html

tallanvor• 12 years ago

Our primary server names identify the location (for us), and we try to keep it very short:

So for example: sea1r001u01. Our team in the data centers provide the initial name based on where they place the server. The unit value starts at 01 at the top of the rack and increases sequentially.

This means that if we have a hardware issue, the data center teams only need the hostname to know exactly where the server is located and get to it.

andyhmltn• 12 years ago

I actually had this problem a while ago but now I use a script I wrote:

https://github.com/andyhmltn/frosty-meadow

To generate one during the setup of the server automatically

bencollier49• 12 years ago

This scheme has no way of denoting if a machine is virtualised or not.

antocv• 12 years ago

dev,stg,prd... omg, whats so bad about actually spelling it out?! Its not like you require those precious bytes for your business to suceed.

ZoFreX• 12 years ago

"The actual purpose abbreviations you use aren’t important, just pick a scheme, make sure it’s documented, and stick to it."

Given that in some cases you might be typing them very frequently, some people would want to shorten them. I assume it's more to do with typing speed than saving bytes somewhere.

thiagoharry• 12 years ago

I use pokémon names to name computers. I just pick the last 9 bits from the computer MAC address, add 1, and check which pokémon have this number in the national pokedex. This scheme can be adapted depending of the network. Perhaps you could use the names of legendary pokémons to name servers and more important computers. It's easy to find images, ASCII art and perhaps even toys to put in the computers to help identification. And even if your network gains 40 new computers each year, the number of existent pokémons grows more than this and you won't be without names. :-)

Flenser• 12 years ago

When this came up before I liked the comment from an ex-dropbox employee on how dropbox found positional hostnames to be a the best solution: https://news.ycombinator.com/item?id=6540044 (top comment by gmjosack)

robaato• 12 years ago

I worked in the field of infrastructure documentation for a while, applying configuration management principles to it.

Naming is very important and often done poorly. The positional scheme you link to works very well.

You need to label things, and bear in mind that you might be asking some outsourced third party "pair of hands" who has no knowleged of your environment to reboot a box - you want to be sure it's the right one!

Active equipment like servers often have naming conventions around function etc, but consider what happens if someone remotely renames the server and its physical label is ot updated...

For passive equipment, e.g. patch panels, we recommended a suffix indicating U position (being consistent about whether U's coount from the bottom, and which edge defines the U position). Most places start with U1 as the bottom U position, and equipment that might take up Us 1&2 is defined as being in U1 (bottom edge). Alternatives OK, but be clear and consistent.

Many organisations are not definitive on location ids, down to city, name of building within the city, even the names of rooms within a building - multipe names often used!

Examples might be:

LON-DOCK1-DC1-AA02-PP-U41

LON-DOCK1-DC1-AB02-SW-U23

Sometimes:

SVR-LON-DOCK1-DC1-AB03-U01

(without U suffix is fine for such kit often)

Lots of fun in this area!

ingenter• 12 years ago

Another interesting naming scheme: http://www.reddit.com/r/nameaserver

harty65• 12 years ago

We decided to be democratic in our office and arrange a vote for the name of the new server. Unfortunately this resulted in the server being called "Ron's Electric Love Machine". (Thankfully this abbreviates to RELM which is a bit easier to deal with)

rachelbythebay• 12 years ago

Even when you pick a naming scheme, it'll eventually cause grief if you get big enough.

Name your machines XXYYN[N] where XX is the building name, YY is the rack name and NN is the position in the rack? You'll eventually have more than 676 buildings, 676 racks, or 99 machines in a rack. Multiple people will have written regexes to split that into building, rack, position and they will break when you grow one of the fields.

dredmorbius• 12 years ago

That's where the subdomain-based CNAME system comes in handy.

And I'd argue that building numbers probably don't want to be part of your scheme.

    purpose###.env.loc##.domain.tld

is about as deep as I'd like to get with my hostnames (though there are other options for shortening them, with DNS search directives and such).

Encoding:

    purpose###.rac###.cab###.aisle###.env.loc##.domain.tld

... might keep you from losing boxen. You will hate yourself typing that. Store the metadata elsewhere, perhaps a txt record for the host.

tragomaskhalos• 12 years ago

Big choice of names? Memorable? Fun? Just name them all after Muppets.

15thandwhatever• 12 years ago

It all depends on your environment.

Do you manage 12 machines in a closet, 200 EC2 instances, or 1,500 systems in 5 datacenters?

Do you have more than one datacenter in a given city? in a given campus? in a given building?

Do you build systems that serve a single purpose such as a database, or do you run multiple daemons on a single system? How do you take docker/containerization into account?

How often are your sysadmins logging into these systems? Once a week (spell out "production"), or 20 times a day (abbreviate it as "prod")?

Are your systems all owned and operated by you? Do you manage systems for multiple clients in the same datacenter?

Does your team consist entirely of your college roommates you started your company with? Or are you a team of 20 spread out across different time zones and different countries? Will your funny/memorable names be offensive?

This all seems like an exercise in trying to build the The Server Naming Tower of Babel Bikeshed.

romaniv• 12 years ago

Yeah, but most of those are good ideas for a moderately large business that's not managing other people's servers. Especially mnemonic names. Would you rather reference ruby.web or W1L1Z (which is often the kind of cap that people come up with by default).

jjmiv• 12 years ago

was the mnx.io article talking about the hosts file? or what you put in your dns manager....or both?

ttctciyf• 12 years ago

I suppose it makes sense to get rigorous and logical about hostnames from an admin point of view, but I do miss the romance and personal expression of naming machines after.. well, scifi entities, fairy-tale dwarves, whatever.

One of the many things I like about my ISP is that they apparently feel the same:

  traceroute to 192.9.9.100 (192.9.9.100), 30 hops max, 60 byte packets
  1  X.X.X.X (X.X.X.X)  7.057 ms  8.826 ms  8.859 ms
  2  c.gormless.thn.aa.net.uk (90.155.53.53)  26.691 ms  28.136 ms  27.243 ms
  3  c.aimless.thn.aa.net.uk (90.155.53.43)  29.673 ms  30.793 ms  30.273 ms

akshatpradhan• 12 years ago

How would this naming scheme work if you're using heroku?

A Server Naming Scheme

Related Stories