[nycbug-talk] Sanity check on new naming scheme

Thu Apr 8 10:20:47 EDT 2010

On Apr 8, 2010, at 10:06 AM, Matt Juszczak wrote:

> Hi ike,
> 
> Thanks!  Two comments. First, the security by obscurity sort of was a joke =) but yes, we don't want to put the description in in case the box gets repuropsed, but more so in case the box gets multi-purposed. Can't tell you how many times someone insists that the primary ldap server is now the primary dns server too. Then what?  ldap01 is no longer valid. 

I worked for a company that had thousands of servers in locations all over the world and early on they made the dumb decision of making the hostname a combination of the location, and either an "s" for server or "n" for network and then an incrementing number. The reasoning for this was that we could simply take a box and change its purpose and you wouldn't have to rename it. I am sure at first it worked out quite well, but when you start to get into the hundreds of boxes it became a real pain because someone would go "application x in location y doesn't seem to be working" and then I would have to spend 5 minutes figuring out where application x in location y lives.

I am sure you are going to counter this argument by saying you are going to keep very good documentation as to what is running where, but I can promise you error and outdated information are going to end up in your documentation and you are only going to discover them when something is already wrong and its going to make things much much worse.

Why not take all your backend services such as dns and ldap and place them on boxes called "admin" or something like that and then use cnames to make ldap01.site point to admin1.site and ldap02.site point to admin2.site and ns1.site point to admin2.site and ns2.site point to admin1.site

> 
> Second, ill do the local hosts, but ill do: 
> 
> boxname.domain.internal 
> 
> And make the search path domain.internal. Any objections to that?  This would be instead of boxname.internal. 
> 
> Matt 
> 
> -----Original Message-----
> From: Isaac Levy <isaac at diversaform.com>
> Date: Thu, 8 Apr 2010 09:57:53 
> To: Matt Juszczak<matt at atopia.net>
> Cc: Francisco Reyes<lists at stringsutils.com>; <talk at lists.nycbug.org>
> Subject: Re: [nycbug-talk] Sanity check on new naming scheme
> 
> Word,
> 
> My .02¢,
> 
> On Apr 7, 2010, at 1:51 PM, Matt Juszczak wrote:
> 
>>> Any reason you don't use functionality as part of the name?
>> 
>> Security by obscurity :)
> 
> Well, yikes- not sure I like that reason, but I can give a different/functional one:
> 
> I'd typically rather name the machines uniquely, (sparrow.hostname.com, crow.hostname.com) instead of functionally, (e.g. www2.hostname.com, www3.hostname.com).
> 
> That way, when the box which was www2.foo.com gets re-purposed for use as svnbackup.foo.com, the machine name doesn't have to be completely changed- and documentation and other materials related to that server don't have to be changed- IMHO it's a crazy task to always be updating documentation across an organization just to change names around...
> 
> !!! Then, for specific services, domain names can be mapped as CNAME aliases (or A records, depending on context/use), to any of the boxes- without much fuss.  Examples, www.publicdomainname.com, svn.domain.internal, wiki.domain.internal, etc...  The stuff people actually use.  When failing-over to a backup for a given service, or whatever, it's less disruptive for (n) number of users- (nothing less disruptive than telling a team of devs they all have to change their source code repo in their IDE's and such).
> 
> I'm a big fan of keeping boxen and services separate identities, as far as dns goes.
> 
> Last important thing for me: for those names, it's really good to have pre-generated lists of the names to use, because it's often the last thing I want to figure out while unboxing/deploying a server.
> Things I've used/inherited in the past: elements from the periodic table, names of birds (from a little book I had in my desk), names of fish, food, island names from around the world, bodies of water, rivers, (stay away from cities and physical locations because eventually every org ends up with some idea of where the boxes physically are).
> 
>> 
>>> Your naming schemse seems sane/sound.
>> 
>> Awesome, thanks!
> 
> 
> I agree- your scheme is simple and clean, and I've had great results with the sort of naming scheme listed.  I have a few personal things to add, (as I have done similar setups), however it increases the management/overhead of naming so I can't say they're hard-rules I follow:
> 
> --
> Regarding <server name>
> unique name for the machine, not it's function/service
> 
> Regarding <data center ID>
> I tend to use the name of the physical network zone instead, for example:
> <server name>.<core network name>.internalname
> e.g.:
> servername.computegrid.internalname
> servername.utilitynet.internalname
> servername.corenetwork.internalname
> servername.officetrusted.internalname
> servername.officeuntrusted.internalname
> servername.dmz.internalname
> With this method, I prefer to keep the documentation about the network out of the machine host name.
> 
> Regarding .internal
> Something SHORT and unique-ish to your org, but not conflicting with TLD's! (make it easy to type, everyone will be typing it a lot!)
> --
> <server name>.<data center ID>.domain.net	-> public IP
> 
> For public use, I really only find value in this naming if it's matched with PTR records, (if we're managing PTR internally)  Otherwise, I don't bother with it at all and focus on the pub. fqdn mappings...
> 
> --
> <server name>.<data center ID>.domain.internal	-> Local IP
> I love this as hostname settings for machines, as well as keeping it resolvable on the internal networks.
> 
> However, for the sake of scriptability/manageability, I tend to also make sure the following convenience is in place:
> <server name>.internal
> 
> This way, users/developers don't need to constantly be aware of which network zone is which, and if a box/service/idea is moved to another network zone, scripts/programs set to reach it still just work.  If the machine is moved to a different network zone, scripts still work and users still can get to it.
> It's also far less typing, important to me as things grow.
> 
> I tend to set this kind of thing up with internal DNS using Bind Include statements in my zone files, keeping the host mappings in single files- I'd bet this is easy with djbdns too.
> This strategy allows for many DNS names to be given for a single host, yet keeping management simple and consolidated to individual zone files.
> --
> 
> A long .02¢,
> 
> Best,
> .ike
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
> 

--
Steven Kreuzer
http://www.exit2shell.com/~skreuzer