The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
installing puppet with cloud provisioner creates unusable certificate environment
|Status:||Needs More Information||Start date:||11/21/2011|
|Branch:||Affected PE version:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
This ticket may be automatically exported to the ENTERPRISE project on JIRA using the button below:
In bootstrapping an EC2 image using cloud provisioner the certificate generation leaves the host in a state that it cannot talk to itself as a puppet client.
$ puppet node bootstrap --image ami-2342a94a --type t1.micro --keypair ec2-keypair --keyfile ~/.ssh/ec2-keypair --login root
everything goes fine and puppet is installed.
Once logged in however running puppetmasterd and configuring an /etc/hosts entry for ‘puppet’ on localhost (
ralsh host localhost host_aliases=puppet)
you get the following error:
info: Retrieving plugin err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: hostname not match with the server certificate err: /File[/var/lib/puppet/lib]: Could not evaluate: hostname not match with the server certificate Could not retrieve file metadata for puppet://puppet/plugins: hostname not match with the server certificate err: Could not retrieve catalog from remote server: hostname not match with the server certificate warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run err: Could not send report: hostname not match with the server certificate
[root@domU-12-31-39-0A-24-5D ~]# getent hosts puppet 127.0.0.1 localhost localhost.localdomain puppet
#1 Updated by Daniel Pittman over 2 years ago
- Description updated (diff)
- Category set to install
- Status changed from Unreviewed to Needs More Information
Hi. I suspect this is unrelated to the cloud process, and actually caused by a bug where we stopped adding aliases (notably,
puppet) to a new master when we created the certificate. That was introduced as part of the CVE remediation process for an SSL vulnerability we had.
Can you please confirm the exact version of the system – cloud provisioner, and the version of Puppet on the bootstrapped master – that you were using, to help identify if that is the case?
Can you also give us the text dump of the server certificate that doesn’t work?
That would be awesome.