RE: editfiles methodology question

[David Masterson]

Mark Burgess wrote:
> On Sun, 2005-11-06 at 14:47 -0800, David Masterson wrote:
>> Mark Burgess wrote:
>>>> Regarding short_hostname, on my system '/bin/hostname' returns the
>>>> FQDN. If I try using $(host), I just get the FQDN. Is that normal?
>>>> That's why I'm using my own variable.
>>> 
>>> This is normal if you have fully qualified names returned by your
>>> hostname lookup, which is not something I recommend.
>> 
>> There is a discussion going on here about the merits of FQDN vs.
>> simple hostname.  Would you care to elaborate on your reasons for
>> not recommending FQDN in hostname lookup? 
>> 
> 
> Just as a matter of principle that you don't mix different kinds of
> information. It is the principle of "normalization" or "normal forms"
> in database theory.  The hostname is one item of information, the
> domain name is another. You should be able to change and manage them
> independently of one another. If you always store the domain name as
> the host identity then you have made it very hard to separate those
> two pieces of information, and have made relative information
> absolute. 
> It is also possible to record information that is incorrect and does
> not match information in DNS this way. Again. normalization says this
> is a bad idea.

Hmm.  I'm in the simple hostname camp, but IT is more in the FQDN camp.  I
need to bring your explanation down a little -- can you give an example of
where FQDN caused problems?  Is it just an esoteric "ease of use" issue or
does it have consequences?

Consider establishing a company policy where all NIS servers are "nis[0-9]".
At the company level, these systems have an FQDN of "nis[0-9].x.com".
However, group NIS servers have an FQDN of "nis[0-9].y.x.com" (where y is the
group).  Obviously, you could have multiple "nis1" hosts in your
organization.  Is this a good company policy?

-- 
David Masterson
VMware, Inc.
Palo Alto, CA