Certificate problems.

[llo...@oreillyauto.com]

I'm setting up a dev / test environment using a couple of Ubuntu 12.04 VMs.

I have puppet installed on one of them, and am trying to get it to sync against itself to get certain things in place to distribute with the nodes.

However, I am having some issues.

# puppet agent --test
info: Creating a new SSL key for puppet-local-master
err: Could not request certificate: getaddrinfo: Name or service not known
Exiting; failed to retrieve certificate and waitforcert is disabled

I've tried a few things, default hostname, random ones, but I continually have getaddrinfo related errors.

What's the best way to get around this?  Changes on my DNS server will not be an option for me, but can do pretty much anything else as long as it can be done locally.

[llo...@oreillyauto.com]

Just as an update, I found a workaround by setting certname to the IP, but I was still wondering if this is the best solution when there isn't a "real" hostname on the system(s)?

[catshirt]

quite new with puppet myself so take this for what it's worth;

if you didn't configure puppet so that it points to the correct server, it will by default look for the machine named `puppet`. presumably, if you're not modifying DNS, you'll need to reconfigure your agent to connect to the correct master (itself). you can do this either in puppet.conf, or by passing the --server option to puppet agent. your error suggests it can't find the server, so it would seem strange to me that setting certname fixed it.

another option besides using the master as a agent to itself, would be to version your master configuration in git, and set up a post-receive hook to re-apply the master configuration.

[Jan Ivar Beddari]

On 06. juli 2012 22:17, llo...@oreillyauto.com wrote:
> Just as an update, I found a workaround by setting certname to the IP,
> but I was still wondering if this is the best solution when there isn't
> a "real" hostname on the system(s)?

echo "192.168.1.1 puppet" | sudo tee -a /etc/hosts

and read
http://docs.puppetlabs.com/guides/setting_up.html#configure-dns-optional

best,
Jan Ivar Beddari

--
http://www.uib.no/personer/Jan.Ivar.Beddari

[jcbollinger]

On Friday, July 6, 2012 3:58:48 PM UTC-5, catshirt wrote:

another option besides using the master as a agent to itself, would be to version your master configuration in git, and set up a post-receive hook to re-apply the master configuration.

Such a setup is possible, but it discards the state maintenance that Puppet normally performs.  That is, if a resource managed by Puppet is changed, it won't be put back to its target state until the next time a manifest update is committed (possibly a long time), or the agent is run manually.


John

[jcbollinger]

On Friday, July 6, 2012 3:17:15 PM UTC-5, llo...@oreillyauto.com wrote:

Just as an update, I found a workaround by setting certname to the IP, but I was still wondering if this is the best solution when there isn't a "real" hostname on the system(s)?

It is not the best solution.  In fact, it's quite a bad solution if there is any chance the machine's IP will ever change (e.g. if it gets its IP number via DHCP, or if it might ever be moved to a different network).  Setting a non-default certname might conceivably prove to be appropriate for you, but I haven't yet heard anything to make me think so.

If the machine is its own source of truth for its host name, then setting the server parameter to whatever host name you have chosen should be fine.  Do verify that the machine can resolve its own name, but that's not normally a problem.  Alternatively, use the default server name ("puppet") and in /etc/hosts add "puppet" as an alias for 127.0.0.1.

Since you have already set up SSL certificates, however, you will need to clear those out to change certnames and servers.  To do so, shut down the master and agent, then completely remove directory /var/lib/puppet/ssl.


John