About lhebert

lhebert · ‎03-06-2020

This can mean one of a few things but ultimately the error code you are seeing is being returned by your KDC. Client not found in database means that the requested SPN cannot be found by the KDC. This most often occurs when both forward and reverse DNS are not properly configured in your environment. If you find the both forward and reverse DNS are in working order then you should review credentials on the KDC and ensure that the credentials we are trying to use exists for this host. You can enable Kerberos debugging to get additional information from the JVM on the Kerberos interaction but generally speaking zookeeper uses one of two credentials. Either HTTP/<fqdn>@realm or zookeeper/<fqdn>@realm.

lhebert · ‎12-19-2019

Hello, Take a look at the Agent configuration on the reported host and make sure that use_tls is set to 1 and not 0. This error usually happens when Cloudera Manager expects TLS from the agent (Based on enabled options ) but the agent is continuing to send data using clear text. If the parameter is set to 1 please restart the agent to ensure that it is set properly. The agent performs multiple task some of these task are performed with data transmitted through the heartbeat others are handled by a pull method through the agent.

lhebert · ‎12-18-2019

Hi, We no longer refer to levels in our documentation but based on what is posted here it would appear as though are on Step 4 of our current documentation for manual certificate configuration. While we understand that you might not be able to provide the full raw contents of your certificate in this forum please ensure that the certificates you are attempting to use have the following two x509 Extended Key Usage attributes. These 2 EKUs must be present in order to use Client/Server Authentication which is the final step of deployment should you chose to go that far. These two EKUs are noted in our documentation. X509v3 Extended Key Usage: TLS Web Client Authentication TLS Web Server Authentication https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/how_to_configure_cm_tls.html#concept_gkg_xs3_lx https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/how_to_configure_cm_tls.html#topic_3 https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/how_to_configure_cm_tls.html Also please make sure that there are no leading or trailing spaces on any configuration parameters within the agent configuration file. If your certificate is non-single root, signed by an intermediate, you may have better success using the verify_cert_dir parameter so that all of your CA certificates including the root certificate are present. When using the verify_cert_dir parameter you must use c_rehash provided by openssl-perl.

lhebert · ‎12-18-2019

Your recent update indicates that an upgrade was performed from 5.14 to 6.2. The 500 error indicates a problem in the system response. Have you properly followed the migration and upgrade documentation found here? https://docs.cloudera.com/documentation/enterprise/upgrade/topics/search_prepare_upgrade_cdh_6.html

lhebert · ‎01-24-2019

Hello, According to the error information it appears as though you are attempting to use mySQL as a database backend. The stack trace reports the the mySQL JDBC driver cannot be located or loaded. HHH010003: JDBC Driver class not found: com.mysql.jdbc.Driver ... Caused by: java.lang.ClassNotFoundException: Could not load requested class : com.mysql.jdbc.Driver Please review the following documentation. https://www.cloudera.com/documentation/enterprise/6/6.1/topics/cm_ig_mysql.html#cmig_topic_5_5_3

lhebert · ‎01-18-2019

HI, It's not uncommon for our documentaion team to cross-link pages to avoid duplication within our documentation. However with that said I'll pass your feedback along to our documentation team.

lhebert · ‎01-16-2019

Hello, The KMS service within the hadoop frame work is responsible for handling key material. The KMS is not responsible for encrypting or decrypting data. The KTS is not connected to access control over data. All encrypted data handling occurs within the DFS client framework. 1.) You will need to review and understand the concepts laid out in our documentation and upstream related to securing the KMS. Cloudera ships a secure by default ACL configuration. New keys are not automatically alotted any access controls. No users are authorized to access new keys which have undefined Acess Controls. The KMS ACL engine is designed to control key release and it is not in any way connected to the underlying HDFS Posix controls. The ACL engine indicately controls access to Encrypted data by controlling access to key material. https://www.cloudera.com/documentation/enterprise/5-16-x/topics/cdh_sg_kms_acl_config.html 2.) Your question here is moderately confusing. HDFS Encryption is Transparent to the DFS client. If a user is authorized to perform decrypt EEK operations they may view the encrypted data. Raw encrypted data is not normally visible to clients in the capacity I believe you are attempting to describe outside the context of the raw end point exposed to the supergroup users. 3.) You can access the raw data end point as a super user if you would like to verify that the data is encrypted. This information is documented publicly in both upstream and in our documentation. hdfs dfs -ls /.reserved/raw/ 4.) The Generate EEK operation is handled internally by the HDFS service user and is not normally exposed to operators. If you are a cloudera customer you should reach out to your account team for additional training and details.

lhebert · ‎01-16-2019

Hello, You are correct we have removed public access for archive-primary.cloudera.com. Customers and users should now access archive.cloudera.com which is part of a distributed network (CDN). This change was made effective Jan 9, 2019.

lhebert · ‎01-16-2019

The page you've referenced cross-links to the one shown below. At the time of this writing we have only certified 1.8u181. Newer version may work without issue and generally support them but we have not certified any releases beyond what is shown on the page at this time. https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_java_requirements.html#java_requirements

lhebert · ‎01-08-2019

Hi, We are sorry you are still encountering this issue. Since we know that the problem is isolated to TLS and that the agent is reporting a null certificate chain you will need to isolate why the certificate chain is null. 1.) Ensure that the certificates are in a standard x509 format for the agent. 2.) Ensure that the truststores/keystores on the CM host are in JCEKS format and not pkcs12. 3.) Make sure that the cloudera-scm user can read the Private Key, Certificates, Truststores, and Password Files. 4.) Make sure that the certificate on the failing agent contains a proper CN and DNS Alt Name if Alt Names are in use. 5.) Are you using self-signed certificates or certificates signed by a CA? 6.) If all else fails you can obtain a tcpdump of attempted communication with the server. The port that we normally heartbeat to is 7182. You can then review the conversation between the server and agent to attempt to identify at what point the error is returned and potentially what error is being observed at the protocol level. You can identify and restrict your tcpdump information by tcp.stream.

Online	Offline
Last Visited	‎01-21-2022 02:39 PM

Member Since	‎01-05-2015 03:05 PM
Last Visited	‎01-21-2022 02:39 PM
Posts	235
Kudos received	19

Cloudera Community

Cloudera Community

Re: Encryption at rest - basic queries

Re: archive-primary.cloudera.com/cdh5/cdh/5 is not...

Re: OpenJDK 1.8 Support in CDH 6

Re: Hiveserver2 HA using haproxy load balancing

Re: Migrating from hortonworks eco-system to Cloud...

Re: Kerberos setup failed on cluster due zookeeper...

Re: Level 2: Enabling Cloudera Manager Agent Hosts...

Re: Level 2: Enabling Cloudera Manager Agent Hosts...

Re: Cloudera Search Tutorial Error

Re: Cloudera scm server start failed

Re: OpenJDK 1.8 Support in CDH 6

Re: Encryption at rest - basic queries

Re: archive-primary.cloudera.com/cdh5/cdh/5 is not...

Re: OpenJDK 1.8 Support in CDH 6

Re: After enabling TLS cloudera agent heartbeat fa...