I am currently running a small puppetmaster + client configuration that is not utilizing Puppet's directory environment feature. My puppet version is 3.6.

I have tried the following:

  1. On the puppetmaster: added environmentpath=$confdir/environments to puppet.conf
  2. On the puppet master: created the necessary paths in $confdir/environments/ (e.g. /etc/puppet/environments/production)
  3. Added my existing modules and manifest (site.pp) to the production environment
  4. Switched to this git branch and ran a test puppet agent -vt on a client

Unfortunately, I am receiving the following error:

Info: Retrieving pluginfacts
Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://puppet/pluginfacts
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://puppet/plugins
Notice: /File[/var/lib/puppet/lib/puppet]: Dependency File[/var/lib/puppet/lib] has failures: true

The puppet run does not fail, but scrolls errors similar to this before completing.

My thought process behind replicating the current configuration (modules and manifests) into the new production environment is that all clients should have their $environment variable set to production by default. Is this flawed logic?

I based my conversion on a Puppet Labs guide.

2 Answers 2


For posterity's sake, here is the fix I found:

I had made two simple mistakes:

  1. I did not restart the puppetmaster (via passenger). This was easily accomplished with service apache2 restart on Debian Wheezy

  2. Upon restarting, I received a stream of new errors indicating issues with reloading puppet. The logfiles containing pertinent information were eventually found in: /var/log/syslog, of all places.

  3. The logs indicated an issue with permissions to /etc/puppet/manifests. It turns out that git deletes empty folders, and as I had migrated my site.pp to /etc/puppet/environments/production/manifests/site.pp, git removed the /etc/puppet/manifests folder which threw errors.

  4. I fixed #3 by adding an empty site.pp to the manifests folder in /etc/puppet


I believe in 3.6 puppet uses directory environments, so don't configure them in puppet.conf, just create the directories under environments. I think you can use: https://docs.puppetlabs.com/puppet/latest/reference/environments_configuring.html

which is subtly different. I also use an ENC, the foreman, so this might be different for you, but you probably need to have site.pp in the global module directory, and not in your environments. We just have our modules in our environments, and site.pp etc are in the global module directory.

  • Does any additional configuration need to be performed on the clients? Or will they pick up the new settings on their next run (assuming they are configured to use an environment that exists, which they are (production))? Sep 26, 2014 at 15:58
  • Not that I know of. That being said, I set up with environments from the get go, so maybe it'll be different. But it should be transparent to the clients if the master is working correctly.
    – jmp242
    Sep 26, 2014 at 16:00
  • 2
    Agents do not need any configuration changes. Note that site.pp outside of directory environments will not work in future versions (perhaps 4.0 even). Each environment should have a site manifest. Sep 28, 2014 at 13:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .