[nycbug-talk] Sanity check on new naming scheme

[Isaac Levy]

Hi Matt,

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 =)

;P

> 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. 

Yep.  I guess exceptions perhaps would be special-purpose hw in big clusters, www1, ww2, - or computenode1, computenode2, etc...  where this naming is a part of a social strategy to keep the boxes purpose clear.

However, I've gone through arguements where some notion of 'scripting is easier if it's www1, www2, etc..', and that falls apart completely in practice- scripted/group management is no more challenging if the machines have unique names or not- I think scripting for www1 www2 www3 etc... is just lazy, and the edge cases you never coded for in the first place are really annoying wastes of time, but that's personal opinion...

> 
> 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. 

No objections at all- it's your network :)
However, I have typically dispensed with the search path of domain.internal (or network.internal), in favor of simply .internal - it becomes just one more file to manage/update in /etc/hosts to me...  But, that's just my personal opinion and I haven't experienced any need which sways me.

Have fun!  I really love it when new/clean naming schemes finally slide into place- daily life gets so much saner.  It's the little things...

Rocket-
.ike


> 
> 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
>