I've been tearing my hair out since 1am this morning trying to get the puppet server and client to communicate.
The latest chapter in this epic saga has this coming up on the client each time I run puppetd:
Could not prepare for execution: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key
I know it's not a client issue because I've re-imaged the client, and used a default standard puppet.conf generated with --genconf.
On the server side, I've removed the puppetmaster rpm, cleared all the directories, reinstalled the rpm and and regenerated a default puppet.conf with puppetmasterd --genconf. What is quite disconcerting is that puppet can't create it's own directories in a lot of cases...
... which leaves me wondering what else is screwed up. Yes, I am running as root. Anyway, after manually creating /var/puppet/run and chowning it to puppet, puppetmaster starts. I don't know where else to look. As said, cleared all files on server, reinstalled, re-imaged client. What am I missing? Puppet version is 0.25rc1.
Douglas Garstang wrote:
> I've been tearing my hair out since 1am this morning trying to get the
> puppet server and client to communicate.
> The latest chapter in this epic saga has this coming up on the client
> each time I run puppetd:
> Could not prepare for execution: Retrieved certificate does not match
> private key; please remove certificate from server and regenerate it
> with the current key
> I know it's not a client issue because I've re-imaged the client, and
> used a default standard puppet.conf generated with --genconf.
> On the server side, I've removed the puppetmaster rpm, cleared all the
> directories, reinstalled the rpm and and regenerated a default
> puppet.conf with puppetmasterd --genconf. What is quite disconcerting
> is that puppet can't create it's own directories in a lot of cases...
> ... which leaves me wondering what else is screwed up. Yes, I am
> running as root. Anyway, after manually creating /var/puppet/run and
> chowning it to puppet, puppetmaster starts. I don't know where else to
> look. As said, cleared all files on server, reinstalled, re-imaged
> client. What am I missing? Puppet version is 0.25rc1.
> Doug.
Depending on how you removed the RPM on the master, you may have SSL certificates still hanging out under /var/lib/puppet/ssl. That's why the certificate it serves doesn't match the new private key.
> Douglas Garstang wrote:
>> I've been tearing my hair out since 1am this morning trying to get the
>> puppet server and client to communicate.
>> The latest chapter in this epic saga has this coming up on the client
>> each time I run puppetd:
>> Could not prepare for execution: Retrieved certificate does not match
>> private key; please remove certificate from server and regenerate it
>> with the current key
>> I know it's not a client issue because I've re-imaged the client, and
>> used a default standard puppet.conf generated with --genconf.
>> On the server side, I've removed the puppetmaster rpm, cleared all the
>> directories, reinstalled the rpm and and regenerated a default
>> puppet.conf with puppetmasterd --genconf. What is quite disconcerting
>> is that puppet can't create it's own directories in a lot of cases...
>> ... which leaves me wondering what else is screwed up. Yes, I am
>> running as root. Anyway, after manually creating /var/puppet/run and
>> chowning it to puppet, puppetmaster starts. I don't know where else to
>> look. As said, cleared all files on server, reinstalled, re-imaged
>> client. What am I missing? Puppet version is 0.25rc1.
>> Doug.
> Depending on how you removed the RPM on the master, you may have SSL
> certificates still hanging out under /var/lib/puppet/ssl. That's why the
> certificate it serves doesn't match the new private key.
Oh, I also found that I get this error on the client when the server
isn't even running.
Huh? I mean, I have a cleanly installed system, with a genconf
generated puppet.conf and it complains about server keys being wrong,
when the server isn't up. Something is seriously screwed here.
On Tue, Oct 13, 2009 at 12:24 PM, Douglas Garstang
<doug.garst...@gmail.com> wrote:
> I removed /var/lib/puppet too.
> On Tue, Oct 13, 2009 at 11:31 AM, Joe McDonagh
> <joseph.e.mcdon...@gmail.com> wrote:
>> Douglas Garstang wrote:
>>> I've been tearing my hair out since 1am this morning trying to get the
>>> puppet server and client to communicate.
>>> The latest chapter in this epic saga has this coming up on the client
>>> each time I run puppetd:
>>> Could not prepare for execution: Retrieved certificate does not match
>>> private key; please remove certificate from server and regenerate it
>>> with the current key
>>> I know it's not a client issue because I've re-imaged the client, and
>>> used a default standard puppet.conf generated with --genconf.
>>> On the server side, I've removed the puppetmaster rpm, cleared all the
>>> directories, reinstalled the rpm and and regenerated a default
>>> puppet.conf with puppetmasterd --genconf. What is quite disconcerting
>>> is that puppet can't create it's own directories in a lot of cases...
>>> ... which leaves me wondering what else is screwed up. Yes, I am
>>> running as root. Anyway, after manually creating /var/puppet/run and
>>> chowning it to puppet, puppetmaster starts. I don't know where else to
>>> look. As said, cleared all files on server, reinstalled, re-imaged
>>> client. What am I missing? Puppet version is 0.25rc1.
>>> Doug.
>> Depending on how you removed the RPM on the master, you may have SSL
>> certificates still hanging out under /var/lib/puppet/ssl. That's why the
>> certificate it serves doesn't match the new private key.
Can you skip generating the puppet.conf with genconfig and just use the RPM installed file?
Can you also show use a --trace --debug --verbose run from the server and the client. I'd like to see the permissions error you showed before and the current server key error. I've got a ticket we couldn't reproduce that is similar at:
So, I just removed the puppet RPM on the client, blew away
/etc/puppet/ssl, reinstalled it, and ran the client with the default
puppet.conf. The problem did not occur. Thinking that it was the
genconf generated puppet.conf causing the problem, I removed that and
used the standard puppet.conf. The problem still did not occur. I know
I removed /etc/puppet/ssl once before, so I'm at a loss now.
To add to my frustration, I set autosign = true on the server and the
client is still complaining "notice: Did not receive certificate".
*sigh*
Doug.
So, it seems that when I use the default puppet.conf that comes out of
the RPM, this error does not occur.
On Tue, Oct 13, 2009 at 2:47 PM, James Turnbull <ja...@lovedthanlost.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Douglas
> Can you skip generating the puppet.conf with genconfig and just use
> the RPM installed file?
> Can you also show use a --trace --debug --verbose run from the
> server and the client. I'd like to see the permissions error you
> showed before and the current server key error. I've got a ticket
> we couldn't reproduce that is similar at:
2009/10/14 Douglas Garstang <doug.garst...@gmail.com>:
> So, I just removed the puppet RPM on the client, blew away > /etc/puppet/ssl, reinstalled it, and ran the client with the default > puppet.conf. The problem did not occur. Thinking that it was the > genconf generated puppet.conf causing the problem, I removed that and > used the standard puppet.conf. The problem still did not occur. I know > I removed /etc/puppet/ssl once before, so I'm at a loss now.
Can you please send me a link to the --genconfig'ed puppet.conf - pastie or something like that. Maybe an issue there.
Also the puppet.conf bundled with the RPM is written by the downstream package maintainers (Todd?) - perhaps there is an issue there also? Can you pastie that also?
On Tue, Oct 13, 2009 at 4:25 PM, James Turnbull <ja...@lovedthanlost.net> wrote:
> 2009/10/14 Douglas Garstang <doug.garst...@gmail.com>:
>> So, I just removed the puppet RPM on the client, blew away
>> /etc/puppet/ssl, reinstalled it, and ran the client with the default
>> puppet.conf. The problem did not occur. Thinking that it was the
>> genconf generated puppet.conf causing the problem, I removed that and
>> used the standard puppet.conf. The problem still did not occur. I know
>> I removed /etc/puppet/ssl once before, so I'm at a loss now.
> Can you please send me a link to the --genconfig'ed puppet.conf -
> pastie or something like that. Maybe an issue there.
> Also the puppet.conf bundled with the RPM is written by the downstream
> package maintainers (Todd?) - perhaps there is an issue there also?
> Can you pastie that also?
James Turnbull wrote: > Also the puppet.conf bundled with the RPM is written by the > downstream package maintainers (Todd?) - perhaps there is an issue > there also? Can you pastie that also?
We ship the puppet.conf file from conf/redhat in the puppet tarball in the Fedora/EPEL packages, as well as the packages I've put up on my fedorapeople.org space. So the package should function as well (or as unwell) as if it was installed from source. :)
It still couldn't hurt to see the puppet.conf to be sure it's alright.
I thought one of the issues reported with 0.25.x involved ssl certs and setting up puppetmaster and clients from scratch with 0.25. But that's just based on a hazy memory, so I could easily be way off.
-- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An idea is not responsible for the people who believe in it. -- Anonymous
I currently see this error on around 30% of our EC2 nodes since moving to 0.25. We also use the rpm's provided for both client and master. The fix is for us to log on to the EC2 node, remove the cert, run a puppetca --clean on the master for the hostname, and then start puppet again on the client.
I haven't had time to figure out was going on yet, but it feels like the first poll is somehow generating a bad key.
> James Turnbull wrote: >> Also the puppet.conf bundled with the RPM is written by the >> downstream package maintainers (Todd?) - perhaps there is an issue >> there also? Can you pastie that also?
> We ship the puppet.conf file from conf/redhat in the puppet tarball in > the Fedora/EPEL packages, as well as the packages I've put up on my > fedorapeople.org space. So the package should function as well (or as > unwell) as if it was installed from source. :)
> It still couldn't hurt to see the puppet.conf to be sure it's alright.
> I thought one of the issues reported with 0.25.x involved ssl certs > and setting up puppetmaster and clients from scratch with 0.25. But > that's just based on a hazy memory, so I could easily be way off.
> -- > Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > An idea is not responsible for the people who believe in it. > -- Anonymous
> I currently see this error on around 30% of our EC2 nodes since moving > to 0.25. We also use the rpm's provided for both client and master. > The fix is for us to log on to the EC2 node, remove the cert, run a > puppetca --clean on the master for the hostname, and then start puppet > again on the client.
> I haven't had time to figure out was going on yet, but it feels like > the first poll is somehow generating a bad key.
Have you logged a ticket?
Could I ask you and/or Douglas to please log one with the client and server logs showing the error (please run Puppet with --trace - --verbose --debug).
>> I currently see this error on around 30% of our EC2 nodes since moving >> to 0.25. We also use the rpm's provided for both client and master. >> The fix is for us to log on to the EC2 node, remove the cert, run a >> puppetca --clean on the master for the hostname, and then start puppet >> again on the client.
>> I haven't had time to figure out was going on yet, but it feels like >> the first poll is somehow generating a bad key.
> Have you logged a ticket?
> Could I ask you and/or Douglas to please log one with the client and > server logs showing the error (please run Puppet with --trace > - --verbose --debug).
This issue seems to still manifest itself in 0.25.1. And I think I can easly reproduce it. Shall I post the details (new ticket on redmine) or it's already fixed? Redmine doesn't return anything if I search for "Retrieved certificate does not match private key".
The reason for this is the way a client retrieves its signed certificate from the server..
Silviu
PS sorry for replying to such an old post, but since it's a bug I think it's excusable...
>> I currently see this error on around 30% of our EC2 nodes since moving
>> to 0.25. We also use the rpm's provided for both client and master.
>> The fix is for us to log on to the EC2 node, remove the cert, run a
>> puppetca --clean on the master for the hostname, and then start puppet
>> again on the client.
>> I haven't had time to figure out was going on yet, but it feels like
>> the first poll is somehow generating a bad key.
> Have you logged a ticket?
> Could I ask you and/or Douglas to please log one with the client and
> server logs showing the error (please run Puppet with --trace
> - --verbose --debug).
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com
> To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en > -~----------~----~----~----~------~----~------~--~---
