Yes; I often direct people to this RFC. Unlike the linked site, the RFC is most useful for its extensive list on what to avoid in a host name. Very good list with all reasoning explained.
This comment is interesting (as well as the other 2 children saying they also use Pokemon for host names), as there has been a study about how kids had fantastic abilities at recognizing Pokemon, but could not achieve the same levels of memorization with flora and fauna:
http://www.ncbi.nlm.nih.gov/pubmed/11924673
This inspired a researcher to create a card game similar to Pokemon, but for our biosphere:
http://phylogame.org/
We do as well. The NAS is Snorlax, the GPU server is Pikachu, and the workstations are Eevee and Vulpix. I would have named the printer Ditto but apparently IT has a policy on printer names.
My old department at the UvA did the same in the past, new sysadmin changed it to European capitol cities. (I'll never lose muscle memory for typing sandshrew and farfetch.) Come to think of it, the DNS server should've been called PokeDex...
(btw, the mail infra consisted only of carebears... I'm looking at YOU J.P.!)
Or simply have a naming convention for hosts. I realize that only makes sense for sufficiently large setups, but once your setup is large enough, it does make things easier.
At $work we maintain setups for customers, and our FQDNs are roughly <function><counter><environment>.<customer>.<ourdomain>.tld. So the second database server in the testing environment for customer "nasa" (hypothetical, of course) would be called db02t.nasa.<ourdomain>.<tld>.
It does make it pretty obvious from the FQDN what the used is being used for.
It looks like there's two types of answers in this thread, and the difference between them is whether their infrastructure is cloud-based or running in a datacenter:
- Cloud: "Who cares? Name them after pokemon or dinosaurs, you can always reprovision and they won't last very long."
- Datacenter: "But what if the name doesn't make sense 16 months from now??"
First rule of running a farm: don't name your animals. You'll get too emotionally attached when it comes time to put them down. Yes it's funny and cool et cetera. But, and I say this with love and twenty years' experience, for fucksake: take the time to plan a sensible ontology and stick with it. Hostnames should describe the purpose, capabilities, and disposition of your assets. Nothing more and nothing less.
This approach "Hostnames should describe the purpose, capabilities, and disposition of your assets" requires you to rename your servers when you repurpose them. And that's an equally bad idea.
Nah, renaming during a reprovision is fine. You gotta stuff that information somewhere, and it might as well be in the name of the thing. Also remember that a machine / IP address can have as many alternate names as you want in the DNS system.
Nice - but don't you mean Atomic Number, not Atomic Mass? The atomic numbers (i.e. the count of protons in the nucleus) are the nice non-overlapping integers 1-118, whereas the masses are all over the shop, and has overlap with isotopes of other elements.
I've used roman emperors (caligula, augustus, nero, otho, etc.).
Also notable is that of my ISP - they use words ending in “less”, for example: “priceless” is the accounting system, “thankless” the support ticket system and “clueless” the customer login.
After working in a few pretty large environments I have some pretty strong opinions about hostnames. I've seen everything from cute theme based names to function/role based names to meaningless uuid based names.
Usually you see the theme based names in much smaller environments, though I've seen it up to hundreds of machines. One problem I have with this approach is that people begin to personify machines, excusing their behavior. "Oh that's just akira being akira." This is counter to actually understanding and diagnosing problems. You're also relying on potentially faulty/emotional memories rather than having an actual stored account of issues. Not to mention, once you have a sufficient number of machines you're going to need a decent service database to know what runs what anyways.
Function/Role based names are what I have the most historical experience with. CBS Interactive, CNET, YouTube, and Dropbox all went this route. This often seems like a great idea and can get you really far. Most configuration management allows you to define classes/nodes/etc based on regular expressions. Sudoers has built in support for hostname globbing. It's also easy to tell what a machine's role is when you get an alert. So why wouldn't you want to go this route?
This method has some pitfalls that become increasingly burdensome as you grow into a larger amount of machines. You might have many types of services that run on a single hardware class. This introduces overhead whenever you need to update a machines role. Imagine it's Saturday and your mobile-web pool is suddenly under provisioned. Well, we have plenty of capacity in our web pool. Just need to rename the host in the machine database, update DNS, update DHCP, etc. While this might not seem like a lot of effort it definitely adds up. When I worked on a fantasy sports product we were constantly renaming hosts as various seasons came around. Same thing with just keeping spare/provisioned hosts around. How do you know how to name the host so that someone can just grab it when they need it? You also eventually get the boxes that serve more roles than the box describes itself as. You'll end up with a box call misc or admin and no one remembers that one day someone set it up as your static origin.
Another fun problem is the inability to describe more in depth what a box does. mysql255 doesn't tell you if it's a master/slave, which data is on it, should it be backed up? I've actually seen places that encoded all of this in a hostname. This is the extreme but it does happen.
The interesting thing about both theme and function/role based names is that to use them effectively in a large environment you already need good tools for managing the roles because the hostname is not effective enough.
At Dropbox, they started with functional/role based names but we decided to move to positional hostnames. These encode the dc, rack, position, and chassis. One immediate benefit we saw with this was quickly identifying when a rack or quad goes down. It's very apparent in monitoring just at a glance. We also have a service database that maps hostnames to tags/roles and those tags appear along-side alerts so you can tell right away which service is affected. We get benefits in easy preprovisioning and reprovisioning. Our configuration has become more generic and easier to comprehend. We can run multiple roles easily on one machine and it's easily discoverable what machine serve what role. In puppet we use an External Node Classifier rather than regex. We only have to worry about base config when a rack is initially installed.
That's not to say this method is flawless. One of the biggest drawbacks to this approach is that machines become harder to talk about and typing them is more difficult. I'd argue that you shouldn't care about specific machines unless they're a problem and in that instance copy/paste should always be used to avoid typos. There's some cool things you can do with PowerDNS' Pipe Backend to get dynamic resolution to service names. Another problem with this approach is it just requires a lot more tooling to get started. Obviously not everyone has the time to build all of the infrastructure around this ideal.
Anyways, sorry for the rant, but everywhere I've worked we've started with role based names and regretted it in the long term. Now that I've finally been able to live what I've long dreamed of, I couldn't imagine choosing another solution.
Obviously hostname conventions are a contentious issue so I won't say anyone is wrong, but these are my experiences.
One of my biggest pet peeves is when people name a host after a product, say 'mysql-prod-101', then later they decide to switch from MySQL to Oracle. I worked in an environment where a number of hosts contained 'tomcat' in the name but they were all running weblogic. Better to name based on the role, as you say, so the mysql-prod-101 would be better named db-prod-101. However, I've come to think that nowadays with configuration managment it's not really necessary to give hostnames at all. People usually don't like that suggestion when I bring it up, but if you are using something like puppet's 'facter' to run actions only on hosts that match certain 'facts', what do you really need hostnames for?
Edit: I just reread your paragraph about using positional hostnames. This seems like a good use, because the main problem I see with role based hostnames is that hosts can take on multiple roles. But in general the hostname seems unimportant if you are tagging your hosts with roles.
Ya, all our dev tools servers are named after the product they're running. (Well, most of them; one is named after a mythological being; one is named after its function.) As a user, this is frustrating because rather than remember what function I'm trying to access (e.g. mail, wiki, bugs, etc.) I have to remember what Atlassian decided to name their product that implements the function I want.
(Fortunately some entires in /etc/hosts + a local Apache server set up with RedirectRules fixes this annoyance, at least for myself…)
I've been part of some of large scale setups where usually location (even numbers = DC A, odd nubers = DC B), operating system (linux/aix/win etc.) and machine type (physical vs. virtual) are encoded in the hostname.
It can only get error prone if you have two hosts with similar names in the same project (made up example: lnx4739p34 vs. lnx4793p34) in the same project, i've seen hostnames getting reassigned because of regular mix ups.
If you happen to do ssh logins and manual troubleshooting, to make sure you're not messing with the wrong machine it's great to have puppet maintain CMDB data like service level, machine purpose, owner and open tickets etc. in a nicely formatted /etc/motd file, along with a autmatic "who" output in .bashrc to see who else is logged in.
Another question regarding hostnames is the use of (sub)domains. I find it highly annoying to deal with hosts like "mysql04.customer.vlan33.berlin2.intranet.my-company.com" instead of "lnx4739p34.myco.net", regardless of the global location.
The company I work for has about 20 sites with over 200 servers per site. We have cobbler boxes in each site (and more recently, puppetmasters). While some of our utility servers run as VMs under either VMWare or KVM, for the bulk of them we want every last scrap of performance out of the server that we can, so we primarily provision on physical machines and treat those physical machines as just containers.
Our naming scheme for the servers is similar to how you describe dropbox - there is a generic prefix and then a rack+uposition number (ie: gen0112). This has worked out pretty well. When we build a site or replace a server, we record the mac address. Then we can assign role-based child hostnames to the physical server name, update the cobbler config, and everything gets built accordingly.
Of course, there is a nice host database to track all these mappings as well as scripts to generate and push those cobbler configurations.
> One problem I have with this approach is that people begin to personify machines, excusing their behavior.
Does that hold with all themes? My first employer named computers after aircraft parts; easy to remember, made it clear that people were talking about a computer rather than anything else, but it never seemed to lead us to personify them.
> I'd argue that you shouldn't care about specific machines unless they're a problem
True once you've scaled up to the point that all your services are distributed, but before then it's worth having an awareness of what runs on what box. Memorable names help with that.
One other downside you've missed with location-based is that it makes it harder to move a machine.
I saw this post and came to write a comment about "save yourself some trouble, make it random or positional and just have a functional inventory system which you'll need anyway" but hey, look, it's gmjosack beating me to it! ;)
I think it depends mainly on the stakeholders. If we're talking about physical machines, I suggest location/hardware based naming. For virtual machines, I'd choose function/role based naming. Though, this depends on type and size of engineering staff that needs to work with it. For end users, I'd add service based names, possibly as cnames. And I'd plan to change the naming scheme as the requirements change.
Has anyone a naming scheme that lasted more than ten years?
The hostnames I develop with are like "imdopsjpl741", difficult to remember. I prefer names like "rover" and "elephant" but can understand how that could be worse for the server farm ops people.
Cute naming conventions are fun when you're small and have no intention of growing the network. If you're planning to scale, you may as well start with practical names that give some context for the location and purpose of each box. Your team have more important things to remember than which country mario lives in and whether pluto is an app server or a database.
I agree, and even if you're small I think having more sensible names is probably a better sign of 'maturity'. On my home network I'm moving back to naming new devices and VMs by type and purpose (e.g. server01, raspberry01, htpc01) rather than continuing the naming convention I had.
At my CCNA class the teacher used local politicans names for routers/switches, I remember it was election period and routing classes usually ended up with discussions about politics.
After many, many nights spent tracking down servers named after:
Indian food dishes (30 of em! "where is jalfrazie?")
Great US mountains (ugh.)
'win2003' the Sun box (ugh again. don't name the box after the OS running on it...)
...i'd say my favorite was 'appname-colo-number#-rackunit#-rack#.airportcode.yourdomain'. This way, the db server in your new york colo JFK1 is easily found in rack unit 20 of rack #5 (db01-20-5.jfk1.example.com).
Once you have +200 servers, having physical location and role mapped to the hostname is a game changer. Even better would be having just a six digit hex hash that you could look up in a noc dashboard.
Note that all that other cutesy stuff is fine as a CNAME, but the FQDN might as well be made significant since it needs to be unique anyway.
Setting up a standard naming convention for hostnames is more logical, efficient, and scalable. Include useful information in the hostname, so you don't have to map random lists of names to functions. "What does server 'Foo' do again? Oh, it is a database server. Was that production, dev, or test?" Do you (or one of your operations team) want to be figuring that out at 2AM when you get an alert? Depending on your setup, something like this may be appropriate: <location>-<notation of physical/virtual>-<function>-<#> (e.g. bos-xen-mysql-005, being a virtualized Xen-based MySQL server in Boston). If you have multiple environments (dev/test/prod), add that too.
Cute server naming schemes are one of my pet peeves. In my experience the only two logical choices are: sequential numbers (e.g. foo1, ..., foo100, ... if your company name is Foo Corp.), or hashes / uuids (like amazon instance IDs, e.g. i-977a24e3). If you want to give a server a memorable or cute name, use DNS or some kind of alias.
Read the aforementioned RFC - with sequential numbers you are not naming them.
I can imagine how thrilled your colleagues are if they have to ssh into i-977 what was the rest of it?
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.
When you're starting off with your cute naming scheme, how do you know how many machines you'll manage in the end? Most places I've worked at have hundreds of servers. Using a simple, easy to follow, don't-make-me-think standard from the beginning is the only thing that makes sense IMO.
To give a server a meaningful name, use DNS.
edit: Also, to take your complaint about "i-977.. what was the rest of it?" and turn it around - imagine this scenario: provision 20 new app servers named foo40..foo59 OR provision 20 new app servers and think of 20 cool names to match our existing cool naming scheme of leonardo donatello michaelangelo raphael master-splinter shredder blah blah blah :)
If you don't have some toolset around managing your servers and have to resort to memorizing hostnames, being able to remember hostnames is the least of your problems.
I stepped away from naming hosts the year I learned to use Puppet. After being able to create an infrastructure based on code, the idea of naming hosts just seemed pointless.
Can you elaborate on that? My company uses Puppet, but we've configured it to determine what to set up based on the hostname of the machine. (I have no idea if that's ideal, but it's what we've got.)
«We used to treat our physical machines as home pets, having few of them, giving them proper names, caring about them individually.
Now we treat virtual machines as cattle on a large farm, marking them with numbers, denying them any individuality, and killing them when we don't need them any more.»
At ITECS, our Systems division uses practical names like engr-ras-201 for servers. However, we have a bit more fun with workstations. My machine was named "waytso." I asked my boss what it stood for once, and she said that after the machine that used to sit on that desk had died, Desktop Support sat down an old Dell Dimension to hold us over until they could get a newer machine ready.
It ended up taking a few months, and one day, they called her and said, "Hey, we're ready to image the new Webteam workstation. What should we set the hostname to?" "Waytso." "Waytso? What does that mean?" "Why Are You Taking SO long!?"
I've seen myself searching for a compilation like this one time ago.
I miss some other traditional in other locations of the world, but still for me it's a great compilation I just saved for "the next time I see myself searching for it".
My lab uses painters. We have DaVinci, VanGogh, Munch, and others. What's cool about these hostnames is that we can find out other painters and learn stuff about them, such as name pronunciation, paintings, etc. When we have a new machine, we search for another painter, we look at their paintings. This is good to learn new stuff. Another good category would be rock 'n' roll bands:
- "Hey, I will run some experiments on zeppelin tonight. Is she free? Thank you."
- "All our computers play a song from its hostname band. Except pinkfloyd. No one had patience to listen to a song for 20 minutes."
The morons in IT department in my current company have accomplished an amazing feat with the host names. We have one host name that I have been using for 2 years almost every day and I still have not memorized it! I am having to cut and paste it every single time.
The host names were invented so people won't have to memorize IP addresses. IT morons here with their "functional hostnames" have managed to defeat the purpose of hostnames, so that they are now harder to remember than IP addresses!
Please please please get a clue, use geography, mythology, Simpsons, anything but stupid "bisappjmpthatthislakdh000283".
I recently designed several themes for a website. To simplify my naming process, I decided to find, like OP did, an already defined list of names and ended up using Paris' Métro stations [1].
Perhaps the question 'how do you name your servers?' should be added to tech interviews, the more cutesy the response, the less mature/experienced the interviewee possibly is (i.e. having not been burnt by the obfuscation of such as scheme)?
Renaming machines is a pain, and they inevitably end up with more/different stuff on them than was originally intended, then your "helpful" name like pukweb01 (production, uk, web, 01) is worse than "pikachu" (as it's incorrect).
the correct way to do this is to give the machine a name with no meaning (maybe pikachu, maybe box005) and have a list of the services running on each machine, and use DNS for those (say www1/ns1 that CNAMEs to the actual hostname).
personally, I'd argue that anyone that calls machines things like "pukweb01" has had little to no experience with a rapidly evolving system...
The users of the servers need never be burnt by the cutesy names and can remember them easier. So it seems not so clear cut what's better all things considered, especially as the ratio of users to operations folk increases.
This is ridiculously unnecessary, and very confusing for new team members and devops. Hostnames should be descriptive and help describe the machine's location and responsibility in the network topology. Like webserver01a (nginx, first machine in LB, us-east1a).
Sure it's not cutesy as "pikachu" or "bobasaur", but it will sure make your nagios/copperegg dashboard make lot more sense. And when shit hits the fan you won't think your servers are cute, despite their clever names.
I (somewhat) disagree. Every machine should have a unique hostname that has nothing to do with its function. It should be in DNS and should be the name you use to remotely manage it. Descriptive names should also be assigned in DNS as functions are assigned to the device (either as additional A/AAAA records or CNAMEs). This is flexible and scales well.
Many years ago, I originally assigned descriptive names to machines as I deployed them, but this didn't scale well as we wanted to move services (and their related hostames) to other machines. So I started assigning unique names to machines, using famous figures born on the day of configuration (as in http://en.wikipedia.org/wiki/October_12#Births). That was 'cute' for a while, but now I just generate random 4-letter words and pick the ones I like. The namespace is large enough for my purposes, the names are short enough for easy typing (ssh fang), and everything aligns nicely in text (zone files, inventory, etc.). In some cases, I've even replaced descriptive names with TXT records in DNS associated with the unique name.
'foo' is whatever, and 'mysql' is bad while 'corp-db' is better as other commentators mentioned.
for XYnn match X to the airport code of the datacenter, match Y to the sequence number of the datacenter, and 'nn' is a 2-digit code for the number in the cluster.
all short names are unique this way. all datacenter can have a mix of prod/int/dev/test. you can use DNS name resolution search path to lookup services like 'ldap' in your local datacenter.
don't use serial numbers. foo-123456789 is annoying for humans to use and will get truncated with interesting results. i had a discussion one time on chat with another engineer where i was looking at box '123' and he was looking at box '789' and we were both getting real confused because it seemed like we were on the same box... because we were...
also only use "company.com" as your domain for every server and desktop in your company. if you need "company.co.uk" then it should only host websites "www.company.co.uk" that points at VIPs and the servers behind that should all still live in company.com. if you have windows boxes then setup a domain for AD "ad.company.com" or "win.company.com" and let your domain servers own that and setup proper DNS delegation from the parent.
We have IP addresses. They are unique numbers that will always resolve to one unique machine, on which a network service exists that we want to talk to. We use the hostname to refer to the unique instance, and a URI's protocol name to refer to the service we want.
smtp. ntp. www. ftp. These are all short names that work great at expressing both what and where the service you want is, under your domain. But what if you have more than one? is it www2? ntp4? ftp3? which host/service do I want?
Context is everything. Your hostnames should be a representation of what you want to access, assuming a service with a default port. Instead of www2, www-devel. Instead of mysql255, mysql-qa-dev-ext. These are contexts that are specific to what you want, not just random identifiers you can use to pinpoint an exact thing.
Renaming hosts is a pain. It should be minimized, which is why CNAMEs are useful. If you can, try to give teams DNS control over the records pointing to the hosts they manage, so they can control them without waiting for the DNS admin to put a change through in a week. Make DNS changes work automatically and immediately (trust me, it's perfectly doable even in large environments). In most cases, you don't really need a host's name changed, you just need a CNAME to the new host you want to use.
In my company we're using musical instrument names for machines. Bass instruments are servers, treble instruments are laptops, and medium ones are desktops.
Interestingly, though run on a shoestring, this proved to be one of the most reliable set of servers on campus. I guess the disaster naming was a sort of a reverse jinx.
To add a little counterweight to the 'should you give cute names' discussion - there is at least one reason why cute names are a good idea. I work for a web host, and our servers are named after musicians. It's a lot more likely on the phone that if I ask a customer which box they're on, they'll remember Hendrix or Prince or Buckethead over web-london-534.
Imagine that some mystery virus has taken down or infected several boxes on your network and management want to know exactly what has gone on. In this scenario things are pretty sober and you really don't want to have anyone asking why the computers are named after some characters from a TV show or pretentious Greek myth characters. They won't see the funny side of it (if there is a funny side).
It is therefore much better to have important network machines and kit named in a logical manner, e.g. location-purpose-number.
As for what people have on their own desks, some people might detest whatever your cutesy name scheme is and be irked at having to use a machine called 'jigglypuff' just because they really never liked Teenage Mutant Ninja Turtles. They might also not really take to their workstation being impersonal, e.g. 'ldn-gfx-23'. Hence, on the desktop let people have a machine name of their choosing.
If I may put forth a slice of my personal philosophy, it's that silly host names have ruled naming conventions long enough. I much prefer boring but logical descriptors that help my network self-document: whether simple codes useful in small environments (like "file01") or more complex schemes suitable for large-scale computing (e.g., "masip150ntvirt" or "cin-me-exch-01"). With the right scheme, 15 characters can tell you a lot about the location, ownership, configuration, and purpose of a particular computer. The cutesy naming conventions do nothing to help admins do their jobs or - in my opinion - actively get in the way.
AlphaTrion is the PDC, A-3 is the BDC/SDC. Iacon is the SQL machine (VectorSigma is the name of the LVM pool). OmegaSupreme/Metroplex/FortressMaxiums are the gateways. Gestalts (Defensor, Computron, Superion) are used for the SANs and any other clusters.
Considering we try to be good guys, we only allow Autobot names for workstations. Starfire, Starscream, Punch-Counterpunch, and other fence sitters are not allowed. I lobbied for Wheelie to be included in that list, but was overruled by others.
[EDIT] I could see how this might have limitations on scale, but we haven't hit those limits internally, so it doesn't affect me yet. :)
I work for a large company that has multiple locations and sub business and many buildings have multiple data centres. By looking at the name, we can tell if its a prod / dev or a test server, location of the server ( city/building code and DC number), generic function ( DB -database could be any type of db , FS- file server, etc ) and unique number. Pretty good to pinpoint the location of the server globally but useless when you need to find out the exact function. While our inventory system is kind of OK, keeping it updated is a pain.
An interesting tidbit; the list is compiled by Greg Ercolano, author of the render queue software Rush[1], for which he received an Academy Award in 2011[2].
It's a great piece of software for the VFX/post-production industry, and he's by far the best software vendor I've
ever worked with.
What a great set of lists! I had a sudden flashback to the days of the "Beowulf Cluster of X" meme, but in all seriousness, my favorite used to be towns I've lived in or visited, but that too is a bit cumbersome to remember in a pinch sometimes.
These days, I go with colors - I usually get a handy 7 right from the start - so I don't need to dig in too much. I've also gone with desserts or sweets and I'm sure Android was a big inspiration (albeit subconsciously) for that.
My habit is to name machines after Star Wars planets /characters. But despite fact that I already have a established pattern it's often struggle to come up with a name.
I think I've gone full circle on hostnames. Cute -> functional -> boring semi serially assigned.
It doesn't matter is my conclusion. where I work we have the remnants of about 5 different naming schemes living side by side (very big environment) and we're not missing out our gaining a thing.
We always resort to some external db (Sometimes just a spreadsheet) to lookup particular hosts based on whatever today's criteria is.
Outgrowing Marvel characters is a sign of good growth. Marvel says they have 7000 characters, and that count might exclude characters that just had one minor appearance.
We reached a point where it was just becoming painful to keep track of them - what a server did and where it was located. When you only have a handful of machines at one location, it's not a big deal. But once that number grows, and especially if spans multiple data centers, cute or geeky naming schemes tend to fall apart.
"Wait, was Magneto the master DB or the NFS server? Did we move DB off there? Is it in Atlanta, or San Francisco, or Phoenix?"
Eventually we reached a point where we had a spreadsheet mapping hostnames to architecture functions and physical locations. We realized that, even though our naming scheme was cool, it wasn't going to scale much further.
In the book "The History of Farting", an A-Z of different farts are described. Great for a laugh, but I doubt they would make good hostnames. You would be too busy laughing at the fact that the "J-curve fart" only exists theoretically, while your co-workers would be attempting to ignite theirs.
At my university, we had a small Beowulf cluster set up for when what we wanted was to play with distributed processing (there was another, much more powerful and better managed, cluster for jobs that actually needed to get done). Naturally, we used names of kings and heroes from Beowulf.
I don't typically manage hostnames, but I use planets from the Hitchhiker's Guide to the Galaxy for removable drives.
Unrelated: if you use the time measurement list for hostnames, or anything else that other people have to type, please for the love of God spell "millennium" correctly.
In Ancient Times, Industrial Light and Magic was on Usenet, and maybe the Internet, via a system named dagobah.
I worked in a computer graphics group that used artist names, like vermeer, escher, davinci, etc. My system was bonestell. In another group I was in, we used names of dances, like bolero, foxtrot, tango, etc. The guy who suggested bolero was thinking of Bo Derek, but I took the idea of dance names and ran with it. My system was tarantella, which was hard enough to spell that people stayed off of it.
At home, I don't follow a pattern, but I have used names from "A Wrinkle in Time". My first quad core linux system was called tesseract and my Windows box was camazotz. I've always like the names of the earliest computers like ENIAC, EDSAC, UNIVAC, etc., so I named my Mac Pro prozac. I've considered naming my two raspberry pis colossus and guardian...
An admin in a research lab where I was an intern had used negative emotions as a naming scheme.
Anger
Despair
Fear
etc.
until someone on his day off created a machine called 'lol'.
I think I noticed all the previous hostnames in his face when he found out about that one...
I've been using names from the Mr. Men series of books, so e.g. tickle, grumpy, topsyturvy, daydream. Easy to remember because the characters are each so unique and different, and gives each machine its own personality: "Oh crap, grumpy is acting up again", etc.
I used to go with "theme" name like wine oriented (chardonnay, merlot...) But after a while it gets confusing to remember which machine does what and switch to more "functional" names like "worker01, worker02, db01..."
If you're geeky enough about your theme, you could use theme-based names that are also functional. For example, all the wines are application servers, all the beers are DB servers, etc.
I once worked for a telecommunications company that used condom brands for internal server host names. Makes me wonder if there are any other major companies that use somewhat inappropriate names for their non-client-facing equipment.
My university used to have their CS lab machines named after breakfast cereals, soups, and pastas. Last year they switched to Unix commands, programming languages, and design patterns.
I use the house names of westeros (game of thrones) for all my hostnames in my home network. Its a lot more fun mounting a drive from winterfell or streaming movies from kingslanding.
I like Harry Potter characters. There are lots of names in those books and the lists are readily available. Lots of them are unambiguous in English which is nice.
Nice! I did this without being aware that it was a good thing to do, and with a small network. I chose Finnish goddess names, some of which got pretty unwieldy...
That could bite you if you happen to start to work with someone with that name. Therefore, RFC 1178 recommmends not naming hosts using names of people.
we use periodic table elements for releases, we even have "isotopes". version numbers perfectly match to atomic numbers, and they all have abbreviations. it's a great way to learn the periodic table as well.
eh. I had that at a previous employer. I used volcano names because there's a fair number of them and they sometimes explode. ( the graphite server was called seismograph... ).
"Choosing a name for your computer" http://tools.ietf.org/html/rfc1178
Shades of colours, for example https://en.wikipedia.org/wiki/Category:Shades_of_blue, are a good, safe source of names.