Member since
09-23-2013
238
Posts
72
Kudos Received
28
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1804 | 08-13-2019 09:10 AM | |
3166 | 07-22-2015 08:51 AM | |
7074 | 06-29-2015 06:43 AM | |
4929 | 06-02-2015 05:17 PM | |
20711 | 05-23-2015 04:48 AM |
05-23-2015
04:48 AM
1 Kudo
So as you read through the error message, (the middle here being signficant) this line appears to be indicating at least part of the problem, as well as the others like it, that follow. add_principal: Operation requires ``add'' privilege while creating "yarn/datanode003.domain.com@MYREALM.COM". You would want to review your /var/kerberos/krb5kdc/kadmin5.acl file. Verify if the name pattern you are using for the CM administrator will properly resolve to an administrative account.
... View more
05-20-2015
07:14 PM
The following discussion covers the changes in the 5.4.x and our approach to the repos. Most likely if you were on 5.3.x or older before you are seeing the change, whereas if you started on 5.4, you are already following the new process automatically. Please see: http://community.cloudera.com/t5/Cloudera-Manager-Installation/Why-is-CDH-5-4-not-set-as-the-latest-parcels-at-http-archive/m-p/26985#M4345
... View more
05-06-2015
10:25 PM
Ok so flat out, if the CDH cluster is new along with the CM install... the whole point of CM is to deploy and manage CDH, so installing CDH by itself basically lays down configuration that can not be ingested automatically into CM. For a one node cluster, it should be possible to add a node via CM (add host) and then deploy CDH over that. Any significant configuration changes you made directly in CDH as far as non default settings, can be configured within CM. If there is significant data in the CDH one node cluster you have, distcp can be used to copy data from CDH cluster to CM manage clusters CDH.
... View more
05-06-2015
05:02 PM
We can evaluate expanding the example and definition of what we do by default as well, thanks for pointing this out, we'll continue to review.
... View more
05-06-2015
04:56 PM
Because we expect the KDC in a hadoop environment to be protected from this by network design.... the reason we hard set TCP rather than UDP is that in complex network environments, we can drive failures within the cluster. IMHO this is valid for internet/hostile network environments, which we strongly reccomend against being used for a cluster environments.
... View more
04-16-2015
04:02 PM
1 Kudo
Sorry, So the term "truststore" is over-loaded. Are you saying a JKS file that you configure from the CM UI as a truststore for each service in the cluster, including management services? Or a "default" truststore like [JAVA_HOME]/jre/lib/security/cacerts (or jssecacerts) that establishes inherent trust as we have been discussing... You have a number of configuration changes to make, one for each service, to recognize that trust store file (as opposed to instrumenting the JDK for trust).
... View more
04-16-2015
01:48 PM
And we cover import/export scenarios between the two implementations here: http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cm_sg_openssl_jks.html So you need to consider that you have a private key component, and a issued certificate component... the combination of the two in a JKS (private key and certificate) allow you to start up a java based service that will support SSL/TLS connections. You can use your IPA based appoach as long as you have access to the private key and certificate it issues, to combine them and then import into a JKS. The the CA certificate that issued the certificate, imported into the truststores I've discussed already, establishes inherent trust within java services, for SSL certificates created by that CA.
... View more
04-16-2015
07:58 AM
Ok so you have 2 paradigims that you are configuring for, the JDK, and OpenSSL "Trust" is established differently between the two implementations, Navigator, being Java based, will derive trust through the default JDK mechanisims I pointed out For the Agents, Hue, and Implala the implementation is based on OpenSSL. Trust can be established for a root CA by directly configuring path to a CA pem file, or if there is a complex intermediary chain through providing the path to where the files are and running the c_rehash tool to generate the necessary base64 encoded symlinks. Navigator is expecting you to configure a jks with private key and installed cert, but then as navigator attempts to connect to other cluster services that are using SSL/TLS, it needs to trust the CA that issued the server cert...
... View more
04-15-2015
09:54 PM
Have you established implicit trust for your private CA in the JDK layer as discussed in our documentation on encryption for the platform, as laid out here: http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cm_sg_create_key_trust.html You can import the CA's certificate into the [JAVA_HOME]/jre/lib/security path, using cacerts or jssecacerts as you see fit. Trust in the JDK is documented in detail here as well http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509TrustManager
... View more
04-04-2015
02:48 PM
1 Kudo
Feel free to use path A as well! It is by far the simplest approach to setup and configuration so that you can get into using the platform quickly. The path B approach lets you manage the installation manually using packages, and would be what you want to do for a production deployment that you intend to run long term. If you have previously attempted install, search for "uninstall" in the installation guide in the docs (top left of docs pages to search) and it will give you the cleanup steps to apply to your previous installation attempts. RHEL 6.4 is fine to use 6.5 is supported as well, the actual OS, database, and JDK requirements are listed in the sections around the link I gave for the single user mode discussion as well. Keep us posted on your progress, feel free to start a new topic to address the specific issue you see.
... View more