Puppet: System Administration Automated

Support

Ticket #1137 (closed defect: fixed)

Opened 9 months ago

Last modified 9 months ago

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

Reported by: whaymand Assigned to: luke
Priority: high Milestone: 0.24.4
Component: library Version: 0.24.3
Severity: critical Keywords:
Cc: Triage Stage: Needs more info
Attached Patches: Code Complexity: Medium

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.

Attachments

diff1 (0.7 kB) - added by whaymand on 03/18/08 09:27:39.
Backrevving patch
diff2 (459 bytes) - added by whaymand on 03/18/08 09:28:00.
Better patch switching hostname to fqdn
0001-tweak-the-already-applied-patch-in-388cf7c3df7ce26.patch (2.4 kB) - added by emerose on 03/19/08 04:35:47.
yet another patch, with tests
facts_patch_1133_1137.patch (2.6 kB) - added by jamtur01 on 03/20/08 12:01:28.

Change History

03/18/08 09:27:14 changed by whaymand

  • patch changed from None to Code.

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

03/18/08 09:27:39 changed by whaymand

  • attachment diff1 added.

Backrevving patch

03/18/08 09:28:00 changed by whaymand

  • attachment diff2 added.

Better patch switching hostname to fqdn

03/18/08 17:32:04 changed by stick

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.

03/19/08 04:35:47 changed by emerose

  • attachment 0001-tweak-the-already-applied-patch-in-388cf7c3df7ce26.patch added.

yet another patch, with tests

03/19/08 04:40:54 changed by emerose

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.

03/20/08 05:45:29 changed by luke

The ticket that caused this is #1133.

03/20/08 12:01:28 changed by jamtur01

  • attachment facts_patch_1133_1137.patch added.

03/20/08 12:02:43 changed by jamtur01

  • owner changed from community to jamtur01.
  • status changed from new to assigned.
  • complexity changed from Unknown to Medium.
  • stage changed from Unreviewed to Needs more info.

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.

03/20/08 13:51:24 changed by jamtur01

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.

03/20/08 14:25:46 changed by jamtur01

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.

03/20/08 14:57:54 changed by jamtur01

  • owner changed from jamtur01 to luke.
  • status changed from assigned to new.

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.

03/20/08 20:11:22 changed by luke

  • priority changed from normal to high.
  • severity changed from normal to critical.
  • milestone set to 0.24.4.

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

03/21/08 00:41:21 changed by emerose

#1147 may be relevant here as well

03/21/08 05:24:49 changed by luke

  • status changed from new to closed.
  • resolution set to fixed.

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

03/21/08 05:28:50 changed by luke

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.