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: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > 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 > > > _______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
