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.
It's easy to be nostalgic for the days of big iron servers or clusters that were around for years as a sort of network landmarks. We used to have dev and QA clusters named after movie monsters and you'd get some great hallway conversations about who was using Godzilla that week.
Made for great mascot toys and posters on the rack doors.
A server can be around for years and years why being different. For instance my main debian package server has been "basson" since 2003. In 2003 it was a large, old SGI server; later on it became a 1U rack server, that was replaced a couple of times; nowadays it's a VM. But the internal sources.list still points to "basson" :)
That's a great scheme. I hope that one day amongst the university computer labs named for Greek/Roman mythology or rock artists, we have a lab of anime characters. At least at my uni, I think a lot of people would get a kick out of that.
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.
> Certain sets are finite, such as the seven dwarfs. When you order your first seven computers, keep in mind that you will probably get more next year.
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).
> 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.
This kind of naming is fine for small projects, and personal setups. In professional settings I would suggest using descriptive names and rely more on DNS.
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.
Functional names for servers are IMHO one of the worst possible options, because functions drift over time.
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"
There is a good point to the drift of functions. You just need to run this one thing, and you do have that server which could just run it. It's a very real thing.
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.
Why can't you rename the host if its function changes? Like if "the 1U box with asset tag XY1Z234" goes from being a web server to a DB server, why not reinstall it and call it db03?
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.
Maybe it depends on how big pockets one used to have, and how willing one was to follow vendors jealously declaring their software should be the only thing running on the 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.
> I'll go with seemingly unpopular opinion that there are only pets, never cattle.
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.
Ehh, it's actually a topic for a yet-unfinished article of mine, but note that I pointed that "us-east-1 lambda service" is still a pet.
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.
I used to name physical servers like pets (greek gods or whatever) and virtuals like cattle (function), with the idea that, yes, function of physical machines can change over time...
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...
Used to name arrays, at one point had a hell of a problem because we found out that we had no way to consistently name, and thus communicate, PCI-X I/O-bays (it was a big POWER server...)
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 ;)
You'll need a mapping for the server names anyway. If you have a large datacenter, I hope it's stored as configuration of your infrastructure as code tool, if it's small, you won't need to check it every time.
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?
"prod-web02" implies that this is the second web server in a cluster of web servers. That makes a lot of sense in 2021, where "prod-web02" is likely an AWS instance or a docker VM that is doing nothing but serving web pages, and which exists in some cloud server where you will never see the physical machine it is running on.
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. ;)
I spent an entire weekend, dialed in by modem from Canada to a certain oil exporting middle eastern country, trying to figure out why the control plane for the ATM WAN that ran LANE for all their hospitals and 911 services was down. Fun times. :P
Cute naming schemes are a holdover from the days of physical servers when location, function, etc were subject to change so an immutable machine name couldn't contain them. Now that most things are virtual and easily created/destroyed there's no good reason _not_ to name functionally. The most common refrain I've heard in defense of these archaic naming practices is that "we don't want the hackers to know which server does what" but if they've managed to get your root DNS zone file or a shell on a box then you're already pretty far gone anyway (not to mention that nmap exists). All it does is impede productivity and create the illusion of security.
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.
> 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?
Alternative method for Arch Linux: Install the `rfc` package, then find the RFC at /usr/share/doc/rfc/txt/rfc1178.txt. A very nice package to have installed when travelling far from an internet connection.
Like a lot of things, people can remember names of things better than numbers. Genes for example, it’s easier to remember their names lz, wnt, than their associated gene Id number. But like stars and many other things there are too many to give each a unique name.
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...
I'm assuming (based on reading how they performed grouping) that percussion01 didn't exist, but perhaps cymbal01 did (since a cymbal is a type of percussion instrument). Therefore cymbal01 would be a web server of sometime. The benefit to naming it this way is you could have multiple types of web servers (internal, dev, prod) and by using a more generic name you could more easily change the function of that web server (so cymbal servers could be dev, then move to prod, without needing a name change).
My feeling, though, is that you care more about the function of a machine than the physical machine itself. Why not change the machine name when you change it’s purpose? There is no reason you need to know that the current prod web server used to be the dev server.
On the other hand, I really hate code names for software versions... I can never remember which name is which version. I wish everyone would just say “16.04” and “18.04”, that makes it really obvious which version cam before the other one.
I never bothered to figure out if Ubuntu kept parts of the name between the 16.04 and the 16.10 version, or if they just used the next letter in the alphabet.
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!
Everything in our system is named <purpose><number>.<location>, but that is because everything is set up automatically by provisioning systems that way. We have thousands of servers in hundreds of data centers, so it the only time you ever go to a particular machine is to debug something.
Back at Uni we got four new workstations so obviously I named them 'death', 'war', 'famine' and 'pestilence'. Then shortly after we added a fifth, it ended up being 'mayhem'.*
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'...
Once I was moved to a new team at work, and the team leader really wanted a team name. I generated like 5 or 10 words from /usr/share/dict/words, one of which was profanity. I could tell that everyone liked Team Profanity, but no one was brave enough to adopt it. I really wish we had, because there was much cursing on that team.
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:
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:
I really like the functional naming part of this, but I don't like the idea of using random names.. I think that server names must be functional otherwise you will tend to think of them as an abstract box that, if you just install that little extra package, will be a fine webserver on top of that mailer.
Don'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.
oh and forgot to mention.. at my current job, there was this practice of naming servers after onions (I'll let you guess where that is).
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 prefer to have mostly meaningless names for machines, and then having more names for them in DNS for their various functions. That way the functions can be moved about the machines and if that's what you care about, then that's how you refer to them (deploy the app Foobar to web01 and web02), but when a machine goes down, you can shout, "clark is down!" web01/dns01/sto01 being down only means the service is down, whereas clark being down is something more severe.
I manage my stuff with Ansible, which makes all this pretty easy.
here if "fsn-node-01" is down, we know it's a major ganeti node that dies. if "unifolium" dies, ... can you guess what happens?
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...
For personal stuff (and even early machines for some companies which blurred the lines) I always chose the names of forests in the Magic: the Gathering multiverse. I try and help keep this page updated purely for that purpose:
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.
To date, Dryad Arbor is still one of the coolest cards in MtG, simply because of both the simplicity and the universality of its quote. When it came out, I was very surprised by the idea that a land could also be a creature. These days we have way wonkier mechanics, but that novelty along with the quote has a special place in my heart.
An opponent being able to remove one of your lands with small creature removal or any ping effect or -1/-1 counter is scary.
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 personal machines I use fiction locations from media I enjoy. My laptop is Hyrule, my desktop is Konoha, and my Pi is MotherBase, but I spell mine all lowercase.
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.
> Nobody expects to learn much about a person by their name.
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.)
for virtual machines i tend to use names that belong to some other entity and call the hypervisor after that. for example Saturn and its moons, Africa and its countries or some authors and their works.
Resource tags, like the ones supported by Vmware, AWS, and other cloud providers would be more important to me than a server name. I suppose for old-school bare-metal on-prem, you could put tags in DNS TXT records and some database.
I am fondly recollecting my time as an undergraduate at CMU in the 80s. All the machines were named from cities and towns in Pennsylvania. Old-school bare-metal on-prem indeed. That time has largely passed as machines are ephemeral. Functional names make more sense now.
I use Harry Potter character names. There were hundreds of the mentioned off hand in the books, so I usually use obscure ones. They have the benefit of being easy to pronounce and spell: Mafalda Hopkirk, Silvanus Kettleburn, Irma Pince, etc.
127 comments
[ 5.3 ms ] story [ 217 ms ] thread[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).
* https://www.wired.com/2009/09/in-africa-a-pigeon-transfers-d...
* http://news.bbc.co.uk/2/hi/africa/8248056.stm
* https://www.bbc.com/news/technology-11325452
[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).
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.
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.
The ones in the middle can quite happily be anonymous / referred to only by their address.
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.
It probably needs updating. It's been a while since the last large leak.
You will read this RFC like this:
$ ietf -n 1178
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....
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>):
* https://en.wikipedia.org/wiki/ISO_3166-2
Don'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...
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.
* 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.
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.
- 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.
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.)
https://en.m.wikipedia.org/wiki/List_of_Harry_Potter_charact...
I have my own silly naming convention and I like hearing about other's. It's a fun topic.