Wow! Nice catch! :) Might want to open a jira for this.
On Thu, Jul 25, 2013 at 6:43 PM, Aaron Cody <[email protected]> wrote: > ok well I figured out what was going on ... not an Ambari problem. > > so I had grabbed the 1.2.4 source tree from apache using svn .. and > immediately checked that into our source control - perforce. > built the source.. built fine... > ran it .. got the cert error. > scratched head. > blew everything away. > re-synced the source from perforce ... rebuilt... built ok .. ran it .. > cert error... > blew everything away ... > grabbed the source from apace using svn... rebuilt .. built ok ... ran > fine.... > so it occurred to me that perforce might be doing something to the source > tree to cause the problem.. > much diffing later... > so perforce ignores empty folders... so they all get stripped out when you > check in the code. > Ambari has a file - ca.config where the cert stuff is configured. > In there, new_certs_dir references an empty folder > (/var/lib/ambari-server/keys/db/newcerts) > In the apache source, that folder has a .gitignore file in it, so that's > all good. > Perforce doesn't see the .gitignore file, so thinks it is an empty folder > and strips it out. > At runtime, the ambari server SSL cert code looks for new_certs_dir and > blows up if it can't find it.... leading to the runtime cert error. > > you might want to put a non-hidden placeholder file in that folder, so it > doesn't get lost so easily ... > > :) > > > On 7/24/13 9:08 AM, "Mahadev Konar" <[email protected]> wrote: > >>Aaron, >> I would say wait for 1.2.5 to be released if this is an issue. 1.2.5 >>has a lot of fixes for ssl's and also has ability to disable ssl and >>better debugging capabilities. I am hoping we can release that in next >>2-3 weeks. >> >>thanks >>mahadev >> >>On Wed, Jul 24, 2013 at 8:51 AM, Aaron Cody <[email protected]> wrote: >>> oh ok just realized that the cert timestamps are in GMT and so should >>>have >>> been fine Š >>> so no nearer to figuring out why registration is suddenly failing. >>> >>> ambari folks .. any ideas? >>> >>> >>> >>> From: Aaron Cody <[email protected]> >>> Reply-To: <[email protected]> >>> Date: Tuesday, July 23, 2013 11:32 PM >>> >>> To: "[email protected]" >>><[email protected]> >>> Subject: Re: problem with the registration step >>> >>> the problem appears to be that for some reason, the SSL cert generated >>>and >>> signed by the ambari server as it starts up is invalid until tomorrow .. >>> >>> openssl x509 -noout -in /var/lib/ambari-server/keys/ca.crt dates >>> >>> notBefore=Jul 24 04:41:20 2013 GMT >>> notAfter=Jul 24 04:41:20 2014 GMT >>> >>> which is really strange as the system date/time on my server seems to >>>be set >>> correctly.. >>> >>> Anyone seen anything like this before? >>> >>> (the version of openssl I've got on my RH6.4 x64 box is: >>> openssl-1.0.0-27.el6.x86_64, ambari codebase v1.2.4) >>> >>> >>> >>> From: Aaron Cody <[email protected]> >>> Reply-To: <[email protected]> >>> Date: Tuesday, July 23, 2013 1:39 PM >>> To: "[email protected]" >>><[email protected]> >>> Subject: Re: problem with the registration step >>> >>> looks like the agent is failing to connect back to the master because of >>> some SSL cert problem?? >>> >>> curl >>> >>>https://ac-dev-01.sensage.com:8441/agent/v1/register/ac-dev-03.sensage.co >>>m >>> >>> curl: (60) Peer certificate cannot be authenticated with known CA >>> certificates >>> More details here: http://curl.haxx.se/docs/sslcerts.html >>> >>> curl performs SSL certificate verification by default, using a "bundle" >>> of Certificate Authority (CA) public keys (CA certs). If the default >>> bundle file isn't adequate, you can specify an alternate file >>> using the --cacert option. >>> If this HTTPS server uses a certificate signed by a CA represented in >>> the bundle, the certificate verification probably failed due to a >>> problem with the certificate (it might be expired, or the name might >>> not match the domain name in the URL). >>> If you'd like to turn off curl's verification of the certificate, use >>> the -k (or --insecure) option. >>> >>> any ideas how to rectify this? >>> thanks >>> >>> >>> From: Aaron Cody <[email protected]> >>> Reply-To: <[email protected]> >>> Date: Tuesday, July 23, 2013 1:28 PM >>> To: "[email protected]" >>><[email protected]> >>> Subject: Re: problem with the registration step >>> >>> attached - thanks >>> >>> From: Siddharth Wagle <[email protected]> >>> Reply-To: "[email protected]" >>> <[email protected]> >>> Date: Tuesday, July 23, 2013 1:00 PM >>> To: "[email protected]" >>><[email protected]> >>> Subject: Re: problem with the registration step >>> >>> Hi Aaron, >>> >>> Could you correlate this message with the server logs and provide them? >>> If you stop and start the agent you should be able to capture the error >>>if >>> any on the server side. >>> >>> To turn on debugging on the agent, edit >>> /etc/ambari-agent/conf/ambari-agent.ini >>> also turning on debugging on the server site might help. >>> (/etc/ambari-server/conf/log4j.properties) >>> >>> -Sid >>> >>> >>> On Tue, Jul 23, 2013 at 12:27 PM, Aaron Cody <[email protected]> wrote: >>>> >>>> Any ideas what might be causing this? >>>> >>>> I am using FQDNs and I can passwordless-SSH from master to all slave >>>> machinesŠ >>>> RedHat 6.4 >>>> >>>> Registration fails: >>>> >>>> self.httpsconn.connect()\n File >>>> \"/usr/lib/python2.6/site-packages/ambari_agent/security.py\", line >>>>63, in >>>> connect\n ca_certs=server_crt)\n File \"/usr/lib64/python2.6/ssl.py\", >>>>line >>>> 338, in wrap_socket\n suppress_ragged_eofs=suppress_ragged_eofs)\n File >>>> \"/usr/lib64/python2.6/ssl.py\", line 118, in __init__\n cert_reqs, >>>> ssl_version, ca_certs)\nSSLError: [Errno 336445442] _ssl.c:353: >>>> error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system >>>> lib\n', None)\n\nSTDERR\nConnection to ac-dev-04.sensage.com >>>> closed.\nRegistering with the server...\nRegistration with the server >>>> failed."}] >>> >>>
