Issue #3898 has been updated by Daniel Pittman.
As requested, my comments edited to a suitable state:
> Standardize on uname -p and hostname -f, in that order, as the
I assume you mean 'uname -n', since the processor probably isn't interesting.
(or we are seeing a SYSV / BSD difference or something.)
> 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 would agree with that, or with using the gethostbyaddr / getaddrinfo methods
which pass through the local NSS stack. Those later are the functions that
the majority of Unix daemons (Apache, Postfix, sendmail, etc) use to determine
the FQDN automatically.
hostname -f is implemented the same way, and by design uses NSS, which means
that the local sysadmin can configure that to do whatever oddness is required
WRT local files, DNS, LDAP, NIS, WINS, or any other name service.
(eg: the suggested approach gets puppet doing the same thing hostname does,
only without depending on a fork/exec and parsing the result of an external
command.)
> 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.
Generally, the hostname on Linux does not contain dots, as it is supposed to
be only the local node name. (eg: uname -n)
Full name stuff comes out of NSS, as used by hostname, etc, and which for most
people means that you are looking at the NSS files module and /etc/hosts.
Daniel
I can't actually speak for the *BSD stack, but I understand they are similar.
----------------------------------------
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.
