3

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.

Felix Frank
  • 3,093
  • 1
  • 16
  • 22
dannyincolor
  • 56
  • 7

2 Answers2

1

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

dannyincolor
  • 56
  • 7
0

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.

jmp242
  • 688
  • 3
  • 15
  • 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))? – dannyincolor Sep 26 '14 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 '14 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. – Felix Frank Sep 28 '14 at 13:07