[Top][All Lists]

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

Re: editfiles methodology question

From: Michael Grubb
Subject: Re: editfiles methodology question
Date: Mon, 7 Nov 2005 14:41:12 -0600

I'm of the opinion that tools should not dictate policy, nor should it force conformity to a particular ideaology.

My question is why does cfengine care if a host name is hosta or hosta.zoneb.zonec? Cfengine should except all three of hosta, hosta.zoneb, and hosta.zoneb.zonec as valid hostnames.
Let the system resolver do what it's meant to do, resolve.
gethostbyname(3) doesn't care if it is a FQDN or UQHN, it resolves as it's configured to resolve, or it doesn't in which case, you code for the failure. This begs the question, why does cfengine care about this? For cfengine to make a distinction requires more code, and more complexity.

In situations where you use a hostname as a key, an unqualified name is broken, due to several previous examples given. Say you have a host named web01, in a couple different departments, that are in different zones. Web01 in zonea may not need to be treated the same as web01 in zoneb. How does cfengine solve this? I certainly hope that it doesn't require two different cfengine servers, or even one server that resides in both zones. In my organization we have two main zones that are used, but they are all managed by the
same people.  Right or wrong, that's the way it is.

If cfengine cares if you use hosta.zoneb.zonec it is broken, it should defer ALL these lookups to the system resolver, and internally track IP addresses, not hostnames. So long as the system resolver will resolve hosta, hosta.zoneb, and hosta.zoneb.zonec to the same IP address, it shouldn't matter what I use where.

The fact of the matter is, any tool that dictates rather than drives policy and/or convention is broken.

That being said, ultimately this Mark Burgess's software and he can do any damn thing he likes, and is right in doing so.
If we don't like it, we have two choices, deal with it, or fork.

That's just my opinion,  I could be wrong.

Michael Grubb

I may have completely missed the mark, here as I have not taken the time or energy to read the code. My comments are based on the contents of this particular thread, and what I construed from cfengine's internals from said thread. So if I'm wrong, I do apologize.

On Nov 7, 2005, at 1:29 PM, Mark Burgess wrote:

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

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

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.


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
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]".
However, group NIS servers have an FQDN of "nis [0-9]" (where y is the
group).  Obviously, you could have multiple "nis1" hosts in your
organization.  Is this a good company policy?

Help-cfengine mailing list

reply via email to

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