Re: [SAGE] Naming conventions for servers, network gear, etc.

[Brad Knowles <brad@shub-internet.org>]

At 1:55 AM -0500 1/7/07, Rodrick Brown wrote:

>  It really depends on your definition of a long hostname? I find
>  subdomains to be really annoying in a practical sense especially in
>  environments where you can easily run into issues where you have
>  duplicate hostnames depending on your search path it can get really
>  confusing, this is very likely in larger environments. ie.
>  servera.foo1.domain.com servera.foo2.domain.com.

I guess it depends on the group that is doing the O&M for these 
machines.  But does every admin need to have full and complete access 
to every single machine?  Do you have just five admins to manage tens 
of thousands of systems, spread across the world?

Why type the thirteen character long "scsinfpladm01" each and every 
time, instead of shortening that to "padmin01" within the 
"inf.scs.example.com" domain, and the domain name portion might only 
need to be typed rarely?


RFC 1178 is old enough that they didn't really worry about always 
creating highly organized section and paragraph numbers, I guess 
because they didn't think that people would be reading and referring 
to these documents so much, and would want a quick and unambiguous 
way to refer to different parts.  And not all RFCs were 
pre-paginated, so you can't even reliably use page numbers and then 
paragraph numbers from there, or something similar.

So, I guess we have to use section and subsection names.  In the 
"Don't Do These" section, there is a short subsection entitled "Don't 
use long names."  They don't mention the fact that many OSes at the 
time had a built-in restriction of maximum hostname length of eight 
characters.  Instead, they give us the following timeless guidance:

          This is hard to quantify, but experience has shown that names
          longer than eight characters simply annoy people.

          Most systems will allow prespecified abbreviations, but why not
          choose a name that you don't have to abbreviate to begin with?
          This removes any chance of confusion.


I dunno.  Maybe us old-school vi types that value economy of typing 
over big flat namespaces are obsolete.  I mean, the economy of typing 
"creat()" over "create()" is not much, and there is enough added 
confusion, that I'm not sure it makes sense.  But "creat()" over 
"create_new_file()", that I can see.


In the "Do These" section of RFC 1178, the next-to-last subsection is 
entitled "Don't worry about reusing someone else's hostname."  Keep 
in mind that this document is old enough that many people would 
remember HOST.TXT tables, and the transition to the DNS, and 
consequently the introduction of domain names to the Internet.  Yet, 
this document already recognizes the value of not even trying to keep 
a flat namespace.


>  The OS type indication in a hostname makes automation/scripting very
>  simple across the board. I have not found a single issue with this
>  scheme over the years please enlightenment on where exactly this can
>  be problematic so far you've stated nothing but religious reasons.
>  Brad I really value your input so please don't take this response as
>  an attack in anyway I just want to see where exactly you feel this can
>  be an issue.

Why encode the OS in the name, when the OS might need to change 
overnight?  Why should the change in the OS require a change in the 
function or the name?

Does it really make a difference to the applications what OS is 
running on machine_named_fred?  If machine_named_fred_on_linux dies, 
and you end up temporarily replacing it with 
machine_named_fred_on_freebsd, and you've got lots of applications 
that would be connecting to that system, why should the hostname have 
to change just because the OS does?  Conversely, why should you have 
to continue to have an old OS encoded in the name, when the current 
OS on the box is something different?


Interestingly, this particular topic doesn't seem to be addressed by 
RFC 1178, but I was pretty sure it had been.  I had to look through 
it several times to be sure, and even now I don't quite believe it 
myself.

Of course, this issue is covered in the other reference that has been 
recommended, namely <http://www.nanog.org/mtg-0405/ringel.html>, in 
the last bullet on page 7.  However, this document also recommends 
longer names over shorter ones, too.


And this also gets back to another fundamental naming question -- do 
we name machines, or interfaces?  RFC 1178 assumes that we name only 
machines and doesn't even talk about interfaces, while Ringel clearly 
assumes that we name only interfaces and the concept of naming just 
machines is totally alien.

So, we get theme names like "tulip" or "lily" in RFC 1178 versus 
"sackler-rtr-pri-x-grafton-rtr-pri" and "anderson-rtr-pri-t-vlan80" 
with Ringel.  Nevertheless, Ringel does suggest creating CNAME 
aliases that would allow RFC 1178 style names to be used for 
occasional human convenience, while the underlying machine is 
actually named something totally different.


Personally, I think we name both types of things, and both types of 
naming conventions are useful.

If I was a network guy, where I had lots of devices each with 
potentially dozens or hundreds of interfaces, then I'd use 
Ringel-style naming.  Or, if I was managing a very large number of 
machines, either in a cluster or in a farm-like environment, then I 
would probably end up using something like Ringel -- maybe 
city-building-room-row-rack-shelf.  The latter would have worked 
pretty well at AOL, for example -- at least, for the guys who push 
the machines around and manage the physical inventory, while the 
e-mail admins could use a CNAME based system like "emoutXX" and 
"eminYY", the news admins could use something like "feedWW" and 
"readerZZ", or whatever.

But if I had a smaller shop, or didn't have to deal with a great deal 
of systems that had large numbers of interfaces, I'd most likely go 
with something much more like RFC 1178.  And I'd most definitely go 
with RFC 1178 style naming for those CNAME aliases.


In either case, I think that both documents have something useful to 
teach us about bad things you should probably avoid doing in 
selecting your naming conventions, and good things you should 
definitely consider in selecting your naming conventions, and neither 
of them is a complete stand-alone reference on this subject.

Where RFC 1178 and Ringel conflict, I guess you need to take a look 
at your particular situation and see which kind of guidance is more 
appropriate for your situation.

Otherwise, where one addresses a particular topic that the other 
doesn't, then I think I'd probably use both.

-- 
Brad Knowles, <brad@shub-internet.org>

Trend Micro has announced that they will cancel the stop.mail-abuse.org
mail forwarding service as of 15 November 2006.  If you have an old
e-mail account for me at this domain, please make sure you correct that
with the current address.