@Meister1867,   Based on the exception, it appears that distrobution started but got into an ambiguous state as the torrent file already existed.  I would recommend cleaning up to see if the agent can start the download again:   (1)   stop the agent with "service cloudera-scm-agent stop"   (2)   Delete all cached files from the "parcel-cache" which is the directory where torrent files are cached. # rm -rf /opt/cloudera/parcel-cache/* Delete all files that have been downloaded by the "flood" torrent mechanism # rm -rf /opt/cloudera/parcels/.flood/*   The goal here is to clear out files that appear to be causing trouble for the download.  When we start the agent, it should detect it needs to start the download again.   (3)   Start the agent with "service cloudera-scm-agent start"   (4)   Monitor parcel status to see if this helps.   ... View more

@kevin001,   Thanks for your question.   When you say you changed the hostname and IP address, how was that done? hosts file... dns...? What was the old and new hostname (if you can share with us)   Cloudera Manager's agents use a uuid (most of the time) as a unique identifier for a host, so a change of IP or hostname should not impact the heartbeat in that case.  If the uuid changed in some way (/var/lib/cloudera-scm-agent/uuid), then you could end up with two entries for the host (old and new hostname) in Cloudera Manager.   First, we need to define the problem, though.  You mention that the host where Host Monitor runs is not showing a heartbeat in Cloudera Manager?  If so, we need to see the heartbeat exception in the Cloudera Agent log ( /var/log/cloudera-scm-agent/cloudera-scm-agent.log )   Once we have a better handle on what the issue is, we can decide in which direction to take the debugging.   Ben ... View more

@IgorYakushin,     If you don't have intermediate certificates, don't worry about them.  Take the instructions to mean "if you have intermediate certificates..."   When troubleshooting these sort of problems, it is important to define the problem very clearly.  To do so, we will need to understand what client/server communication is failing.   If the agents are not heartbeating to Cloudera Manager, then the cluster will appear in BAD health.  To find out if they are heartbeating, go to the Cloudera Manager Hosts -> All hosts page. There, look at the "Last Heartbeat" column and if there are no values or values greater than 15s, there is a problem where the agent's hearbeat is not being received.   If that is the case, go to the agents and review the /var/log/cloudera-scm-agent/cloudera-scm-agent.log file for exceptions regarding heartbeats.  You can share them here for review.   Also, look at the /var/log/cloudera-scm-server/cloudera-scm-server.log on the Cloudera Manager host to see if there are exceptions or messages occurring at the same time as the heartbeat error in the agent log.  Share them here if there are.   From there we can take a closer look at your agent configuration and certificates.     ... View more

@IgorYakushin,   It seems we removed that section from CM 5.10.  I'll test in the coming days to find out if the behavior has changed.  The step to import the agent certificates is still in the 5.9 docs:   https://www.cloudera.com/documentation/enterprise/5-9-x/topics/cm_sg_config_tls_agent_auth.html#concept_lvp_pzk_rp   However, the 5.9 docs are not clear, either.   I'm going to go over the TLS documentation in coming weeks and fix problems and clarify the instructions.   For now, I recommend you import each of the agents' certificates into a single JKS file (after having imported your root CA first).  Point CM's Path to Truststore configuration to that JKS file.  After that, restart Cloudera Manager. If you still have problems, we can help.   Regards,   Ben     ... View more

@IgorYakushin,   The agents' certificates only need to be in the CM truststore for "level 3" CM/agent security.  In that scenario, the agent presents its public certificate to CM and CM verifies it trusts the certificate.  In other trust scenarios, only the root CA in the chain of trust needs to be in the truststore.   Regards,   Ben ... View more

Hi @Cindy,   There is a lot packed into your post; I'll do my best to hit the main points:   (1)   We added a banner in Cloudera Manager 5.9 to warn about using the embedded db in production.  Previously, there was no warning   (2)   The https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_installing_configuring_dbs.html#cmig_topic_5_2 link only describes creating a new external Cloudera Manager Database.  It does not describe how to migrate the data over. At this time, Cloudera does not publish documentation regarding migration of Cloudera Manager databases.   (3)   Without knowing exactly what was configured, it is hard to say what happened, but I think that you haven't configured Cloudera manager to use the database.  See this section on how to do so:   https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_installing_configuring_dbs.html#concept_i2r_m3m_hn   That script, when run, should update your /etc/cloudera-scm-server/db.properties file (which tells Cloudera Manager what database to use.)   (4)   In order to stop "cloudera-scm-server-db" you need to have all connections to the databases it hosts closed.  Running a "stop" will signal Postgres to not allow new connections and to wait till clients have closed their connections to shut down.  If you have other services using the embedded database, this may never happen.   To force a close of all open connections and a shut down:   # service cloudera-scm-server-db next_stop_fast # service cloudera-scm-server-db stop   (5)   The "embbeded" banner is displayed if the following shows that "embeddedDbused" is true:   <cm_host>:<cm_port>/api/v14/cm/scmDbInfo   ****WARNING****   make sure you have a backup of your current embedded db (located by default in /var/lib/cloudera-scm-server-db) before trying any migration.  If you use a new db, the Cloudera Manager database will be blank and you will be asked to create a cluster again.   I hope some of that helps; let us know if you have other questions or need clarification.     ... View more

@Fawze,   Currently, LDAP authentication for Cloudera Manager is only available in Cloudera Enterprise as outlined here:   https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_feature_differences.html   If you wish to discuss licensing options with Sales, the following form can be used:   https://www.cloudera.com/contact-sales.html   Ben     ... View more

@nkumari,   For the one user, what message are you seeing, exactly, in the UI when they try to log in? Since Active Directory authentication will concatenate the username provided in the UI with an '@' character and then the domain you specified to form a userPrincipalName.   For example, if you login with 'myname' and your "Active Directory NT Domain" configuration in Cloudera Manager is "example.com" then the userPrincipalName used to authenticate to AD is:   myname@example.com   This works most of the time, but it will fail if the login string used does not match the left part of the user's userPrincipalName attribute in Active Directory.  Sometimes the userPrincipalName shortname (left of the '@' sign) does not match the sAMAccountName that users often use as their login.   I'd check to the value the user who can't login is using as their username and see if the userPrincipalName that it generates in for authentication matches the userPrincipalName that exists for that user in their AD object.   The problem could be something else, but the issue I described is something we have see from time to time.   The remedy, then would be to use LDAP as the external authenitication method.     ... View more

Hi @IgorYakushin,   To add to what @mbigelow mentioned, you can enable Kerberos without using TLS to secure communication between your agents and Cloudera Manager, but that would allow the kerberos keytabs to be transmitted from Cloudera Manager to your agents in the clear (risking a malicious party gaining access to your ketyab).   Most of the security you will likley need is taken care of by inabling TLS for Agent communication in this section: Configuring TLS Encryption for Cloudera Manager Agents   This will encrypt communication when the agent gets the keytabs and other files from CM.   If you want more security by having the agents do verification of Cloudera Manager's certificate signer and hostname, then you can configure your trust file for each agent (to trust the CM signer).   In summary, you don't need to have TLS enabled to enable Kerberos.  If you need to protect the keytabs, enable TLS Encryption for Agents. If you need higher security by having the agents trust the signer of the Cloudera Manager server certificate, you can proceed with the other steps: https://www.cloudera.com/documentation/enterprise/latest/topics/how_to_configure_cm_tls.html#topic_3   Ben     ... View more