help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: editfiles methodology question


From: Martin, Jason H
Subject: RE: editfiles methodology question
Date: Mon, 7 Nov 2005 11:15:21 -0800

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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]