Member since
04-22-2014
1218
Posts
341
Kudos Received
157
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 26261 | 03-03-2020 08:12 AM | |
| 16421 | 02-28-2020 10:43 AM | |
| 4725 | 12-16-2019 12:59 PM | |
| 4475 | 11-12-2019 03:28 PM | |
| 6679 | 11-01-2019 09:01 AM |
02-24-2017
02:51 PM
@Piks, I think I have seen this before. Check your /opt directory on the zookeeper hosts to make sure that it has "execute" for other. I reproduced what you see by setting the following: drwxr-xr--. 3 root root 21 Feb 7 13:50 opt Try running: chmod 755 So that it looks like this: drwxr-xr-x. 3 root root 21 Feb 7 13:50 opt Try starting services again after that. Regards, Ben
... View more
02-24-2017
11:01 AM
One more way to get low-level versions for everything: Hosts --> All Hosts --> Inspect All Hosts (button). This will return a report of CM and CDH packages.
... View more
02-24-2017
08:35 AM
1 Kudo
@guillaume_vande, A big thanks for pointing that out. We have updated the Spark2 page to include both versions with respective links. https://www.cloudera.com/documentation/spark2/latest/topics/spark2_packaging.html#packaging Let us know if you find anything else that needs correcting. Regards, Ben
... View more
02-23-2017
01:00 PM
Hello @IgorYakushin, After enabling TLS for the Cloudera Manager UI, the management services will need to know where to find trust for the signer of Cloudera Manager's Certificate. The management service roles contact Cloudera Manager to download information regarding the cluster, so if that information cannot be downloaded, the management service roles will fail. To configure the truststore used by the Management Service roles, see this documentaiton: https://www.cloudera.com/documentation/enterprise/latest/topics/how_to_configure_cm_tls.html#xd_583c10bfdbd326ba-7dae4aa6-147c30d0933--7a61 (you need to perform steps 2 and 3 in the Enable HTTPS for the Cloudera Manager Admin Console section) Regards, Ben
... View more
02-23-2017
08:05 AM
Hello @IgorYakushin, Cloudera's documentation does have some basic background here: https://www.cloudera.com/documentation/enterprise/latest/topics/cm_sg_guide_ssl_certs.html https://www.cloudera.com/documentation/enterprise/latest/topics/cm_sg_create_key_trust.html For Cloudera Manager / Agent encryption: https://www.cloudera.com/documentation/enterprise/latest/topics/cm_sg_config_tls_security.html To your specific questions: (1) my.truststore or jssecacerts? By default, the JDKs ships with a file that contains common public CA certificates for trust: $JAVA_HOME/jre/lib/cacerts Java will look to that file if it is not told (in a program or via command line) to use another file. If there is a $JAVA_HOME/jre/lib/jssecacerts file present, that file will be read instead of the "cacerts" file there. If you want to use my.truststore (your custom file) then you would need to let the JVM know to use that file. Cloudera Manager should have configuration options form most Java Keystores, so that is one way to tell the JVM where to find the truststore. See this section of the JSSE reference for more information about the truststore: http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509TrustManager Basically, 1. if CM (Cloudera Manager)'s truststore configuration for a service or role is specified, that will be used. 2. If none is specified, java will use "javax.net.ssl.trustStore" if it is set (at the command line, for instance) 3. If "javax.net.ssl.trustStore" is not set, then$JAVA_HOME/jre/lib/jssecacerts is used 4. If $JAVA_HOME/jre/lib/jssecacerts does not exist, then the default $JAVA_HOME/jre/lib/cacerts is used. When securing Cloudera Manager/Agent communication (I assume that is what you meant by levels 1-3): 1. no truststore is required for level 1 (TLS enabled, no certificate validation) 2. only openssl trust store is required for level 2 (TLS enabled, agent needs trust for the Cloudera Manager server certificate signer 3. Both of the above are required, and Cloudera Manager needs to be configured to read a truststore containing all the agents' public certificates. (CM validates the agents' certificates) I don't have a really good beginners guide to the topics handy at the moment, but you'll find some reasonable information here: https://en.wikipedia.org/wiki/Transport_Layer_Security
... View more
02-16-2017
10:59 AM
1 Kudo
@Rachel Try adding quotation marks around your URL. I think the shell is interpretting and is messing up the string that is sent. To debug curl and see the problem with the URL that is sent to Navigator, add the "-v" option. Ben
... View more
02-15-2017
01:15 PM
1 Kudo
Hi @zhuw.bigdata By default the hdfs user will be used. You can specify any user, but the user needs to exist in both clusters and, if you are preserving permissions, the user needs to be an HDFS superuser, too. Regards, Ben
... View more
02-13-2017
12:43 PM
@guruprasadc11, I just noticed that you indeed your Remote Parcel Repository URL needs adjustment. You specified: http://loclahost/cdh However, there are no parcels or manifest.json files in that directory. If you want Cloudera Manager to see the parcels for CDH, you would need: http://localhost/cdh/cdh-5.10 Make sure http://localhost/cdh/cdh-5.10 contains the parcel files and the manifest.json that goes with them. Regards, Ben
... View more
02-13-2017
12:37 PM
@guruprasadc11, The requirements for a valid parcel that can be recognized by Cloudera Manager is that the parcel file and accompanying "manifest.json" file be located in the same directory. What do you have in your cdh-5.10.0 directory on the local repo HTTP server? Make sure that the files there are accessible, too, and that permissions are not preventing listing/download. For more information regarding your CDH repository and parcel, tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log while adding your URL to the list of parcel repositories in the wizard. Cheers, Ben
... View more
02-13-2017
09:29 AM
Hello @mattreading, In order for the upgrade script to complete, yum must be funtional on the hosts you are adding. It appears that there is something wrong with one of the repositories and that causes a failure when building the yum cache. Since it appears broken, you might try removing the "HP-spp" repository from /etc/yum.repos.d/ and try the upgrade wizard again. Make sure that you can run "yum makecache" on that host. If you can, the wizard should be able to work. Regards, Ben
... View more