CDH 5 (Latest) Fails to deploy using CM on JDK Installation

[#1]

I'm deploying a brand new cluster using CM 5 and latest version of CDH.  The deployment consistently fails when attempting to deploy JDK to the nodes.

Please forgive my ignorance if the solution is obvious as i've been away from linux for some time.

https://archive.cloudera.com/cdh5/redhat/7/x86_64/cdh/5.5.2/repodata/repomd.xml: [Errno 14] curl#60 - "Peer's Certificate issuer is not recognized."

Thanks in advance.

[#2 · Accepted solution]

Hello datacowboy,

Yes you are right. If there is mandate to have a archive.cloudera as repository then we should look at your certificates.

But, yes if you are fine with creating a local repo then you can follow http://www.cloudera.com/documentation/enterprise/latest/topics/cdh_ig_yumrepo_local_create.html

Let us know if you need any further assistance.

Thanks.

[#3]

Hi 

It seems you are using cloudera's http repository. Make sure you have cleaned up your local yum repository cache and cloudera's repository is accessible from your server.

Thanks,

Satz

[#4]

That's correct, I'm doing a basic setup using Cloudera Manager.  Here are the steps I've taken so far.

1. Verified i can access the archive locations from the server.  - check

2. Executed yum clean all - check

3. Retry cluster install using CM 5.5.1 - no joy

4. Rebuilt centos 7 servers

5. Verified access to archive locations from server - check

Interestingly, when i tried to build a local repository using yum commands, i received the same "Peer's issuer certificate is not authorized" error.

[#5]

Hello datacowboy,

This in general happens in a scernario where your component between your server and repository isn't changing the secured certification.

Can you please share curl output for repomd.xml?

[#6]

Consult,

Test Command: curl https://archive.cloudera.com/cm5/redhat/7/x86_64/cm/5.5.1/repodata/repomd.xml

Here is the output from curl command:

curl: (60) Peer's Certificate issuer is not recognized.
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.

[#7]

All,

It looks like our device "man in the middle" is the cause of our issue.  Curl and WGet are rejecting the internal cert that's being passed back.

Now, i need to figure out how to get the parcels to a create a local repo.

Thanks,

DataCowboy

[#8 · Accepted solution]

Hello datacowboy,

Yes you are right. If there is mandate to have a archive.cloudera as repository then we should look at your certificates.

But, yes if you are fine with creating a local repo then you can follow http://www.cloudera.com/documentation/enterprise/latest/topics/cdh_ig_yumrepo_local_create.html

Let us know if you need any further assistance.

Thanks.

[#9 · Accepted solution]

All,

I was able to work around the issue by adding sslverify=false to the yum.conf file on all nodes.  I know this isn't ideal, but in order to get a POC up and running, this was the least heinous option.

BTW - when we setup CDH in production, we'll take the time to configure a local repository.

I appreciate everyone's input and suggestions.

-DataCowboy