Bug #1137

0.24.3: fqdn fact is truncated to short hostname in client/server mode

Added by Derek Whayman about 4 years ago. Updated about 4 years ago.

Status:Closed Start date:
Priority:High Due date:
Assignee:Luke Kanies % Done:

0%
Category:-
Target version:0.24.4
Affected Puppet version:0.25.4 Branch:
Keywords:
Votes: 0

Description

fqdn is correct under facter and local puppet run:

<0> sa_dewha@engpsr0154.intranetdev.barcapdev.com (0 jobs)
 /
  % facter fqdn
engpsr0154.intranetdev.barcapdev.com

class zztest::setup{
    notice "fqdn = $fqdn"
    notice "hostname = $hostname"
}
notice: Scope(Class[zztest::setup]): fqdn = engpsr0154.intranetdev.barcapdev.com
notice: Scope(Class[zztest::setup]): hostname = engpsr0154

When in client/server mode:

notice: Scope(Class[zztest::setup]): fqdn = engpsr0154
notice: Scope(Class[zztest::setup]): hostname = engpsr0154

Somehow the domain portion of the host name is being stripped off.

diff1 (749 Bytes) Derek Whayman, 03/18/2008 09:27 am

diff2 (459 Bytes) Derek Whayman, 03/18/2008 09:28 am

0001-tweak-the-already-applied-patch-in-388cf7c3df7ce26.patch (2.4 kB) Sam Quigley, 03/19/2008 04:35 am

facts_patch_1133_1137.patch (2.6 kB) James Turnbull, 03/20/2008 12:01 pm

History

#1
Updated by Derek Whayman about 4 years ago

Tracked it down to a change in network/handler/master.rb Apply the attached diff1 (i.e. going back to the 0.24.2 code) fixes the fqdn. This problem only manifests itself in client-server mode – I think that section of code is client/server-specific judging from my debug output. Similarly diff2 where we look up the fqdn from facter rather from the hostname fixes it too. I’ll defer to Luke as to how the code should look :–)

Derek

#2
Updated by Chris MacLeod about 4 years ago

This also seems to affect the ‘domain’ fact as well, it is missing it’s value in 0.24.3.

No clue what other facts may be affected.

#3
Updated by Sam Quigley about 4 years ago

the patch just added attempts to maintain the functionality added in 388cf7c3df7ce26e953949ed6fe63d76cbbb3691 — ie, the hostname/domainname/fqdn of the certificate will be used in preference to the hostname/domainname/fqdn reported by facter whenever that makes sense. (I suspect the original patch was essentially correct, and that it just had an ordering bug.) this patch also adds tests which fail when fqdn is being truncated, and which pass when this patch is applied.

#4
Updated by Luke Kanies about 4 years ago

The ticket that caused this is #1133.

#5
Updated by James Turnbull about 4 years ago

  • Status changed from 1 to 2

Okay – I think the attached patch should work – it combines fixes from both johnf and emerose and whaymand. I’ll make a comment in #1133 as well.

Can all please test and respond… Thanks.

#6
Updated by James Turnbull about 4 years ago

Okay the patch fixes part of the problem but not the core issue. See http://pastebin.com/m3a883e6d. So the facts are set in the clientname definition and debugging reports the correct fqdn, hostname, domain, etc. But the domain fact in manifests is blank and the fqdn is truncated. So something must happen after clientname to change the fact values.

#7
Updated by James Turnbull about 4 years ago

Further notes – I can reproduce the error when running the client on the local master but it works correctly when I connect a remote client.

#8
Updated by James Turnbull about 4 years ago

  • Status changed from 2 to 1

bartc has checked a number of clients – all 0.24.3 – and reports differing behaviour between different clients. It is unclear why some clients work and others don’t.

#9
Updated by Luke Kanies about 4 years ago

Marking #1141 as a duplicate (note that there’s a patch attached to it).

#10
Updated by Sam Quigley about 4 years ago

1147 may be relevant here as well

#11
Updated by Luke Kanies about 4 years ago

  • Status changed from 1 to Closed
  • 7 set to fixed

emerose’s patch applied in commit:54bedb2bbae2b84fc8f9df8b95e0a904a4e709f7, and he’s right that #1147 is partially the culprit. I’ll be fixing that next.

#12
Updated by Luke Kanies about 4 years ago

Note that the reason that nodes were behaving differently is that some nodes had cached node information with facts, and some had cached information without facts.

The fix to #1147 means that when a node uploads facts, its cached node value will be considered out of date and will get refreshed.

Please verify this behaviour.

Also available in: Atom PDF