RFC 1178: Choosing a name for your computer (1990)
tools.ietf.org
tools.ietf.org
I can't find the post that linked it, but it had a very nice scheme.
EDIT: found it: https://mnx.io/blog/a-proper-server-naming-scheme/
EDIT2: one-liner to get a random word from the file:
cat wordlist.txt | tail -n +2 | sed -E 's/\s*(\w+)\s+/\1\n/g' | sed -E '/^$/d' | shuf -n 1
i.e. <print file> | <skip first line> | <split lines into words> | <remove empty lines> | <choose random line>
This might be the coolest thing I've read all year...
Some time later we got two more boxen and the female members of our research group were given the job of naming them, and we ended up with 'itchy' and 'scratchy'...
* for the Pratchett readers I was wrong, it should of course have been 'Kaos'...
It is fairly straightforward to incorporate into your infrastructure as code workflow for managing your "cattle".
One problem I see, specifically for the environment, is that "dev" is now a TLD (thanks Google!), so you have to be careful should you try to do a short cut like "web01.dev" you may get a surprise depending on your resolv.conf:
* https://en.wikipedia.org/wiki/.dev
Lots of 'generic' TLDs now thanks to ICANN:
* https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
There's both ".accountant" and ".accountants".
The article describes geographic sub-domains, and uses "nyc" as an example, but that's a TLD now as well. It may be better to use UN/LOCODE as a starting point:
* https://en.wikipedia.org/wiki/UN/LOCODE
If you don't need down to the city/municipal level, then ISO 3166-2 may be useful (<nation><hyphen><subnational>):
sed "$((RANDOM % 1632 + 1))q;d" words.txt
wget http://nerab.github.io/wordlist/words.txtDon't do it! If you're labeling hardware and need multiple functions, use virtualisation or containers, and then the host is named after that (e.g. we use Ganeti, so gnt-01, or say kube-01).
At home, I name machines after inspiring political figures and while I like the naming, it does discourage me into treating those machines as cattle, which I should do more.
I had no idea how many kinds of onions there were turns out there are many, especially if you start to take in Latin names and translations...
But then I need to learn how to spell colchicifolium, and neriniflorum, and no, those two are not related (or are they) and what does meronense do again? and oh yeah corsicum is the replica of one of those...
Those naming conventions are cool until you start to document your stuff properly and start being serious about training and including new people. Then you should focus on meaningful, easy to remember, type, and generate, names.
I manage my stuff with Ansible, which makes all this pretty easy.
at first I couldn't either, but then I learned it's an old KVM node hosting a bunch of virtual machines, and it means pain, definitely something severe. yet it's not meaningfully different from "corsicum" dying (which is "just" a VM).
adding meaning to machines reduces the cognitive burden (for oldies) and discovery burden (for newcomers) of figuring out what is what.
that assumes you don't run services bare-metal. if you do, then maybe it makes sense to use meaningful names for those, but in general, I strongly try to avoid doing that anyways... and if I do, having a functional name for that metal is mostly harmless: if the function changes, the name changes, and then I need to do a name change, which I allow for.
but that is rare, because if i dedicate full metal for a function, you can bet it won't be readily available for other purposes...
It's not that I don't enjoy fun and personal naming schemes, it's just that it's a constant annoyance when dealing with a large number of different systems.
We've been hired to deal with different companies, who picks some random naming, cars, athletes, plants, cities and so on and it's confusing as hell. How am I suppose to remember that Ford and Volvo are your two web servers? Now I need to maintain a list mappings for your servers and look them up every time I need to change your web configuration. Just call them prod-web01.company.com and prod-web02.company.com, it's fine and everyone will be able to guess what those servers do.
You can also do web01.prod.company.com and web01.test.company.com, but while it looks cleaner (and I personally prefer it) is does hide the "prod" or "test" in most shells, so you constantly need to check that you're not messing with a production box.
Have individual hw named in unique way that isn't related to functionality it runs, then use CNAMEs specific to functionality - i.e. never point a DNS client at "freddy.dc.somecorp.com", you point it at "dns01.dc.somecorp.com".
The decision on what machines need unique names, not just pseudorandom IDs or similar crap, is well described by another comment here https://news.ycombinator.com/item?id=26054487 - which I like to put as "named systems are the systems you care about"
In fact, I'll go with seemingly unpopular opinion that there are only pets, never cattle. The pets just happen to have components, but at some level of the stack you're hitting a precious pet. Even if said pet is "us-east-1 Lambda service"
Where I see this most often is with companies that place a unusual high cost on servers, virtual machines or containers. In those cases I normally just application servers, that's a good a description as any. The only difference is that I won't thing twice about deleting a server called app01 and recreate it using Ansible, Puppet, docker-compose or whatever deployment tool that customer uses.
In my mind there aren't "pets" any more, and if there is that's a mistake that needs to be corrected. The customers I deal with who have pet servers are the most dysfunctional and the ones with the most challenges, both technically and organisational.
I think the approach of naming the host "freddy" works for small installations (and all installations in 1990 were small), where reinstalling a single server is a manual process and impacts your capacity, and where humans remember "Oh, freddy is the one with a very large hard drive." If you've got any sort of automation, let alone virtualization, you should be keeping facts about hardware somewhere other than people's heads and so you can index them by the actual identity of the hardware - the fact that web04 had a large disk last year is remembered by a field on your inventory entry for XY1Z234, not by any human. And reinstalling web04 as db02 is just a matter of running a script from the comfort of your work-from-home laptop - certainly no need to visit the datacenter.
I think this lines up with your point about pets being higher levels of abstraction - I wouldn't point any DNS client at dns01, since that's a specific server, I'd point it at a virtual IP that can be bound (possibly multicast) by any dnsNN server that happens to be up. That virtual IP is the pet and the API surface, and it belongs to no actual server.
In my experience, unless a server was a VM host (or, these days, k8s cluster), it was rare that it would be single function. We just didn't have the money to allow such waste of resources. So unless you had single-software with enough requirements to hog the whole box (usually DB servers), then everything tended to have multiple functions, and reimaging was rarer event.
So I prefer to have "Freddy the web serving system", which might contain several machines named in style of R04-24.SFO.i.contoso.com ;) - because "freddy the web serving system" is the part that I care, and individual components enter everyday care only in the metrics of capacity planning dashboard.
This is emphatically not true beyond a certain point, perhaps around 500 boxes or so. My last job involved working on a fleet of about 15,000 hosts; I can promise that extremely few of the servers were precious pets. They really were cattle, and we would blow away and reimage them into different functions (with hostnames matching the function) moderately frequently.
In the case you described, whatever drives the replacement system is the pet - the so-called cattle are just "components" that became interchangeable for the bigger "pet" system. As another commented called it, you need good names at the edge - where the edge for me is the level where you care about the system. We used to care about individual components of a computer and those would be effectively "pets" of the time. Nowadays, you do not give name to a DIMM in your server nor take extra care to ensure it works. And so on, till you reach the level you actually have to care, and that's where you need to name it (IMO) because that's your pet, even if it's composed of what people call cattle.
As for hostnames matching functions - I found much more use when making hostnames reflect basic type of hw and physical location, and would keep the name as long as the location didn't change. The rest depended on what functions were currently applied to the machine.
But the problem with that logic is that the name is not only attached to the metal, it's set (and mostly so, I'd argue) in software, as the OS hostname. And then what happens next is that the motherboard of that precious pet melts down and you scramble to move those drives to a spare, and now you have two metals with the same name.
It just doesn't work so well.
And your fancy random or pseudorandom looking naming scheme is cool and fun until someone new comes in and asks you wtf colchicifolium is...
Name machines on purpose. If the purpose changes, the OS will likely follow as well. If not, renaming shouldn't be that big of a deal, or, to put it another way: if you can't rename, you can't reinstall, and then you'll fail.
Now naming hardware is the "fun" part. when is the last time you did an inventory of your motherboards? or is it disks we're naming? the raid array or individual ones? how about memory sticks? or do you only name precious server cases? ;) after all, that is where the label ends up...
But if a pet "melts", well, the pet died. You moved the functions over to another pet. Whether it's a move from Zeus to Jupiter, or rebuilding your precious cattle management system on eu-central-1 after us-east-1 burned down and you got slapped with data locality requirements, is less relevant ;)
Anyway, is prod-web01 that server with an outdated web server that you keep because of that one system that couldn't migrate, the one with a Java server that runs those proprietary tools, the one with IIS that runs that FOSS code that the developer decided to write in C#, the one supporting your main applications or the one you insulated in a special network because it hosts a powerful API that you don't want to expose?
This was written in 1990, though, and there was no cloud, and VMs were quite rare things, (and we had to walk to school uphill, both ways, in the snow). Machines were physical things, and no one had the budget to buy an entire computer to be the second production web server - a machine ran a lot of different daemons that did a lot of different things, and the roles and responsibilities of a given physical piece of hardware would change as time went on. Which is still true today, but today it's just that a machine runs a lot of docker containers instead of running a lot of daemons, and we don't care where the docker containers are running, whereas back then we very much cared what machine it was running on, because sometimes we had to go to that machine and reboot it or kick it or install more RAM.
At the time, I was working at Alcatel (before it was Alacatel-Lucent, before that became Nokia), on a 450Gbps switch which was used for things like routing satellite TV feeds or handling distribution from big fiber backhauls, or running LANe for small nations. On the third floor, we had several racks of these switches in "the lab" which we used for testing and development work. While you could push a new software load from the comfort of your desk, if you borked things badly enough you'd sometimes have to go downstairs and plug a serial cable into the front of the control card so you could go poke around and force the card into a sane state.
So, when a new hire came in, they might say, "Hey mrweasel, I uploaded a bad load to Spock, and it's stuck in a boot loop. Where can I find that physical machine?" And you'd say, "Head down to the third floor, turn left out of the elevators, walk to the second last row of racks. On your left there should be switches named "Picard", "Riker", "Deana", etc..., and on your right should be "Kirk", "McCoy", and friends. Spock is third on the right between McCoy and Uhuru."
That conversation is way more confusing if all of these machines are named "test01-test20". You couldn't even name them that - there were lots of different products in different areas of the lab, so you'd need the product name in there, and they'd be "rsp7670-test01" through "rsp7670-test20".
And, when you want to push a new build from your desk, it's way less likely you'll mistype "picard" when you want to update "data", but it's quite easy to accidentally clobber "rsp7670-test05" when you mean to overwrite "rsp7670-test06", which was sure to summon an angry developer to your desk asking why you just killed their 48 hour validation testing, 45 hours in.
I had the joy of working on several ATM to the desktop campus networks using LANE and an ATM WAN using LANE to connect several thousand locations for an organization belonging to a large nation state. Thanks for triggering some horrible memories. ;)
If you are dealing with assets in a physical environment then obviously the above doesn't apply.
As a side note: a long time ago (before I knew what I was doing) I ran a Windows Server environment for my dad's business. The main server was Jake and the off-site backup was Elwood.
Uh, my servers with at least 256G of RAM and a raid60 of more drives than you have virtual machines can't easily be moved around.
> If you are dealing with assets in a physical environment then obviously the above doesn't apply.
Yes, baremetal, the only way to guarantee performance!
Single function bare metal, that is. At which point, the boring functional naming scheme re-applies easily.
If you're running multiple different functions on a single box, how are you guaranteeing any performance for any single function? How does that differ from using a hypervisor with similar limiting features?
Depends on what you think is the most costly: kernel control of processes, or hypervisor control of kernels controlling processes.
Based on my experience, no hypervisor is worth the trouble if you have the budget for dedicated servers.
> If you're running multiple different functions on a single box
The thing is, you don't do that unless you must.
No wonder helium was mostly hanging ...
Sorry, could not resist. It is a clever naming scheme. At one site a client used names from The Three Stooges, then they got the 6th server (exhausting the list of the lead characters).
* Don't overload other terms already in common use.
* Don't choose a name after a project unique to that machine.
* Don't use your own name.
* Don't use long names.
* Avoid alternate spellings.
* Avoid domain names.
* Avoid domain-like names.
* Don't use antagonistic or otherwise embarrassing names.
* Don't use digits at the beginning of the name.
* Don't use non-alphanumeric characters in a name.
* Don't expect case to be preserved.
* Use words/names that are rarely used.
* Use theme names.
* Use real words.
* Don't worry about reusing someone else's hostname.
* There is always room for an exception.
Unfortunately, I only remember the test and production server names. The test systems were "Trinidad" and "Tobago". The production systems where "Nevis" and "Nassau" (the app started with an 'N').
The thing that made this work really well was that the first syllable hinted on what the rest of the word would be and then everything beyond that reinforced that you read it right. This even was the case that foreign accents, while slightly off still reinforced the "you heard this right".
The machines _also_ had names of "test01" and "test02" or similar... but we (as devs) never used those names because you had to listen to the end of it to be sure that you had the right machines.
You will read this RFC like this:
$ ietf -n 1178
That's a good point, but humans are very different to computers - machines (be they physical or virtual) are provisioned for a specific purpose (even if that is to be "Fred's PC"), whereas humans need time to grow and can decide for themselves what to do as a career / what their hobbies will be, and change it any time.
But realistically, yes, the RFC is right that you may end up with machines whose purpose changes or multiple machines have the same purpose etc. But when they don't, it is much easier to have meaningful names. If you will name them differently, then please make sure all developers can access the list/mapping document and it is kept updated. It's frustrating if you want to investigate some production problems but end up looking at the wrong server's logs because devops didn't tell anyone they moved an application /website etc.
I like someone else's comment about app01 being easier to reason about and recreate than something named more specifically, and in the modern world, its easy to spin up a new docker instance or VM so there's less need to "let's just add this small service on that machine because it has spare capacity" (where capacity could be CPU/RAM etc.)
There's a good selection, it's pretty varied and there's no shortage of em (assuming you don't exceed 100-200 new systems in a 3 year period). This also has an accidental side-benefit of not being tasked to name new hosts at work, unless your really want to call the new database server Stufful, for example.
Another thing to keep in mind with more descriptive hostnames like `database`, is to serialize them from the start. It's a very minor thing but after you have three hosts with one of them missing the serialization, it's going to stand out like a sore thumb and it could be a major undertaking on changing that name where it's used.
When it comes to project names, there is a certain level of permanence that name (or codename) is going to have. Once chosen, that name will be thrown around in the codebase almost universally. The same does apply to the hostnames, at least in part when it comes to configuration files (and by extension, certain hard-coded hostnames that could linger around in the code years after the host in question has been decommissioned).
Or, as told by xkcd: https://xkcd.com/910/
There were the better-known folks like linus (Linus Torvalds [1]) and gregkh (Greg Kroah-Hartman [2]), but also relatively more obscure people, like shemminger (Stephen Hemminger [3]) and stelian (Stelian Pop [4]).
I didn't recognize most of those names at the time, but now that I do, I wonder what those people would have thought about having a large organization's computers named after them. A bit creeped out, I would think.
[1] https://github.com/torvalds
The most sensible naming scheme for us was to distinguish them by index. But there were two important differences: TPUs have many sizes, which means some are larger than others; if you're using a v3-256, you're very likely the only researcher doing so. They are also distinguished by type; v3 is more powerful than v2. Finally, they are region-based; the less powerful v2's are in the US, whereas the v3 fleet is mainly EU based.
That led to the convention of tpu-v3-8-euw4a-1, tpu-v2-256-usc1a-0, and so on.
The "tpu-" prefix might seem redundant, but I find it's helpful in conversation. That's a personal preference though, and if I had to do it again I'd probably drop the tpu- prefix entirely.
I found this scheme was horrible for VMs though. TPUs are often used for specific training runs, and the scheme above is easily added to bash files / config scripts. But for VMs, you're often SSH'ing into them all the time.
Ultimately we started naming the VMs after the researchers who originally needed them. Our current primary training box is song.tensorfork.com, named after researcher songpeng who it was created for. So the SSH scheme was pleasant: song@song.tensorfork.com for him, shawn@song.tnesorfork.com for me, arfa@, aydao@, etc.
When arfa neded a VM, I simply named it arfa.
All other more complicated naming schemes failed with time. No one (including me) could remember long VM names, let alone ones with numbers in them.
The other scheme that persisted was to use anime characters, as emersion mentioned. Tensorfork itself runs off of vegeta, which is my personal Hetzner server. "goku" was one of our primary workhorses at one point, due to its large VM size.
Our final two VMs are named "test" and "nuck", which also seem to work quite well (much to my surprise). "Is test down?" is almost completely unambiguous. And it's easy to remember which one is which: "nuck" is in Canada, so therefore "test" is the one in europe.
A pattern emerges here: most of our VM names are short, four-letter identifiers: arfa, song, test, nuck, goku, with vegeta being the standout. All other conventions failed with time.
https://mtg.fandom.com/wiki/Forest
These days, for work, it’s just boring unambiguous stuff. I think with more cloud infrastructure and the rarity of shared unix servers with home directories for people, it’s rare that I have any emotional investment in a machine. They’re basically soulless now.
It sees play (I think) in Legacy and Commander where there are a bunch of specific powerful ways to abuse it (e.g., combo off early with Arbor + Gaea's Cradle to generate a bunch of mana), but you're not going to pull that off often in cube, so it would mostly be a basic forest that your opponent can easily remove.
For servers I use for my roommates and I (Jellyfin and the like), we name them after the quirky students that go to our university that we appreciate.
[0]https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
https://tools.ietf.org/html/rfc2468
("2 4 6 8, who do we appreciate")
(IP via pigeons).
The IP datagram is printed, on a small scroll of paper, in
hexadecimal, with each octet separated by whitestuff and blackstuff.
The scroll of paper is wrapped around one leg of the avian carrier.
A band of duct tape is used to secure the datagram's edges. The
bandwidth is limited to the leg length. The MTU is variable, and
paradoxically, generally increases with increased carrier age. A
typical MTU is 256 milligrams. Some datagram padding may be needed.
Upon receipt, the duct tape is removed and the paper copy of the
datagram is optically scanned into a electronically transmittable
form.* https://www.wired.com/2009/09/in-africa-a-pigeon-transfers-d...
[1] The Naming of Servers https://tools.ietf.org/html/rfc2100
Made for great mascot toys and posters on the rack doors.
(My machines all have musical instrument names).
It probably needs updating. It's been a while since the last large leak.
I always wanted to use 'Starships from Iain M. Banks' science fiction', which is why no one ever listened to me.
For personal machines, I have been using adjectives that start with 'i'.
Wikipedia’s decision to delete the list was utterly ridiculous, thankfully they all made it over to the fandom wiki.
Unfortunately they’re now a finite resource, RIP.
The ones in the middle can quite happily be anonymous / referred to only by their address.
https://en.m.wikipedia.org/wiki/List_of_Harry_Potter_charact...
I inherited a couple servers "jules" and "vincent" [after the Pulp Fiction characters]. I added mia and ringo, I started finding remaining names weren't great. Butch is a bit homoerotic. "zed" is one I've used, but I can't wait for the day someone without a sense of humor figures that out. I've also used "chopper" now. "Marsellus" is too hard to spell. "watch" is next on my list, but that's really dredging the bottom of the barrel.
The other network, we used Scooby Doo characters because there was no way that room would ever have more than five systems... of course the next tranche of added systems had to go with a totally different theme. So the room now has the mystery machine occupants, and ... dragons from how to train your dragon.
Now I don't bother and just select the default. Or name it after where it's going to be, or what it's going to do, or when I got it. If I'm going to repurpose or move it I'll probably just reimage it anyway.
The wifi is still named "Periodic" though and it still uses a chemical makeup as the password (e.g. c3h5n3o9).
In my own private home lab -- which has grown way too large -- I like using names of the Garbage Pail Kids [0] as hostnames.
There's a few benefits to this naming scheme, when dealing with physical machines at least: 1) you can usually find a name that suits the "temperament" of the particular host and 2) you can tape the trading card to the host (or the rack, next to it) to make finding / identifying it easier.
--
Naming can make sense, our old cluster was named after orchestra parts. When you logged In you where placed on the lobby. The machines where clustered (violin01, violin02, tuba01) and grouped by function types (percussion were the web servers)
New cluster it’s login01,login02 , the work cluster names I don’t remember...
The iso images are numbered (ubuntu-server-16.04.02-x64.iso or whatever) thankfully, so i have 4 ubuntu templates - "leaving LTS this year", the next two LTS, and whatever the 9 month version is currently (20.10 being the current 9 month version)
Thankfully qemu/docker/lxc have made "freezing" a stable, working machine at 16.04 (or even 14.04 if you had the foresight to set it up on qemu at least) - but now i have tons of naming issues. We use a pooled hypervisor system, so sometimes i name things after which pool "server" they are on because i will spin two vms on different servers in the pool with the same VM name (say asterisk-voip) but when you log in it will say asterisk-pve2 or asterisk-wok3 as a quick "hint" as to when i actually "finished" installing it.
for DNS i only name stuff when an "app" requires it either for TLS/SSL or whatever reason. I don't maintain a real DNS server anywhere, and i really should, but i don't like naming things for literally all of the reasons hashed over by everyone in this thread!
But Genes and Stars are different In my mind because they are names pointing to separate things. Though they are numbered in order of discovery....
Then as they stop being my primary devices they get other planet / ship names. The torrenting machine was suitably called Skaro. :p
Two exceptions are my PiHole and OctoPi. The old PiHole used to be called TimeLock but when I upgraded I didn't keep the name
http://wiki.swordofthestars.com/sots1/Sci-fi_References#Star...
- Device size and computing power maps roughly to the ship size: my desktop is named after a battleship, while my Kindle is named after a destroyer.
- Servers are always named after carriers. It just made sense to me somehow.
- Like the warships, the names can eventually get reused as the devices are replaced.
For this one that difficulty disappeared very quickly once I got to the section where the existence of a computer in Tahiti was indeterminate.
Also don't fall into the trap of just assigning random serial numbers to servers. I later worked somewhere that did this and it makes it difficult to communicate about the servers in the middle of outages. I've had communication issues where I've been talking to another engineer and I was using the first hex digits of the server name and they were using the last as shortcuts and we thought we were logged into different servers and it was the same one. You hardly ever want humans dealing with your server names, but when humans do need to use your server names it is one of the times that really matter because shit is on fire.
Group them by single purpose of what the cluster does with some kind of incrementing number. The idea to use theme names and not "project" names is also deeply 100% wrong. When you have 100,000s of servers you run out of theme names and you'll fail to remember the name schemes in the middle of an outage. Name them after what the servers do, and keep them more or less reflecting their purpose. Consider carefully some kind of numbering scheme to keep the short names unique across datacenters so you don't have a dozen foo-101 servers. You may want to use incrementing serial numbers for both datacenters and cluster members or something so "foo-1-101" and number your datacenters (or logical cluster number if you're really big and stamp them out 30,000 at a time or something).
Oh right this is the RFC from 1990. Yeah, shit has changed, this RFC needs to evolve.
Back in 1990 when this was written a single system admin hand managing 20-30 servers was a lot. Web didn't exist. I can't recall any kind of load balancing or much clustering. You might have SunOS boxes running RIP doing routing across internal subnets that were 10baseT. NAT and firewalls weren't used much at all and servers would just sit on public IPs. This RFC is prehistoric.
All 3 of these are more or less coming back with IPv6.
Has a nice Far Side too.
Like "git" ? ^^
It is now !
We ran into this years ago when we named our machines after the Marx Brothers. We started out with Harpo, Groucho and Zeppo. When two more arrived, we used Chico and Gummo. IIRC we added Karl, Deutsche, Skid, Birth and Spencer before giving in and adopting a proper 'cattle not pets' convention (which, by the way, isn't covered by TFA).
It is:
...
Of course, they could have called the second one "shop2" and so on. But then one is really only distinguishing machines by their number. You might as well just call them "1", "2", and "3". The only time this kind of naming scheme is appropriate is when you have a lot of machines and there are no reasons for any human to distinguish between them. For example, a master computer might be controlling an array of one hundred computers. In this case, it makes sense to refer to them with the array indices.
I have my own silly naming convention and I like hearing about other's. It's a fun topic.