question Re: CDH 5 (Latest) Fails to deploy using CM on JDK Installation in Archives of Support Questions (Read Only)

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

datacowboy — Fri, 16 Sep 2022 10:03:21 GMT

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.

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

sathishkumar — Thu, 11 Feb 2016 09:28:41 GMT

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

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

datacowboy — Thu, 11 Feb 2016 15:11:23 GMT

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.

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

Consult — Thu, 11 Feb 2016 16:17:37 GMT

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?

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

datacowboy — Thu, 11 Feb 2016 16:34:06 GMT

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.

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

datacowboy — Thu, 11 Feb 2016 16:51:34 GMT

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

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

Consult — Thu, 11 Feb 2016 18:23:04 GMT

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.

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

datacowboy — Thu, 11 Feb 2016 19:20:46 GMT

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