Re: editfiles methodology question

[Michael Grubb]

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.

Regards,
Michael Grubb

P.S.
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
> up
>
> host.example.com.exmample.com
>
> etc.  It's a fragile act dealing with multiple systems without
> normalization.
>
> > 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.
>
> M
>
> 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
> > > 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?
>
>
>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine