On Sat, Aug 21, 2010 at 3:12 PM, Markus Roberts <[email protected]> wrote: > All -- > > Something we'd be interested in getting feedback on; Facter 1.5.8rc2 > includes a patch for three issues around fqdn determination: > > http://projects.puppetlabs.com/issues/1291 > http://projects.puppetlabs.com/issues/2085 > http://projects.puppetlabs.com/issues/2573 > > that change the results significantly enough in some cases (e.g. when > reverse dns name != forward name) that it could be considered a bug: > > http://projects.puppetlabs.com/issues/3898
Reading through [#3898] I believe the issue is absolutely is a bug. We should not rely on address to name resolution because it will quickly become a nightmare to support. Even if we all agree forward and reverse name resolution being in agreement is "correct," in the real world this configuration is uncommon and extremely difficult for staff to "fix" due to the critical nature of name resolution. > Anyone who's testing the release candidate is encouraged to watch for > effects that could arise from these changes, and chime in on the > desirability / undesirability of the behaviours (and bonus points to > anyone who comes up with a simple, obviously correct and easy to > implement resolution that will satisfy everyone in all cases). Here's my proposal. Unfortuantely, we're going to have to draw a line in the sand about what is "proper" system configuration and then assume that configuration. Standardize on uname -p and hostname -f, in that order, as the authoritative fully qualified name of the machine. If a system does not return a fully qualified name from one of these two commands, then the system is improperly configured and it's not a bug in Facter. I agree with #1291 and #2085, Facter should not be executing domainname which is NIS/YP related. The proposed solution should satisfy the author. I disagree and challenge #2573, we should not be doing DNS checks and instead should only rely on the configuration of the system. hostname -f should satisfy the author of #2573 since it returns the expected FQDN. The proposed solution should satisfy the author of #3898 because we would no longer rely on forward matching reverse and instead rely on a "properly" configured system. I think that should satisfy all four issues. What will happen, however, is that anyone who has mis-configured their system such that hostname -f or uname -p both do not return a string with a period *and* they expect facter --fqdn to contain a period, then the proposed solution will "break" facter for them. The solution is for them to properly configure their nodename and hostname and not for us to patch facter again. This is acceptable in my mind, since it's a trivial change to the system hostname rather than a sweeping change to the DNS infrastructure. In fact, executing "hostname foo.bar.com" will be sufficient to fix the problem. In the field, this mis-configuration of hostname -f and uname -p not containing periods is common, but I do not believe it is the majority of the population. I believe the majority have "properly" configured node names. -Jeff -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
