@TCloud, The exception is in the agent and indicates to us that the agent is not able to verify the certificate that was returned by Cloudera Manager during the TLS handshake. In order to know why, we should look at what host the agent tried to contact (server_host in config.ini) and what certificates were listed in the SAN of the server certificate. You can use the following command to see what certificate is returned: openssl s_client -connect $(grep "server_host" /etc/cloudera-scm-agent/config.ini | sed s/server_host=//):7182 </dev/null | openssl x509 -text -noout Then, check to make sure agent's truststore has the proper certificate that trusts the CM cert.  To test, you can use: openssl s_client -connect $(grep -v '^#' /etc/cloudera-scm-agent/config.ini | grep "server_host=" | sed s/server_host=//):7182 -CAfile $(grep -v '^#' /etc/cloudera-scm-agent/config.ini | grep "verify_cert_file=" |sed s/verify_cert_file=//) -verify_hostname $(grep -v '^#' /etc/cloudera-scm-agent/config.ini | grep "server_host=" | sed s/server_host=//)</dev/null   The above is probably not that elegant, but you should be able to run it as it is.  It will grab your hostname and trust store file from the host's config.ini and then connect to your CM host to do a TLS handshake.  "-verify_hostname" will tell openssl to also do hostname validation to mimic what the agent does.   The result code of the above command should give us a better idea of why the handshake is failing.   ... View more

@wert_1311,   Cloudera and the agents will communicate to make sure that parcels are distributed and enabled on all hosts that are managed.  In this case, it sounds as if your attempts to copy information may have contributed to running out of space.  5GB isn't much space, though, so it could be you will need more space.   To allow the agent to correct the situation, you can do the following:   (1)   Stop the agent service cloudera-scm-agent stop   (2)   remove the contents of the parcels directory: /opt/cloudera/parcels/* (3)   Start the agent:   service cloudera-scm-agent start   (4)   Monitor the agent log to see if it starts downloading the files. ... View more

@Da,   CSD files used with CM 5 should be compatible with CM 6.  If you hit any problems that you think may be related to CM 6, please do let us know.     ... View more

@vincenth,   I'm not sure what you mean by "Authority Certificate." I think you mean Certificate Authority. https://en.wikipedia.org/wiki/Certificate_authority   If so, then no, there is no restriction on this being public.  You can create and manage your own authority. The advantage of using a public CA is that it is likely already trusted by clients (like browsers or openssl).  However, if you have control over your clients, there is no reason why the clients could not import whatever root CA public certificate of the CA you create.   If you are OK with running creating and using your own CA, you can save a good deal of money since public CAs do need to charge for their services.   If you have the $ and don't want to manage a CA, a public CA will work fine.   I wouldn't recommend self-signed certificates for production as management can become cumbersome.   Truststores, rather than havining your root CA may require every certificate of every host in your cluster.  If you add a host, then, you would need to update all trust stores.   If you have clients connecting to a different hostname (public) to CM and Hue, then you can add the hostnames you want to Subject Alternative Name in the certificate.   see:  https://en.wikipedia.org/wiki/Subject_Alternative_Name   If you are interested in learning about using OpenSSL to maintain your own CA, this person seems to explain it pretty well (though I haven't gone over it completely):   https://jamielinux.com/docs/openssl-certificate-authority/index.html   I can't speak for the overall design, but the above should help a bit with the TLS side of things. ... View more

@dennisli,   No, that password stuff is all server side.  There are no passwords to supply from the hive client side.   Can you explain what you have done so far with CDH and what you are trying to do? Are you following some instructions?  Are you new to Cloudera Manager and CDH? There are some fundamental concepts about how configuration is done with a managed cluster, so feel free to ask questions.   If you installed Cloudera Manager and then used it install CDH with parcels, then if you run "hive" command from any host that has a Hive role on it.   For instance, if you have HiveServer2 or the Metastore or a Gateway role installed on hosta.example.com, you can ssh to hosta.example.com and simply run:   hive   This will connect according to the client configuration that is in /etc.  Cloudera Manager manages the passwords in your hive-site.xml, so you should not have to do anything with them.  The "*******" is redacted so you can't see the password.   Try going to a host with a Hive role on it and run:   hive   once you get a prompt, you can run:   hive> show databases; ... View more