Ask Your Question
0

Hash/Array Fact Stringified When POSTing To Master

asked 2016-03-31 08:38:47 -0500

zsl gravatar image

updated 2016-03-31 08:58:12 -0500

I have a module with customized fact named foo, which is a hash value like:

foo => { "running" => false, "version" => '0.1'}

In the manifest of the module, I need to read foo[running] to find out if foo is running on the client side. Everything works fine on most of my servers , but on some servers, the following error occurs:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: ::foo is not a hash or array when accessing it with running at /etc/puppet/environments/production/manifests/site.pp:72 on node 9.110.85.159
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Puppet environment

Master   : 3.8.2
Agent    : 3.8.2
PuppetDB : 2.3.6

NOTE: This fact only applicable to Windows clients.(confined)

What I already checked:

1.stringify is set as false on all the clients.

2.puppet apply the following code on the problem clients. NO ERROR occured.

if foo[running] {
  notify{ 'Hello': }
}

So at least on the client side the fact could be accessed correctly as hash.

3.The fact was stored as STRING in the yaml file on the Master.(!)

/var/lib/puppet/yaml/facts/myserver.yaml

foo: "{\x22running\x22:false,\x22version\x22:\x220.1\x22}"

Which should be like:

foo:
    running: false
    version: 0.1

4.However the fact data queried from PuppetDB via HTTP API is well formatted JSON.

curl http://puppetdb:8080/v4/nodes/myserver/facts/foo
[ {
  "value" : {
    "running" : false,
    "version" : "0.1"
  },
  "name" : "foo",
  "environment" : "production",
  "certname" : "myserver"
} ]

I think the problem is when the client try to retrieve catalog from master, the values in fact data it POSTs are somehow stringified. But if so,

  1. How possible? (with stringify = false in puppet.conf)
  2. why the data from PuppetDB is standard JSON instead of string?
  3. Why only a few of servers have this problem?

Does anyone have any idea HOW I can find the real cause, please?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2016-05-01 22:59:38 -0500

zsl gravatar image

I'm here to eat my own dog food.

The reason is very simple and stupid. The date time on the client side is not accurate. If the datetime on the client side is just one hour before or after the datetime on the server side, this error will not happen.

I know SSL authentication requires the time accuracy. But the client should prompt an more obvious error instead of stringifying the facts...

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2016-03-31 08:38:47 -0500

Seen: 2,207 times

Last updated: May 01 '16