Puppet » Facter

I’m not sure if this comment belongs here or if I should open a new issue, but we recently ran into a problem when implementing the dhcp domain-search option on our dhcp server. The more recent dhclients (4.1.x) on Linux and I believe BSD will now include requests for domain-search which results in search value(s) in /etc/resolv.conf that have trailing periods (.).

Facter does not strip these trailing periods from the domain and fqdn values returned. The result is the puppet client in a client/server environment will will suddenly think it’s name has changed and request a new certificate (one that has a trailing dot). The puppetmaster will then refuse to authenticate the host because it doesn’t think the name matches the certificate issued by the puppet ca.

I’ve made a very simple patch that fixes the problem in the facter domain.rb file. I’m attaching the patch. The option mentioned by the original poster to strip the trailing dot should work as well and may be a better solution.

--- /usr/lib/ruby/site_ruby/1.8/facter/domain.rb    2011-10-16 10:36:29.000000000 -0700
+++ /usr/lib/ruby/site_ruby/1.8/facter/domain.rb.new    2012-02-02 16:40:03.890869844 -0800
@@ -36,9 +36,9 @@ Facter.add(:domain) do
       search = nil
       File.open("/etc/resolv.conf") { |file|
         file.each { |line|
-          if line =~ /^\s*domain\s+(\S+)/
+          if line =~ /^\s*domain\s+(\S+)\.+/
             domain = $1
-          elsif line =~ /^\s*search\s+(\S+)/
+          elsif line =~ /^\s*search\s+(\S+)\.+/
             search = $1
           end
         }

I haven’t been able to get the doc signed, however I would like to remove the patch I uploaded as it doesn’t work properly. The original posters suggestion is better, but you must escape the ‘.’ in the regular expression with a backlash… $1.sub(/.$/, ‘’)

From the pull request:

jeffmccune commented 19 hours ago If we strip trailing dots from the domain fact we no longer support fully qualified domains. I don’t think we want to force everyone to an unqualified domain.

As discussed in the ticket, this was rarely possible in any case. Now, rather than having undefined behaviour where some rare set of failures could potentially lead to a fully qualified search path in resolv.conf leading to this fact having a trailing dot, it is always one of the two possible forms.

The only alternative is that we always terminate the name with a ., marking it as fully qualified (and violating the expectations of most users) instead.

There really isn’t an “unqualified name” here either, by the way – this is defined as the DNS domain name of the machine; that isn’t a definition that admits “partial domain names”.