I'm setting up a puppetmaster (2.7.6) in ec2 via gems (on rhel6) and I'm running into problems with the cert names and getting the master able to talk to itself.
my puppet.conf looks like this:
[main]
logdir = /var/log/puppet
rundir = /var/run/puppet
vardir = /var/lib/puppet
ssldir = $vardir/ssl
pluginsync = true
environment = production
report = true
certname = master
When I start the puppetmaster process the ssl directory looks like:
ssl/private_keys/master.pem
ssl/crl.pem
ssl/public_keys/master.pem
ssl/ca/ca_crl.pem
ssl/ca/signed/master.pem
ssl/ca/ca_crt.pem
ssl/ca/ca_pub.pem
ssl/ca/ca_key.pem
ssl/certs/ca.pem
ssl/certs/master.pem
I have an /etc/hosts entry on the box to point the 'puppet' hostname to localhost so that I don't have to change the 'server' option.
When I run the agent I get the following:
# puppet agent --test
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: Server hostname 'puppet' did not match server certificate; expected master
err: /File[/var/lib/puppet/lib]: Could not evaluate: Server hostname 'puppet' did not match server certificate; expected master Could not retrieve file metadata for puppet://puppet/plugins: Server hostname 'puppet' did not match server certificate; expected master
err: Could not retrieve catalog from remote server: Server hostname 'puppet' did not match server certificate; expected master
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
err: Could not send report: Server hostname 'puppet' did not match server certificate; expected master
If I specify the certname as the server (with corresponding hosts entry) I get:
# puppet agent --test --server master
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://master/plugins
info: Caching catalog for master
info: Applying configuration version '1321805956'
notice: Finished catalog run in 0.05 seconds
Which is success of a sort, that source error will bite me later when I'm applying manifests. I've tried a couple of other variations with using the ec2 private hostname and gotten mixed results.
I'd like to avoid setting server = 'x' and use dns/hosts to control what 'puppet' resolves to in order to decide which server (plays easier with availability zones, etc)
So after some investigation I figured this one out. Puppet 2.7.6 doesn't set subjectAltNames on the server certificate when it generates that cert for the master (it really doesn't know that it's a master at any point).
There are two ways to correct this:
1. manually generate the certifcate for the master
2. set dns_alt_names in puppet.conf
add
dns_alt_names = puppet
to the master (and the master only) before you run puppet master or puppet (causing the certs to be generated)Now with an /etc/hosts or dns entry connecting to 'puppet' will work just fine.
The other error related to plugins is a bug about having pluginsync enabled but no plugins available to sync.
You have the certname set as master. For the way you are setting it up, either get it working with puppet, or use the host file to set the ip address of master instead of puppet.
You may also want to use a FQDN such as master.example.com or puppet.example.com so you can use dns entries without requiring search domain entries.
One tip for using puppet in EC2 is to assign an ElasticIP to your puppetmaster, and then create a DNS entry for the ElasticIP CNAME and not an A record for the IP.
AWS DNS servers vary their response based on if the query came from within the same EC2 region, or exterior. If the CNAME request comes from within a EC2 region, the AWS DNS servers will respond with the internal IP of the CNAME.
You should use the CNAME in DNS so that when EC2 puppet clients query the AWS DNS servers for the IP of the Puppetmaster, they will receive a response that directs them to the internal IP of the puppetmaster, and not the external IP.