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

[Richard Chycoski <rskiadmin@chycoski.com>]

You naming scheme should reflect your environment.

For example, our desktops are simply named <username>-<OS/platform>[<n>]

So, for user jsmith who has a Linux box on his desk, the hostname would 
be 'jsmith-lnx'. If he also has a Windows XP desktop or laptop, that 
would be 'jsmith-wxp'. His Solaris machine might be 'jsmith-sb100'. This 
works well for our 30,000+ desktop/laptop/personal systems since we have 
a directory that keeps track of where all the employees are located, and 
personal workstations tend to stay with the user. We have a flat 
namespace for users and networks - subdomains are worse than labelling 
hosts with their OSes in our company because the physical and logical 
organisation of the company is constantly changing. We rarely change the 
OS on a given machine.

This doesn't work well in the data centre, but we still have the flat 
namespace to deal with, so have unique host names across the entire 
company. (Something like a half million names or more.)

Why keep it flat? See the previous item - the only constant is change.

You need to consider how your organisation works when you decide on a 
naming scheme. Most large Service Provider organisations (like phone 
companies, ISPs, search engine companies, etc.) that have thousands of 
similar machines generally use the physical location model for naming - 
and this makes sense. The organisation of the equipment tends to 
transcend the organisation of the people in an SP environment. SPs have 
a lot of customers pounding on a lot of gear, with a relatively smaller 
number of people to take care of that gear, and the purpose of most of 
the gear is to directly serve the customer.

In an Enterprise (that is not an SP), it's normal for most of the gear 
to serve the employees, rather than directly serve the customers. This 
can put a different perspective on system naming. A large global company 
that is constantly changing the internal structure may need a more 
flexible naming scheme, especially one that doesn't require altering 
host names based on location or organisational role for every machine 
that gets 'repurposed' on a regular basis. Other large companies are 
quite hierarchical or balkanised, and subdomains and naming schemes that 
contain the life history of the device (:-) may be perfectly appropriate.

It also depends on how you manage your machines. We have a database that 
keeps track of all of the pertinent information for every production 
router/switch and every data centre host in the company. Rather than 
encode the rack/shelf information into the hostname we generally only 
get it down to the room, and let people look up the rest in the 
database. This has been a good compromise for us as a balance between 
host name size, findin hosts, and keeping the number of hostname 
alterations down (when racks move within a data centre). Some of the 
more fixed network gear *is* identified down to the rack, as this gear 
does not move. Our network racks are bolted down to the floor, our 
computer racks are on wheels. The naming schemes reflect the difference 
in permanence of location.

And a personal preference - even if subdomains are used, keep the 
physical hostnames unique. Functional names (like 
'imap.subdomain.domain.com') are less likely to cause you a problem, but 
you can confuse people (and some systems) with duplicate hostnames. It 
gets worse when the subdomains are as cryptic as the hostnames, as in:

bldg5xdm1.lon1.company.com and bldg5xdm1.lon2.company.com

As to the long/short names - there are certain software packages that 
barf on long names, so for one particular database package we had to 
create eight character names (with no hyphens) for the machines, and 
make the CNAMES be our 'standard' names (jsmith-lnx). Ugh. I'm convinced 
that every naming scheme has its own nemesis out there!

- Richard

Brad Knowles wrote:
> 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.
>