[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
>
- Re: editfiles methodology question, (continued)
RE: editfiles methodology question, David Masterson, 2005/11/06
RE: editfiles methodology question, David Masterson, 2005/11/07
RE: editfiles methodology question,
Martin, Jason H <=
RE: editfiles methodology question, Martin, Jason H, 2005/11/07