bootstrap aws instance - set server address in instance puppet.conf?

[Leej]

Hello, new user here. I'm trying to bootstrap an aws instance and need to change the server setting in puppet.conf on the client/instance that is created. Is there anyway to do this beyond modifying hosts post-hoc?

puppet node_aws bootstrap --image ami-e1e8d395 --keyname mykey --login ubuntu --keyfile ~mykeyfile.pem --puppetagent-certname aws_server_test --region=eu-west-1 --type t1.micro -g webserver

This provisions an instance but fails to register a cert request on the puppetmaster with :

notice: Puppet is now installed on: blahblah.eu-west-1.compute.amazonaws.com
notice: No classification method selected
notice: Signing certificate ...
err: Signing certificate ... Failed
err: Signing certificate error: Could not render to pson: getaddrinfo: Name or service not known

Checking the instances puppet.conf shows that the server config variable is set to "puppet" which I want to change to "myserver.somewhere.com". Now I dont know if this behaviour is a bug, I would have thought that since I'm running puppet from the master server, bootstrapping should be able to update the server variable correctly or there should at least be a command line option.

I know I can run a script at somepoint and modify my hosts files but I'm trying to keep things automated and simple. What am I missing?

I should also note, if I ssh into the created instance I can modify the puppet.conf file with the correct server name and a certificate request is issued which I can then sign.

Any help.best practices greatly appreciated - lj.

[Leej]

And 5 minutes later I read the man page docs.puppetlabs.com/pe/2.0/cloudprovisioner_man_node_aws.html "Note that any configuration parameter that's valid in the configuration file is also a valid long argument, although it may or may not be relevant to the present action. For example, server is a valid configuration parameter, so you can specify --server <servername> as an argument.".

I would normally feel really stupid, but I'm just too happy to have found that :)

[Leej]

So I've cracked the initial problem and I can deploy an instance and auto configure puppet but I am still missing something, possibly a conceptual misunderstanding on my part.

I spin up an aws instance with :

puppet node_aws bootstrap --image ami-e1e8d395 --keyname puppet --login ubuntu --keyfile ~puppet.pem --puppetagent-certname new_certname_1 --region=eu-west-1 --type t1.micro -g webserver --server mypuppetserver.somewhere.com

This fails with :

notice: Waiting for SSH response ... Done
notice: Installing Puppet ...

notice: Puppet is now installed on: blahblah.eu-west-1.compute.amazonaws.com
notice: No classification method selected
notice: Signing certificate ...
err: Signing certificate ... Failed

err: Signing certificate error: Could not render to pson: The certificate retrieved from the master does not match the agent's private key.
Certificate fingerprint: 35:39:B7:DD:19:0E:7A:D6:07:AE:6D:64:FF:2E:92:37
To fix this, remove the certificate from both the master and the agent and then start a puppet run, which will automatically regenerate a certficate.
On the master:
  puppet cert clean mypuppetserver.somewhere.com
On the agent:
  rm -f /home/lj/.puppet/ssl/certs/mypuppetserver.somewhere.com.pem
  puppet agent -t

However if I sign the certificate by hand on the puppet server :

sudo puppetca -s new_certname_1

My client then (eventually) will update via puppet, so things are *almost* working, although the error is misleading.

So here are my questions.

1) I obviously want to maintain a secure install so I want to sign the certificates. Should node_aws bootstrap be signing the certificates automatically (as it seems to be attempting to do)? Is it possible to create a certificate before bootstrapping the instance so that there is a certificate ready and waiting for the client?

2) I dont know the ip address or have a fqdn for the instances I am spinning up. I want to put some files on my clients. In fileserver.conf I am using the cert_name to control access e.g.

[files]
  path /etc/puppet/files
  allow new_certname_1

I was surprised that this worked.

Now heres where my conceptual understanding is failing me - since it seems every certname has to be unique (e.g. I cant just create a group controlled by the certificate name) how can I restrict access to the fileserver when provisioning new instances without manually modifying the fileserver.conf?

3) I should also ask - does a client need to be authenticated via its certificate before it will be given access to the fileserver? If so I assume I could then just use * since the certification requirement would reject uncertified clients. Sorry this is possibly a stupid question but it is not clear from the documentation but if so my second question is moot.

[Martijn]

Here's another option for people who are not using Puppet Cloud Provisioner, but for example EC2's autoscaling or launching test-instances by hand.:

Ubuntu and Amazon Linux images include a tool called CloudInit, which makes it easy to perform bootstrapping tasks on a new instance. It's built into the official images.

You provide scripts in the 'user-data' metadata that you enter when you launch an instance. CloudInit takes that input and runs it. It's quite versatile, supporting various formats such as shell-scripts, cloud-config yaml, upstart jobs, content downloaded from URLs, compressed and mime-multipart content, etc. See https://help.ubuntu.com/community/CloudInit for docs and http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/examples/ for some examples.

We enter something like the following in the user-data metadata to bootstrap our Puppet nodes. The %i is replaced with the instance-id by Cloud-Init, to generate a unique certname. That's all that's needed to bootstrap from a default Ubuntu image to a puppet node.

#cloud-config
apt_update: true
apt_upgrade: true
packages:
- puppet
puppet:
  conf:
    agent:
      server: "puppet.example.com"
      certname: "%i.web.cluster1.ec2"
      pluginsync: "true"

Regards, Martijn Heemels

Op maandag 2 juli 2012 22:58:28 UTC+2 schreef Leej het volgende:

[jblaine]

Having the same problem as quoted below. I'm even using autosign for the time-being while trying to solve this. Leej, did you solve this?