RE: editfiles methodology question

[Mark Burgess]

I don't think it's such a problem as it used to be, when the hostname
was actually compiled into the kernel :) But even now, you can get into
a mess with double host resolution, e.g. hvaing systems trying to look
up

host.example.com.exmample.com

etc.  It's a fragile act dealing with multiple systems without
normalization. 

>From a coding perspective, domain names are a pain. Because (as we have
battled about before on the list) it is actually impossible to discover
the domain name of a host without an explicit delcaration of it. So code
that tries to append the domain name to hostnames for lookup has to make
an educated guess - which it sometimes gets wrong.

M

On Mon, 2005-11-07 at 11:07 -0800, David Masterson wrote:
> 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?
>