Issue #3898 has been updated by Jeff McCune.
Copying my comments from the mailing list as per request from Rein. 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 -n 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 -n 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 -n 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 ---------------------------------------- Bug #3898: fqdn fact requires reverse PTR matches the forward http://projects.puppetlabs.com/issues/3898 Author: micah - Status: Accepted Priority: Normal Assigned to: Paul Nasrat Category: library Target version: 1.6.0 Keywords: Branch: It seems like the patch applied in #2085 (commit:dca615c98b864d75e2ac5899d98d04a2bd979eba) changes the way the fqdn fact is determined. What it does now is: name = Socket.gethostbyname(Socket.gethostname).first and then it parses that output to pull out the hostname ($1) and then the fqdn $2. The gethostname call seems like the right way to get the hostname (its a much better improvement from parsing the output of the 'hostname' command, which essentially just does that). However, running gethostbyname over that hostname means that the fqdn is looked up by taking the hostname and then doing a DNS resolution of that hostname to get an IP, and then doing a reverse lookup of that IP to end up with the fqdn. That means that if your reverse does not match the forward, then your fqdn fact is going to end up with something different from your hostname fact. For example, if my gethostname() returns "nuthatch", and then gethostbyname does a lookup of that using my configured resolver setup, it will result in the IP 204.13.164.1, and then if you lookup the reverse on that IP, you end up with 'seattle.riseup.net'. So my hostname fact will be set to 'nuthatch', but my fqdn will be set to 'seattle.riseup.net'. This would be a surprise from how it previously worked (hostname --fqdn) which would produce "nuthatch.riseup.net" for the fqdn, and "nuthatch" for the hostname. Looking at hostname --fqdn it seems to use getaddrinfo() for that process. Looking at ruby, it seems like Socket.gethostbyname uses both gethostbyname and getaddrinfo. First it looks up your hostname with getaddrinfo(), then it runs gethostbyname() on the answer it gets from getaddrinfo(). It seems to me that this fact shouldn't be doing doing reverse lookups to get the fqdn, but rather do what hostname -f does, which is something like: <pre> require 'socket' addrinfo = Socket.getaddrinfo(Socket.gethostname, nil, nil, Socket::SOCK_DGRAM, nil, Socket::AI_CANONNAME) af, port, name, addr = addrinfo.first puts "fqdn: " + name </pre> NOTE: i am sure there are better ways to do this in ruby NOTE2: yes, it is better for me to have the reverse match the forward, but that isn't the point here :) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
