Greg
2009-May-21 00:35 UTC
[Puppet Users] Certificate issue for puppetd on same node as puppetmasterd
Hi all, I''m trying to get a puppet daemon to run on the same host as a puppetmaster, and I''m seeing an interesting problem on 0.24.8 on Solaris. One of the rules is to push out a current puppet.conf - heres the rule I''m using: file { puppetconf: path => $operatingsystem ? { solaris => "/etc/opt/csw/puppet/puppet.conf", default => "/etc/puppet/puppet.conf", }, owner => root, group => root, mode => 644, source => [ "puppet:///puppetdaemon/puppet.conf- $hostname", "puppet:///puppetdaemon/puppet.conf- $kernelrelease", "puppet:///puppetdaemon/puppet.conf" ] } Now the issue I am seeing is with the actual file transfer. When it comes to actually update the puppet config file, the messages file shows this: May 21 09:37:50 puppetmaster puppetd[3644]: [ID 702911 daemon.warning] Certificate validation failed; consider using the certname configuration option May 21 09:37:50 puppetmaster puppetd[3644]: [ID 702911 daemon.error] (//Node[default]/puppetdaemon/File[puppetconf]/source) change from {md5}846ec1befda534749269c6ec294bad40 to puppet:///puppetdaemon/puppet.conf-puppetmaster puppet:///puppetdaemon/puppet.conf-5.10 puppet:///puppetdaemon/puppet.conf failed: Certificates were not trusted: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed The weird thing here is that it seems to handle the initial handshakes and perform the rest of the work, its only when it comes to replacing a file... Running the puppetmasterd in debug mode yields this bit of info: debug: Using cached node for puppetmaster.domain.com debug: mount[puppetdaemon]: Describing /puppetdaemon/puppet.conf- puppetmaster for puppetmaster.domain.com debug: Overriding puppetmaster with cert name puppetmaster.domain.com debug: Allowing authenticated client puppetmaster.domain.com(10.1.2.3) access to fileserver.retrieve debug: Using cached node for puppetmaster.domain.com info: mount[puppetdaemon]: Sending /puppetdaemon/puppet.conf- puppetmaster to puppetmaster.domain.com debug: Overriding puppetmaster with cert name puppetmaster.domain.com debug: Allowing authenticated client mplops1prd.domain.com(10.1.2.3) access to fileserver.describe So it appears that the file is being sent to the client, and it is the client that is rejecting the file on the basis of the invalid certificate. Heres the weird thing - its happy with the certificate for everything else... The only other bit I will point out is that both the client and the server appear to be using the same certificate. I have this working without issue at a seperate site using the same configuration (as far as I can tell...) Has anyone seen something like this before? thanks, Greg --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
jeff
2009-May-21 03:25 UTC
[Puppet Users] Re: Certificate issue for puppetd on same node as puppetmasterd
Hey Greg, What a timely email. Just this afternoon I was working on bringing a new .24.8 puppetmaster online in effort to test migrating to using apache/passenger as a frontend. While troubleshooting, I tried running the tried and true puppetmasterd in lieu of the apache/passenger frontend in order to verify that I had indeed set everything up properly, and ran into exactly this. This was attempted by using the new puppetmaster as the puppet client (i.e. there is only one system I''m working with). I mention this only because the only reference I could find to the SSL error message had to do with clocks being out of sync between clients and server. Clearly not the case in my scenario. For completeness, this particular environment is Debian Lenny, running the .24.8 puppet and puppetmaster packages from SID. I must admit it''s a bit un-nerving, as I had always assumed I could spin up a new (or replacement) puppetmaster at anytime, should the need arise. Anyhow, count me as a very interested party to learning how to get this working. Thanks, - Jeff Greg wrote:> Hi all, > > I''m trying to get a puppet daemon to run on the same host as a > puppetmaster, and I''m seeing an interesting problem on 0.24.8 on > Solaris. > > One of the rules is to push out a current puppet.conf - heres the rule > I''m using: > > file { puppetconf: > path => $operatingsystem ? { > solaris => "/etc/opt/csw/puppet/puppet.conf", > default => "/etc/puppet/puppet.conf", > }, > owner => root, > group => root, > mode => 644, > source => [ "puppet:///puppetdaemon/puppet.conf- > $hostname", > "puppet:///puppetdaemon/puppet.conf- > $kernelrelease", > "puppet:///puppetdaemon/puppet.conf" ] > } > > Now the issue I am seeing is with the actual file transfer. When it > comes to actually > update the puppet config file, the messages file shows this: > > May 21 09:37:50 puppetmaster puppetd[3644]: [ID 702911 daemon.warning] > Certificate validation failed; consider using the certname > configuration option > May 21 09:37:50 puppetmaster puppetd[3644]: [ID 702911 daemon.error] > (//Node[default]/puppetdaemon/File[puppetconf]/source) change from > {md5}846ec1befda534749269c6ec294bad40 to puppet:///puppetdaemon/puppet.conf-puppetmaster > puppet:///puppetdaemon/puppet.conf-5.10 puppet:///puppetdaemon/puppet.conf > failed: Certificates were not trusted: SSL_connect returned=1 errno=0 > state=SSLv3 read server certificate B: certificate verify failed > > The weird thing here is that it seems to handle the initial handshakes > and perform the rest of the work, > its only when it comes to replacing a file... Running the > puppetmasterd in debug mode yields this bit of info: > > debug: Using cached node for puppetmaster.domain.com > debug: mount[puppetdaemon]: Describing /puppetdaemon/puppet.conf- > puppetmaster for puppetmaster.domain.com > debug: Overriding puppetmaster with cert name puppetmaster.domain.com > debug: Allowing authenticated client puppetmaster.domain.com(10.1.2.3) > access to fileserver.retrieve > debug: Using cached node for puppetmaster.domain.com > info: mount[puppetdaemon]: Sending /puppetdaemon/puppet.conf- > puppetmaster to puppetmaster.domain.com > debug: Overriding puppetmaster with cert name puppetmaster.domain.com > debug: Allowing authenticated client mplops1prd.domain.com(10.1.2.3) > access to fileserver.describe > > So it appears that the file is being sent to the client, and it is the > client that is rejecting the file on the basis of the invalid > certificate. Heres the weird thing - its happy with the certificate > for everything else... > > The only other bit I will point out is that both the client and the > server appear to be using the same > certificate. I have this working without issue at a seperate site > using the same configuration (as far > as I can tell...) > > Has anyone seen something like this before? > > thanks, > > Greg > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Ohad Levy
2009-May-21 04:02 UTC
[Puppet Users] Re: Certificate issue for puppetd on same node as puppetmasterd
comment out the SSLCARevocationFile option in apache. cheers, Ohad On Thu, May 21, 2009 at 11:25 AM, jeff <jeff.adams@kw.com> wrote:> > Hey Greg, > > What a timely email. Just this afternoon I was working on bringing a new > .24.8 puppetmaster online in effort to test migrating to using > apache/passenger as a frontend. > > While troubleshooting, I tried running the tried and true puppetmasterd > in lieu of the apache/passenger frontend in order to verify that I had > indeed set everything up properly, and ran into exactly this. > > This was attempted by using the new puppetmaster as the puppet client > (i.e. there is only one system I''m working with). I mention this only > because the only reference I could find to the SSL error message had to > do with clocks being out of sync between clients and server. Clearly not > the case in my scenario. For completeness, this particular environment > is Debian Lenny, running the .24.8 puppet and puppetmaster packages from > SID. > > I must admit it''s a bit un-nerving, as I had always assumed I could spin > up a new (or replacement) puppetmaster at anytime, should the need arise. > > Anyhow, count me as a very interested party to learning how to get this > working. > > Thanks, > > - Jeff > > Greg wrote: > > Hi all, > > > > I''m trying to get a puppet daemon to run on the same host as a > > puppetmaster, and I''m seeing an interesting problem on 0.24.8 on > > Solaris. > > > > One of the rules is to push out a current puppet.conf - heres the rule > > I''m using: > > > > file { puppetconf: > > path => $operatingsystem ? { > > solaris => "/etc/opt/csw/puppet/puppet.conf", > > default => "/etc/puppet/puppet.conf", > > }, > > owner => root, > > group => root, > > mode => 644, > > source => [ "puppet:///puppetdaemon/puppet.conf- > > $hostname", > > "puppet:///puppetdaemon/puppet.conf- > > $kernelrelease", > > "puppet:///puppetdaemon/puppet.conf" ] > > } > > > > Now the issue I am seeing is with the actual file transfer. When it > > comes to actually > > update the puppet config file, the messages file shows this: > > > > May 21 09:37:50 puppetmaster puppetd[3644]: [ID 702911 daemon.warning] > > Certificate validation failed; consider using the certname > > configuration option > > May 21 09:37:50 puppetmaster puppetd[3644]: [ID 702911 daemon.error] > > (//Node[default]/puppetdaemon/File[puppetconf]/source) change from > > {md5}846ec1befda534749269c6ec294bad40 to > puppet:///puppetdaemon/puppet.conf-puppetmaster > > puppet:///puppetdaemon/puppet.conf-5.10 > puppet:///puppetdaemon/puppet.conf > > failed: Certificates were not trusted: SSL_connect returned=1 errno=0 > > state=SSLv3 read server certificate B: certificate verify failed > > > > The weird thing here is that it seems to handle the initial handshakes > > and perform the rest of the work, > > its only when it comes to replacing a file... Running the > > puppetmasterd in debug mode yields this bit of info: > > > > debug: Using cached node for puppetmaster.domain.com > > debug: mount[puppetdaemon]: Describing /puppetdaemon/puppet.conf- > > puppetmaster for puppetmaster.domain.com > > debug: Overriding puppetmaster with cert name puppetmaster.domain.com > > debug: Allowing authenticated client puppetmaster.domain.com(10.1.2.3) > > access to fileserver.retrieve > > debug: Using cached node for puppetmaster.domain.com > > info: mount[puppetdaemon]: Sending /puppetdaemon/puppet.conf- > > puppetmaster to puppetmaster.domain.com > > debug: Overriding puppetmaster with cert name puppetmaster.domain.com > > debug: Allowing authenticated client mplops1prd.domain.com(10.1.2.3) > > access to fileserver.describe > > > > So it appears that the file is being sent to the client, and it is the > > client that is rejecting the file on the basis of the invalid > > certificate. Heres the weird thing - its happy with the certificate > > for everything else... > > > > The only other bit I will point out is that both the client and the > > server appear to be using the same > > certificate. I have this working without issue at a seperate site > > using the same configuration (as far > > as I can tell...) > > > > Has anyone seen something like this before? > > > > thanks, > > > > Greg > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Greg
2009-May-21 04:24 UTC
[Puppet Users] Re: Certificate issue for puppetd on same node as puppetmasterd
Not running Apache - I''m still using a WEBrick based setup, mostly because Apache -> Mongrel isn''t playing ball... But that''s a different story... Further analysis has shown me that there is an error message in WEBrick''s masterhttp.log file: [2009-05-21 13:54:30] ERROR OpenSSL::SSL::SSLError: SSL_accept returned=1 errno0 state=SSLv3 read client certificate A: tlsv1 alert unknown ca /opt/csw/lib/ruby/1.8/openssl/ssl.rb:166:in `accept'' At first I thought it had chopped off the alert, but it appears to be complaining about the lack of a CA... The files all appear to be in order - its signing certificates happily enough... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Greg
2009-May-21 06:56 UTC
[Puppet Users] Re: Certificate issue for puppetd on same node as puppetmasterd
OK... I have finally cleaned up most of the mess this has created... One of the issues I guess was that I was also trying to move the puppetca from one puppetmaster to another... I now have a situation where I have 2 puppetmasters, one "master" and one "slave-master"... The master holds the puppetca for all hosts (with an rsync process to the slave-master for backup), the slave-master doesn''t do any CA work (as far as I can tell) Clients connected to the master work fine, clients connecting to the slave-master for puppet and master for ca_server are not fine. I''m getting themessage "unknown ca". Given that the slave-master is not using a ca, I''m fairly sure that this means that its the one complaining about not knowing the ca... If I pull the config back to the following on the clients: server = puppetmaster-slave ca_server = puppetmaster-master I still have the same problems. Is there anything else I''ve got to set to get the clients to do all CA work from the correct master? (Note, the slave-master is set to get everything from the master, and the puppet client daemon running on the slave-master successfully gets everything it needs from the master.) thanks, Greg On May 21, 2:24 pm, Greg <greg.b...@gmail.com> wrote:> Not running Apache - I''m still using a WEBrick based setup, mostly > because Apache -> Mongrel > isn''t playing ball... But that''s a different story... > > Further analysis has shown me that there is an error message in > WEBrick''s masterhttp.log file: > > [2009-05-21 13:54:30] ERROR OpenSSL::SSL::SSLError: SSL_accept > returned=1 errno> 0 state=SSLv3 read client certificate A: tlsv1 alert unknown ca > /opt/csw/lib/ruby/1.8/openssl/ssl.rb:166:in `accept'' > > At first I thought it had chopped off the alert, but it appears to be > complaining about the lack of a > CA... The files all appear to be in order - its signing certificates > happily enough...--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Jeff Adams
2009-May-21 17:01 UTC
Solved? Re: [Puppet Users] Re: Certificate issue for puppetd on same node as puppetmasterd
My WEBrick''s masterhttp.log file was telling a slightly different story: [2009-05-21 11:41:22] ERROR OpenSSL::SSL::SSLError: sslv3 alert bad certificate /usr/lib/ruby/1.8/openssl/ssl.rb:122:in `accept'' As it turned out, in my /etc/puppet/manifest/site.pp file the filebucket configuration was pointing to a different puppetmaster host. Once that was fixed to reference the local puppetmaster, my cert errors went away and the manifests applied properly. Hope this helps someone. - Jeff On 05/20/2009 11:24 PM, Greg wrote:> Not running Apache - I''m still using a WEBrick based setup, mostly > because Apache -> Mongrel > isn''t playing ball... But that''s a different story... > > Further analysis has shown me that there is an error message in > WEBrick''s masterhttp.log file: > > [2009-05-21 13:54:30] ERROR OpenSSL::SSL::SSLError: SSL_accept > returned=1 errno> 0 state=SSLv3 read client certificate A: tlsv1 alert unknown ca > /opt/csw/lib/ruby/1.8/openssl/ssl.rb:166:in `accept'' > > At first I thought it had chopped off the alert, but it appears to be > complaining about the lack of a > CA... The files all appear to be in order - its signing certificates > happily enough...--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Greg
2009-May-22 06:54 UTC
Re: Solved? Re: [Puppet Users] Re: Certificate issue for puppetd on same node as puppetmasterd
Mine was similar... In my case, the second (slave) puppetmaster had built its own ca certificates when it was first started. Obviously these were different to the primary CA''s certificates. Copying across the CA certificates onto the slave puppetmaster solved my remaining issues - even though the slave puppetmaster is not supposed to be performing as a CA at all... Thanks guys! Greg --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---