@VuSand3259,     You can use this endpoint:   https://cloudera.github.io/cm_api/apidocs/v19/path__users_-userName-.html   using the PUT method via REST API allows you to update the user object defined here:   https://cloudera.github.io/cm_api/apidocs/v19/ns0_apiUser.html   For example, the following would make an existing user "mytestuser" a full administrator in CM 5.15 (you would need to use the api version that is right for your CM version):   curl -u cm_user:cm_pass -H "Content-Type: application/json" -X PUT -d '{"roles" : [ "ROLE_ADMIN"]}' http://cm_host:7180/api/v19/users/mytestuser ... View more

@BenK,   Cloudera Manager's steps for starting servers are based on internal dependencies, so there isn't a configuration in Cloudera Manager that could be used to change it.  I suspect that the StreamSets fix may have been around dependencies, in the CSD, but that's just a guess.   The only alternative I can see at this time is to bring the services up one at a time. You could do that with the API and wrap it in the script:   https://cloudera.github.io/cm_api/apidocs/v14/path__clusters_-clusterName-_services_-serviceName-_commands_start.html   You can see all REST API stuff here: https://cloudera.github.io/cm_api/apidocs/v14/   For instance, you could write a shell script that executes a serice of "curl" commands that start the services. There is a complexity in that you need to wait till the service is really running before started, but that can be accomplished by using:   https://cloudera.github.io/cm_api/apidocs/v14/path__clusters_-clusterName-_services_-serviceName-.html   and parsing out the status.  If a service is "STARTED" start the next one...   "serviceState" : "STARTED",   It might be something to play with if you are stuck in this state long term.  The API is in Java and Python and you can find examples of usage here too: https://cloudera.github.io/cm_api/ ... View more

@Genthandsome,   Actually, that stackoverflow may be off target since it talks about public addresses.  Your browser needs to resolve a hostname into an IP so that your computer can connect to Hue.  If that resolution (or mapping) fails then the client (browser in this case) cannot connect to the host specified in the browser's URL. ... View more

@Prav,   More or less, I think we are on the same page.  One thing to keep in mind, too is the offset so that you can make sure you are seeing all the results in the timeperiod.   For example:   Return the first 1000 queries starting from most recent:   https://hostname:7183/api/v17/clusters/cluster/services/impala/impalaQueries?from=2018-07-09T12:59:32.776Z&to=2018-07-10&limit=1000   Retrun the next 1000 queries:   https://hostname:7183/api/v17/clusters/cluster/services/impala/impalaQueries?from=2018-07-09T12:59:32.776Z&to=2018-07-10&limit=1000&offset=1000   Return the next 1000:   https://hostname:7183/api/v17/clusters/cluster/services/impala/impalaQueries?from=2018-07-09T12:59:32.776Z&to=2018-07-10&limit=1000&offset=2000   (Keep doing this until you get 0 results) If you get 0 results AND you also have a warning, that means you have another partition to traverse. In that case, you would use the date/time in the warning to populate the "to" parameter in the next query (assuming the warnings show the date time 2018-07-10T01:16:17.434Z):   https://hostname:7183/api/v17/clusters/cluster/services/impala/impalaQueries?from=2018-07-09T12:59:32.776Z&to=2018-07-10T01:16:17.434Z&limit=1000   If the number of queries is equal to the limit, increment the offset to return the next 1000:   https://hostname:7183/api/v17/clusters/cluster/services/impala/impalaQueries?from=2018-07-09T12:59:32.776Z&to=2018-07-10T01:16:17.434Z&limit=1000&offset=1000   and repeat until you get 0 queries returned.   If you get another warnings date/time, replace the "to" parameter value with it and repeat. If you get 0 results and 0 warnings, there are no more queries to retrieve.   NOTE:  While you are doing all these queries, running queries may complete, so it is a good idea to specify an initial "to" date that is a little bit in the past if you want consistent results. ... View more

I have the SSSD configured to short name and everything looks good now!!! Thanks @bgooley ... View more

One other thing. It looks like there were some issues with the Ubuntu OS and after switching over to Centos 7.5 the CDH 5.15 install ran without much issues. I have a question though, in the the install screens it has a Data Node configuration value:   DataNode Data Directory dfs.data.dir, dfs.datanode.data.dir   Comma-delimited list of directories on the local file system where the DataNode stores HDFS block data. Typical values are /data/N/dfs/dn for N = 1, 2, 3.... These directories should be mounted using the noatime option, and the disks should be configured using JBOD. RAID is not recommended. In JBOD mode say the server has 20 hard disks so each of the 20 disk will have 20 file mount points. I think we need to set this value to comma-delimited /data/1/dfs/dn, /data/2/dfs/dn, /data/3/dfs/dn....../data/20/dfs/dn . Now what happens if some of the data nodes have different number of JBOD disks say 20 disks in some and 10 disks in others. Since this is a global variable dfs.data.dir how does it allocate the 20 data directories in those data nodes with only 10 JBOD hard disks? Since there is no hostname defined in this variable to indicate different nunber of disks in different hosts. Also in future if new datanodes are added with different number of disks how is this specified while adding new data nodes? Thanks! ... View more

@PeterLuo,   The "config.zip" error can be ignored.  It is expected due to a cosmetic bug that is fixed in Cloudera Manager 5.13 and on.   First thing we need to know is how you know the region server did not start.  What are you seeing when you try to start HBase? Also, is it just one Region Server or are other HBase roles also not starting?   The best place to start troubleshooting a Cloudera Manager initiated start of a role is to review:   - the agent server logs on the host where the region server failed to start - the stderr.log and stdout.log files for the process will give clues about any issues the supervisor is having starting the process.   Here is the general process of how a service starts:   - You click start in CM - CM tells the agent to heartbeat - the agent sends a heartbeat to CM - CM replies with a heartbeat response - Agent compares what it has running with what CM says should be running (and decides what to do to match what CM says) - Agent retrieves the files necessary to start the process from CM and lays down the files - Agent signals the supervisor process - Supervisor checks to see if processes need to stop/start - If starting, the supervisor will execute CM shell scripts to start the process - Once the shell is complete, the process runs as a child process of the supervisor.   Hopefully that helps clarify the process so you can start troubleshooting. The process's stdout.log file (in the process directory's logs directory) is a good place to start. You can view them in Cloudera Manager by going to the role's status page and clicking the "Log Files" drop-down. ... View more

Did you able to fix the issue, I am also facing the same. if you are able to fix it, can you pls share the resolution. ... View more