Re: editfiles methodology question

[Mark Burgess]

Michael - cfengine doesn't care and makes no policy on this. 
I don't really care, but I see that using fully qualified names as host
names breaks several principles in CS. You apparently care.

All I will say is that if one makes certain choices one has to live with
the conseqeunces and that might make it harder to do what you want.

Your questions are all explained in the documentation. Cfengine
classifies both qualified and unqualified names, as it understands them.
But the harder you make it for cfengine to distingush between
qualified and unqualifed names, the harder it is to try to do the right
thing when users write ambiguous values. 

You're flogging the wrong horse here. If cfengine is broken, it is not
because of names. This discussion started because someone had defined
the fully qualified name as the hostname and could therefore not find
the unqualified name -- that is because it no longer exists.

M


On Mon, 2005-11-07 at 14:41 -0600, Michael Grubb wrote:
> 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
> >
> >
> 
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine