Yes, plz to be opening bug. =) I'm not certain that is the right solution, we might be able to fix ssl_context.cert_store.set_default_paths as used by excon to DTRT which may be more correct, but that'll take more research... On 6/21/13 2:41 PM, "> wrote: " type="cite">On Fri, 21 Jun 2013, Lamont Granquist wrote:It looks like excon is now searching for an openssl.cnf, and omnibus ships with the example openssl.cnf which openssl installs by default in the omnibus build at /opt/chef/embedded/ssl/openssl.cnf -- and when it finds that file it goes off and does something using incorrect information that isn't entirely clear to me... Since the start of openssl.cnf begins with a comment about "This is mostly being used for generation of certificate requests." it isn't clear to me why a client app expects to get something useful out of that. But it also isn't clear to me why openssl isn't installing that as openssl.cnf.example or something. AFAIK, we could remove that out of the omnibus build and then I think it will fall back to the DEFAULT_CA_FILE in the omnibus build correctly... If you manually nuke that file does excon 0.25.0 work correctly?Yep! That allowed a successful run with excon 0.25.0. Should I open a bug with all of this info?On 6/21/13 12:50 PM, "> wrote:On Fri, 21 Jun 2013, "> wrote:My newly launched nodes started failing in their route53 recipe last nite with this error: FATAL: Excon::Errors::SocketError: route53_record[chef-ci-web.dev.needtogetmyoontzon.com] (resolver::default line 128) had an error: Excon::Errors::SocketError: Unable to verify certificate, please set `Excon.defaults[:ssl_ca_path] = path_to_certs`, `Excon.defaults[:ssl_ca_file] = path_to_file`, or `Excon.defaults[:ssl_verify_peer] = false` (less secure). On such a system, I see: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/excon-0.25.0 On a system launched only a couple days ago, I see /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/excon-0.24.0 I see 0.25.0 changed the behavior of how it finds certs: https://github.com/geemus/excon/blob/master/changelog.txt I'm not sure if I should bug geemus, or the chef community. In the meantime, I'm gonna see if I can pin my clients to 0.24.0 so we're not stuck on this.I was able to prevent excon 0.25.0 from being installed, and instead install excon 0.24.0 by calling this early in my run_list: chef_gem "excon" do version "0.24.0" end fwiw. My deets: AWS Linux 2012.09, chef 10.24.0 |
Archive powered by MHonArc 2.6.16.