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

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