One place we named all the (Unix) machines with names beginning with a 'C': cbed, cnic, cweed, csun (a Sun box, of course!), cmen,... We were (obvs?) developing in C, and our office was known in the company as "C-centre". All seemed to make sense at the time.
The most useful naming scheme that I have seen in a professional setting for end-user computing is [OS]-[SerialNumber]. Win-asdf1234 is immediately telling for sysadmin types that spend a lot of time in Active Directory or an ITSM. If you were in a multi-location stop, perhaps a location code as well.
I like to give domain-joined computers the rights to modify some typically-unused AD attributes (givenName, surName, etc) on their own objects. I assign a Startup Script to populate make, model, serial, etc, into these unused attributes. These attributes are nice because their display specifiers allow them to be added to views in Active Directory Users and Computers very easily.
In places I've worked that have done this, it has frequently led to problems. Those names are harder to tell someone verbally, are easier to confuse, and easier to fat-finger without noticing.
we name devices based on the inventory asset tag we affix as a prefix + the acronym of the department the device is assigned to as the suffix. clean and consistent across thousands of devices.
I named computers in a church after biblical characters for a while and moved back to asset tags. You can never be sure how to spell Nebuchadnezzar and asset tags are sooo much easier.
I would also recommend picking a system with a sizable pool of options. Naming my computers after the planets seemed like a fine idea, until you start living with someone and start adding Raspberry Pis and other devices around the home. Eight planets didn't quite cut it, and now I have an odd mix of mythological characters.
My system was to have the machines be the planets, and then their drives would be the moons. It made it easy to remember which drives would be available on a given machine. However, it was also a problem when I wanted to add a second drive to Mercury and didn't have any options...
Growing up, my dad named all his computers after native trees and plants where we were living. (e.g. Redwood) I’ve carried on doing that! Currently the main computers in the house are Cottonwood, Prickly Pear, Hackberry, and Honeylocust.
I like tying the scheme to the domain. For instance, mine has always been starfleet.mil. Forever non-public domain. Lots of options for host names. (I've never been able to figure out a cohesive way to do this for Star Wars.)
If you were going for deities, maybe olympus.<something> for Greek gods. Wherever the pantheon is supposed to be homed. Hinduism would give you more host names than you could (probably) ever use...
Your mentioning the pantheon gave me a flashback to how one of my old companies named their non-prod environments. The dev environment services were named after all the Greek gods, and the QA/demo environment services after the Roman gods. It was so horribly confusing…
Before I started using zfs and drive names stopped mattering, I'd name my personal storage drives after heroes from the Iliad, and the corresponding backup drives after the heroes' wives.
.mil is an valid (restricted) tld [0], and has been for a long time. And while starfleet.mil is still currently unregistered, I wouldn’t be surprised if they changed given recent trends [1]…
I'm sure it works fine, but .mil is a real TLD and someone (like the new Space Force or whatever they call themselves) could register it and use it publicly tomorrow.
I use chemical elements at home. They have nice short abbreviations that can be used mnemonically, e.g. mo (molybdenum) is my modem and pr (praseodymium) is my printer. And if I somehow lose DNS and /etc/hosts on every machine, I can still look up their IPv4 addresses in a book.
I use the last name of science fiction authors for my machines, and the first character is a hint to the usage. E.g. NAS is Niven, Web server is Wells etc.
(don't ask me for the name of the developer box).
Coming from a systems background (administrator, engineer, and architect for many years): this is horrendous, but insightful as to how things were back when it was written.
Coming up with a uniform, concise, and easily decipherable scheme is really the best for naming nodes on a network (be it at your home, or in a data center with 10s of thousands of machines (virtual and physical)).
GUID is a bit extreme, but leveraging DDNS, and having a plan is always the best (and not naming things after a finite index like: planets, cartoon characters, mythological objects, or models).
If you're going to be naming a lot of computers, it's surprisingly important to pick a naming format that is (1) expandable and (2) trivially parseable. The naming scheme that seems simple when you're in a garage can be constraining when there's too many to track in a spreadsheet.
My favored format is somewhat complex in terms of layout, but is compact and easy to read once you get used to it:
IATA code (https://en.wikipedia.org/wiki/IATA_airport_code)
Cluster number (digits)
'r' (for "rack") \______ if meaningful for you
Rack number / (ignore for EC2/GCP)
'm' (for "machine")
Machine number
An example hostname might be `dls1r56m10.mycompany-prod.com`.
Alternatives that don't work as well:
* Don't use a fixed-width field anywhere. Google used two-letter cluster names, and when those ran out they discovered that the two-letter assumption had worked its way into every layer of the stack. One of the important core services had `uint16_t cluster` in its wire protocol.
* Don't make up your own cluster names. Don't use names like "northwest" or "east". IATA codes are your friend and you will love them because someone else already decided what they should be and wrote them down.
* Don't use fields without delimiters. Being able to say "read digits until the next non-digit" is incredibly useful when writing ad-hoc parsers in shell scripts, because those parsers won't break when you bring up the first datacenter with more than 99 racks. If you tell people not to write hacky ad-hoc parsers in shell scripts, they will (1) do so anyway and (2) not tell you.
* Don't leave off the cluster number. Yes, you only have one cluster in us-west-2 right now, but maybe in five years you'll need to have more than one because you want to run 30,000 EC2 instances there but all your per-cluster infrastructure software falls over at 20,000 instances. Then you can just turn up "pdx2" instead of trying to explain to Hashicorp engineers why you want to run the world's biggest Consul cluster.
* Do not put the production hostnames under a subdomain of your corporate website. If you are ACME LLC then your hostnames should end with `.acme-prod.com` instead of `.prod.acme.com`. The same is true of corporate IT assets like laptops or workstations (`acme-corp.com` -- NEVER `.corp.acme.com`). Why? Browser cookies.
Pick the nearest airport? Or a nearby airport? Airport in the location's capital city? There's always an airport[0].
The purpose is to have a Schelling point that bypasses any tedious weeks-long arguments. Otherwise your Frankfurt datacenter gets named "ceurope" because the London datacenter got "europe" first, or you named the Ohio datacenter "east" and there's a fight about whether to call the new Virginia datacenter "easter".
[0] If you're building a submerged datacenter in the middle of the Atlantic then ... well, do your best.
Yeah see, it doesn’t necessarily solve any of these problems.
If you have to do all this guesswork or refer to documentation anyway, maybe just use the human readable and immediately interpretable name of the town the DC is in. Increment a number for each new DC in the area. No cognitive hoops to jump through.
“I know we’re physically closer to BDL, but I think we’re culturally closer to JFK and, come on, you know the name is cooler,” says the guy determined to reintroduce bikesheding into the naming process.
There's only one good "closer to" for these purposes, and that's "by packet latency." The prefix is basically the location of the carrier hotel that serves your DC.
I'm sure someone can find an objection. For example, Belfast (UK) is "GB BEL", but isn't actually in Great Britain (it is in "the United Kingdom of Great Britain and Northern Ireland").
Here, "GB" stands for "United Kingdom of Great Britain and Northern Ireland", not "Great Britain".
> The codes are chosen, according to the ISO 3166/MA, "to reflect the significant, unique component of the country name in order to allow a visual association between country name and country code".[5] For this reason, common components of country names like "Republic", "Kingdom", "United", "Federal" or "Democratic" are normally not used for deriving the code elements. As a consequence, for example, the United Kingdom is officially assigned the alpha-2 code GB rather than UK, based on its official name "United Kingdom of Great Britain and Northern Ireland" (although UK is reserved on the request of the United Kingdom). Some codes are chosen based on the native names of the countries. For example, Germany is assigned the alpha-2 code DE, based on its native name "Deutschland".
+1 for airport codes. I was surprised to learn about this convention which seems to be used by many CDNs when I first started working for Netflix, but it makes a huge amount of sense.
Now if I just had a dollar for each time I've fat-fingered sjc002 to scj002 ... :)
The IATA code thing seems a bit wobbly. Am i really going to sit and work out if our datacentre in Sutton is closer to Heathrow or City airports?
We name our datacentres with a two-letter city code and a digit (or some letters and then some digits in your framework!). The city codes aren't from any canonical list, but it turns out there aren't enough to matter. So far, this has served equally well at avoiding arguments about what to call things.
We name machines ${datacentre}-${other_stuff}. That makes it trivial to tell what exact datacentre a machine is in. That's very nice if you have to reason about networking. In your scheme, if you had multiple datacentres near one airport, you would have to know the mapping from cluster to datacentre, right?
The usual (and suboptimal) solution to that one is to just use the biggest airport in the metro area -- e.g. servers in Chicago are tagged ORD even if they happen to be located next door to Midway.
However, IATA does provide city codes even if no airport in that city actually uses them. London's is LON, Chicago's is CHI. It's better to just use those.
Same. Biggest airport in the area unless the data center is somehow VERY close to a secondary airport or something.
Can't speak to others but one of the main reasons is if our team has to fly chances are they're hitting the main airport, anyway. Like, we're not going to try to finagle a Spirit or RyanAir flight, just fly to ORD and taxi / uber. For someone looking to travel on the cheap and with no concerns about time those airlines and airports are fine, but work demands change that math.
Including location detail in the name would only seem appropriate for massive operations which include slow and methodical procedures for changes. Otherwise you would end up moving servers and now having names which incorrectly suggest their mount positions.
A proposal to reserve the high bit to signal a "long name" was unfortunately(?) not accepted.
This was nearly a decade ago, so things may be different now. You'd have to ask someone who currently works there to tell you what their cluster names look like.
A rare gem. Now cue all the people, not having read it, chiming in with comments of the form “What I use is… [something which the RFC recommends against doing]”.
Eg, nothing wrong with naming the webserver simply "web". Particularly in modern times where it's going to be a VM/container, and never do anything else.
Also nothing wrong with naming your laptop after yourself. Laptops weren't much of a thing in 1990, these days everyone at my company has their own. And seeing a login or packets on tcpdump from "bob.example.com" is very much helpful.
Back in the day, we named the computers of our customers by tv shows or movies (futurama) and the disks inside them after the characters (fry, zoidberg, etc.).
Worked well.
Coolest thing I did in the past about that was to name the servers of a start up in which I participated after the characters/places of "The Odyssey": Penelope, Telemaco, Itaca...
For people that likes to stay in a given theme: I worked in a company that was using pokemon names for hostnames. Given there seem to be close to a thousand of them now, it's probably not such a bad idea for a small network where you don't expect more than a few hundreds host at a given time.
It begun with skydiving location, as the guy in charge of PC administration is a diver, then he switched to pokemon as he figured out it was easier to take the next pokemon in the list.
Considering we are only about 25 people at work, we have a long way to go before running out of names...
When naming "pets", thematic names are nice: Tolkien characters, words-starting-with, deities, elements, plants, animals, etc.
When naming "cattle", schemes that have fairly intricate coded meanings and numerical elements generate things like LDW21-0743 (London, Desktop, Windows, 2021, number 743).
Somewhere between 50 and 100 machines and you need to transition, and it can be surprisingly traumatic.
We have a greyhound, and they are closer to cattle than pets at the beginning of their lives. Each dog has a unique combination of numbers tattooed in their ears. Then they are named according to a weird convention where litter-mates share a "first name" while having their own unique "second name". For example, my greyhound was named Del Sol Madison, and she had litter mates with names like Del Sol Martin, Del Sol Maxine, etc. These names are used for identifying the dogs, but they are not trained to respond to them because they aren't pets. Once we got her, we called her Maddie and that's just been her name ever since.
When I worked at NASA, I basically did both. We had fixed format official "cattle" names that included the organization code and the computer's inventory number. Those names were useless to humans, so I always also registered a human-friendly "pet" alias. It was a bit more trouble, but it generally worked well. The pet names also has some structure, with prefixes differentiating classes of systems (desktop, server, lab), but they were otherwise free-form and picked to be useful to the users.
The first big Unix workstations site I worked at, at the same time as this RFC, the head sysadmin started naming SPARCstations after vacation destinations she liked (`cozumel`, `stcroix`, etc.).
I guess it brightened up the all-gray cubicle farm.
My hostname idea was to name network printers after trees (e.g., `pine`, `elm`).
You can also make the hostname work with the FQDN. I once got the hostname `ilove.mit.edu`. I later got them to rename it to `ihavealovehaterelationshipwith.mit.edu`.
I name for expected performance. A remote server named Arnie should be strong, reliable and always come back. A music server named Elvis serves music with elements from multiple genre and not mind being told what to do by someone who knows a lot less about how it does what it does (that'd be me) than it does. A back-up server named Methuselah should not die for a very, very, very long time. So far, it's been a successful scheme.
In college our data systems ran various vaxen boxes, and there were few enough that they used planet names. Distinct, easy to remember, unlikely to clash with any other terminology. And had their needs grown beyond the 8 non-Earth planets (Earth wasn’t used, and Pluto was still a planet at the time) they could simply begin using the names of moons and other well know rocks flying about the solar system.
In my own personal home setups I’ve followed the convention of choosing a from a religious pantheon the name of a god whose role most approximated— very loosely— whatever the system is going to be used for. I had a Hephaestus for a while that was a workhorse of a machine where I would work on special projects, etc.
I would argue metadata does not belong in a device name. Location, OS, etc., should all be tracked in the device management system.
The impulse to encode lots of metadata in a device name is reasonable, but less is more. Location, user, application, even OS can all change. What then does it mean for the device name?
And how often do you need to distinguish between a laptop and a desktop, really?
Name things uniquely, and as little beyond that as possible. If the system generates its own unique default (Windows) or manages its human-readable hostname on its own (Mac), use that. Let your device management tools tell you where it is, what model device it is, what OS it runs, etc., not to mention countless other things you’ll never fit in a name.
I used to make exceptions for infrastructure, but with automated network management tools, I don’t even bother with that anymore. All that matters is that a device is represented in a database by a primary key, and I don’t even care what that is.
The best naming convention is not to bother with conventions at all. Let the machines do that work.
We always had the location in the name. It really helps when you have multiple data centers. If a machine was to move from one data center to another, it would be renamed (or more probably rebuilt).
Each DC had a different business usage, so knowing that immediately gave you context of what that machine should be doing.
We also would also have the environment (prod or dev) in the name. It just gave you an immediate understanding of the sensitivity of the machine and therefore stopped/warned folks from doing crazy things in prod.
Of course, YMMV, but I've always been a fan of names which give you context. Too much can be annoying but a little goes a long way.
Sure. And I would add that application identifiers can be a different problem domain. `app-dev.houston-1.example.com` would be a perfectly reasonable name for an application, whether it resolves to a host or a load balancer or a CDN endpoint or whatever. The underlying machines I still don’t really care about; they will register their availability in the cluster or whatever automatically, or else they’ll get names like “db” and “web” in the docker-compose file, or what have you. But sure, where a human might reasonably need to enter a name for a resource in order to access it, a brief descriptive name makes sense.
Yep, this is my position. As soon as you do it, people are going to (1) try and squeeze more stuff in and then (2) the names become configured somewhere and diverge from whatever the original purpose was.
Another requirement is you want the names to be a sparse address space: there should never be confuse-able or mistypable characters which drop you into another computer name - so systems like r0001, r0002, r0010 etc. should be right out.
Finally you also want the name to be human pronounceable: if everything's going well, it'll never be said. When things are not going well though, you want it to be something that can be communicated verbally if you need to - i.e. over the phone, or across an office.
Hence, word-lists are ideal as hostnames. Keep them short to around 2-3 syllables. They must be meaningless (and thus also not imply meaning). Any other information you need should come out of the CMDB. If you need more specific info hanging around, then you DNS and CNAME's to set up aliases for things like trying to SSH into "the machine at these rack coordinates" and keep that information updated from your CMDB.
I agree with everything you said here. I also have another rule: I never reuse a machine name. If a machine gets retired, the name it had is retired along with it.
I started doing that after a hard-to-diagnose problem that resulted from restoring a configuration file that referred to a machine that had been retired, but the name was reused, making it refer to the wrong machine.
I agree. I used to name my machines using metadata, but that became problematic after a while. When machines move or are repurposed, then you either have a misleading name or you have to rename the machine. I prefer to avoid both of those situations.
That's why I switched to names that have no relationship with the particulars of the machines they are assigned to.
It's incredibly useful to categorize hostnames. It won't encompass all possible information, but enough to know at a glance what you're dealing with. Hostnames end up in all sorts of places, backup files, monitoring systems etc, and being able to tell a webserver from a switch and prod from test makes life easier to everyone.
The argument that equipment change location and uses sounds to me like an environment where disposing and creating new hosts is much too hard. The lifetime of a host should be simple and well defined such that no one is tempted to make such changes without decomissioning.
The last company I worked switched to such a scheme for their servers, and it was not a good experience. The person who spearheaded it regretted the change.
The problem was that you still have to consult a key in order to decipher the hostnames, and since the names were all similar to each other, mistakes were an everyday occurrence.
Since you had to refer to documentation anyway, using more unique names would have reduced error and confusion.
Ideally, endpoint devices are enrolled and provisioned automatically. Decommissioning is a few clicks. Service hosts are deployed and destroyed via ansible or orchestration.
Backups, monitoring, logging, SIEM, etc. are integrated with the CMDB such that events and managed hosts are linked in both directions.
If anything, I’m spoiled on having automated systems making lifecycle terribly easy. I would concede that’s a blind spot in my perspective; many organizations aren’t going to be similarly equipped. If such an organization is managing more than a few dozen devices, however, they may have bigger problems than naming.
As it should be. Thus far, the people who advocate for the abolishing of host names have been the same people who lack lifecycle processes. I don't think this is a coincidence. Most people tend to solve the problems they can grasp, and it is hard to see what you lack.
> Name things uniquely, and as little beyond that as possible
I think that points to UUID or an incrementing counter, but the incrementing counter may be harder to ensure uniqueness depending on how names are created (which can change in the future).
There's a tension here between the two user groups who need to interact with the name: whatever software system manages the things, and human beings.
I worked on a system that had dozens of small-form-factor linux computers, that served as gateways for a fleet of thousands of bluetooth environmental sensors. Because of the nature of the facility construction, it was considerably easier to provision devices before deployment, then record location and other meta-data later. So the unique ID (a 16-digit hexadecimal number) in the system was completely disconnected from the metadata, but the common name of the device was defined almost entirely from the metadata. That also meant that while the unique ID was immutable and described a unique computer, the common name more described a location and purpose that a computer could be deployed to. Even so, that distinction lived waaay up in the facility management software design, and in practice, the only people even aware that the unique ID existed and was a distinct number from the "name", were the people tasked with provisioning the device for deployment.
Plenty of orgs have multiple people named "Steve", a few even have multiple people named "Stephen A. Ambrose", but no good org has multiple employees with the same employee ID number. And to further that analogy, no good org expects its employees to completely ignore the human name in favor of the employee ID.
210 comments
[ 3.6 ms ] story [ 256 ms ] threadObviously programming in C wasn't your only favorite pastime.
[1] https://www.rfc-editor.org/rfc/rfc2100
I like that scheme. I find it meaningful to name things in my life after things in my natural environment. Helps me remember that I exist inside it.
If you were going for deities, maybe olympus.<something> for Greek gods. Wherever the pantheon is supposed to be homed. Hinduism would give you more host names than you could (probably) ever use...
0: https://en.m.wikipedia.org/wiki/.mil
1: https://www.spaceforce.mil/
The ".home.arpa" domain is explicitly set aside for 'home' non-public networks in https://datatracker.ietf.org/doc/html/rfc8375.
- Jovian moons
- Trees
- Constellations
- U.S. state capitol cities
- Chemical elements
Stephenson?
Coming up with a uniform, concise, and easily decipherable scheme is really the best for naming nodes on a network (be it at your home, or in a data center with 10s of thousands of machines (virtual and physical)).
GUID is a bit extreme, but leveraging DDNS, and having a plan is always the best (and not naming things after a finite index like: planets, cartoon characters, mythological objects, or models).
My favored format is somewhat complex in terms of layout, but is compact and easy to read once you get used to it:
An example hostname might be `dls1r56m10.mycompany-prod.com`.Alternatives that don't work as well:
* Don't use a fixed-width field anywhere. Google used two-letter cluster names, and when those ran out they discovered that the two-letter assumption had worked its way into every layer of the stack. One of the important core services had `uint16_t cluster` in its wire protocol.
* Don't make up your own cluster names. Don't use names like "northwest" or "east". IATA codes are your friend and you will love them because someone else already decided what they should be and wrote them down.
* Don't use fields without delimiters. Being able to say "read digits until the next non-digit" is incredibly useful when writing ad-hoc parsers in shell scripts, because those parsers won't break when you bring up the first datacenter with more than 99 racks. If you tell people not to write hacky ad-hoc parsers in shell scripts, they will (1) do so anyway and (2) not tell you.
* Don't leave off the cluster number. Yes, you only have one cluster in us-west-2 right now, but maybe in five years you'll need to have more than one because you want to run 30,000 EC2 instances there but all your per-cluster infrastructure software falls over at 20,000 instances. Then you can just turn up "pdx2" instead of trying to explain to Hashicorp engineers why you want to run the world's biggest Consul cluster.
* Do not put the production hostnames under a subdomain of your corporate website. If you are ACME LLC then your hostnames should end with `.acme-prod.com` instead of `.prod.acme.com`. The same is true of corporate IT assets like laptops or workstations (`acme-corp.com` -- NEVER `.corp.acme.com`). Why? Browser cookies.
What do you do if there's no airport?
The purpose is to have a Schelling point that bypasses any tedious weeks-long arguments. Otherwise your Frankfurt datacenter gets named "ceurope" because the London datacenter got "europe" first, or you named the Ohio datacenter "east" and there's a fight about whether to call the new Virginia datacenter "easter".
[0] If you're building a submerged datacenter in the middle of the Atlantic then ... well, do your best.
If you have to do all this guesswork or refer to documentation anyway, maybe just use the human readable and immediately interpretable name of the town the DC is in. Increment a number for each new DC in the area. No cognitive hoops to jump through.
How many San Joses in the world? (1700ish)
Pennsylvania has two Baldwins, two Whitehalls and two Elizabeths.
UN/LOCODE tends to have an abbreviation for most places.
> The codes are chosen, according to the ISO 3166/MA, "to reflect the significant, unique component of the country name in order to allow a visual association between country name and country code".[5] For this reason, common components of country names like "Republic", "Kingdom", "United", "Federal" or "Democratic" are normally not used for deriving the code elements. As a consequence, for example, the United Kingdom is officially assigned the alpha-2 code GB rather than UK, based on its official name "United Kingdom of Great Britain and Northern Ireland" (although UK is reserved on the request of the United Kingdom). Some codes are chosen based on the native names of the countries. For example, Germany is assigned the alpha-2 code DE, based on its native name "Deutschland".
https://en.wikipedia.org/wiki/ISO_3166-1
UN/LOCODE may be more appropriate:
* https://en.wikipedia.org/wiki/UN/LOCODE
* https://unece.org/trade/cefact/unlocode-code-list-country-an...
Has both country code and location with-in that.
Now if I just had a dollar for each time I've fat-fingered sjc002 to scj002 ... :)
UN/LOCODE may be more appropriate:
* https://en.wikipedia.org/wiki/UN/LOCODE
* https://unece.org/trade/cefact/unlocode-code-list-country-an...
Has both country code and location with-in that.
We name our datacentres with a two-letter city code and a digit (or some letters and then some digits in your framework!). The city codes aren't from any canonical list, but it turns out there aren't enough to matter. So far, this has served equally well at avoiding arguments about what to call things.
We name machines ${datacentre}-${other_stuff}. That makes it trivial to tell what exact datacentre a machine is in. That's very nice if you have to reason about networking. In your scheme, if you had multiple datacentres near one airport, you would have to know the mapping from cluster to datacentre, right?
However, IATA does provide city codes even if no airport in that city actually uses them. London's is LON, Chicago's is CHI. It's better to just use those.
Can't speak to others but one of the main reasons is if our team has to fly chances are they're hitting the main airport, anyway. Like, we're not going to try to finagle a Spirit or RyanAir flight, just fly to ORD and taxi / uber. For someone looking to travel on the cheap and with no concerns about time those airlines and airports are fine, but work demands change that math.
Is there more to say about this? How do browser cookies conflict with server and PC hostnames?
The actual implementation was something like this:
A proposal to reserve the high bit to signal a "long name" was unfortunately(?) not accepted.This was nearly a decade ago, so things may be different now. You'd have to ask someone who currently works there to tell you what their cluster names look like.
Modern server “cattle” style naming, which I assume you have in mind, is actually explicitly mentioned as a reasonable idea in the RFC text.
Eg, nothing wrong with naming the webserver simply "web". Particularly in modern times where it's going to be a VM/container, and never do anything else.
Also nothing wrong with naming your laptop after yourself. Laptops weren't much of a thing in 1990, these days everyone at my company has their own. And seeing a login or packets on tcpdump from "bob.example.com" is very much helpful.
Until you have more than one webserver.
It begun with skydiving location, as the guy in charge of PC administration is a diver, then he switched to pokemon as he figured out it was easier to take the next pokemon in the list.
Considering we are only about 25 people at work, we have a long way to go before running out of names...
When naming "pets", thematic names are nice: Tolkien characters, words-starting-with, deities, elements, plants, animals, etc.
When naming "cattle", schemes that have fairly intricate coded meanings and numerical elements generate things like LDW21-0743 (London, Desktop, Windows, 2021, number 743).
Somewhere between 50 and 100 machines and you need to transition, and it can be surprisingly traumatic.
1. https://twitter.com/DawgBelly/status/862786851072909312
Then you get to argue about the PTR record ...
It's generally considered to be a bad idea though, and in the case mentioned above, local policy forbade it.
I guess it brightened up the all-gray cubicle farm.
My hostname idea was to name network printers after trees (e.g., `pine`, `elm`).
You can also make the hostname work with the FQDN. I once got the hostname `ilove.mit.edu`. I later got them to rename it to `ihavealovehaterelationshipwith.mit.edu`.
Edited for missing words.
In my own personal home setups I’ve followed the convention of choosing a from a religious pantheon the name of a god whose role most approximated— very loosely— whatever the system is going to be used for. I had a Hephaestus for a while that was a workhorse of a machine where I would work on special projects, etc.
The impulse to encode lots of metadata in a device name is reasonable, but less is more. Location, user, application, even OS can all change. What then does it mean for the device name?
And how often do you need to distinguish between a laptop and a desktop, really?
Name things uniquely, and as little beyond that as possible. If the system generates its own unique default (Windows) or manages its human-readable hostname on its own (Mac), use that. Let your device management tools tell you where it is, what model device it is, what OS it runs, etc., not to mention countless other things you’ll never fit in a name.
I used to make exceptions for infrastructure, but with automated network management tools, I don’t even bother with that anymore. All that matters is that a device is represented in a database by a primary key, and I don’t even care what that is.
The best naming convention is not to bother with conventions at all. Let the machines do that work.
Each DC had a different business usage, so knowing that immediately gave you context of what that machine should be doing.
We also would also have the environment (prod or dev) in the name. It just gave you an immediate understanding of the sensitivity of the machine and therefore stopped/warned folks from doing crazy things in prod.
Of course, YMMV, but I've always been a fan of names which give you context. Too much can be annoying but a little goes a long way.
Another requirement is you want the names to be a sparse address space: there should never be confuse-able or mistypable characters which drop you into another computer name - so systems like r0001, r0002, r0010 etc. should be right out.
Finally you also want the name to be human pronounceable: if everything's going well, it'll never be said. When things are not going well though, you want it to be something that can be communicated verbally if you need to - i.e. over the phone, or across an office.
Hence, word-lists are ideal as hostnames. Keep them short to around 2-3 syllables. They must be meaningless (and thus also not imply meaning). Any other information you need should come out of the CMDB. If you need more specific info hanging around, then you DNS and CNAME's to set up aliases for things like trying to SSH into "the machine at these rack coordinates" and keep that information updated from your CMDB.
I started doing that after a hard-to-diagnose problem that resulted from restoring a configuration file that referred to a machine that had been retired, but the name was reused, making it refer to the wrong machine.
That's why I switched to names that have no relationship with the particulars of the machines they are assigned to.
The argument that equipment change location and uses sounds to me like an environment where disposing and creating new hosts is much too hard. The lifetime of a host should be simple and well defined such that no one is tempted to make such changes without decomissioning.
The problem was that you still have to consult a key in order to decipher the hostnames, and since the names were all similar to each other, mistakes were an everyday occurrence.
Since you had to refer to documentation anyway, using more unique names would have reduced error and confusion.
The metadata database for hosts starts looking an awful lot like DNS after a while.
Backups, monitoring, logging, SIEM, etc. are integrated with the CMDB such that events and managed hosts are linked in both directions.
If anything, I’m spoiled on having automated systems making lifecycle terribly easy. I would concede that’s a blind spot in my perspective; many organizations aren’t going to be similarly equipped. If such an organization is managing more than a few dozen devices, however, they may have bigger problems than naming.
I think that points to UUID or an incrementing counter, but the incrementing counter may be harder to ensure uniqueness depending on how names are created (which can change in the future).
I worked on a system that had dozens of small-form-factor linux computers, that served as gateways for a fleet of thousands of bluetooth environmental sensors. Because of the nature of the facility construction, it was considerably easier to provision devices before deployment, then record location and other meta-data later. So the unique ID (a 16-digit hexadecimal number) in the system was completely disconnected from the metadata, but the common name of the device was defined almost entirely from the metadata. That also meant that while the unique ID was immutable and described a unique computer, the common name more described a location and purpose that a computer could be deployed to. Even so, that distinction lived waaay up in the facility management software design, and in practice, the only people even aware that the unique ID existed and was a distinct number from the "name", were the people tasked with provisioning the device for deployment.
Plenty of orgs have multiple people named "Steve", a few even have multiple people named "Stephen A. Ambrose", but no good org has multiple employees with the same employee ID number. And to further that analogy, no good org expects its employees to completely ignore the human name in favor of the employee ID.