[colug-432] Puppet Foreman default environment

Rick Hornsby richardjhornsby at gmail.com
Thu May 14 10:57:50 EDT 2015


Still teaching myself puppet and starting to poke around in Foreman.  Primarily I'm using Foreman as an ENC rather than a full-on provisioning system.

I have to be missing something stupidly obvious, but a few hours of digging through Google & documentation hasn't gotten me anywhere.

I'm bringing up new VMs using vagrant puppet provisioning.  From the Vagrantfile:

  config.vm.provision "shell", inline: "sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm"
  config.vm.provision "shell", inline: "sudo sudo yum -y install puppet"

  config.vm.provision "puppet_server" do |puppet|
    puppet.puppet_server = "puppet.ktzr.local"
    puppet.options = "--environment=dev --verbose"
  end


I'm running into trouble with the environment.  A puppet agent run insists that the node's environment is production:  

	==> default: Warning: Local environment: "dev" doesn't match server specified environment "production", restarting agent run with environment "production"

The puppet documentation seems to indicate that this environment setting is coming from the ENC - Foreman.  I can go into Foreman after the node shows up and manually change the environment from production to dev. 

	hammer host update --name web01.ktzr.local --environment dev

Then the agent is okay with being dev, sort of.

Is there a way to tell Foreman the default environment is something other than "production", that when a new host is registered to make it land in an environment other than production?

A second, but related question:

Subsequent runs of puppet agent either require the environment flag to always be provided, or a change to the /etc/puppet/puppet.conf file, otherwise after setting the host to the correct environment in the ENC this:

	Warning: Local environment: "production" doesn't match server specified node environment "dev", switching agent to "dev".

Related to that, would it make sense to have the client's puppet.conf file managed by the puppet master?  The problem I see there is that if somehow it gets screwed up, puppet is now effectively broken for whatever hosts took the bad change.

thanks
-rj


More information about the colug-432 mailing list