Hi @TCloud ,   The documentation contains information about the trusstore in Step 4: https://www.cloudera.com/documentation/enterprise/latest/topics/how_to_configure_cm_tls.html#concept_xtp_q3w_wn   It does not include *what* to put in the truststore file, though, so yes, that is something that should be improved.   If you are using a Certificate Authority to sign your certificates, you can simply add the root CA certificate to the truststore. If you are using self-signed certificates, each agent's certificate needs to be imported so CM can validate the agent's certificate.     ... View more

Hi @Daggers ,   For which logs are you looking? Hive Metadata Export generally happens on the *source* cluster, so you should be able to find the command and associated logs by logging into the source cluster's Cloudera Manager, navigating to the Hive service and clicking the "Commands" subtab.  You can then look at the results of the command for more information.  If the command contains stderr/stdout logs, the top few lines should include the host on which the command ran, too. ... View more

@ca,   Testing for compliance and compatibilty takes a good deal of effort so we usually only certifiy later OS release on the latest CM/CDH versions.   By "supported" in this case we mean that we have tested and certify CM/CDH on that OS release.   Part of obtaining software from our distrobution is that we test to help ensure stability with the products.  That takes some of the guess-work out, but that also means that if you want that assurance, "certified" configurations may not include the latest OS releases and third-party code. We seek to balance stability with rich features that our users demand.   Hope that helps explain things a bit more.  Please feel free to ask more if you have any questions! ... View more

@BiggieSmalls,   The error you show indicates that the certificate and key files specified for Hue are not in the expected PEM format.   The key needs to have the key stored in base64 between: -----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----   The certificate file needs to have the certificate in base64 between:   -----BEGIN CERTIFICATE----- -----END CERTIFICATE-----   The "no start line" error from openssl libraries is explaining that it cannot find any BEGIN line   make sure your ssl_certificate and ssl_private_key files contain the above text. ... View more

@lamdeptunhien9x,   I just worked with Cloudera engineering and we have fixed up the code logic that led to the false ERROR.  I tested and it looks good. We'll add the fix into future releases.   Cheers,   Ben ... View more

@bob_the_web,   There is only one Cloudera Manager binary.  Without a license, the limited features of Express are available.  To unlock the Enterprise features, a trial or purchased license is required.   https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_licenses.html   You can find how to install CM here:   https://www.cloudera.com/downloads/manager/6-2-0.html ... View more

@ca,   Since Cloudera has not tested CM/CDH on RHEL 7.5, we cannot certify CM/CDH will work on that OS version. In general, it is possible, and even likely, that you will not encounter any problems.   If you do hit a problem that is related to the later release, they will not fixed.   Depending on how much risk you are willing to incur, you could try it.  If you are paying Cloudera for support, consult with your Cloudera Account team.   Let us know if you have any questions.   Ben ... View more

Hello @manu_009 ,   Before performing any steps, let's step back and look at the situation you presented:   (1)   You had a working cluster for a long time, changed nothing, and all of a sudden you are faced with a situation where Cloudera Manager won't start.   (2)   The stack trace you provided (without context) indicates a problem where the MySQL driver is not receiving a response from the MySQL server:   The last packet successfully received from the server was 108,228 milliseconds ago. The last packet sent successfully to the server was 1 milliseconds ago.   Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost. at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2914) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3337) ... 20 more   I imagine there is more to this wrapped exception, but the above suffices in confirming that CM is sending requests out through the connection to the MySQL database, but it is not receiving replies as expected.   (3)   - From this, we know that TCP is OK in the sense that the client (CM) can open a connection with the server (mysql). - Since you are not using postgres, do not worry about trying the cloudera-scm-server-db thing (that's only for the embedded db and you are not using it... the result you got is expected as the package was correctly not installed)   NEXT STEPS:   (1)   Verify startup problem in /var/log/cloudera-scm-server/cloudera-scm-server.log   While cloudera-scm-server.out may have good information, most of the server logging is in cloudera-scm-server.log and it will have some context as well.   (2)   Since the evidence presented points to there being a problem outside of CM and the MySQL driver connection, it stands to reason we focus our efforts there.  Since the Server is MySQL, we should check to see if there are any connections open from CM to MySQL and if there are queries that are running on MySQL as the "cm" user on the "cm" db.   I recommend - running:  service cloudera-scm-server stop  verify that there are no processes returned when running: ps aux |grep cmf.Main   - Log into mysql server and run: SHOW FULL PROCESSLIST;  This will show you a list of running queries  Check if there are any "cm" ones - If there are, there should not be since CM is stopped.  Stale or hung queries can cause the type of behavior you are seeing, so we can kill off any queries being run by the cm user on the cm db. - run this to kill any left over queries: KILL <ID>   (3)   If there are no "hung" or long-running CM queries, and CM still does not start (with the same exceptions), then we may need to look at the connection over the wire with tcpdump/WireShark.   I'm hoping, though, that the issue you are seeing is related to a situation with some "hung" queries.  You mentioned you could connect to MySQL outside of CM, so that supports the theory that this is a CM-specific DB problem.   ... View more