RE: editfiles methodology question

[Martin, Jason H]

I should add that I'm not suggesting that hostname should return both
values, just that one has to take both values into account whenever
specifying a machine.

-Jason Martin

> -----Original Message-----
> From: Martin, Jason H 
> Sent: Monday, November 07, 2005 11:15 AM
> To: help-cfengine@gnu.org
> Subject: RE: editfiles methodology question
> 
> 
> A hostname is not a unique key on its own though. A hostname 
> is only unique within a domain, so you really need a 
> 'composite key' consisting of hostname and domainname 
> together to get a unique value. So, using the database theory 
> analogy, one cannot designate a hostname as a primary/unique 
> key in the table of hosts.
> 
> -Jason Martin
> 
> > -----Original Message-----
> > From:
> > help-cfengine-bounces+jason.h.martin=cingular.com@gnu.org
> > [mailto:help-cfengine-bounces+jason.h.martin=cingular.com@gnu.
> > org] On Behalf Of David Masterson
> > Sent: Monday, November 07, 2005 11:08 AM
> > To: Mark Burgess
> > Cc: help-cfengine@gnu.org
> > Subject: RE: editfiles methodology question
> > 
> > 
> > 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
> > 
> > 
> > _______________________________________________
> > Help-cfengine mailing list
> > Help-cfengine@gnu.org
> > http://lists.gnu.org/mailman/listinfo/help-> cfengine
> > 
>