ENC "node.rb --push-facts" leads to client failure "Unable to fetch node definition"

When on puppetmaster host in file /etc/puppetlabs/puppet/puppet.conf I change the line

external_nodes = /etc/puppetlabs/puppet/node.rb


external_nodes = /etc/puppetlabs/puppet/node.rb --push-facts

to make Foreman a non-ENC (as mentioned in “Pushing facts to Foreman when not using the ENC functionality” in the manual), but inventory only for facts and reports, the clients fail with the following output:

puppet agent -t

Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: Find /puppet/v3/node/host.fqdn.de?environment=develop&configured_environment=develop&… resulted in 404 with the message: {“message”:“Not Found: Could not find node host.fqdn.de”,“issue_kind”:“RESOURCE_NOT_FOUND”}
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Could not find node ‘host.fqdn.de’; cannot compile
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Expected outcome:

Only ENC functionality should be disabled, but facts should be seen in Foreman and clients should get their environment from the puppet configuration files.

Foreman and Proxy versions:
Plain install of Foreman 1.17 on Ubuntu 16 Xenial, just followed the quickstart installation Foreman :: Manual

Foreman and Proxy plugin versions:
Plain install, I do not know about plugins.



2018-07-07 13:52:46,327 ERROR [qtp1288767878-64] [puppetserver] Puppet Server Error: Could not find node 'host.fqdn.de'; cannot compile

When I set node_terminus = plain the clients work again, but their facts are not reported to Foreman.

Why does nobody answer? I just followed the manual and the behavior is not that I expect reading the manual. Is the behavior expected? How could I support to solve my requirement, that is:

Push facts to Foreman, but do not use Foreman as ENC.

Thank You

The manual does not say you should use external_nodes = /etc/puppetlabs/puppet/node.rb --push-facts to push facts but not use the ENC.

It says that you can run sudo -u puppet /etc/puppet/node.rb --push-facts , and that will push facts for all hosts who have ever reported to the puppet master.

--push-facts uploads all facts sequentially which have changed since the last run.
--push-facts-parallel uploads all facts in parallel which have changed since the last run. The number of threads is specified by the :threads setting or the number of processors.
--watch-facts runs in the foreground and upload facts based on inotify events, used in conjunction with either –push-facts option.

I think you should either put the call to the script in a cron to run it periodically, or something similar. As far as I know, ‘external_nodes’ will always expect the ENC YAML format, which you will not get by passing --push-facts to the script.

Hope that helped,

Thank You very much! You really helped me to solve this.

Solution for me is:

Leave node_terminus = plain to disable ENC functionality.

Install a Cronjob for user puppet for every full hour to push the facts:

sudo crontab -l -u puppet

0 * * * * /etc/puppetlabs/puppet/node.rb --push-facts

This works :slight_smile:

Including the environment, which was not the case with puppet server 3.8 :slight_smile:

Maybe the manual could include this information, I could create a pull request, but I think maybe it would be better if someone with more knowledge does it.

1 Like

A PR to https://github.com/theforeman/theforeman.org would be greatly appreciated. It’s a great place to contribute :slight_smile:

OK I will do.

I have to admit that I just wondered how the facts came into the old puppet 3.8 server and I searched for and found a cronjob like above (but for user root, which I think is not good regarding security aspect).
I guess I myself set that up, but did not document it easily to find in the puppet.conf. So, few years ago, it looks like I somehow figured that solution out, and even referenced the manual in the cronjob comment, but this time not, so I guess the manual has optimizing potential.