Hopefully this can help somebody in the future with this endpoint or understanding how to decipher the API if you have already moved past this issue.     However, if you look at the example for the hosts_decommission_command endpoint [0] you will see the following:     from __future__ import print_function import time import cm_client from cm_client.rest import ApiException from pprint import pprint # Configure HTTP basic authorization: basic configuration = cm_client.Configuration() configuration.username = 'YOUR_USERNAME' configuration.password = 'YOUR_PASSWORD' # create an instance of the API class api_instance = cm_client.ClouderaManagerResourceApi(cm_client.ApiClient(configuration)) body = cm_client.ApiHostNameList() # ApiHostNameList | (optional) try: # Decommission the given hosts. api_response = api_instance.hosts_decommission_command(body=body) pprint(api_response) except ApiException as e: print("Exception when calling ClouderaManagerResourceApi->hosts_decommission_command: %s\n" % e)     For CM to deserialize this request, the body being sent must be of type ApiHostNameList. ApiHostNameList is just a list of strings that are the host names you want decommissioned [1].   items list[str]     Here is an example that tells the defined CM (api_host) to decommission two hosts (host3.example.com and host4.example.com) defined in the ApiHostNameList assigned to the body:   import cm_client from cm_client.rest import ApiException from pprint import pprint # Configure HTTP basic authorization: basic cm_client.configuration.username = 'admin' cm_client.configuration.password = 'admin' cm_client.configuration.verify_ssl = False # Create an instance of the API class api_host = 'https://cmhost.example.com' port = '7183' api_version = 'v30' # Construct base URL for API # http://cmhost:7180/api/v30 api_url = api_host + ':' + port + '/api/' + api_version api_client = cm_client.ApiClient(api_url) api_instance = cm_client.ClouderaManagerResourceApi(api_client) body = cm_client.ApiHostNameList([" host3.example.com ", " host4.example.com "]) try: # Decommission the given hosts. api_response = api_instance.hosts_decommission_command(body=body) pprint(api_response) except ApiException as e: print("Exception when calling ClouderaManagerResourceApi->hosts_decommission_command: %s\n" % e)   This endpoint will return an ApiCommand object which can be used in further code to monitor the progress of the command along with returning other details that I will not be covering in this answer [2].       [0] https://archive.cloudera.com/cm6/6.0.0/generic/jar/cm_api/swagger-html-sdk-docs/python/docs/ClouderaManagerResourceApi.html#hosts_decommission_command   [1] https://archive.cloudera.com/cm6/6.0.0/generic/jar/cm_api/swagger-html-sdk-docs/python/docs/ApiHostNameList.html   [2] https://archive.cloudera.com/cm6/6.0.0/generic/jar/cm_api/swagger-html-sdk-docs/python/docs/ApiCommand.html ... View more

This is a known issue for Cloudera where this endpoint always returns the license message and isn't functional.   Use the API endpoint /cm/commands/hostsDecommission or /cm/commands/hostsRecommission instead.   ... View more

I thought you were restarting the CM server each time but I'm glad you figured it out! ... View more

Try the jar I linked you first and as a note CM doesn't follow referrals so you may have to use the global catalog port. ... View more

Use LDAP binding and set the bind username to what you set here (along with the bind password in CM):   CN=username,OU=Hadoop,OU=Prod,OU=ServiceAccounts,OU=Users,OU=Site,DC=domain,DC=org    Then from the output of your ldapsearch make sure the attributes and membership are what you expect and have configured in CM.     You can also test the ldap config set in CM with the following: https://github.com/gdgt/ldapcheck/releases (grab the one with dependencies) https://raw.githubusercontent.com/gdgt/ldapcheck/master/src/main/resources/ldap-config.properties (for sample config)   On the CM node: java -classpath '/usr/share/cmf/common_jars/*:./cmldap-v1.0.0-cm5.jar' com.gdgt.app.LdapChk 'ldap-config.properties'         ... View more

Check that the agent can talk to the CM first and then verify that the CM is actually able to pull down a el7 parcel (I've seen this where only the el6 parcel was present and one node was el7). Then try shutting the agent down and clearing out the .flood folder from the path you mentioned before starting the agent again.    Overall hard to say exactly what's going on without more information. ... View more

@dchu You can check the CM server log at /var/log/cloudera-scm-server/cloudera-scm-server.log while you attempt to log in to see what the exception is (if there is one).   Can you show an example query using ldapsearch to return a user? (redact anything you don't want seen publicly) ... View more

@nonames Go to one of the hosts and look through the /var/log/cloudera-scm-agent/cloudera-scm-agent.log file for any exceptions talking to the CM. Also go to the CM->Hosts tab and check that the agents are heartbeating (under 15 secs each interval).   If the agents are in bad health and not talking to CM then there will no way for the agents to know to fetch a parcel from CM so you must resolve the health issues with the agents to the CM. ... View more

Change the directories below for Service Monitor since the procedure is the same as for the Host Monitor.   You can salvage the contents of the Host Monitor by using the LDBStoreTool Java Class to repair the corrupted LDB:   Make sure the Host Monitor is stopped completely (it should be since it is unable to open this LDB). Backup the /var/lib/cloudera-host-monitor directory with tar or cp. Run the LDBStoreTool Java class to try and bring the corrupt database to a consistent state (please adjust the directory to the one reported in the exception): java -cp "/usr/share/cmf/lib/*" com.cloudera.cmon.tstore.leveldb.tool.LDBStoreTool repair --directory /var/lib/cloudera-host-monitor/subject_record/subject_ts/partitions/subject_ts_2017-10-30T18:03:04.415Z [ main] log INFO Logging to org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via org.mortbay.log.Slf4jLog [ main] CMONConfiguration INFO Config: jar:file:/usr/share/cmf/common_jars/firehose-5.12.1.jar!/cmon.conf [ main] ConfigUtil WARN Could not find configuration file cmon-cm-auth.conf [ main] LDBResourceManager INFO Max file descriptors: 4096 [ main] LDBResourceManager INFO Setting maximum open fds to: 2048 Running repair command Success   Start the Host Monitor and it should start now.   If the LDBStoreTool Java class is unable to repair the corrupt LDB then you will have to purge the /var/lib/cloudera-host-monitor directory similar to steps noted above by Michalis.   ... View more

This is actually a known bug on Cloudera's side since the parcel download component of the agent has incorrect TLS/SSL logic that is fixed in CM versions 5.12+.   A workaround without disabling TLS:   Add the Root CA of the CM certificate to the /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem.   If you don't have the Root CA of the CM certificate you can obtain it by doing:   openssl s_client -connect CM_HOST:7183 -showcerts   And then copying all of the below sections into a file: ----BEGIN CERTIFICATE----   ----END CERTIFICATE----   Before adding the contents of this file to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem.    ... View more