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.
+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.
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.
“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.
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'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".
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.
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.
I use porn star names to name computers in my company network.
It's easy to claim that "lisaann" and "peternorth" are just randomly invented names, and then watch some corporate drone blushing and struggling when asked to explain why they find those names inappropriate.
If I'd notice that thing I would probably just silently judge you and file you into the "immature edgy teenager"-category and avoid giving you any meaningful decisions from now on.
Don't worry, he doesn't actually do this, mostly because admitting you know who those people are isn't nearly as bad as actively using those names in a workplace.
Big yikes, that's a hostile work environment and is a huge risk for your HR I am sure. I would not be comfortable working with such conditions, and would be sure to let my HR rep know.
Unless they're obviously fake artist names, I wouldn't do that. Every real name carries the risk that a new hire might share that name, leading to all the confusion mentioned in the article.
Wrong battle, my friend. Directly referencing porn in the workplace creates a hostile work environment because porn is a taboo subject that offends some people, like it or not.
Yeah, it would only be meaningful for people who already have some mental images of said [porn]stars. The rest would just see random names. For that, actual random name generators exist. It's not hard to make your own, and compile a database of distinctly sounding and distinctly written first and last names. Then, of course, a company would hire someone with exact same “impossible” name.
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.
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.
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).
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`.
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.
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...
Mildly recursively, when I play at trying to name all the elements[1] in fifteen minutes, I think of the sets of things elements are named after. Geographic places (Europium, Londinium, Americium, Californium), laboratories (Berkelium, Lawrencium), people (Einsteinium, Nobelium, Curium, Seaborgium), astronomical things (Helium, Selenium, Plutonium, Uranium, Mercurium), things known in the ancient world (Silver/Argentum, Lead/Plumbum)... although it's never enough for me to get all of them.
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...
When you only have a few computers to manage, have fun with names. But when you start to have hundreds (or thousands) of computers, you really need a naming convention. At that point, you're dealing with multiple environments, locations and business units. Being able to glean that information from a name is very helpful.
Also, at that scale, names are never permanent. You're renaming (or rebuilding) hosts as they change location and usage.
The worst is when you scale up from a small firm where all the hosts are named after movie characters and all services are hard coded to those names. Been there, its rough....
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.
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.
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.
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…
.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.
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.
I intentionally violate this RFC for workstations and laptops. Some applications leak client hostnames to remote servers. I prefer to keep it bland. For public servers I would say I am in alignment and would only add I keep server names and domain names programmatic, short and simple enough for anyone inebriated to type. It's worked out well thus far.
My home wifi SSID is Marsnet, and my machines are all named after Martian surface features. So there's olympus and pavonis, arcadia and xanthe, and so on. I'm typing this on syrtis-major. I'm hoping not to run out of surface features.
Some of my machines are references to LoadingReadyRun's Installation Anxiety[0][1] sketch. When I was in college ~15 years ago, I built a file server, so I named it toilet. I eventually put a web server on it too, and when I replaced the hardware, I named it gram, but my blog code still retains the old name[2]. And yes, I named my router dishwasher.
I'm dead set against IoT, so naming my computers after fixtures or appliances hasn't caused conflicts.
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.
My home computers are "themonolith" because it's a too-big rectangular prism that kinda looks like a monolith, and pi1 / pi2. Kind of uncreative and now I want to name them after something cooler.
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).
Everyone here is talking about creative machine naming schemes, but almost every org in the world names machines with random strings, like what Windows OOBE generates by default. Sometimes the names are pre-OOBEd with scripts that generate images for new machines, but they are still mostly random. I have never seen a creative machine name in an academic or business setting. It's interesting how different HN is from most orgs.
Honestly, even most home machines are randomly named, I think.
My 2000-person employer (in finance!) names desktop machines with dictionary words and a short seemingly random suffix. So you could be GIRAFFE84F, there won't typically be other giraffes.
Servers get names that are concatenations of meaningful abbreviations that are meaningless to an outsider, you might be on nycfithro603.
Actually I can't think of any org I've worked for that had random strings for its physical machines. Cloud VMs, yes (though not always).
My experience is completely different. Having worked in companies between 15 and 15k employees, I've never seen anything other than random strings.
A while ago I wrote a script that uses GPT to generate some machine names and then check them for collisions with existing ones. So no suffixes needed. I thought I was innovating, hahaha. Very interesting.
I named all my computers and VMs after sword or sword namesakes e g. Katana, Excalibur, Scimitar etc.
All my versioning names also follow some popular project's version names e.g. x86 & amd64 internal designations or codenames. Similarly, for smaller versioning tasks I have used Fedora Project's release names. I just do it to learn something along the way as well.
It just gives the different entities I work on a personalized touch.
I strive for a list of names that are shorter than 6 characters each.
Usually it will follow a theme. In 20+ years of IT I have set up a couple of networks of systems.
Some past themes...
Characters of the current book series I am reading. Hunger Games, Star Wars, Star Trek, C. S. Lewis Novels, Tolkien Novels, Louis L'Amour Novels
Trees, plants, flowers, etc...
Clouds
Snakes, birds, etc...
The important thing is to be unique, memorable and thwart the 'cattle' people.
For several years I've been using the naming conventions to drive configuration management and other tools. Ditched rack and DC identifiers years ago because.
1. Usually not a concern.
2. When it is, it's in ipam/dcim. Plus you can usually tell from ip address.
A simple format is: app-specific-general-tierNN. foo-mysql-db-p01, foo-nginx-web-p01
Then data is nested in a hierarchy using hiera, saltstack, or custom merge behavior in cdktf. Since the names are most specific to least specific it's easy to apply configuration for each section, letting the most specific configuration override on merge.
Easiest way to automate some of the annoying bare metal/vm requirements without bringing in or writing additional tools. You rack it, set the hostname in the idrac, then let dhcp and provisioning tools do their thing.
Culture Ship names [1] have served me well for many years now. I thought I’d have run out by now, but coming up with variations has extended the pool quite a bit.
For my private network, I used The Black Company for characters. Logging on CROAKER. Primary Domain Controller would be DOMIN8R; Backup Domain Controller is THELADY. Heavy wizardry on ONEEYE or GOBLIN. Various servers got CATCHER, SHIFTER, LIMPER, and the like.
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've had the same naming scheme for my personal devices for about 15 years now. The word list is from a show I was watching at the time. Workstations are protagonists, servers are antagonists, mobile devices are child characters.
Last year I finally exhausted names from the first show and added a second one to my name list.
Is it more logical to name them things like phone-2023-1 and cloud-server-5 - sure. But the reality is my personal infrastructure is going to max out at like 40 concurrent devices, and that's including stuff like network devices which does get more "practical" names (like office-ap-1, tv-switch-1) since I rarely ssh into them. So may as well have a little fun with naming
I used to work for a state gov entity, one of the counties I worked with named their servers after Looney Toon characters. I always thought that was cool and fun. Where I worked named the servers after the departments. /sigh. Such boring.
I very much disagree with the Don't choose a name after a project unique to that machine section.
If you know a machine (especially a server!) is going to be used for one thing, name it after that thing. If you get a second one, you wipe both and rename them to thing-1 and thing-2.
If you move a machine, you absolutely wipe it!
"I named the new search server "gohan" because the original search server was called "goku" because he's searching for the dragon balls" is cute on the surface, but then you have to explain to everyone that joke and then they have to remember it. No one's going to be confused by "search-new-2021".
That's from 1990, which is firmly from the "pet" era, not "cattle".
Computers were scarce and expensive, virtualization wasn't a thing. Any random machine might turn out to do DHCP, FTP and payroll, just because the software had to go somewhere and that particular machine had the spare resources and was hooked up to the right network.
Though I can't imagine this is going to be particularly constructive, I've spent a lifetime on the lookout for any opportunity to brag about the names I've given various hardware devices because they're quite funny.
Perhaps - for end users/non-admins - it'd be best to point first to a list of "favorite" names??
Here are my favorites of mine, which have all notably performed the function of a unique system name quite admirably:
For naming all the machines on my home network, I go with the theme of "kinds knives or blades". I like the symbolism (knives are symbolic of logical thought).
The only problem is that I have a lot of machines, and am running out of names!
My fiancé runs a knife factory. There are so many names. Perhaps you just need to embrace some of the more descriptive names! “Folding Hunter Knife - Nickel Silver Drop Point”
That would be one way! But I also want the names to be relatively short and contain no spaces or non-alphanumeric characters, because I type them in a lot.
I still have 20 or so left on my "future names" list. I'm now into names of knife types in the African continent.
>Words like "moron" or "twit" are good names if no one else is
going to see them. But if you ever give someone a demo on your
machine, you may find that they are distracted by seeing a
nasty word on your screen. (Maybe their spouse called them
that this morning.) Why bother taking the chance that they
will be turned off by something completely irrelevant to your
demo.
I see their point, but I’m going to consciously ignore this advice because it makes my life more interesting.
I used to carefully name all of our computers. Starting a few years ago, I stopped even knowing the names of most of the physical machines on my home network. Sure, I'd have to go to the DHCP reservations list to figure out the name of my kids' computers to remote into them.
The VMs and containers on my proxmox server are all named after the service and a trailing number. Plex is plex1, file servers are fs#, unifi controller is unifi1, etc. Once having a VM or container became essentially free, it mostly eliminated the need to think up or remember names.
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).
I remember once coming across my-hostname-is-longer-than-yours.mit.edu. My university used ship types as names for their machines. Workstations (of which there were many) had a short 3-letter ship type followed by two digits. That worked very well.
Privately I use fantasy/Science Fiction worlds. One of the first was discworld (it had a very large harddisk), and I stuck with it. I've had beleriand, dagobah, tatooine, and my most recently ferrix. Okay, mostly Star Wars planets, I guess.
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...
Back in the day I worked for a small IT company that hadn't yet implemented DNS or DHCP, all machines including office PCs were named using periodically distributed hosts files. Reading this file was fun, to see the imagination slowly dwindle. The names started using the usual themes, planets, gases, Tolkien characters. By the end the names had degenerated into 'door', 'window', 'chair', 'pen'.
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.
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.
For many years, I named my (personal) computers after fictional AIs—starting with the Marathon series, so the first two in this set were Durandal and Leela.
More recently, I have been naming them after the cats in Diane Duane's Feline Wizards series (which begins with The Book of Night with Moon); however, having run through Rhiow, Saash, Urruah, and Arhu, I'm going to have to find a new naming scheme for my next one!
After trying to convince the Ubuntu petname package maintainer to make the source-code PEP-8 compliant, I went on to build a JavaScript clone based on the spy tools listed in the Vault-7 leak. I called it `nsaname`.
It's much more limited in possible combinations than petname, but it's perfect for naming secret projects.
There were so many arguments between otherwise reasonable people over server names.
Some went for cute, some for mythology, some planetary (which can be quite limiting if you stick with only the home solar system), and finally my favorite - the purpose-based, numerically suffixed.
Ah, I remember the day we retired the last machine named after a forest in Magic: the Gathering and shredded its soul into a thousand pieces, each of which adhered to one AWS service or another. I still feel guilty. Especially when the bill arrives each month.
I have for a while, and will for the foreseeable future, name my computers `terminal`. It started as a joke, but has turned into a habit. Every device I own is named that, with the exception of my cellphone, which is named `phone`.
I have always had something on my personal network called 'kremvax' since the '80s. Now, it's back to being the name of an actual VAX. You had to be there...
for the company computers we do COMPANY ABBREVIATION-DEPARTMENT#number(-LT if mobile workstation). has worked out nicely so far but we are a small operation. for home, i use Iron Man characters. I like to name my main gaming PC as villains, like Iron Monger. I am a HUGE Spider-Man fan, but I admit I don't think it is as cool to see Doc Ock or Kraven as opposed to... War Machine... light up on the network.
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.
At home, I use characters from the first anime I watched as a digisub concurrent with it airing in Japan. It had considerably more female characters than male, so I use the male names for printers.
These seem to adhere to the guidelines. I have been using https://iancoleman.io/bip39/ for a while to name VMs. Generate 15 words, pick a pair that I can visualize, and I'm done.
I stuffed the RFC into GPT and asked for a summary, and asked it to write 10 examples of each point. It "hallucinated" an interesting elaboration of the "use real words" rule that wasn't mentioned in the RFC:
They seemed to have certain patterns to them, so I asked: "Describe in words the linguistic and other techniques you used to come up with that list of silly words."
>Sure, the process of generating a list of silly, unreal words involves several linguistic and creative techniques:
>Phonotactics: Phonotactics is the study of the rules governing the possible phoneme sequences in a language. In creating these words, I adhered to the phonotactic rules of English, ensuring that the combinations of sounds were plausible for English speakers.
>Phonaesthetics: This is the study of the inherent pleasantness (euphony) or unpleasantness (cacophony) of the sound of certain words, phrases, and sentences. To come up with silly words, I chose combinations that are typically associated with a humorous or whimsical sound in English.
>Combining Familiar Sounds: To create these unreal words, I combined familiar sounds and syllables from English in new and unusual ways. This increases the chances that the words will be pronounceable and memorable, while still being novel and silly.
>Consonant-Vowel Structure: Most of the words follow a basic consonant-vowel structure, which is common in English and makes the words easier to pronounce.
>Morpheme Mixing: Morphemes are the smallest meaningful units of language. In English, we can combine morphemes in different ways to create new words. In this case, I combined various nonsensical morphemes to create new, unreal words.
>Influence of Existing Words: Some of the created words might resemble or remind you of existing words in English. This was intentional as these associations can make the words sound more familiar and easier to remember, while still being clearly unreal.
>Humorous Connotations: Many of these words were designed to have humorous or whimsical connotations. This was achieved by choosing sounds and syllable combinations that are often associated with humor, silliness, or absurdity in English.
>Variety: In creating this list, I sought to ensure a wide variety of sounds, syllable counts, and levels of complexity. This increases the overall silliness of the list and ensures that there are words that will appeal to different tastes.
>Remember, though, that creating silly, unreal words is a highly creative process and there are no hard-and-fast rules. The most important thing is to have fun with it and create words that make you smile!
I've never heard of Phonaesthetics or Phonaesthetics (but they sound plausible and pleasant ;) ), so I asked: "To elaborate about Phonaesthetics and Phonaesthetics, give me as many explicit examples of possible of how those techniques apply to the list of computer names you generated above."
>Sure, here's how the principles of phonotactics and phonaesthetics apply to some of the silly, unreal words I created as potential computer names:
>Phonotactics:
>"Brungle": This word adheres to English phonotactic rules, in which a single consonant or consonant cluster ("br") can be followed by a vowel ("u"), and then ending in a consonant or consonant cluster ("ngle").
>"Fribzoot": Again, "fribzoot" starts with a valid English consonant cluster ("fr"), followed by a short vowel ("i"), another consonant cluster ("bz"), a vowel ("oo"), and ends with a consonant ("t").
>"Blupzark": This word adheres to the English phonotactic rules with a valid consonant cluster ("bl") followed by a short vowel ("u"), a consonant ("p"), another consonant cluster ("z"), a vowel ("a"), and ending with a consonant ("rk").
>"Tringwop": Here, "tr" is a common consonant cluster, followed by a short vowel ("i"), a consonant cluster ("ng"), a vowel ("o"), and a final consonant ("p"). Each part of the word is a permissible combination in English.
>Phonaesthetics:
>"Snorkwib": This word has a whimsical sound to it, due to the combination of the "sn" sound at the beginning, often associated with words like "snicker" and "sneak", and the "wib" at the end, which is an uncommon but still pronounceable combination in English.
>"Quibnorf": The use of "qu" at the beginning adds a quirky, whimsical sound, while the ending "-norf" adds to the absurdity, reminding one of words like "dwarf".
>"Glibfraz": The "glib-" prefix may remind us of the word "glib", giving a sense of smooth, quick wit. The "-fraz" suffix has a zany, fun feel to it.
>"Plonkstir": The beginning, "plonk", may bring to mind the English onomatopoeic word 'plonk', giving a playful, silly feel. The ending "-stir" balances it with a more usual word ending.
>Phonotactic rules ensure that the created words are plausible and pronounceable to English speakers, even though they are entirely made up. Phonaesthetics, on the other hand, contributes to the silliness, whimsy, and overall appeal of the words, making them suitable and memorable as computer names.
>Please note that while these linguistic principles can guide the process, the creation of such words also involves a considerable degree of creativity and intuition.
These techniques are also useful for generating memorable nice sounding company and product names, too!
The RFC is for a different time and place. Though some of the principles still stand and I have deployed/used many of them, but not all are applicable.
I'm not saying my scheme is perfect, or even very good, but it works for my needs and I've used the following convention for around 30+ years. I've got two schemes, one for small sites/personal installations, and one for big sites.
w for workstations. t for tables. p for printers. c for cameras. a for access points. s for servers. m for mobiles/cellphones. v for vms. i for iot devices. u for "devices we don't know how to designate." x for sensors, e.g water leak sensor, package delivery box sensor.
Obviously if you only have three devices in your entire home, it doesn't really make sense to have a "naming scheme."
For personal installations and small sites (not an exhaustive list):
a-studio-ap6 (access point in studio)
a-catbathroom-ap6pro (access point in cats' bathroom)
a-workshop-ap6 (access point in the workshop)
a-rv-aplr (access point in the rv)
w-lloyd-vr (workstation, household VR/gaming computer)
w-justin-storm (workstation, storm is the CPU case manufacturer)
l-justin-surfacebook2 (my surface laptop)
l-joyce-surfacebook2 (wife's surface laptop)
l-joyce-surfacestudio (wife's surface laptop)
l-justin-mbp2013 (my old macbook)
p-office-hp3600 (office printer)
p-workshop-konica (konica minolta printer in workshop)
p-office-canon (office printer)
v-justin-ubuntu (virtualized linux)
v-justin-arch (virtualized linux)
v-justin-win10 (virtualized linux)
t-lloyd-weather (samsung table for weather)
t-lloyd-ipad00
t-lloyd-ipad01
c-lloyd-frontdoor (camera at front door)
c-lloyd-garagedoor (camera on outside of garage door)
c-lloyd-garageceiling (camera on the garage ceiling)
s-lloyd-main (main home server)
s-lloyd-backup (backup server)
s-lloyd-storage (backup server at the storage locker)
s-lloyd-cloud (our racked server in some midwest datacenter)
s-lloyd-rv (server in the rv)
m-joyce-pixel6 (wife's cellphone)
m-justin-pixelpro7 (cellphone belonging to me)
m-justin-note20 (cellphone belonging to me)
m-justin-iphone13 (cellphone belonging to me)
The local machine is given the name, though some cannot be easily renamed, or they have a restriction such as NETBIOS name length, and then the MAC is also set with a name on the router too, so magic packets and other tools know what the device is named even if the device is not broadcasting any name.
It helps with identifying mystery devices on the network, and who owns the device. I apply the same principle to naming cats and people. "grey-cat", "black-cat", "fuzzy-black-cat", "pink-human", "mao" (cat), "cat", "cath" (also cat), "orange-cat", "chat" (also cat), "gatto" (cat).
For large sites with dozens or hundreds of servers or multiple sites/data centers:
IATA codes with rack and machine name and absolutely nothing creative, and clear separators between each part. e.g. lax-r01-s17. And then I make sure that any publicly accessible machines sit on their own "prod" domain separate from the company's main domain, e.g. hn-prod.com, or bigcorp-prod.com
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.