Puppet agent doesn't properly get certificate ubuntu client centos puppetmaster
|Affected Puppet version:||Branch:|
I have a CentOS 5.8 puppetmaster running: puppet: 2.7.12 ruby: 1.8.5 facter: 1.6.6 kernel: 2.6.18-274.18.1.el5xen
And a Ubuntu 10.04.4 client running: puppet: 2.7.12 ruby: 1.8.7 facter: 1.6.6 kernel: 2.6.32-343-ec2
When I try to connect for the first time. (I have this server in autosign and sites). This is what I get:
Mar 22 21:14:10 ip-10-140-2-112 puppet-agent: Reopening log files Mar 22 21:14:10 ip-10-140-2-112 puppet-agent: Could not request certificate: getaddrinfo: Name or service not known Mar 22 21:14:23 ip-10-140-2-112 puppet-agent: Reopening log files Mar 22 21:14:26 ip-10-140-2-112 puppet-agent: Could not request certificate: Could not write /var/lib/puppet/ssl/private_keys/myserver.com.pem to privatekeydir: Invalid group: 0
The directory /var/lib/puppet/ssl is owned by puppet, so perms are good. I have tried this with more than one client. I tried delete everything in /var/lib/puppet/ssl and get the same result.
From a Centos client running 2.7.12 it works fine.
Let me know if you need any more info.
#1 Updated by Stefan Schulte over 1 year ago
- Status changed from Unreviewed to Needs More Information
- Assignee set to Banio Carpenter
puppet.conf on your agent will probably help. The first error I see is
Could not request certificate: getaddrinfo: Name or service not known
This is most likely because you have not set a server in
/etc/puppet/puppet.conf on your node. By default the agent is trying to contact a server
puppet which might be incorrect in your environment. You can check the config by running
# puppet agent --configprint server puppet
The second error might be related to #4964. Can you please run
# ls -ld /var /var/lib /var/lib/puppet /var/lib/puppet/ssl # getent passwd root # getent group 0
#2 Updated by Banio Carpenter over 1 year ago
The issue is not that the puppetmaster server isn’t set. Here is my puppet.conf:
# cat /etc/puppet/puppet.conf [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=/lib/facter pluginsync=true templatedir=/templates [agent] server=puppetmaster.int.mydomain.com
And for good measure, here is the server print out:
# puppet agent --configprint server puppetmaster.int.mydomain.com
Here are the perms:
# ls -ld /var /var/lib /var/lib/puppet /var/lib/puppet/ssl /var/lib/puppet/ssl/private_keys drwxr-xr-x 13 root root 4096 2012-02-24 21:07 /var/ drwxr-xr-x 25 root root 4096 2012-03-06 18:34 /var/lib/ drwxr-x--- 9 puppet puppet 4096 2012-03-06 18:34 /var/lib/puppet/ drwxrwx--x 7 puppet root 4096 2012-03-28 21:15 /var/lib/puppet/ssl/ drwxr-x--- 2 puppet root 4096 2012-03-28 21:15 /var/lib/puppet/ssl/private_keys/
here are the getent:
# getent passwd root root:x:0:0:root:/root:/bin/bash # getent group 0 root:x:0:
So root does exist and the group 0 does exist. All the necessary directories appear to have the needed permissions for traversal and creation by the puppet user.
#3 Updated by Banio Carpenter over 1 year ago
I figured out that the very first “Name or service not known” error is just from the agent running on startup before the puppet.conf gets changed, so we can ignore that part of my initial post. Subsequent executions only produce this error:
# puppetd -t info: Creating a new SSL key for myserver.com err: Could not request certificate: Could not write /var/lib/puppet/ssl/private_keys/myserver.com.pem to privatekeydir: Invalid group: 0 Exiting; failed to retrieve certificate and waitforcert is disabled
puppet is not able to create /var/lib/puppet/ssl/private_keys/myserver.com.pem for some reason.
#4 Updated by Stefan Schulte over 1 year ago
If puppet runs for the first time and you do not have your final
puppet.conf in place puppet might first create the SSL Key in
/etc/puppet/ssl. And I am not sure what happens if puppet creates a key but is not able to send the certificate request. But you said that you tried to remove
/var/lib/puppet/ssl (so the client will create a fresh certificate) with no effect.
So let’s concentrate on
Invalid group: 0 first. I’d like to now where the error is raised so can you please run
# puppet agent --test --trace
I suspect that the following may not work as expected on your system:
# irb irb(main):001:0> require 'etc' => true irb(main):002:0> Etc.getgrgid(0).name => "root" irb(main):003:0> Etc.getgrnam('root').gid => 0
#5 Updated by Banio Carpenter over 1 year ago
This has been resolved. It was a stupid mistake on my end. It appears the root “/” permissions were wrong.
drwxr-x—– 23 root root 4096 Apr 4 08:23 /
drwxr-xr-x 23 root root 4096 Apr 4 08:23 /
Everything is working well now. This was accidently done on the original ami, so all new ubuntu instances were affected. Really dumb mistake.
Thanks. Please close out this issue.