Slashdot Mirror
Best DNS Naming Scheme For Small/Medium Businesses?
Bandman writes "My business just purchased a couple dozen blades, and with our existing servers, this brings us to around 60 machines. We're geographically dispersed, and most of the users who need to connect to servers are not technical (if that matters).
We used to use theme-based naming schemes, but we've been migrating to a more utilitarian system. I think it's clearer and more concise, but I've had some feedback from users who didn't find it understandable.
What do you use for your internal DNS schemes? How big is your network, and what do you recommend for future expansion? Does it matter to your users at all?"
The guys at work seem to enjoy their time with Jenna quite a bit.
Server0000
...
Server0001
Server0002
Server0003
Server9998
Server9999
Body parts. Easy to remember.
"Where is that file?"
"In the nose."
...therefore all my servers are given a hostname string equal to the Dell "Service Tag", followed by a dash, followed by the Dell "Express Service Code".
I really love my junior admins, and whoever the poor schmuck is that will take my place as senior sysadmin once I'm gone from here.
That won't work, unless you use first and last names (how many Jenna's are there again?), in which case the joke will quickly become obvious.
Linux, you magnificent bastard, I read the fucking manual!
The best suggestion I can think of right now is to use short names or words and NOT use acronyms, because you'll end up with lots of people either not remembering the acronyms (typing them with typos) and/or not remembering which acronyms are associated with what.
Using something that should be familiar to most employes and not offensive to anyone would also help, especially when they call for tech support.
As a reference, on my network at home all the computers, servers and even devices have names from the Metroid games (Zebes, Samus, SR388, etc).
Your users really shouldn't have to know the name of any server, anyway. That's what shortcuts and mapped drives are for (pushed down via login scripts/GPOs).
Name the servers with logical names based on their function, and maybe an extra number to distinguish servers with the same function. Put all of the REAL info into database. Trying to put lots of config/location details into the DNS name is a waste of time. There no reason to have names like FILESERVER-CHICAGO-02-2003RT when FILESERVER2 would suffice.
A good host name should denote the following:
-location
-department/cost center
-purpose
-prod/stage
-some sort of serial # to make it easy
Depending on how your sites are named (I like using airport codes but it might not scale right for your org), you could wind up with:
sjcmarkfilep01
Which would denote san jose office, marketing, fileserver, production, 01.
Adjust as necessary for your use.
Even Jesus hates listening to Creed.
Something along the lines of XXyyy01, XXyyy02, where XX is a two-character code for the computer center in which the box physically resides, yyy is the basic function of the box, and 01, 02 are numbers to describe each unique server in each location/category. Zones on Solaris servers are indicated with -Zn where n is the zone number.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
We (somewhere between small and medium, branches in Germany, Austria and the US) use two naming schemes:
The primary scheme is [serverclass+#].[branch].domain.com This is what we, the tech staff, use for establishing connections for live systems and what we communicate to our users.
Examples would be mail1.berlin.domain.com, internalweb3.munich.domain.com etc. These names are more logical than physical, ie. one machine that offers several services via one IP is reachable under several names. This allows us to flexibly assign machines to certain roles.
The second naming scheme is what we use to identify the physical (resp. virtual) machines, versus the logical services. And it's simply Shakespeare characters. In my branch we went through the Tempest, the others started off with King Lear, Othello and another one whose name escapes me. We use those names only for reference and for management operations (SSH'ing, file transfers, whole-disk backups, virtual machine management), so our users never get to see those.
Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
My employer is a Windows shop (shudder). The servers run by IT use a 2-3 letter prefix to indicate the role, followed by the version of Windows, followed by an enumerating suffix. Hence we end up with names like exw2k301 (Exchange Server, Windows 2003, server 1). Of course, standards are made to be broken and the main print server maps to nt008a and the file server to nt014. Unless you can turn the servers into load-sharing devices and then use purely functional names (mail, web, file, print, etc), there's going to be a learning curve for your users.
There's a whole RFC on this:
http://www.faqs.org/rfcs/rfc1178.html
Interesting read...it specifically says:
'Don't choose a name after a project unique to that machine.'
I agree with the reasoning, but on large scale DNS deployments, I can also see this being a nightmare... I just use arbitrary names, nothing too hard to spell.
As fun as it is to give servers clever names, only the tech savvy staff are going to remember the true purpose of that machine (oh it's a reference to the roman goddess of proxy caching... duh, what's wrong with end user!).
It's easier for users to follow the idea if naming conventions follow a logic pattern. My small company has locations in multiple states and use host names like cityFileServer or cityProxy. Once users understand the role of a particular server, it's a trivial task to use one physically located at a different site. This also helps prevent vague help requests like "the server is down" because they are able to articulate exactly what they are talking about.
If it's a network of equipment that will never be used by end users, hell make it clever as you can. Most of the IT staff are going to use the IP addresses rather than the hosts anyway.
Everything at my office is named after Simpsons characters. We have Krusty, CrazyCatLady, DrNick, McBain, SideShowBob, etc...
In my organization we have multiple business units that we've bought over the years.
While we've attempted to migrate most of those units into enterprise apps, we still have a few outliars.
For servers we'll typically use something like.
business unit
location
server function
# of server performing that function (exchange = exchange01, etc..)
For common things like front end servers we'll give nice friendly names to. citrix, webmail, etc...
I've worked in shops with 100 boxes to 10,000 boxes. Having systems with cute names from a movie or theme works for a while, but the system starts to break down once replacement machines start entering the network.
Probably the best naming scheme was first sub-domained by airport code and/or country code:
jfk.us.domain.com
lgw.uk.domain.com
If that doesn't work, you can also do city.country.domain.com
Once you've got your subdomains worked out, the machine host name ends up being the function, or a code you've designed to indicate function (since you don't want to tell everyone what your boxes do). You probably also want to include a numeric component as well. ie NS3, NI2 (Network Infrastructure ie DNS, DHCP, routing, firewall, etc). Make sure you document what each designation machine does, that way people don't start running around naming things incorrectly.
I like this system because it allows for growth, replacement, and tells you something useful about the machines if their name shows up in a log somewhere.
I would argue that many of your users don't need to touch the machines, especially those in production. If there are some that users need to access, you can always create a CNAME to give them that gets them to a box that already has a name in your organized naming scheme.
Hope that's useful.
-Runz
With cryptic names. Well, not cryptic, they just have nothing to do with the function. The users shouldn't have to know anything about the names of the servers. They should just tell you what they're trying to do, and you should go forth and fix it, or tell them why they're stupid as nicely as possible (unless you work in an all-Unix shop and you're the only one who knows how to work sh.)
If it's really big and complicated, use subdomains, that's what they're for. It's most convenient if you can map them to subnets for your own sanity.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
While it may not be the more desirable, I've always used the following or similar context in server naming:
1-3 character Company Name: CO
1-2 character City, Building, or locale: CY
1-4 character Server Function: SRV
1-3 character Identifier: 01
Final Name: COCYSRV01
A more real-world example would be:
Company: Cogs Inc
City: Dallas, TX.
Server: Active Directory Server
Server ID: #2
CGI D ADS 02 = CGIDADS02
If you have trouble making up a universal acronym for something, try visiting the following site: http://www.acronymfinder.com/
Regardless of the size of the company, this schema has always worked for me.
Depends how the 60 blades are logically divided up. I can't imagine you have 60 different daemons running, or a reason for 60 absolutely distinct servers. Group them into clusters, number servers in the cluster (don't bother including location in the hostname, just have a table somewhere if actual location matters), name the cluster something random and be done with it.
Working in a large datacentre a consistent naming scheme is critical for ease of maintenance. This should not only encompass the servers but also any switches, firewalls, load balancers or other hardware.
As a suggestion for you, try to come up with a scheme that is meaningful and provides information about location, purpose, operating system and any other information that might be pertinent. For example NYCSWT01IOS for New York, Primary Switch, running IOS, or INDSAP02LNX for a SAP server in Indiana running Linux
What we do is use a series of numbers separated by periods to designate a hierarchy. For example, the servers in the company all share the first number, say 192. Then, each department has its own number, say 168, giving us 192.168. Then, each location in the department has a number, such as 204, taking us to 192.168.204. Then we give each server a unique number, like 10, bringing us up to 192.168.204.10. It's very easy for me to recognize where a machine is by that address. We try to keep the numbers under 255 to make them easier to remember, and it's really not many more digits that a long distance code and phone number.
Make a Hash MD5 code from the location address of the server + it's Serial number. Use that for the server name. Or use a dictionary. start from a pre-determined random page and use the 3rd word on that page.then every server takes the 3rd word from the next page and so on... or start from 0001 and work up..
Laters Sol "Have you found the secrets of the universe? Asked Zebade "I'm sure I left them here somewhere"
It doesn't really matter what you name the machines, so long as they are unique names. At my company we use the names of sugars for all our Linux machines, and alcohols for all our macs.
Now, the important part is just to use aliases for all services. So for example, if SMTP runs on a machine called dextrose, then create a DNS alias smtp.department.company.com that points to that server. If there is more than one server providing the service, you can either use round-robin DNS (if it doesn't matter which one is used), or just provide a numerical suffix to the alias.
If you have a compute cluster, I strongly recommend numbering the machines sequentially, then you can use a tool like PDSH or bash {} expansion to address groups of machines.
Road Runner, which is a cable internet provider for Time Warner if you didn't know, uses a perfect system. My e-mail is at new.rr.com and the NEW is northeast wisconsin (even though it covers all of Wisconsin except Milwaukee). I've seen other acronyms for different areas too. Nobody seems to forget 3 simple letters around here. So I dunno much about networking but I think you set up the subdomains and point each one to each server and you're set.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
I would go with .com
When I was at the University of Edinburgh back in the 1980's, I seem to remember the CS workstations being named after pubs in the city. That worked since there are so many pubs in Edinburgh - practically one on every street corner. It worked pretty well because the names were distinctive and recognizable, and it was at least a little humorous. I think it's better to use a set names that people already recognize, since the brain is really good at recognition. Abstract names are not so great, since they require conscious effort to memorize.
You can create subdomains, and maybe be more descriptive with utilitarian names based on what they do or something descriptive enough to be clear, i.e. externalweb.servers.xxx.com, john.desktop.xxx.com or even mail.france.xxx.com.
Or you can keep the funny names, but use different schemes for different places/functions.
Having worked at two companies now with 8,000+ servers each, unless you're changing server roles all the time, function based names are best. Even in a small environment, I would recommend this scheme. Pad the names to at least two digits, more if your expectations require; i.e. 01, 02, 03. Site names based on local airport codes are also good. If you have multiple sites in one geographical area, suffix the names with 01, 02, 03, ...
Examples:
nagios01.sfo.example.com
nagios02.sfo.example.com
nagios01.phx.example.com
dns01.lga01.example.com
dns01.lga02.example.com
Some would argue against this for purposes of "security". I think this is flawed for several reasons:
1. It's security through obscurity, which is no security.
2. If someone's freely in your network, the jig is already up.
3. It only serves to complicate things when you get bigger, and inevitably go to function based names.
Yes, I am a smart ass; it's better than the alternative.
The University of Wisconsin CS Dept. used cheeses. Never seemed to have a problem with running out, although they named two machines kraft-slices and velveeta, and the lawyers moved in and made them change.
Incidentally, included among the cheeses were puff, whiz, and head (the latter is also a popular Wisconsin food product, so it's all good).
[boss' name]ISADIK
[female boss]ISACNT
Etc....
Outside of the cartoon characters I use in the lab, I like to 'model' my naming scheme on 'Common Language Location Identifier' (CLLI)
DNS001NYNYUS
DNS002NYNYUS
SMTP01NYNYUS
POP301NYNYUS
FTP001LACAUS
etc...
I use the names of Elements for my machine naming scheme. They are short, recognizable, and if you want to be really anal, they are already in groups and you can apply those groups to type of servers.
(Halogens are the mail servers, Lanthanides are the web servers, actinides are the databases, etc)
"Dogs and cats, living together...it's mass hysteria!"
Use an abbreviation for departments och service.
Like mail01, mail02, ldap01 .....
Never use given names like: Gandalf, Merlin, Rincewind or whatever from your favorite move/book/game.
I can't think of something more unprofessional than using given names for computers.
We use different naming schemes for different subsets of servers depending on what they're used for.
For general-use clusters that people are going to ssh in to do work on, need to remember the names of, and are actually different (i.e. we don't have five servers just for load-balancing, but for five different things), we tend to use theme-based names that are short and hard to misspell. E.g. the old standby of computer scientists: turing, knuth, etc.
For servers that are going to be used as part of a cluster, or identical machines with identical mounted filesystems/home-dirs, we pick a name and append numbers. E.g. foo01 through foo99. There's really no reason to give them names, and it makes simple bash/perl/etc. scripts easier to write than walking a list of names kept in a file. Round-robin DNS then resolves foo to one of the foo## randomly for a user who just wants any machine in the cluster. (If you want to get fancy you can preferentially direct them to an unloaded machine.)
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
(Credit: Gordon Greene)
If you want an endlessly expandable name space, you can't beat STDs. The catch is that no one can spell half of them.
Dead celebrities are good too. You can use the cause of death as a subdomain, to keep things a bit less chaotic. People *can* spell those.
Again in the "depends what they're for" vein, we do have a set of general-purpose servers with identical mounted filesystems/home-dirs that do have different, non-numerical names (still the short, hard-to-misspell variety). These are mainly compute servers for people who leave long-running jobs in screen, because it's easier to remember "I set some stuff up on knuth" than "I set some stuff up on foo32". The load-balancing can be sub-optimal in this approach (people tend to pick a machine they use as "their" compute server, and some names seem more popular than others), but it mostly works.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
So name them Haze, Jameson, Presley, etc. Those even sound reasonable.
Here is what I did.
I used a utilitarian naming scheam and then use CNAMES for functions.
Everyone is happy.
Where I currently work, we manage 550+ AIX (and a few Linux) systems. I'm told there are also about 800 or so Windows images. They all have theme based names. Most AIX systems do have biological names, but a few are named after lakes and chemical elements. Windows I'm told uses car names.
Similar servers do get related names. For example, all chemical elements are Siebel systems, Oracle runs on snakes and TSM on nuts (main site) and monkeys (the backup site). IMHO, this works well, as it makes it easier to remember what server(s) demand your attention, and harder to confuse systems with too similar looking names.
If you can't name more superhero characters than you have servers then either...
(a) We're going to take your official geek card away.
or (b) You should already know more about naming conventions than anyone reading this.
Seriously, there shouldn't be a problem with a mix and match scheme. For instance, name a typical server ohio-27-002.mycompany.com but use DNS to give the important ones a second name as in wolverine.mycompany.com
Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
In a small/medium business, there are not enough systems that you need to worry having structured naming conventions. In those situations, I just make sure they are,
* 8 chars or less (for compatibility with everything)
* no special characters (punctuation, etc.)
* easy to spell and to pronounce
* hard to confuse with users/functions/places -- who knows what this server will be used for in the future. Save yourself the effort of renaming it.
Sometimes I pick a theme, but it's mostly for fun, or to make it easier to come up with a name.
Are you talking about having a user point their web browser to CRM-server.XYZ.com? or are you having them connect to a network drive? -filer/share....
I wouldn't tie the name to the hardware since you should be architecting your environment to be able to migrate the application/share to new hardware in the next few years, so doing something like DL380-row1-rack2-A isn't a wise idea.
If you're naming storage devices (arrays) than -- is a good solution. EMC-1234-14AA
Coming up with "cutesy" naming schemes like national parks, sports teams, beers, guns, cartoon characters are neat if you have 5 systems that no end user would connect to or get offended by.
Server1 ...
Server2
Server3
Server4
I think you can probably see where this is going.
We used to use theme-based naming schemes
oh god please no.
Our machines were named based on themes, and that's the WORST idea on the planet. If you are going to give things names, things that need to be immediately recognized for what they are. If you have too many to give them logical names, then name them as radically different as possible so you can tell them apart in a heartbeat. The whole point of naming them is to avoid confusion, or we'd just number them wouldn't we?
Name them Orange, Peanut, Chrysler, Diamond, and Dolphin. Pick names that are not easily confused. Stay away from names that identify people or places, to avoid other communications issues. "Tom has that" should not leave you wondering if Tom is a server you don't usually work with, or is someone named Tom. Same for "Where's that database? Detroit?"
I have to deal with one group of servers that are all named by Star Trek (TNG) ship names. And at another location they are all weather phenomena. BAD IDEA. I don't deal with the trek machines much and they just can't understand why I can't remember the difference between Enterprise and Intrepid. Sure if you deal with them daily you'll get the hang of it, but picking similar names is a nightmare for anyone unfamiliar with the system. If we only had one space ship for a server I could associate that uniqueness with its purpose. But no, I'm thinking "OK the firewall runs on the spaceship... oh ya that's right we have SEVEN of those... was it DS9 because it's a station? Maybe Defiant because it's defying the hackers? OK where'd that list go?"
NO THEMES
And if you're tempted to use a different theme for each location, just DON'T. What's more important to you, being able to tell what a machine does, or knowing where it's at? If you do theme by location, all you're going to clarify is where it's at.
I work for the Department of Redundancy Department.
Mostly obvious names internal. Dev1 Dev2 are the 2 primary dev servers Backup is the backup server svn is the svn server test is the live environment test cluster. Where it gets confusing is in our hosting cluster. The external world sees the cluster as just hosted. but each server also has a 2nd network card linked directly to our internal lan where ssh etc is available internally the servers are names alpha, beta, ceta, delta etc apart from the 2 mysql servers which are called db1 and db2 oh how inventive I am
We use location/company initials/dev-test-qa-prod/function/number for most of our machines. Seems to work and once you get the scheme, you can start guessing where things are if for some reason somebody doesn't have the docs on a certain application.
For instance:
ABICPWEB02 would be A = Data Center: Arizona, BIP = Big Important Company, P = Production Server, WEB = webserver, 02 = #2
It CAN get tricky with things like DBICQASQLCLU01 (Delaware, Big Important Company, QA, SQL Cluster, #1), but whatever... You can figure it out. :)
Grandpa: My Homer is not a communist. He may be a liar, a pig, an idiot, a communist, but he is not a porn star.
I tend to pick a religion or set of mythos and just go with the varied names therein. I have a domain with Hades, Ares, Zeus, Athena, etc. I also did a Hindu one with Shiva, Kali, Lakshmi, Ganesh, Vishnu, etc. Hard to get them mixed up that way, and you can generally tell which are related by their names.
People are like slinkies; useless but fun to watch when you push them down the stairs
I started with three computers: Balthasar, Melchior, Caspar. They're my MAGI-System.
My Laptops are EVA00 and EVA01. I spray painted them accordingly...
No I don't wear a blue and white neoprene suit when operating them. I don't wear hair clips, either. But I do call the stylus of my PDA "The lance of Longinius"...
EOF
- 1st letter : S for Solaris, L for Linux, W for Windows, etc.
:
- 2nd letter : P for Production, T for Test, etc.
- After is the shortened name of the service : DNS, FTP, etc.
- And end it with some incremental numbers : 00, 01, etc.
So it might look something like
SPDNS00 or LTFTP01 or WPEXCHANGE01
something like 192.168.1.1 which resolves to 192.168.254.254 for example. I haven't heard of any users complaining about this so it must be great!
Names serve at least two purposes. First, they designate a particular machine and should be kept the same over its lifetime (barring the occasional re-christening) to avoid confusion if someone reads old documentation (e.g. trouble tickets about failed hardware). Second, names designate the purpose to which that hardware is being used (e.g. "mailserv" should always be the current mail server). Over time as hardware gets reassigned, these two purposes will inevitably drift apart.
The solution to this quandary is to realize that it is not an either/or problem. Nothing prevents you from having multiple DNS entries for each machine. Put the "real" name in the DNS that is kept invariant right along side a "purpose" name (e.g. "www", "smtp", "dev1", "test4", etc.) which can be freely changed as needed.
-- hostnames (very long ttl - should never really change) jfk-l3-n1 jfk-l3-n2 pvd-cg-n1 then cname functions (shorter ttl, so you can move functions from machine to machine): prod1db -> jfk-l3-n2
The actual name you give the server is arbitrary. End users should not reference this name whatsoever. The name should not be tied to a function, since functions can move from server to server. How many companies have mail2 as the mail server and mail does something like printing or DNS. Or DNS is downgraded to a workstation and bind1 now is the DNS server. If you want to use the serial number or asset number. My personal favorite is to "name" servers using names like bob, sally, walter, joe. You then give functional names through DNS. mail.domain.com points to john.domain.com, ftp.domain.com points to mikey.domain.com and so on. End users only refence the functional name, that way moving or upgrading systems is transparent. Same goes for load balancing and DR nonsense. Avoid location and functional names, when these change is causes more work or confusion. I'd even recommend against using company name in the system name. You never know if you'll get acquired or name changes. Upper management gets their panties in a real bunch when the old name shows up somewhere.
My first experience was with two servers only, so the obvious choice was to name them Beavis and Butthead. Then the network grew and we decided to go with planets (keeping good ol' Beavis and Butthead). After a while (a few years) the network grew again, and by that time, each location decided how to name their own servers. Oh.. beavis and butthead are still breathing!
The comments on this article make me stabby.
If/when I run a company where I need to hire IT folk, this will be one of my interview questions. If someone says a good naming scheme would be planets, elements, or some other theme based nonsense, (s)he's getting the boot.
Yes, I am a smart ass; it's better than the alternative.
... from clients, here's a quick rundown of what people name their machines.
At #1: brand names: hp-xxxxxxxx,DELLxxxxxxx; These are probably default-ish names as set up by their respective server/workstation installs.
At #2: unimaginative computer task names; workstation01 through workstation 67, server, fileserver, notebook, and so on.
At #3: user types / names; administrator, JohnDoe, etc.
At #4: television personalities of the non-human kind; Chairface being one of the more obscure.
At #5: random english words; frustrator, biatch, soprano, atlantic, colossus, coffee, dragon, etc.
At #6: indecipherable stuff; B36Y321, for example. It may be some manner of encoding scheme known only to the SysAdmin at the places, but it definitely make trouble-shooting with an end-user more difficult. "Are you running this on B36Y321?" -"Yes." "Are you sure?" -"Oh, sorry, I'm on B36Y312. Let me go find B36Y132" "..." "..." "..."
At #7: norse gods; The top three: Thor, Freyr, Loki
Beyond that it gets a little mixed.. TV characters are somewhat popular - though I must say there are a lot of girls' names in there that don't fit into #3; i.e. the name is not the name of the (primary) user.
Now, whether going by the above is sound advice for YOUR business, I wouldn't know. I will say this, however, names are -much- easier than cryptic encodings. I can understand some encoding for differentiation between offices, departments, all that; Beyond that, however, finding the machine named "-Thor" is a lot easier than finding machine "-23" in a long list of other "-##"-numbered machines for most places; I guess because numbering only makes sense if you physically have them in a row of sorts; moving machines would automatically break that.
...and also the first post I see where there is more than one name for each machine. It does make sense, though - so much sense that I wonder why most people don't seem to do it. It does allow for transparent moving of duties between machines, which sounds very useful to me. But then again IANAsysadmin.
Note: Any sysadmins who do have sound reasons for using exactly one name per machine are encouraged to share them. I'm not an admin, but I'm also not stupid enough to pass up information.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Any place I've worked at, I've always advocated using utility-based naming schemes, prefixed with the org's abbreviated name, e.g. xyz-mail01. As systems needed replacing, I've migrated many places to such a scheme, usually from theme-based or other similar nonsensical systems. It just looks more professional and is easier to become acclimated to as new staff arrives.
At home, however, I use the Cthulhu Mythos as a naming theme. I posted this from my laptop, Byakhee. Nonsensical, yes, but it keeps me amused.
Never start vast projects with half-vast ideas.
Nal-Hutta - (the Hutt's new homeworld - for the beancounters)
Tatooine - remote-office server
Hoth - the cold northern office..
Alderaan - for the site in India that works out of a condemmed bulding.
That list covers ~ 3000 - easy enough for a small business.
As has been said before, cute conventions do tend to fall apart after a while. On our network (A World War Two Aviation museum) we use classes and names.
Desktops - WW2 Aces. Gabby-Gabreski, Pappy-Boyington. My office machine is Richard-bong, which leads to great conversations about if Bong is ok, where is bong, etc.
Servers - WW2 Operations. Anvil, Mincemeat, Overlord
Misc devices. Gateways, Access points - WW2 A/C. Mustang, thunderbolt, spitfire.
Having classes has been more useful than anything else. Plus, it gets people at least a bit interested in how we do things, since folks ask about what the names on their machines mean.
There are some people that if they don't know, you can't tell 'em.
I'm not a developer so I don't get to say all the cool things I do at work often here *grin*
OK, at my current employer there are about 100 or so servers in a single geoloc, so it's really no big deal to name them. My previous job was at a company with a few thousand boxes spread out over three timezones in four cities (in the US), India, Australia, the UK and Brazil.
I was not involved in the naming scheme project, but I thought it worked very well.
Basically, the machines were named as follows:
[three-leter tasking code][3 digit num sequence].[location subnet].[main subnet].[company name abbrev].com
So let's say the company was Mordor Corp. The FQDN for a web server box in the Portland data center would be:
WEB219.pdx.us.mordor.com
An app server in Brazil was:
APP416.ads.br.mordor.com
In the case of the servers in the US, initially they used the airport codes for the cities (Portland = pdx, Houston = iah, Ft. Lauderdale = fll, etc) but later we just came up with three-letter codes for some data centers because it was more intuitive (HOU is better than IAH). For the other countries, we used the generic 'ads' subdomain and the two-letter ISO country code.
The server types were:
STO - File servers
APP - Application servers (could also be web servers)
WEB - Web servers (dedicated)
SQL - Database (any type)
PDC - Primary domain controllers
SDC - Secondary domain controllers
EXC - Exchange servers
DNS - Guess
LIC - Licensing servers
TSS - Dedicated terminal services boxes
SRV - Generic servers (to be avoided!)
There were a couple more but these were the main ones.
This scheme worked very well because the identifiers and numeric sequences are mnemonic, but most importantly, it scales. Numeric sequences were assigned as servers were imaged and named, pulling the codes from a simple database application someone at the company wrote. The sequences were tasking-specific, meaning that APP servers were sequential and unrelated to the WEB sequences, for example. The only problem I ever saw with that was the situation where we had more than 1,000 server of a single type, but as far as I know that never happened. In any case sequences could be re-used as servers were retired.
I've seen server naming schemes that used cartoon characters, Star Wars figures, elements, celestial bodies, etc. None of them worked (or would have worked) beyond 100 boxes or so.
The twitter monologues. Click on my homepage and be amazed.
We use roles for almost everything (machine.dev.company.com, machine.staging.company.com, etc.), but that doesn't stop us from giving the machines additional entries with easier to remember names. My colleague that runs IT here likes Winnie the Pooh, so all of the servers have at least one entry that names it as a Winnie the Pooh character.
It was annoying when I started working here (at my previous job the servers were named after Dilbert characters), but since I don't run IT I don't really care what he names them.
Pedro
----
The Insomniac Coder
My computers are named after the characters of Harry Potter. The network is called Hogwarts. The computers are named Fred & George, (those two have identical specs), and my laptop is named Hedwig since it's mobile.
This is probably not a good system if you have a lot of computers, as you might be running into the more obscure characters...
Spoon not. Fork, or fork not. There is no spoon.
Why do people seem to almost always associate a hostname with the service/application that the host provides? (Don't get me started on applications that bake in the hostname into their configurations and can not be configured to bound to certain IPs.)
For hostnames, we use some type of theme. For example, our e-mail gateways use the messaging gods (hermes, mercury, etc). For our file service cluster we used Matrix characters (neo and trinity). Then we overlay service names that the application and clients use like smtp.example.com, mx.example.com, imap.example.com or ifs.example.com. These service names AND applications are then bound to virtual IPs.
We also try to not reuse hostnames. That way when we talk about "medusa", we know what physical box we are talking about and don't get in to the "which box/generation of medusa are we talking about" issue. On the other hand, service names just move from box to box as upgrades take place all unknown to our users.
To us the hostname should not be known by anyone outside of the sysadmins group. Our users just care about the services that our servers provide and as long as they can connect to imap.example.com, they are happy.
> We're geographically dispersed, and most of the users who need to connect to servers are not technical (if that matters).
This is the most important thing about your situation. I would suggest you the following:
-Use sequence numbers for the actual host names (S01, S02, etc.) for maintenance/sysadmin purpose, and put a bright sticker with this name on every machine so it's easy to get a lambda user to find on which power button he should push when your are providing support on the phone
-Use DNS self-explaining aliases in zones matching the geographical area (www.michigan.yourcompany.com, accounting.wisconsin.yourcompany.com, etc)
-Make a webpage in your intranet (or a memo) to explain what is an alias, then create a simple web page where power users can add/remove aliases for servers (while not being allowed to remove your records or to use existing names). This is easy to do in both Linux and Windows.
-Make sure to configure the default domain extension for the workstations so people can access *their* WWW without having to type the FQDN, or if you are on Windows use WINS
At first people might mess up things a bit, but after a while they will actually get things working very well. And what is interesting is that people from various areas will find very different solutions; some will use planet names (lamers!), other will use user names, etc. To each his own.
In the end, what matters is that the end users can find the machine.
lucm, indeed.
At work we use names of minerals and elements. But for my personal machines, I took the advice of an acquaintance who claimed that computers should have 4-letter female names. There are plenty of names to choose from with 4 letters, but they are still short and you type computer names quite a bit. And finally, since your wife or girlfriend is going to be jealous of the time you spend with the computer it should have a female name to "fit."
Obviously, female sysadmins should choose 4-letter male names.
I let my wife choose whatever names she likes, but she has generally chosen female names as well. Friendlier perhaps than male names.
As it are mainly non-technical people how often do they need to connect to a certain machine by hand?
I would give them two names. One by function, like sales or marketing and that is what they will use: http://sales./ Once the machine gets a new task, you re-point it.
One name for the technical people.
Also look if there are different segments where they will be used, so that a segment is very easy to recognise.
Be carefull with groupnames that can not be very large, like planets. There you will very soon need to be naming moons and people might not know the names of the moons.
As the people tjought it was not clear, why not ask THEM how they see it. They are the people who are going to use it and it might be easier for you to addept to them then the other way arround.
Naming shemes I have seen everything from mere numbers over beers to the obvious start trek names.
Don't fight for your country, if your country does not fight for you.
I have never seen a slashdot thread with as many serious, and disparate, replies before.
And the RFC(1178) that someone pointed at was, at it's best, unhelpful.
If there was a standard(Something for OpenISO, perhaps?) that everybody used, it would be great.
Then we would all only need to learn one standard. Which, I think, would feel more acceptable to most. And no, this is not about "freedom", it's about being pissed of twice a day because some bastard named a server after his old girlfriends dog.
Server names could also then be created automatically, using easy-to use GUI tools for the faint of heart, and also "decode" in the same way, making some level of rough categorization possible(i.e. "list all file servers").
You might argue that that kind of data should be stored in a database, and not in a server name. Then I ask you, why do server names exist at all, if not to define the server for it's users? Why not only use IP then?
Regarding the location of the server, however, I don't think that should be in the server name(i'd rather put that in the subdomain). I mean, a mail server running Linux will continue to do so even if it is moved to a new location.
And yeah, were I work we use abbreviations, which results in names like SRVAPPDEVVM03 (the VM-part, denoting a virtual machine, feels a bit unecessary nowadays, though). I wouldn't say I am particularly pleased with our way, but there is only so much time left to think about things, it seems. Using abbreviations are a complete necessity though.
But I have also been naming stuff after LOTR-caracters, Cartoon characters and whatever, too. That stopped working way back, when we passed the 20-server mark, though.
Baboons are cute.
It probably isn't a huge performance hit on your DNS servers if you're talking about 100-200 hosts with a few dozen CNAME aliases.
I typically do [initials for host type]+serial to begin with, and expand from there. ws101 is workstation 1, fs105 is fileserver 5 and app102 is application server 2. You can then extend that with region codes, or the last IP octet, or whatever semantics you need, separated by dashes. app105-lax-234 might be my fifth app server in LA, with 234 as the last octet of an IP block I'm familiar with there.
Finally you can create CNAME records for user-accessible names (one network I manage is drummers: rich, bonzo, krupa, etc, another is Roman names: trajan, pugio, caesar). This way users who only need to know a few hosts don't have to learn anything new, and you can change the underlying A records without making anyone angry.
Again, this incurs performance penalties (each CNAME adds a lookup) but it separates user-readable names from a more rigorous underlying system.
... An Ask Slashdot that doesn't give us enough info to answer the question. You say you've gotten away from themes (thank God for that!) and are using a "utilitarian" scheme. (I think you mean "functional"; "utilitarian" is a kind of ethics.) And you say your users find it confusing. But what is the scheme and why do your users find it confusing?
And while we're talking about communicating ideas: it's hard to imagine a DNS scheme making that much difference to user comprehension. It doesn't matter whether a server is called "Baltar" or "PrintersEast", all the user needs to understand is that it's the name of something they have to connect to. If your users are all confused, it probably has more to do with how you're communicating procedures to them than what your systems are called.
You're over 26 machines, but I've always liked using the phonetic names of letters. There's a couple of options depending on which branch/time of the military you like, but the nice thing is they are meant to be easily heard and each one starts with it's own letter which makes tab completion/sorting work out great.
I name servers after stars. Astronomical stars that is, not celebrities.
Speaking of which, I can think of nothing worse than a server called tomcruise.example.com. It would inevitably contract some nasty worm and spend all its time trying to propagate it across the network, while languishing at it's original purpose. Hmmmm...
I used to work for a large company that had a couple hundred servers in data centers all over north america, and I would like to recommend that you make sure that the naming convenion is directed at administrators, and not end-users. In our particular example, we would include a data center location, system type (OS, VM, etc.), general purpose abbreviation (usually to make the name unique and identify the main purpose) and the number (useful for clusters). So for example a SharePoint VM server running Windows 2003, located in Dallas data center would be named DALVM2K3SP01. This name can be almost immediately interpreted by a systems administrator looking through the logs, and if you still need something to make your users happy, you can always create a perdy CNAME along the lines of DALSharePoint for them to use. We started off with cute names, like LOTR characters or Transformer names, but they carried no informational or identifiable value and soon got very confusing and hard to come up with and remember for both sysops and users.
Bow before me, for I am root.
I agree on keeping it short and pronounceable over the phone.
Users don't really need hostnames. They get mapped drives through login scripts, and that works fine for the 10 to 50 hosts networks which I manage.
For the TLD of your internal domain, you cannot use .local anymore since Apple hijacked it a few years ago for their Rendez-vous thing or whatever. I now mostly use .lan, and also inherited a network which was using .private.
Then comes the company name of course, sometimes in a simplified form.
If distinguishing locations is important to you, you could use location-based sub-domains. But most times, it's not worth the trouble.
To keep various info about hosts (function, configuration, main user, etc.), I had a small database (could also be a spreadsheet). Then I realized I could keep everything in DNS too. So for the last years, I have just used TXT (and sometimes also HINFO) DNS records. Since DNS zone files need to be edited anyway when there are changes, the rest of the info is done at the same time in the same file. And it can be queried from anywhere with plain DNS tools. (In fact I have this very handy alias for searches: alias hostinfo='host -l -a mydomain.lan | grep -i ')
As for non-offensive names, at one place using Greek god names, the boss wanted his notebook named Eros. I don't think anyone would find it offensive, but I'm not sure the boss realized it would be visible in Network Neighborhood. Anyway, probably nobody noticed. As mentioned, users use shortcuts and mapped drives. Nobody cares about names. It's only for network admins.
It should be really easy for IT to have a page somewhere that translates server names to locations.
Most people relate better to local server *names* the function becomes associated with that server and name. Most of the time, there should only be 2-3 servers per "location" that any given user is using. (and I worked for a BIG company).
This whole utilitarian naming scheme is just going to be too difficult. It works if you KNOW the name, but it is hard to communicate the name in any sort of non-cut and paste environment. Which means that whatever you were being lazy about, turns out at just the time you would be the most lazy, and you need to know the name, you won't be able to. And you will have a difficult time finding.
Finally, is somewhat practical security through obscurity. It is better to have server name and function separated. It means that there is less information leakage just through the network map.
Good security would mean not showing information that would make lives easier for the bad guys.
Do not show the OS and it would be smart to not show what they are actually doing as well. There may be some scumbag that realises that "za1w2k7dc123" would be a very useful machine to hack into and we now know what weaknesses to try and exploit...
I'll see your Constitution and raise you a Queen.
One thing we do in our internal network is to have two sets of names. One set is logically named and reflects a specific purpose. For example, "svn.internal.tld", "db.internal.tld", "web.internal.tld". 'svn' is the svn server, 'db' is the db server, and so on. The same machine can potentially be mapped to from many of these names (for example, 'svn' and 'db' may resolve to the same IP).
When we write our internal scripts and configure our software, hostnames are ALWAYS specified using the logical function names.
On top of this, each of the physical machines has a unique name for itself, following whatever arbitrary naming scheme we choose (in our case, it's fruits: lemon, orange, etc.). We use this name when talking about actual machines with problems (e.g. "lemon just went down").
It works well enough for us. When we move services, we don't have to change our internal scripts or configuration at all, just change the dns reference for the given service. The nicknames allow us to talk about each individual machine easily.
I know this has been said already, so please consider this an additional "vote" for this method, rather than a redundant post: Since your business is geographically dispersed, using names that match the geography is, IMO, a good choice. Your non-technical users don't know (or care) about the topology of your network, but I would venture to say that they probably know where your business has offices geographically. (The company I work for has offices in several U.S. cities and one European city, and everyone knows where they are.) Using names that match up the geography is as intuitive as calling those locations on the phone and dialing the correct area code. This method should make it easy to set up things in the future, such as OpenVPN tunnels between the various facilities, and any sysadmin or user in the future will have an easy time determining which system they're communicating with.
McCain/Palin '08. Now THAT's hope and change!
I can't tell you how many times I have seen names like "server1" or domain names like "contosodomain". Keep it short! For Server #1 on the production network in San Francisco, use something like "svr1.sf.prod.example.com". The shorter the better!
First, the disagreement. In the U.S., a "midsize" business is generally defined as one with approximately 1,000 or so employees. The number of machines he mentions would normally put them in the "small" business range.
On the other hand, I agree with your subdomain scheme. This avoids confusion and allows greater freedom in naming the individual machines.
If they can't remember IPs, they shouldn't be allowed on your network.
Power Users must be able to identify machines by MAC as well as IP.
Admins must be able to do both - in hex, decimal, binary AND octal.
Octet delimiters are for pussies.
Learning HOW to think is more important than learning WHAT to think.
We had a test server which started off as something bland but since it was a test server people kept crashing it often. It became affectionately known as "Kenny". Now everyone just says "Who Killed Kenny!" when it dies a horrible death.
I've worked in a number of shops, ranging from very small (less than 10 servers) to medium size (over 300 servers). I've found that character names and theme names for servers generally don't work so well on a long time scale. Support staff comes and goes, and people have to keep re-learning that Bilbo is the fileserver in New York and Frodo is the database server in Seattle.
Most end users don't relate to a server by name anyway, they know it as their F: drive or whatever. So the server name is only relevant most of the time to the administrative staff. The bigger the organization, the more important it is to have some kind of consistent sensible naming scheme.
I worked in one shop that had a lot of locations (several per state), but on average, less than 10 servers at each location. So we had servers names like sc03fs02, to denote the second fileserver at one of our locations in South Carolina. The router at SC03 was sc03rt01, the switches were sc03sw01 and sc03sw02, and print server devices were sc03ps01, etc. This made it easy to triage alerts from our NMS when things went down. I didn't have to have intimate knowledge of the server to know that if an alert came in that sc03dc01 was down (dc meaning domain controller), that it was a fairly serious problem. Anything matching the pattern ????dc?? was a big deal.
And in case you haven't guessed, user computers were also named either dt (desktop) or lt (laptop), so sc03dt23 would be a user's desktop in the SC03 office. Also, when everything is in DNS, sorting your zone by name makes for a fairly quick, easy, and complete inventory of what you have site-by-site (poor man's SMS).
A system like the above has to be tailored for the size of your organization, and your structure. If you only have one major office, you obviously don't need location codes. But I worked for a hospital that had servers for different business units (the hospital, the clinics, and the college), and so we prefixed servers by a three letter code denoting organizational unit.
The only place I've seen theme names work well for users is with printers. When I worked for one of the Big 6 accounting firms years ago, the printers in my local office were named after musical instruments. It was easier for users to remember "I print to Cello" than it was to remember "I print to clthplj4500n02." In other offices, printers might have been named after Disney characters, whatever.
Don't even expect people to be able to spell cthulhu or googol (Sergey Brin couldn't).
No mod points today, but I liked this one.
Call the entire network TRANSLTR and name one NDAKOTA. (Read Digital Fortress by Dan Brown to get this)
I work for a large enterprise with +100K devices and their naming is standardized on the who made, where it is (ie geographic location) and it's role (server vs desktop). Plus some number to keep it unique. But strangely enough this standard only applies to the unix/linux machines. This standard is of great use because just knowing it's name you know a lot about the environment you are going to support. On the flip side. The Windows machines are the same as the primary user. eg jsmith-1. This has been in place for almost 20years so it works for us.
:
potts123=personal ottawa sun 123eg.p = personal
s = server
ott=ottawa
rich=richardson
s=sun micro
h=hp
We would see a names like these
srichh123=server richardson hp 123
AK
I like to use the Windows network ability to add comments or descriptions to everything...that way, when we use Red-app5, we can know that this is the app server at the "red" location...
We have given every location a color; Red, Blue, Green, etc...and we name the servers to what they are; app, web, bdc, pdc, etc...
However, we have to keep in mind that someone might not know what a pdc is or a dns, or a fw (fire wall)...so we use the "description" field to add information like "This is Red's Fire Wall" or "This is Blue's Proxy Server"...
This may all change as we move to a Linux network, but for now it seems to work. The names are simple and descriptive, and the description field fills in the gaps...
Using both the service tag and the express service code is a little redundant isn't it?
We use the service tag in all of our workstation names with a dash and room number. If they are in a lab, we use a 2 letter short code for the lab and then the computer number. When we set it up in AD, we add the primary user or primary function in the description.
Using the location in the name give the name a lot more value when looking at logs or reports. When we look at the computer name in say AD, we know we have to correct one just by knowing the room number. Its easy for people to communicate changes to use without having to know the entire name.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
... servers name you?
A couple of years ago (like way before the movie came out!!!) I decided to use transformers names for computers/server at work... Well now I would like to share this scheme with you! First, well there are the bad and the good guys... The decepticons were all the Windows Machines and of course, since we were a Linux dev shop, all Linux machines were autobots! The DNS/DHCP was of course in linux, but since it could serve both sides, was named Cybertron So of course my Personnal laptop was named OptimusPrime... hehe but the best part of this naming scheme was when we had to build a cluster... Individual machines were named, for exemple after the constructicons... and the cluster was to form: DEVASTATOR!!!! and you could even go further like I did... naming your windows backup server Soundwave and labeling your dat tapes Laserbeak-01 and so on... Don't forget to name your main linux file server TELETRAN-1!!!! :D
Bob
My first experience with this, back when we thought our Sun 3s were as cool as digital watches had once been, was cheese. The server was cheddar, and other hosts were edam, gouda, and so on. Yawn.
My current employers have two themes going. Lab machines have the names of stars (merak, rigel, alcyone, etc.). Desktop and production machines are the names of cars, so our server is veyron (fastest and most powerful car we could think of), my desktop machines have been model-t (a Sparc 5 :-), twingo (Ultra 5), tatra (first Linux box on our production network; we had been 100% Sun prior to that) and now monaro (a little crude but brutally fast).
Our original file server was kenny. Eventually we really did kill kenny...
...laura
What do you do when a server moves? General guidelines say you shouldn't put the computers location in the name.
Why use alphabet soup in the name when you can fully exploit the capabilities of DNS?
What I did on a slightly smaller network than the one you're proposing is this:
As an example: you have two offices (Boston and Miami). In each you have three roles: printserver, fileserver and gateway, and one machine in Miami and two in Boston. The themes would be Maniac Mansion and BOFHs. You end up with:
Boston (domain bos.example.com):
edna IN A 192.168.1.1
bernard IN A 192.168.1.2
hoagie IN A 192.168.1.3
gateway IN CNAME ed
fileserver IN CNAME bernard
printserver IN CNAME hoagieMiami (domain mia.example.com):
printserver IN CNAME pitrsimon IN A 192.168.2.1pitr IN A 192.168.2.2
gateway IN CNAME simon
fileserver IN CNAME pitr
You then give your users only the alias.
Doing things that way, you can easily locate each server. You can make a reference to a particular server easily and you can shuffle tasks around just by changing CNAMEs. The users can access everything with little hassle (fileserver for the local fileserver or full FQDN for the CNAME for a remote one). You can also delegate easily and should you need it, you can add extra levels. You could add country codes after example.com in case you open an office in Vancouver changing your hierarchy your names to:
fileserver.bos.us.example.comprintserver.van.ca.example.com
or even add extra levels under the city names if you need:
fileserver.hq.bos.example.com
fileserver.researchlab.bos.example.com
WTF is happening to slashdot? When I mean plain old text, I should not need to type those stupid html tags! Sorry about the odd spacing in the zone files.
GPG 0x1B479C78
Nothing is more enjoyable to your users than machines named 010010010010.domain.local
Yes, I know I fucked up ed.bos.example.com, no need to tell me.
BTW, don't forget the backbone, it is a network too.
GPG 0x1B479C78
Sure, I only manage less than a dozen machines. But my machines are named after the greatest bands of the 80s. Journey, Survivor, Genesis, Survivor, they're all there.
And I have an internal MediaWiki set up for documenting them all, including every role each server provides.
use a hostname scheme that is completely utilitarian. Like a rack number and position.
Use aliases to name *service* on the machine that people access.
European rivers, Greek and Roman gods, and fruits.
I've also been in a place that used network, purpose and number together. That works very well for servers, as by the name of the server you know what it does. And if you're told to go to, say, the Exchange server, you can bet going to a machine name such as "xxxEXCH01" will get you to one.
Going by physical location for all machines doesn't work well, as you need to change DNS for every workstation move.
I don't run the policy at work, but all my home computers recently I've named after moons of Saturn (which would scale up to a network of 60).
My PowerMac G5? The biggest case I've ever owned - that was called Titan. (Incidentally, my iPod which connects to it is called Huygens.)
When I get the new iMac? Black on one side, white on the other - that will be Iapetus.
My first Intel-based Mac was a laptop which I called Pandora, mostly because I suspected that the thing inside would turn out to be evil.
Well last company I worked at we used CLLI codes. Each Node had a name after the site code. ie. ORLDFLAKR01 ORLDFL was a city (Orlando, Florida) AK was the site code in the city (Apopka) so ORLDFLAK was the site code R01 was the first radio at that site. Servers were S01-S99 or SB1-9 Routers were RT1-9 Switches were SW1-9 Now if you get to the end of a series, such as RT9, just make the next one RU1 and go with it. This makes the name describe the city,state and network device, all in a fixed format of 11 characters. That makes it easy to search for problems and put in a DB. Now this might not be a good idea if you have 1000's of servers in a location, so in that case you might want to go like 3 char site, 2 char floor, 3 char rack, then S01-99 for the rack. so like ORL02AAAS01, which is ORLando, Floor 02, Rack AAA on that floor, and Server 01 in that rack. On the plus side when you start looking at circuit tracking program (if ever) most are keyed off a CLLI codes.
We use planet names for the actual hostnames of our machines, from the real universe or fictional ones depending on domain. However, end users *never, ever* see those names. The end user sees a function name (with a number if there's more than one), and a location subdomain (or one of our 'special' subdomains .demo for VMs suitable for showing customers, and .wan for VPN services.)
They don't need to know that 'crm.pdx' is really terra, and 'sharepoint.wan' is really luna, or that 'allproducts1.demo' is VM gallifrey running on vmware server mars.
I have used many server, but those are the one that I still know the names ... Veronica, Petra, Maria, ...
Love many, trust a few, do harm to none.
I used to name machines with meaning.... like sles10 (e.g. a box with Novell SUSE Linux Enterprise Server 10). However, does that describe that it is 32bit, 64bit, Intel, PPC, etc? What about its purpose? Is it a web server, email, dns, dhcp?? What about it's location? Aack!! To try to put all of that information into a name means having incredibly long names... which probably isn't desirable. Oh sure, you can build a cryptic code using single letters where the placement tells you the type of the coding to use... but then you have names that look like hash... eww!
So... here's my opinion. Name machines how you like. If you want a set of machines to have some kind of relationship... then maybe do a theme for that set. The relationship could be based on CPU, OS, function, whatever. So if you DO choose a theme, I don't think you need to be uniform. Have fun.
So... how do I know what a machine is used for, what it is, what it runs? A database. All companies should have a record of their machines at least for warranty and support... add the rest of the information there. Just my opinion.
For example, if you have a cluster of two machines... maybe one is called romulus and one is called remus. Or jacob and esau. Be creative IMHO. Have fun. Don't get caught up naming, enjoy the job and make people guess why you name machines why you have named them. You'll have stories to tell instead of boredom.
In our colo, everything has several names. 1 to refer to it's rack location, 1 to designate it, 1 for it's production task and then if it has EARNED a cool nick, it gets one (believe me it's fun to CNAME "pig-bastard", "re-booty-licious" or something similar when it is earned). If all the machines have one NIC, the A record should be the rack location and the rest CNAMES of that. Makes knowing all about a server via an NS lookup easy and sometimes fun. I've never understood why folks use only one NS record and decide to choose between cool and functional.
US Democracy:The best person for the job (among These pre-selected choices...)
Why is everyone so intent at putting the servers location in the name? IT support should be able to look up a servers IP and have the subnet clue them into the location. Remember, the location of a server should NOT matter to the users. Where I work now network ops used to have this stupid idea of putting location in the names of servers. So now we have servers scattered around the US with names that do not match their location. You also don't want the company name in the server. We have a couple servers left over from years ago that have a company name in them that hasn't existed for 5 years. So now they have a company and location that's part of their name and both are incorrect.
Server function as a part of the name I'm okay with. Usually if you change the function of the server you also reburn it. This means that any links to that server are going to go away anyways.
Of course user desktops are a different beast. Those are usually re-imaged so frequently that it's fine to name them with location and some number. Also, if they are ever moved to a new location they are re-imaged before going back out on the network.
So, my preferred naming standard is unique, theme based names for servers and location + ### for user desktops.
Here's the name standards of systems I've managed.
Personally I don't care *too* much as long as the names are sensible. It is best if I can tell exactly what the server is for by looking at the FQDN. web1prod.sfo.client.com tells me that is the first production web server in San Francisco for Client. No mystery.
However, usqwxussmc01.01.mebs.host.com (yes that was an actual hostname) tells me nothing about what the server is or even what account it was for. In that case, 'host.com' was a generic hostname used by the company I worked for, not tied to the client system.
I used to work for a so called fylkeskommune in Norway, I guess one can compare this to a quite small American state. Our naming scheme was based on function, geographical location and username (the username was the users birthdate). So a standard name would be something like this: school.oslo.121250. On servers we used the same system, but instead of a username we used some simple description like this: school.drammmen.fileserver1
MOD THIS UP
This is some of the best advice in this thread, and it really needs to get some mod points to help counteract the stupid advice of "use comic book character names!" and single-level schema topography.
This guy's advice works because:
1) it scales to any size organization
2) it identifies the actual equipment
3) it identifies the equipment location
4) it identifies what the equipment does/how it fits into the organization
Aside from scaling well and being able to tell you where, what, and how, there's little more than a naming scheme should do.
There are times when you know you can use less without impeding future deployments (such as a geographically-isolated business which would be unable to expand), and that's OK. But for the most part, reducing yourself to a naming convention with a namespace of only a couple hundred variants at best (comic characters, etc.) which tells you -nothing- about what you're looking at is problematic.
Here's a funny one for you which will cause nightmares: systems named after firearm cartridges. So you get things like: 22lr, 223rem, 556x43, 270win, 762x39, 762x59 - and so on and so forth. Then you've got the additional problem of having two different naming conventions for a cartridge, and you start having problems (ie 308win vs. 762NATO vs. 762x51 - all essentially identical cartridges). Just... don't.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Two comments about location-based naming:
1: If you've got multiple geographic locations that require a duplication or replication of services, using the geographic location in the name makes sense.
2: You certainly would NOT want to use room or building location in a name for exactly the reason you cited.
Naming conventions are mainly for humans to understand the relationship of the servers and their duties, locations, configurations, etc. A good naming convention takes many of these elements into account. There isn't a single naming convention that's right for every situation, though being more specific and concise is generally better than not.
For example, a small company I worked for a number of years ago used Greek and Roman mythology. Zeus and Hera were the PDC and BDC, respectively. Apollo was the mail server. For our small environment, that made sense.
A bigger company I recently worked for used something much less creative - a combination of the subnet we assigned for the branch office, the role of the server, and a sequential number:
XXXYYsssnn ...where:
XXX was an abbreviation of the company
YY was the server role
sss was the subnet info
nn was the sequential number
It was difficult to determine exactly where that server was located physically, but it was easy to determine where it was on the network.
Both of those methods offer some advantages and have some drawbacks. If the first method were used in the second example, we'd have run out of names to use and nobody would be able to remember where each server was located physically OR on the network. Conversely, there wasn't any need to apply the second method to the first example as there was only a single location and a small number of servers to keep track of.
The larger your pool of servers, the larger the area in which they're dispersed, and the larger the differences in roles each server has, the more specific you'll need to be with naming.
My sources are unreliable, but their information is fascinating. -- Ashleigh Brilliant
Brings new meaning to picking through your files....
svr01, svr02 , svr##
it's good for user and support
no meaning but does mean all
don't try to use "name" as a matter of "meaning" ref.
it doesn't help
while svr## makes a small group of ppl really memorizing which function belongs to which svr
ur support pls must make the whole list of svr handy...and not work like "users".....unless will be 'lusers'
You can have your themed or utilitarian naming scheme for internal IT purposes, but these should not be the names that users ordinarily see. My recommendation for a naming scheme is:
{function/application}.{site}.{domain}
Combine this with a dns search list that starts with the local site. The same machine may host multiple functions/applications.
I'm a user. I want the crosspoint application. I type "crosspoint" into my browser, and hey presto: I'm there. I take my laptop to another site, and it connects me automatically to the best available server. If I really need to connect to my home server I type in the site name as well.
This works well for administrative purposes also. By giving a machine separate names for each of its functions you support breakup of those functions across multiple machines in the future.
I used to use greek gods and goddesses, just like many people, but that got boring. Now I use bacteria and virus names (campylobacter, salmonella, clostridium, etc.).
There are hundreds or thousands to choose from, even if you narrow it down to only stds or GI infections.
Good luck!
-b
No offense, but I've stopped responding to AC's.
When I first began my last admin job, the management insisted on using the room name as part of the computer name. Eventually the technicians revolted after having to move rooms full of computers several dozen times per year.
I instituted a new system, made up of a short prefix based upon the device type, followed by the asset tag number. This had the added benefit of making sure that devices were asseted before they could be set up.
SV-100001 (Server)
WS-100002 (Workstation)
LT-100003 (Laptop)
PR-100004 (Printer)
Et cetera
Virtual machines are a bit special since they do not have a physical asset tag. We decided to simply allocate numbers to them sequentially, starting at VM-00001.
For servers, we would often create a friendly name, in the form of a DNS CNAME pointing to the actual name.
$TTL 3600
$ORIGIN internal.domain.com.
tiger IN CNAME SV-12345
Had I took the time, I could have programatically added DNS HINFO records using data from the asset management system, and maybe even a TXT record containing the room, floor, building and site address.
For a small to medium business, I have had success with using naming themes. Linux servers are periodic elements. NAS file servers regardless of their OS are planets and moons. It really came down to unique naming that non-technical personnel could say and remember. Using usage acronyms and numbers was hopeless and re-provisioning made the numbering scheme undesirable after a few years. My least favorite names were manufacturer and a number "DELL47". PS: Window workstations are all variants of trees. In a small company allowing some users to pick their computer name in a large enough theme that is not super geeky gives them some sense of ownership.
At a previous job, I was witness to a couple of examples of how not to do it...
When I got hired as an admin for a startup consulting company, I realized I was in for a challenge. My boss had already deployed a few servers, but it turns out he wasn't very creative with the naming conventions. The first server was called "dualath" because it contained two Athlon CPUs. The next one after that was also an SMP Athlon machine, so it was thus dubbed dualath2. To my knowledge, they're both still running although at least one has been updgraded to a single Opteron processor.
After the incidents above, we started naming some servers after the names of elements but quickly realized we were going to have a problem. You see, my boss was a horrible speeler. He woke me at 3AM one night because he couldn't log into a new server that I had set up during the day. After about a half-hour of coaching him over the phone, I figured out that he didn't realize there was a Y and two Ls in "beryllium".
I use unique names for each host(star wars, lotr, greek myth, etc). Then I setup cnames for each function and point those at the host that serve them. For more info, check out: http://www.infrastructures.org/bootstrap/directory.shtml
As others explained these strict naming schemes are a stupid idea. First of all they indicate you have no documentation and rely on hostnames to document your network. They are painful to read/type. Hard to spell over the phone. Confusing when you add an ftp service to spdns000. Typos are easily made (ltftp01 is rebooted instead of lsftp01). Naming errors are bound to happen (what do you do when you notice an error a few weeks after a server has been set up but only discovers it now when the hostname is already in dozen of config files, do you waste time fixing something that, in the end, is completely irrelevant ?). The naming convention also totally breaks when you merge or collaborate closely with another company with not the same naming convention. Etc. I could go on and on.
Here is what works: a naming convention with no specific rules. Just use unique names, not too exceedingly hard to type or remember. Use CNAMEs to represent functionnality. Encode the location in subdomains. Example: {shrek,moon,highway}.{losangeles,newyork}.company.local, with 'webmail' pointing to the right servers in the 2 locations. If you are afraid to not remember what is the OS/purpose of highway.newyork.company.local, then look it up in your network documentation.
At my company (~5500 employees) we use towns in the UK. Not sure who implemented that policy, it was there long before I was. I adopted a variation for my own computers (and ones I set up for family members). I use towns in Saskatchewan, since that is where I am from.
At my company we use a different naming scheme for each group of servers. I.e. Our Email servers are based on a TV show, our Web servers are based on Marvel Villains, our firewall servers are based on cities. (not the actual assignments, just the way it works)
That way when a server craps out the host-name alone is enough to clue you in on who is responsible for it and what other servers may be affected.
I.e. If SG1 has a problem, Wake up Sam, and check on SG2, Tocra, Jafa and Hatak.
Of course these makes sense in a mid sized to large organization where any moderately important service runs on at least two servers and the really big things have dozens of dedicated machines.
--= Isn't it surprising how badly I spell ?
$function$num{-$tag}.$location.domain.com
Where $function is something like www, or db, or stats, or admin, or backend, or whatever; $num is a numeric identifier (0 for a master, 1+ for interchangable spares/slaves); $tag is an optional tag indicating, e.g. the internal management network (-mgt) or a LOM (-lom), and $location is an abbreviation for the location; e.g. www3-mgt.thdo.newzbin.com is a webserver via the LAN at Telehouse Docklands.
It's nice because you can tell at a glance vaguely what a machine will be doing, where it is, how it's being accessed, and roughly how critical it is (db0 better not die, but db9 can probably burn). Friendlier ad-hoc names can be made up and pointed at appropriate machines, of course.
Make what the machine thinks itself as a generic hostname, but also set up a CNAME that non-IT people can easily remember.
When you eventually upgrade the system you can point the CNAME to the new system transparently.
just because I can
On our network of ~30 machines, we use chemical elements. This will let our network grow to a couple of hundred without our having to think about new names.
The last octet of the machine's IP address is the atomic number of its name, so the truly geeky among us can dispense with DNS altogether for internal hosts. "Beryllium? Oh, 192.168.10.4!"
so you're saying that you can't do your own job? maybe you need to go back to the help desk.
Many good suggestions have been provided and I think you'd be hard pressed to really find a serious weakness with any of them. At the end of the day all that matters is that the convention is logical and consistent. As several posters have pointed out, ideally your end users will never see the server names. So long as each server is uniquely identified and is convenient for the people who will actually refer to the servers by name it really doesn't matter what you use.
The bigger question though is how to keep track of all of these servers. A naming convention certainly helps but all that really matters is that each server be uniquely identified. Heck I worked for a place that simply used SVR###### where they started with 00001 and just added one each time a new server arrived.
Regardless of naming convention a good asset and configuration database is essential. Heck, even an Excel spreadsheet would work for a place your size. It's there that you keep track of all the essential details such as make/model/serial number/OS/switch port assignment/applications/etc.
The idea of a server naming convention is to give a quick and dirty (but repeatable) method to the madness. There's a lot more information that could be conveyed in a server name but I'd argue that the name is not the proper place for it.
Anyone who's worked in IT knows how temperamental the server gods are. The only reasonable solution is to name servers in ways that will ensure uptime.
Because the server gods are perverse, you'll want to indicate that you *expect* the server to crash, so that the gods will perversely prevent that from happening. Names from famous disasters are good: hindenberg, challenger, that sort of thing. When the server gods see a DNS name like titanic.company.com, they laugh to themselves and say "ha, we'll show him! that thing is *never* going down."
The corollary is giving troublesome DNS names to projects you don't like. The HR director pissed you off? His new personnel management app should reside on uncrashable.company.com, or ninenines.company.com. You can do an absolute good faith effort to keep that thing running, but the server gods will explode power supplies and hard drives (several at a time, of course) left and right.
If I wanted a sig I would have filled in that stupid box.
I'll chime in with the location subdomains + machine function. My old place where I wasnt the Sr. Admin had a random system naming scheme based on whatever the crew was "feeling" at the time, so you end up with machines named "Gordita" and "Pink Pony" - WTF do they do? And this was for 100+ servers.
My new place where I'm in charge goes like this...
server function.city+office number.country.domain.com
NAS1.sj1.us.example.com (NAS file sever one, in office one in san jose, united states) I try to keep all the server names under 4 characters so I have MX#, APP#, DB#, WEB#, etc...
Pluralitas non est ponenda sine neccesitate
I used to work in a big company, and they had boring rigid names for all servers, based on the location and a numbered code.
At one time, I was responsible for the build of three servers, and I named them after 'super-clubs' in Ibiza. (privilege, amnesia, and space)
When my boss asked me how the names came about, I wasn't quite so truthful:
PRIVILEGE - "As this was the 'sysadmins' server, only privileged people used it."
AMNESIA - This machine actually had memory problems and needed new memory chips before I rebuilt it, so that was my explained reasoning for this one.
SPACE - This was the network file store, and had a huge amount of free disk space....
Sig out of date
Guess you guys aren't into virtualization then?
It's a simple matter of complex programming.
You forgot the following:
- Processor architecture
- Processor topology
- Operating System
- At least 4-digit serial number so they don't roll over
I'd suggest a hostname more like this: sjcmarkfilep0001opteron870he4waywinxpsp2
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
We have two schools of thought. One is the group naming standard. All the Linux servers will be bands. All the Windows servers will be car manufacturers. By doing this, the purpose is masked and the server can be reused for various functions without a server name change. In addition to this, making a DNS alias that is more purpose based like sqlserver1.company.com keeps people from screwing up or using the real name of the server.
The other school of thought is an inital based standard. Location, Type, OS - four letter/number abbreviation for the purpose. It makes sense in practice, but then if you repurpose the server, you rename it, which is fairly trivial anyway if you're repurposing the server. For example, if you had a production Windows 2003 server in Chicago for accounting, it would be CP3-ACCT. The name is short enough to remember and can be pieced together if you happen to forget it.
It's all up to you though. You could have a silly server name like D2003PT4GHOST-5674. Or you could have a server like ZZTOP. Or you could have COCOPUFFS. Pick something though that you can have a lot of. At an old job, we had a toss up between naming everything after Sesame Street characters or Star Trek ship names (I know, that's a gap). We chose Star Trek ship names, and after 20 servers, I realized I don't even know that many Sesame Street characters. I got to 10. As always, YMMV.
When I worked for one of the Big 6 accounting firms years ago, the printers in my local office were named after musical instruments. It was easier for users to remember "I print to Cello" than it was to remember "I print to clthplj4500n02."
No, no and 1000 times no. When I print something is about the only time I care about the physical location of a machine, because I have to actually walk to the printer and collect it. So I need to know which printer is nearest to me. It's much easier to figure out that the printer closest to the meeting room on the west side of the third floor is 3Wcolor than to try and remember whether it was oboe or bassoon that was on this floor.
Something I always tell people about naming standards. "Everyone has an opinion and usually they are always right". Names have different meanings to a lot of different people and there are too many perspectives that make sense. Its hard to find a naming standard that everyone will "like". I know because I was in charge of the naming (and DNS) for a fortune 500 company.
For what its worth, here is what I would recommend for medium to large networks.
1. Use a database. I had over 600,000 DNS entries in our database, and yes the names were all unique. You might look into something like http://iptrack.sourceforge.net/ or a new interesting work in progress I found at http://opennetadmin.com
2. Start with a location based hierarchy. Each location should have its own subdomain. Location naming is an interesting thing on its own, several things can work here. Just dont fall into the Active Directory trap of creating flat naming spaces. Make well defined groups, and location is good for this.
3. Now that you have location based domains you can start naming within them. The naming standard can now be similar from site to site. I would suggest host names like the following:
srv001.loc.example.comptr001.loc.example.com
ws01.loc.example.com
I bet you can guess what these boxes are.
4. Always use functional names, never actual names. Things like mailsrv01 is better than exchange01 because you might just replace it later with something else. No name change required then.
5. You will likely have a very generic unique name like srv074.loc.example.com to identify a specific server. This name is something used for management of the server. You should then have other names that reference the same IP(s) that are the more human friendly names like mail.example.com, wiki.example.com etc. Its these friendly names that move from box to box as the environment changes. The base server stays the same.
6. Users will remember the first name you give them. They dont really care too much about what the name is. Once they commit it to memory, thats when your stuck with it. They might gripe at first but once they commit it to memory thats the naming standard they will "like".
7. Use suffix search appropriately to help daily usage of names. This way users of a particular location only need to type part of the FQDN. You can put the global services in the top most domain like web.example.com.. then they just go to "web" in the browser.
Anyway.. blah blah hope it helps.
Choose a theme, then name things after those things. People can learn remarkably well that Dexter is where you go for mail, Rome is where you go to store and retrieve files, The Sopranos is the firewall, etc. It does make it easier if the name has something to do with its function.
On the otherhand, it could be location and function sfo-mail, nyc-fileserver, pdx-webserver, etc.
I favor the theme idea with functions matching the name (MrMcFeely for the mailserver, KingFriday for the fileserver, MrRodgers as the web server, OfficerClemens for the firewall, etc)
One of the low points in my career as a sysadmin was trying to explain to a new and particularly clueless manager why his scheme to call each machine on the network by its university property tag number was a poor idea. In the end he was so enamored by his own bureaucratic "logic" that I couldn't convince him that a 10-digit alphanumeric property tag number wasn't a suitable mnemonic device for people to use (in fact, for most people it would have been easier to remember the 12 digits of the dotted quad form of the IP address) and ultimately I gave him what he insisted on and set up DNS records as requested for each of the machines. Of course the happy thing about DNS is you can give a machine multiple names, so just because he thought of, say, the departmental mail server as U2953A6CD9.[dept].[university].edu didn't mean everybody else had to remember it that way.
Which is why I recommend that if you have a mandate for using cumbersome enumerative or descriptive naming schemes imposed by some part of your organization that you consider using multiple naming conventions for your machines, or at least a system of handy aliases for commonly used hostnames.
I name my servers with technical name like "Down", "Up", "Broken", "Defective", "dead", etc.
(boss): "Hey mike, what's the name of the web server again ?"
(me:) "Oh the web server? It's dead."
(boss): "WTF????"
We use a pretty simple scheme where I work.
*.local.example.com - replace * with the users' names. John's computer address is john.local.example.com on the LAN.
*.vpn.example.com - replace * with the users' names. This is for VPN connections.
idostuff.example.com = replace 'idostuff' with what that server does. DNS? dns.example.com - fileserver? fileserver.example.com. If you want, you could do smallish themes for groups of similar services. For a couple systems (primary/master pair), I use Mufasa and Sarabi (King/Queen lions from The Lion King).
Just some ideas...
I talked to a sysop once and he named all machines after a line in a poem, so that in his Mac Finder the list of machines would read like a (quite random) poem.
Makes a hell of a lot of sense!
You will gain money by alie. Life is not
worth sending. get
stuck in the mechanical bulls.
Everyone told him, You do
Stop the message may be
a fattening action. You attempt things
It is not how.
at my old job we used to name them after cars
I've been at a number of companies where the IT staff (or some specific individual on the staff) has come up with a "clever" coded naming method for the hosts. Without fail this has been a disaster either usability (easy recall by technical staff) or security (naming for the platform or function tells an attacker too much). The coding scheme has always been sold as "more professional" that the previous (thematic) naming scheme, but is obviously just an excuse to lord authority over other departments at the expense of any real technical benefit.
While I can understand that the thematic naming schemes can be seen as unprofessional, that's no excuse for the unusable or insecure schemes that replace them. My advice, if you are not going to go the simple thematic route, is to use an even simpler coding scheme: one or two letters followed by two or three numbers: A1 or AB123. This results in more than enough hostnames for any conceivable purpose (625,000 hosts should be enough for anyone), allows a certain amount of meta-coding on top of the names, without revealing anything to would-be attackers (e.g. DNS servers can be named ?D???, mail servers can be ?M???, workstations ?W???, etc.), and, best of all, the names are reasonably memorable (at least as memorable as a license plate). By only using one or two letters, you also avoid the possibility of accidentally assigning "naughty" words as hostnames while handing out sequential names.
just a ghost in the machine.
I was building servers with another guy once. I asked him "what should the naming scheme be?"
Him: I dunno. How about... stars?
Me, looking at a smallish server: Okay, what's a famous dwarf star?
Him: Sneezy.
Assume I was drunk when I posted this.
I have always used a standard nomenclature identifying physical server by location and architect (x86, sparc, etc). Then use logical service names for hosts, e.g. names.domain.com
Especially if you are using VM, this will allow you to direct loads and migrate loads as needed. If you ever start doing geographical loading of services you are set and won't need to restructure.
Call me uncreative but it always been easier to be straight forward then poetic.
Theme names are good. Choose a theme that doesn't have any overloaded context (like cities, for example) or common names and you'll be fine. If you are worried about your machines not being easily identified for their purpose, just make a DNS alias for it, e.g. alias athena.yourdomain.com to mail.yourdomain.com or what have you.
Complicated naming schemes are bullshit and the bane of civilisation. If I have to deal with one more machine named W832COHRWTFBBQKEKEKEKE.somedomain.com, I will shoot myself. Those names are hard to relay to people, not easily remembered, and only really relay information to the people who came up with the god damned naming scheme. It's infinitely easier to tell a employee to login to 'zeus' than it is to tell him to login to 'w832COHRWTFBBQKEKEKEKEKE'.
Comment removed based on user account deletion
We use (horse) race course names at work.
I prefer a combination of theme names and functional names though. Theme names tend to be a lot more friendly and easy to remember, plus you can use them in conversation when you need to refer to machines; functional names are useful because they tell you exactly what a machine does and where it is, but they're a bugger to use when you're talking about machines because it's just - usually - a list of numbers and letters.
Yeah, I had a sig once; I got bored of it.
Use an extended George Carlin theme. It's an "ice-breaker".
I divide all our services into two layers, divided by resource type. Specific equipment is given human names (I like to use the names of Scientists and Philosophers, EG: Edison, Hume, Bohr, Galileo, etc) and then service canonical names which are machine independent. (EG: mail.*, webmail.*, dav.*, ns*.*, etc) These cnames often constitute multiple entries as appropriate when multiple machines are behaving as a cluster.
By layering the DNS records this way (all A names are hardware names, all service names are cnames) I can switch around DNS and services quickly and easily with minimal interruption. If I change a machine or add new machines as load increases, I change only a single cname record and all domains I'm hosting (currently around a hundred) update immediately without problem.
Yes, it causes a bit more latency in the way of DNS lookups, but DNS traffic is still well below 1% of my total bandwidth usage, and I've never heard a single complaint. We operate at 10% or less usage of available bandwidth, even when you only look at our peak hours, 8:30 AM to 4:00 PM - burstable contracts are very, very nice.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Where I work, the hostnames are essentially comprised of a 3 digit department code concatenated with the machines serial number.
Asset tracking has been an issue in the past so this methodology allows for tracking machines over a heterogeneous infrastructure. If a tech has to re-image a machine, the naming structure is simple enough to ensure that the same hostname is applied.
"And the RFC(1178) that someone pointed at was, at it's best, unhelpful."
Thank you for making all us aware of its limitations.
"If there was a standard(Something for OpenISO, perhaps?) that everybody used, it would be great."
An old time-tested RFC is unhelpul but if you stick an ISO number to it it would be somehow great. Yes, it makes sense.
"Then we would all only need to learn one standard. "
RFC-1178. On the other hand, RFCs are just that: Request For Comments. You are free to critizise 1178 or write up a new one to open it to other's critics to build an enhanced one more to your liking.
"Server names could also then be created automatically"
If that's your point, you can just give them random numbers, I mean, seriously.
"making some level of rough categorization possible(i.e. "list all file servers")"
What's a file server? Would you want to segregate NFS from AFS from SMB fileservers? Does FTP get into the "fileserver" category? On the other hand, you can stick whatever info you deem necessary to HINFO and/or TXT records.
"You might argue that that kind of data should be stored in a database, and not in a server name."
A name server *is* a database. You can even use a RDBM to feed your nameserver. You are aware of it, don't you?
"Then I ask you, why do server names exist at all, if not to define the server for it's users?"
DNS has its complexities that bring quite a big bunch of functionality with it. Did you ever read the "classic" O'Reilly's "DNS & Bind"?
"Regarding the location of the server, however, I don't think that should be in the server name(i'd rather put that in the subdomain). I mean, a mail server running Linux will continue to do so even if it is moved to a new location."
Yes, but your great Linux server won't serve mail once you delete it's mail serving software, add the NTP one and start serving as an NTP server... maybe at a different location too.
"But I have also been naming stuff after LOTR-caracters, Cartoon characters and whatever, too. That stopped working way back, when we passed the 20-server mark, though."
1) My last count on LOTR-caracters was over 400, not 20 (well, not LOTR but Tolkien's fictional universe).
2) Nobody said that using theme-based names limited you to use just *one* theme.
3) If you don't care about single machines, then there's no need to use clear identifications to distinguish each of them; numbers would do OK.
But I'd be giving them Borg designations so that it would be easier for them when they take us over.
http://cfa-www.harvard.edu/iau/lists/MPNames.html
--
by kobold2
* My god, you seem to be pissed off in general, or you deliberately misunderstood all points I tried to make.
* The RFC is only applicable to small systems. Obviously.
* Yep, DNS is technically a database, I know this since I am not a total moron. But that was not my point either. Most NOC-servers does not use DNS, but a specific database, to store system specific data, mostly for security, TTL, and availability/redundancy reasons(not all eggs in the same basket).
* A file server is a server that serves files, this might or might not include an FTP server. I wasn't pretending to come up with a perfect standard. I said rough, remember?
* In larger systems, you seldom, if ever, change the role of a server(during it's 3 year life span).
Especially with all the virtualisation going on, it is much easier to simply create a new one. But I would rename it, if that happened.
1 & 2. The limitations of theme-based naming schemes does not stem from the number of available names, but the fact that it is impossible to read any information from the name of a server called "FIDO". Hence, all new employees need to learn lots of wierd names.
3. No, numbers would not be OK, since you usually work with maybe 5-6 servers at a time. Once you figure it out, using ERDBDEV02 is waay better than constantly having to remember new variants of DODO, FIDO or SAURON.
Imagine this: A user calls, "my system says 'an error with the BILBO-server prevent the application from starting.'. What do I do?".
Now say you have hundreds of servers...well, yeah, you could have the BILBO server name in some support database, but since that is obviously not working right now due to some(maybe related) DNS issue, you don't know what it is. A good point is that BILBO is easier to spell over the phone than LSWIN03, but that point has nothing on the fact that you immediately know that it is logon server 3 that is failing.
That's just how it works for me. Or worked. I am not a sysadmin anymore, even though I do handle some servers for development purposes.
Baboons are cute.
Besides as a machines passes from one asset life cycle to another it can keep it's name avoiding confusing scenarios. Developers can use machine names like clarke, brin, bear, asimov and users can be hosted on byron, keats or shelly.
Maybe it's kinda lame, but I find it helps when the users can relate to the machines by name instead of some confusing pseudo-name-code, it also makes for less confusion when supporting the machine.
I also like animals and cartoon characters.
My ism, it's full of beliefs.
It seems to me that the people who want the so-called utilitarian names are the people who least need to have access to the actual machines, really. Such as managers, who want to know where the machines are and possibly what they do, so they can make plans and budgets. I am, by the way, a UNIX system manager myself in a middlesized company.
There are several practical advantages to not using utilitarian names:
1. If a hostname is easy to pronounce, it is a lot easier to talk about the server - like when users say "I have a problem on bentley". Names like "as400_3_aix" or "mhz890-6" don't exactly roll off your tongue, so they don't get used. Sometimes they are abbreviated - e.g. "dash 6" - or they are referred to rather circuitously, like in "the big LPAR that runs AIX 5.3; it is 5.3, isn't it? I need a login on it." It may seem like a small thing, but you just try to live with it as a user or sysadmin.
2. A hostname that is easy to pronounce is also easy to type. This may not be relevant if you don't connect from the commandline, but take it from one who does it tens of times every day: it is a lot nicer to write "ssh fox" rather than "ssh as400_3_linux". Again a small thing, really, but it can make the difference between being slightly annoyed and not - and a person that is in a bad mood is less responsible.
3. If you work in a big-ish company, you may have a setup where you can't just slap new names into DNS as and when you need them. They need to be approved by the security officer (No, I can't think why that is either, but it happens none the less), which takes days, so you end up pre-allocating them in batches. Which means that you don't know what is going to be running on the server when it is actually installed, since it hasn't actually been planned yet. So you might as well just allocate some simple, easy and pronouncable names.
4. Fun. SW engineers are often creative people with a good deal of humour, even if other people don't quite see it that way. And being allowed to integrate your sense of humour into your work means that it will be more dear to you - it will contribute to a pleasant and relaxed atmosphere in the workplace. This actually matters - a lot, in fact.
I don't think there really are any overwhelmingly strong reasons for the utilitarian names; a manager who perhaps thinks about the servers once a month could reasonably be expected to make the small effort to look up what and where the servers are in a spreadsheet. As far as I can see, it is more a matter of whether it looks "messy" or not. But this is where DNS comes to our help - it is perfectly simple to have it both ways. What I do on my servers is to set the machines' hostnames to something pronouncable, make the primary DNS entry the same, and then assign aliases as needed along the way. Some aliases are "utilitarian", others are functional, like "qadisk", "devsrv" or "perforce". The funny thing is - everybody uses the non-utilitarian names, even though they have both options.
For example If I have a Windows server 2003, I call it Ubuntu710, if I have a RHEL box I call it MACOS10, if I have a Vista machine I call it FedoraCore7. I got to name a mainframe once and I called it AmigaOS and for Sun servers I call them DOS2 through DOS6. I call HPUX boxes AIX5 and AIX boxes HPUX11. The marketing department has been getting Macs lately and, despite protestations, I insisted they be called windows2000 to maintain naming standard consistency.
This makes for fantastic meetings, any phb that tries to get involved usually walks away with a headache, PM's usually want to slit their wrists after the first 10 minutes of discussion. Crackers usually fuck them selves up as their brain tells them one thing and their os map tools tells them something else, usually resulting in them launching the wrong attack against a machine and setting off all sorts of alarm on our IDS, a hardened fedora box called windows95.
My ism, it's full of beliefs.
In the long run, theme names are easiest for people to remember. For example, I work for a company of 60+ servers, and they are all named after characters and locations in the Discworld series of novels.
I always try and find names from translations of Tolkien that are different in the translation and not too long...
This presents an interesting challenge in that it's hard to find these quickly using Google etc. Since we're generally under pressure trying to set up a new server it's great fun.
So we've had:
kontu (Shire in Finnish)
kulma (Egladil in Finnish)
klofta (Combe, near Bree, in Norwegian)
megye (Shire in Hungarian)
breeg (Bree in Dutch)
We are a small company so we only have four servers and about ten laptops etc, so I'm not likely to run out any time soon... and of course as other people have said, we use CNAMEs to map services to servers (and this makes it easier to move services between servers too)
As this list grows every year we never run out of names. And it already contains 777 as of today.
http://namingschemes.com/Nobel_Laureates
"Is it friday yet?"
Each host should have a non-functional name. That is, it's name. This should clearly identify the machine. And have no functional reference at all.
The reason for this is that despite the idea the machines are all the same, they do have different personal histories and quirks. If you use functional and location based names renaming nysum52 to losyb01 disconnects the history of the device (of course, you can remember the serial numbers if you must, but this is easier).
nysum52, by the way, was the 'machine that would not die', it was due for decommissioning, but the management said to wait until it died by itself. Long after all the other machines bought at the same time had died a natural death, it just kept on working. We had to pull the plug...
Each machine can run one or more services. Each service needs to have attached to it a logical service name as a DNS alias. Thus the server holding the human genome is known as humandna, and the mouse genome is accessed via mousedna. Whether these are one the same machine or not doesn't matter. I can move one or both and simply have to update the DNS to get clients to connect to the correct source.
If you want a location included you can add the location as a parameter to the logical service name, hyphen separated. Thus the four imap server become imap-london, imap-sydney, imap-newyork, imap-madrid. Or you can use subdomains in DNS. imap.london.mybusiness.com. Either has the advantages that they become readily scriptable, easy to read, obvious on inspection, and best of all, self documenting.
I've never seen anyone connect to the wrong machine/service combination with this sort of set-up. It can be a nightmare if you are, as I am, a crap typist.
There is a website devoted to this very topic, namely namingschemes.com. It has hundreds of example naming schemes for small to large networks. And it's also a wiki, so you're free to add your own comments and examples.
At my work we use a very strict theme: three-letter animal names. It would amaze you how much creatures still fall in that category (I'm dutch, not sure if it applies for english as well).
But I never understood why host names have to be descriptive; it's what I use cname records for. For example, my home fileserver is called genie, but it is also reachable via fs1 or ns2 (fall-back name server). My router/firewall is reachable via fw0, ns1 and ntp, but is called gnome.
What's wrong with descriptive CNAMEs?
I used to look after the servers for a company that specialised in medical databases, so all the servers had a medical theme. We started with greek physicians (GALEN) and ended up with Carry-on film doctors (TINKLE).
In another job I was given the test servers to look after. I decided to use the prefix T (for test) and ended up with: TSHIRT, TTRAY, TCUP, TTOTAL, TSPOON and my favourite - TDIUM
Ouch.
"If you keep doing what you've always done, you'll keep getting the results you've always gotten."
yes, we do that also. Everything is theme based. Except for the printers which are named after offices. So prt-fin is the thingie which throws paper out somewhere in the finance department.
Atari rules... ermm... ruled.
My firm has a global network, and each machine carries the name of a famous (or not-so-famous) cyclist from the country in which it is located.
I'd simply partition my DNS to get sub domains for each physical location: chicago.company-office.com, etc.
Then I'd name the servers' A records by the room they are in such as for machine 001 in the server room SR001.chicago.company-office.com or dell-SR001.chicago.company-office.com and the PTR records accordingly. May be add a VXX for virtual machines on a particular server.
Workstations and laptops assigned to users are named by the user.
However, all servers get CName aliases for each function, such as intranet.company-office.com, webmail.company-office.com, files01.... etc. See there is no location for this.
This way users get functional names that are easy to remember, and to communicate. Admins can consolidate, split services across different machines with ease. They can relocate servers w/o hassle and it is easy to see where a server is by doing a reverse lookup, which will give you the location based A Record information.
An alternative is to maintain TXT records in DNS for the location and other information, such as server type and configuration.
Another consideration is to make server names transparent between internal and external access. The mail configuration should be the same regardless if I'm in or outside the office network.
Busy helping non technical users of OpenOffice.org - http://plan-b-for-openoffice.org/
At my previous employer's they used to name servers categorized into numbers. Not something I would recommend for really large environments (we hosted about 70 servers of which 32 Citrix MPS) but I thought it really worked well in our environment. The naming was like this:
xxxxx101, 102 etc: Cluster nodes
xxxxx201, 202 etc: SMTP/Mailbox servers
xxxxx301, 302 etc: File/Print servers
400 Citrix Servers
500 Database servers
600 Test environment
700 VMware hosts
800 network functions (dhcp/dns/proxy)
900 management/admin/tooling servers.
We did have branch offices but those all used Citrix, so there was just one server site. Replace xxxxx with a geographical location, company, department, whatever, if necessary.
Using this naming convention you can refer to a server as "The 203" and we all knew that was the Exchange SMTP bridgehead server, for example. I also found these short numbers easier to remember than names.
MMO Vampire Role Playing
Do you have a reference for that?
It's not that I don't believe you, it's just that I have found that just about everyone I've talked to has their own definitions of what "small" and "medium" mean in terms of businesses. From my perspective, I'd say "small" is anything under 100 employees, and "medium" starts just above that. However, I also know people who consider "small" to end and "medium" to start at more like 20.
So having some kind of official or semi-official authority defining this would at least make it easier to have an idea what size *some* people are talking about when they say "small" or "medium" business...
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
My way is the best way ever, and no other way in the world would work for anyone more efficiently and memorably than mine does for myself. It is as follows:
Top Level Domain:
THE JOKE
Second Tier:
IS ON
Personal Machines:
YOU
Its DNS. Use it.
If you have such lazy users that they can't be bothered to remember the correct URL or server name then use aliases. Give the servers good host names that make sense to the IT department (such as fs01 for file server 1) and add aliases in DNS for applications residing on the server (such as salesdata1).
We have a legacy naming standard, a physical naming standard, a new naming standard, a web naming standard (including subdomains) and then the other half of the company uses their own standard. Granted this came about through various insource/outsource movements, but we are now talking about 700 odd UNIX and 1200 windows machines.
The real standard is a logical one - I dont mind it but others hate it. It basically goes:
So a prod Solaris database server for the OPM application might be opmprddbss001. The naming standard specifies the varitions for other services etc, but it isnt perfect. If a application has a small database it intermittantly gets called dbs or app. The app TLAs vary depending on who wrote the design - sometimes its the project name, sometimes its the software. In general it works, it isnt pretty but its enough to have an idea what a box is when you hear about it until you have too many of them. 20 odd backup servers makes it a stop and think exercise to know what services what and why.
The physical naming is pretty straight forward - single letter for the site, a cabinet number, the cabinet position and if needed the blade slot. Scales, works, easy to understand, but not that nice to track 2000 odd bits of kit. We tie them in via DNS TXT records and a config database.
Then there is the legacy standard - - so a Solaris box in cab 574 would be csun5740 etc. Worked enough, but I found coming into that fleet that it was hard to differentiate bdun1010 from bdun0110 and generally only knew the usual suspects by name straight off. Also it would not have worked with blades, it was from an earlier time.
The web standard was logical but out on its own. As most boxes ran multiple apps it just listed its role and function so stuff like ptdbs1 for a prod test database box. Clean enough, but you had no idea what anything did unless you looked it up, and mapping stuff back to location needed a wiki page or text file.
And then there is our network standard - all I know is that it has a site code in it, but to me most look like they came out of an md5 sum.
Oh, and the firewalls are all Blackadder themed - cute but I never remember what does what.
But all that was in vain - the application teams seemed to persist in using IPs in code anyway which sort of falls over when your DR relies on DNS redirection.
My advice - pick something that gives you a quick idea on what it does and track the rest elsewhere. Domaining is a good idea if you can keep it simple. Machines change, applications change - dont try to put it all in a hostname or make it so rigid you need a perl script to figure it out.
The web server: web.myapp.com The database: db.myapp.com The backend for editors: edit.myapp.com And then again they can all point to same physical machine. DNS should abstract away the IP numbers, not just replace them.
Check out my cross-platform apps
For the purposes of sysadmins, then the host names should be meaningful with regards to the tasks sysadmins tend to perform on the boxen. But hostnames are sometimes exposed to users etc. Since DNS allows the mapping of MORE THAN ONE NAME to an IP address, it's no trouble to use the dns 'database' to store and handle the meaningful geographic names ( eg: oh-xxx.somecorp.com. ) that sysadmins like, and also the possibly business line specific name the users like ( eg: sales.somecorp.com. ) .
If a sysadmin wants to know the geographic name for a box, then the sysadmin can easily look it up. And the users can call the various boxen whatever they want too.
...
I've realized a long time ago, and this article's comments confirm it again, that there's two types of admins: the anal, by-the-book type, who tend to give their machines very clean, logical names with lots of meaning, and which nobody but them manages to remember; and the chaotic, playful type, who give their machines names from various more-or-less-known sets of words, which contain no information about the machine at all, but are easy to remember by most people who work with them on a regular basis.
The schematic naming is very interesting from a management perspective: just looking at the name will tell you everything from what the machine does to what colour of underwear the operator who installed it was wearing. In my experience, however, users tend to see a random string of characters, and fail to extract the information from the name. Also, was it ap or app, prod or prd, ...
The chaotic naming is utterly useless from a management perspective, beyond using distinct sets for distinct projects. However, to a certain degree, it antropomorphizes the servers, which makes the names way easier to remember for most humans.
Both approaches are equally valid - it just depends on your personal preference. I have insufficient datapoints to make any kind of statistically valid inference, but I have the strong impression that Windows engineers tend to go for strict naming, while *nix engineers tend to go for the chaotic approach. YMMV.
What a depressingly stupid machine.
I've always been very fond of:
[rack][number].[airport code].[domain]
rack is the letter designation of the rack in this facility
number is a two digit unit number. This should usually only go from 1 to 40. :)
airport code is the code of the closest airport. In the case of multiple facilities in the
same city, you can either suffix it with an incremented number, or pick another airport.
domain is your domain, you fool.
For an example, we'll use the Internet hub of the world, Nebraska. Our imaginary facility is located just outside of Omaha, which is airport code OMA.
The first machine in the first rack would be: a01.oma.example.com
Now there's never any question to what city you're looking at, nor even the location of it. It's not a big security risk, since this doesn't give up your physical address to unknown 3rd parties. They'd have to know where your facility is, where your cage is, and then get access to it to do any harm.
Naming with arbitrary names is fun, but a pain to remember when you exceed a couple dozen. Which machine was Karma? Well, at one place, we had smart, stupid, free, steak, kfc, ix, ns. Those are the only ones I can remember. It makes it real tough when you need to check through everything. When you can work down sequentially, it makes things much easier.
If you want fun names too, just set cnames to the good name.
Serious? Seriousness is well above my pay grade.
I don't know if this is part of your plan, but you should differentiate servers and services. Each server should have a unique name, ie "elrond.london.example.com", "frodo.hongkong.example.com", etc, or whatever theme or scheme you wish.
Then, each service should have a logical name, ie the server running web server for Human Resources could be hr.example.com (then you can move the service from one server to another without having to worry about renaming servers). This way, your internal naming scheme doesn't really matter to the users, and it shouldn't.
It's doubtful any user has connected to a host machine, ever or ever will within their lifetime. A host is a machine hosting a services, and it's the service the user find's important, and use(which is why we call them users). If you have a host that supports different services name each service distinctly. Also name each metal box something unique. You can also add a name for the location of the box. None of these need to be in the same domain. You might have a subdomain for the admin(s) of machines.domain.com, so that there is confusion as to what they intend to so. I don't have time to go into more detail I have to clean up a message, someone rebooted bkg3 when they wanted to reboot bkg4.
-- Prepared at the direction of, or to be sent to Legal Counsel, in anticipation of litigation. Attorney Client Pri
The issue's been beaten into the ground, of course, but a layer of separation between the physical host and the use(s) to which it is put is advisable.
Base hostnames:
Making the base names use themed names, like type of fruit, extension of the seven dwarves, etc. is fine as long as you're in one site. Once a company covers multiple sites, embedding those sites in the name is often helpful, although best for hosts that will *never* be moved, and good luck if you're bought out and the whole server farm moved.
Pick those themes carefully, though. Few will realize "apache", "osprey", and "fokker" are all types of aircraft, since the aircraft themselves were often named after unrelated *other* themes.
Tying such names to the underlying network infrastructure is a poor idea for gear other than routers, switches, etc. It would be a shame to have to do a grand renaming of a bunch of servers just because the network topology was tweaked.
Virtual Hosts:
Base-naming virtual machine instances inside the namespace of the containing host (or cluster within which they migrate) isn't a terrible choice - unless you expect to convert "real" hosts back and forth between that and being virtual hosts. If so, go by the prior section.
Functional Names:
CNAMEs are your friend, and this is the primary use for them, to make aliases, often several of them, to map services to the hosts (or VMs) that are providing the services.
Burying Arbitrary Info in a Hostname:
DNS has TXT records for completely arbitrary information - whenever possible, I'd recommend using those instead of complicating the hostname itself. However, it's still a crying shame that BIND doesn't allow host RR types to be filtered based on the querent, a key reason many sites are reluctant to use TXT RRs to their fullest.
So there you go. Edit at will, and good luck :-)
What I truly hate is something like this: ricldapweb1.company.com. It's completely illegible, makes no sense, and tries to pack way to much information into just one level of the dns hierarchy. DNS has hierarchies with semantic significance. Use them.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
If you have so much excess server power that you can just randomly decide to make your Exchange server also be a DB server, then you should be using virtualization to partition these servers anyway
What should one do if the server has enough CPU to do both mail and database but not enough RAM to run three kernels (one hypervisor, two virtualized), especially with the higher RAM requirements of Windows compared to *Linux or *BSD?
lgw.uk.domain.com
[...]
If a software application was called "Pacific Beach" the machine name would contain it, condensed to PcfcBch with an 01 at the end. Come on people, our language has vowels, use them.
Wales is part of the UK ;-)
What about the typing? Original UNIX had as few characters as possible for commands, e.g. 'vi', 'ls', 'top', 'df'. The reason for this was not just because core-memory was all that was available, typing mattered too. Why force all your users to type in lengthy names for machine names?
At a guess the poster has a few servers and lots of workstations. The servers can be given short, easy to remember names. Planets will do when starting out, as will mythical beasts, LoTR or animal names.
When it comes to workstations nobody needs to know what their machine is actually called, so you can have I.T. Dept friendly names that have the service tags in them.
i've delt with companies in the past that used a sub-domain category naming scheme. It sounds REALLY dumb at first but it makes sense and is easy to remember in the long term.. example: oracle01.hstntx1.us.mycompany.biz an Oracle server in houston (location 1) in the us.. not that hard to figure out what it is.
We are a global company, with representation in (seriously) all 7 continents. Although I personally like themed naming (such as fish, TV show characters, etc), we have too many servers that must be easily identified to a physical location, so we can't reasonably do themes.
We use a convention that has the continent, country, and city-shorthand (state is unnecessary as we have no redundant city names with servers in them), followed by a hyphen and then the purpose of the server.
For example, NAUSCH-SMTP01.ourdomain.com would be in North America (NA), United States (US), Chicago, and it's an SMTP server (number 01). It's overly simple, but it really does help when we need to know where and what it is.
Users also hate strange names like "a-fs1". And ultimately the names aren't for the admins, they are for the users. If you want you can give the equipment the fancy name (including location) but then alias the names with what you want the users actually using.
Users tend to do things like say "oh that file is on picard." and dislike it when they have to say "oh that file is on ren-cup-ef-es-2" for RenCupFS2 (company id: REN, location: Cupertino, function: Fileserver #2).
On the other hand just calling things fs1 to fs20 because you have 20 fileservers in your company is frustrating as well. If you want executives to grok the files you should mirror how meeting rooms are named. If they are just numbered like 9-4. for building #9, meeting room 4. then that sort of highly numeric scheme should be used in the company. but if your rooms are named Oak, Maple, etc at one location and Pisces, etc at another. Then go with some simple meaningless names for the servers.
Ultimately you'll just have to make a table of names to function no matter what technique you name them. because eventually someone will come to you unsure on how to navigate your network.
“Common sense is not so common.” — Voltaire
That is how we name things around my shop for the most part. DTXXXX for desktops LTXXXX, POSXXXX for point of sale terminals. Servers are a little different... Servers are WHATIDO1 so PDC1, PDC2, fileserv1 fileserv2, appserver1, mailserv1, etc.
"Real" Admins use Star Wars Names. Every company should have a Chewbacca Server....
I use nonsense names, generated out of three random syllables, e.g. "ridana" or "kasuri". These are generally easy to remember and easy to pronounce/understand. And as long as we only have offices in Europe I don't have to worry whether one of this names is a dirty word in Japanese.
I had an idea to name all of my servers after pokemon... and to place them in subnets differentiating them by their main elemental type (grass, water, fire, etc.)
You could start with zipcodes or counties or cities, depending n how spread out you are.
sort of like: county-serial.city.blabla.com
Or how about department or division names?
---- Booth was a patriot ----
I tend to use films / books for networks / subnets and characters in them for nodes. If you tailor the network segments to the expected users you'll have a forewarning of what the problem is when "Noddy in Toytown is dead" as opposed to "Case from Chiba_city"
Laptops/Desktops:
p-smithj (j smith's 1st desktop)p-smithj-02 (j smith's 2nd desktop)l-smithj (j smith's laptop)
h-smithj (j smith's home machine)
this is all well and good until you replace someone's desktop and the techs are too lazy to go back and rename things. we have plenty of p-smithj1 or psmithj-01s floating around.
--Mike
But the majority of users typically print to one or two printers in their office (a laser and perhaps a color inkjet). If there is a big sign on the printer that says "Oboe" or "Bassoon" it's probably easier for them to identify and remember that name, rather than a cryptic code name (especially if there are other similarly cryptic printer names). Plus, users don't generally need to know what printers are on the third floor above them or the first floor below them, or even across the office on the same floor. They print a document to the printer at the end of the cube row.
My team supports around 2000 Unix servers, we have about 3000 Windows servers admin'd by my counterpart's team, and the naming schemes we're using seem to mostly work. Each server has (at least) 2 names. The system gets a hardware name like t2k123, and then a logical name, like clarify-web-prd-01. This way, I know it's a Sun T2000 (t2k), it has a number (123), and it's used for clarify, it's a webserver, it's production, and it's #1 in the (in this case) cluster. There's probably also a clarify-web-prd-02 which will be on hardware that isn't t2k123. And somewhere I bet there's a clarify-web-stg-01, a clarify-web-dev-01, and maybe even a clarify-app-prd-01 and so on.
This answers the important questions: Whose program is it for? What does it do? What's the criticality, and which one is it?
I suppose you could work location into the hardware name, but a simple spreadsheet or a file on the box saying where it is (building, room, rack) is just as effective.
I used to use unique names for each system, using a theme (greek gods and godesses). The idea was that each system may have multiple uses, or could get repurposed, so I did not want the name to be the same as the function. I added a DNS alias for every service the server provided, so that the service could be moved with the alias. Also, I wanted the name to be memorable. Having used serial number based naming conventions in the past, I found that an easily spoken, and spelled name was the right fit for the company. Ever need to add a printer from server 56X79? This worked for many years in a single location for a small and medium sized business.
Enter today. No longer that small or medium. Over a dozen locations. Over a hundred servers. And most importantly, the IT team is larger, so I was no longer imaging all the servers myself. Communication within the team became _very_ important. Proper documentation was critical as I could no longer recall what all the systems were doing. And, most important of all, VMs entered the picture. Now I had a situation such that, I never repurposed a VM. I would kill it, and create a new one. Also, I had a hard time recalling which machines were in which location. So, we came up with a new scheme:
Locationcode-Service.domain.com.
Example (machine in DC running DNS):
dc-ns1.domain.com
Users don't need to know it. They get their DNS entries via IP address anyway, so that one makes a crappy example. How about this, a SQL server in San Diego:
sd-sql1.domain.com
Hmmm, close, but which databases were on that again? Here is where DNS alias can come back into play:
sd-accounting CNAME sd-sql1.domain.com
Now I have a simple nameing scheme for all locations, using simple codes that immediately tell me where a machine is, and what it is doing. So far, it is working great, and it addressed all the issues I had with greek gods, klingon food, cars, flowers, trees, stars in tke sky, simpson's characters, etc. naming schemes.
In short: for me, s/n bad. greek gods bad. location-function good.
At www.pan-univeralism.com we use 16-bytes for a brane ID, 16-bytes for a galactic identifier, a 4 byte galactic sub-region identifier, a 16-byte solar system identifier (we recommend the top bit as an interstellar flag) and 4 bytes for planet identifier, then we use a simple 16-byte id for each computer on the planet.
Then, we use CNames to map each computer's numeric id to a porn starlet's name, so we can remember them.
If you use a "role-based" nameing scheme. Lie. Do NOT name systems with high-security needs what they are. billing.yourcompany.local should be a honeypot. Let the REAL billing be done on something like dns-b.yourcompany.local. (Actual DNS systems would be dns-1.yourcompany.local, dns-2.yourcompany.local etc.)
That being said, I strongly prefer theme names for security reasons. People on the inside know that meowth has next year's production plans, but an intruder would not know meowth from zubat. (Zubat being the CEO's kid's laptop which is only on the network at all because the CEO insists, and the last guy with your job was fired for refusing).
Little Brother, watching the watchers
For a humourless pedant, you certainly are choosy about the details you latch onto.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
For example, a small company I worked for a number of years ago used Greek and Roman mythology. Zeus and Hera were the PDC and BDC, respectively. Apollo was the mail server. For our small environment, that made sense.
That's funny. That's exactly the convention we used at the last company I worked for as well. Zeus, Poseidon, Hera, and many others were used. I enjoyed using colorful names. Now I'm working at an ISP and everything all the computer names are boring letter/number combos. Of course, it's probably a better plan considering we have upwards of forty servers.
http://technet.microsoft.com/en-us/solutionaccelerators/bb892167.aspx
http://www.microsoft.com/technet/solutionaccelerators/cits/dsd/acctmgmt/default.mspx
We're adopting the LOCATION-DOMAIN-TYPE-INDEX naming convention outlined in Microsoft's Account Management solution accelerator for all infrastructure systems, including servers and network devices. For the location code, we're using the code name of the nearest airport, so names look something like dca-ex-dc-01.int.example.com (a domain controller). When the interface name is significant - we want it to show up in traceroutes, for instance - we put the interface information in DNS with the server/device name as a subdomain, which gives us FQDNs such as ser-0-0.sfo-ex-rtr-01.int.example.com (a serial interface on a router) or v10.fa-0-1.sfo-ex-rtr-01.int.example.com (VLAN 10 on router interface FastEthernet0/1 - perhaps there are more elegant ways to convey this info).
Where our servers have ILO interfaces, we add "-c" (for "console") to the server host name to come up with the ILO host name. We also set the ILO IP address to be the server's primary management address plus 1, e.g., if the server is 192.0.2.15, then the ILO is 192.0.2.16.
We have received conflicting advice regarding domain names: using a non-existent TLD (such as .local or .lan), creating a private subdomain (e.g., corp.example.com), or registering the domain in an alternate TLD but never using it publicly (e.g., example.net). Using a non-existent TLD seems dangerous, especially with recent activity by ICANN on the topic of alternate global TLDs, but I don't know what the administrative or security implications of using private domains/subdomains are. For my own personal network, I've registered a second domain, but for the businesses we manage, I think we'll create private sub-domains instead (mostly because it doesn't cost any money).
I used to like thematic names (space ships/movie characters/authors/whatever), but I have come to appreciate encoding certain kinds of information in the host name itself (i.e., approximate location, owner/operator, and role), especially when a hardware inventory isn't available. Plus, nothing says "unprofessional dork" like showing your boss's boss network diagrams with tags like "fruitfucker.example.com".
I'm proud of my Northern Tibetian Heritage
use:
LLL- Location :( )
PPP- Production Status
TTT(T)- Type (sometimes 3 doesn't do it
SSS- Seq. Number
LLLPPPTTTSSS
Even if you don't have multiple locations, plan ahead, ditto with production status. you may not have production, staging and development now, but you may someday.
The type can be, app (servers that run apps), file (file servers), Mail...
And if its an oddball or you need more description, you have 2 or 3 (I never take away from the numbers, but you could) characters to play with on windows(NetBIOS rules suck...)
Some examples:
Servers in two towns
PHIproApp1 - the 1st application server in Philadelphia
PITproApp1 - " " Pittsburg
PHIstgMail1 - the 1st mail server in Philadelphia
I actually know people who really used to think that moving a few extra DNS packets around the network was "too inefficient". Those same people thought that moving even a few extra bytes is "too inefficient", if it was something that has to be moved often, like a host name. That was just a few years ago. Those same people now think nothing about placing the file server for an office site half way around the world, if the rack space, power, cooling, or backup in that office is limited.
When you are buying your first hundred machines, it is tempting to use "cute" names. As you pass a thousand machines, it's not cute any more. When you get to five thousand machines, you really appreciate having machine names that look like inventory tags, and CNAME records that map application-defined hierarchical names into those hardware names.
What do you do when a server moves?
How often do servers move anyways? They're not notebook PCs, they are big heavy iron boxes, often bolted into a chassis in a room visited by no-one but sys-admins. If a server is physically relocated it is generally regarded as a significant event. Might as well give it a new hostname as well. If you think that is a hassle to users, well that is what CNAME records are for. Nobody said the hostname of a server has to be the only name that can be used to find a server.
General guidelines say you shouldn't put the computers location in the name.
What general guidelines are these? I've not seen anything forbidding the practice, and in fact it has been requested by some outfits I've worked with that hosts be named based at least partly upon location, especially when the site is large and in separate buildings. It is really a pain to have to get out a network architecture drawing to figure out where an errant server is because it is named solely for its function, and it is impractical to go searching for it because it could be down the hall or it could be in a building on the other side of a site that is 3 km long.
How 'bout making full use of DNS capabilities and subscribing to one system of naming hosts and use CNAME records to provide preferred names for users to use?
If a server is named after building/room/rack it can be easy to track down problems and you need physical access to the server to resolve them. CNAME entries like WWW, FTP, MAIL and so on can be used to give them functional names.
Cutesy theme names might be confusing to some, but there can also be issues with badly chosen functional hostnames of any type that make them about as useless as IP addresses for remembering what hosts are what. To get around various Windows networking shortcomings hostnames sometimes have to be short, and too much info gets crammed into them to the point they become meaningless. What the hell is VAN01AP5B anyways, besides hard to type or remember? That is where properly using DNS subdomains could be better used too. AcctPay-5B.Admin.Vancouver.example.com is much more descriptive and the hostname is easier to type and remember (AcctPay-5B). Computers local to the server in question (the most likely users) could type only the hostname and not the FQDN, and of course CNAMEs can be used to assign more concise names.
One interesting DNS scheme I've seen maps element names to subnet IP address by atomic number, e.g.
x.x.x.1 hydrogen, h
x.x.x.2 helium, he
x.x.x.28 nickel, n
x.x.x.29 copper, cu
x.x.x.97 berkelium, bk
You get names, abbreviated names, and the Periodic Table as a failover DNS, all with no creativity required.
Greek gods & mythology heroes
zeus (the big chief), ifestus, posidon, hera, athena, hercules and so on..
The company I work at used to use a mixture of Greek and science fiction names for servers - heavy on the science fiction, mostly Star Trek and some other stuff mixed in.
It's rather annoying when a server suddenly shows up as offline in the monitoring system and I have to think hard about wtf Kronos is supposed to be doing, and who I have to call about it at 3 in the morning when I can't get it to boot up.
I'm glad we've switched to a useful naming convention in the last year or so - now it goes by sub-company name, purpose, and machine number if it's in a cluster/load balance (which pretty much everything is). So "subcompanywww1" is easily recognizable as one of X sub--company's load-balanced web servers when it dies, and I know if it can be left alone until morning if it's on fire.
For every action there is a completely absurd lawsuit.
Sorry guys, but I was thinking the whole point about the DNS system is to ease use of computers by USERS, not sysadmins. I have too often found networks where the sysadmins named the servers for their own easy usage rather than ease usage by users. No user is caring about where the f... computer is located. There is plenty of other databases and systems that can be used to ease the work of sysadmins that nobody should have to hack the names for this purpose.
Achille Talon
Hop!
Need a lot of names (1400), many of which end in "-os"? Try Greek Islands.
now we need to go OSS in diesel cars
We use Greek letters. Xi, Kappa, Epsilon, et cetera. We've only got a couple dozen servers, so that works for us.
As trivial as it seems, I think computer naming reflects on the corporate culture. Doesn't it seem like it'd be more fun and laid back to work where the computers have names like homer, marge, maggie, lisa, etc, than net001, net002, server-6a, firewall-3a, etc? I agree with just letting the administrators of each machine pick its name, subject to some basic rules that should be fairly obvious.
exactly!
1st character = type of resource (Server/Router/Switch/workstation/DBNAME/ClusterName
2nd character = environment (Production/Lab/Test
3-5 = site/location abbreviation
5-x = role (and sometimes product) abbreviation
y = increment
One important thing to note, the first character is the most important; the naming scheme can be distinct across types.
For example, when it came time to devise things for end-user nodes and things like printers, it became more useful to tie things to other attribues, like Language, Desktop/Laptop and Cost center. Mind you these were also managed by different teams (with different identification needs).
Keep in mind that you can access things like asset tags remotely, or at least gather them during your inventory process, should you need that for support/replacement purpoces.
Whatever system you use, it should be easy and unambiguous to pronounce. Want to name it after a service? samba, www, login, and the like are fine. But when you start coding things into the name, it all starts turning to mush in the brains of people who only erratically connect to the machine, or people who are communicating over the phone. Talking with someone about a pair of machines whose names are unpronounceable and vary by only one or two characters is confusing as hell. Having worked with a group that gave machines helpful names like fnabl3 and fnag13, I know this pain. Maybe the abbreviations made perfect sense and were unambiguous to them since they used them all the time, but as someone asked to briefly help with a problem it was frustrating and error prone. Sure, cheddar and swiss don't tell you anything about the service in question, but they are hard to mess up.
Search 2010 Gen Con events
There are useful points in RFC1178, but some of it is obsolete or unscalable.
Important issues IMHO include:
1. Keep hostnames short. There's not much left technically these days that breaks on >8 characters even in places where mainframes survive, but humans need short names.
2. Use domains where they make sense, but don't go crazy with them. No one should have to remember more than a half-dozen subdomain names or more than one hierarchical level, i.e. ..one.universal.parent.domain is okay, but ...parent.domain is going to be a major hassle.
3. Make the hostname expressive, but not obvious.
4. Avoid confusion between machines, even if you end up having to name a large number of machines with your scheme over many years.
5. Don't forget that in nearly all cases, you can give different audiences different names that make sense for them for the same machine without changing the machine's One True Hostname. In many cases, this is a very good thing to be doing because it is increasingly expected that a well-planned environment will allow for refactoring services among hosts, migrating services around without eliminating hosts.
To that end, I've become fond of schemes that make up a hostname with an 8-character name where the leading 3-5 are letters that carry usage and management meanings, and the remaining are digits identifying the particular host, so that a machine which changes function significantly might get a new name, but keep the same host number. The last one I used like this was working with an environment of a few hundred machines, so we had the luxury of 5 letters in the alphabetic part of the names. We mapped these to:
Physical location (i.e. which data center)
OS
Business-side owner (department or shared-use)
General function (database, frontend web server, web app server, etc.)
Support class (production, development, QA testing, sandbox testing, etc)
Because we had a lot of room in 3 digits, we also were able to encode more info into the high digit of the host number as well, so we could tell which of our networks a machine was on by "which hundred" the number was in. This scheme allowed us to do useful things in handling those machines without having to do much thought/research. Admins and even some users could tell what a machine was without looking it up in a database.
This is somewhere between the obscurity of using elements, astronomical names, or porn star names (I'm scared of anyone who could name 250 machines after porn stars...) and the invitation quality of using names like "fileserver-01" or "billing" that legitimate users should not need and intruders would appreciate. If you really must have user-friendly names, make them in addition to the canonical name for the host and segregate them into a distinct DNS zone.
"* The RFC is only applicable to small systems. Obviously."
The RFC is *mainly* focused to small/medium system but it certainly is aplicable to all kind of systems. Tell me which point, either from the "don'ts" or the "dos" is of no application on large deployments. The only dubious one, out of a list of 11 "don'ts" and 5 "dos" is "use real words". And yes, "Use theme names" *is* of application: "make the name out of the main function, then the state code, then the inventory number" is both an algorithm *and* a theme, as it is a theme "the set of natural numbers" just like "the set of LOTR characters" is.
"Yep, DNS is technically a database, I know this since I am not a total moron."
Good to know.
"But that was not my point either. Most NOC-servers does not use DNS, but a specific database, to store system specific data, mostly for security, TTL, and availability/redundancy reasons(not all eggs in the same basket)."
I feed DNS data out of flat files, MySQL databases and BDB through LDAP. In the last two cases, the underlying database holds not only domain name data. Your point is, again?
"A file server is a server that serves files, this might or might not include an FTP server. I wasn't pretending to come up with a perfect standard. I said rough, remember?"
But you are ready to attack an RFC because it isn't a "perfect standard" either while nobody seem to have taken the time to produce a better one since 1990. You both failed to provide a better standard and to properly qualify the lacks from the current one (HINFO and TXT fields do cover the example you provided, don't they? Not that I myself find them of any use, but that's out of the question here).
"In larger systems, you seldom, if ever, change the role of a server(during it's 3 year life span)."
In larger systems you *seldom* change the role; the RFC both covers the case where you don't change the name and when you change it too; it's not judicious to use functional names in any case: you are "labelling" the system, not its function. Just as a lame comparation, since most delivered PCs comes with Windows, why we should take into account anything out of Windows world? (by the way, it would simplify the "fileserver" case: it would be a SMB fileserver since there's no other kind).
"But I would rename it, if that happened."
The old guy "now get off my lawn" story: Once upon a time we (as in the team I belonged by the time) did that. Usually a "server grade" PC started its life in a "heavy duty" environment (say, a fileserver) then some years down the line new faster hardware retired it from the front line and it were redeployed (different name) on a "second rank" role (say as a DNS, a test server, a cold backup, even in some cases as a user workstation, whatever). We managed some two hundred servers at the peak (not so big environment, but quite enough to find scale problems on not well fitted standards and protocols). On a five year cycle (by the end of my period on the team) we found by chance that our Dells were slightly but still significatively more problematic than our IBMs. Since we changed names when redeploying such a fact went under the radar for years; were we used the same name on the boxes for their whole life that fact would have just jumped out to our eyes (yes we used asset tags, that's how we discoverd, but while we used computer names day-in day-out, asset tags were something we had to explicitly look for, so the relationship between field attendances and computer brands went undiscovered for ages).
"1 & 2. The limitations of theme-based naming schemes does not stem from the number of available names, but the fact that it is impossible to read any information from the name of a server called "FIDO"."
Just as it is impossible to read job status from the name "John Smith"; the name "John Smith" is only meant to distinguish "this" guy from "that" guy. His job status is given by his job title "John Smith, CTO". By doing this -distinguishing individuality f
Where I work, we name machines with three "syllables" like this:
nycdc-db-sprov.domain.com
which translates to "New York City datacenter, database, service provisioning". Subdomains would be cleaner, but we don't have enough of each type of machine to justify the hassle of having so many subdomains.
I always suggest liberal use of subdomains, maybe even a 2nd level domain for everyone department.
...therefore all my servers are given a hostname string equal to the Dell "Service Tag", followed by a dash, followed by the Dell "Express Service Code".
I get that this is a joke, but you do know that the "Express Service Code" is just the Service Tag in Base36, right?
Host names that try to convey more information than this either don't give you the information you need most of the time or are so complex they are unwieldy, and in either case are not memorable.
Information is what databases are for, and all a host name needs to do is identify a record in a database, and (as other posters have pointed out) should not identify with people, projects, etc.
I give up, you win.
Baboons are cute.
At a previous employer we named all of our machines after elements on the periodic table. We also used the corresponding atomic number as the last octet of the machine's IP address. So for example:
iron.company.com would be 192.168.1.26
Comment removed based on user account deletion