@sanjaysubs You should be able to track operations and relevant logs under details page if you retry the operation. Also check CM server logs before the message: Failed to complete installation that should give more details. Make sure your CM repo has allkeys.asc file. If not add it from the cloudera repository link.   Hope this helps, Paras Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button. ... View more

@snm1523    1. This is a functionality to be provided by the OS vendor since package installations use yum which is not Cloudera managed. 2. No we don't have another way. Ideally for both these security specific use cases, you should create temporary /local repositories only where authentication is not required.   https://docs.cloudera.com/cdp-private-cloud-upgrade/latest/upgrade/topics/cm_ig_create_local_package_repo.html     Hope this helps, Paras Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button. ... View more

@PDDF_VIGNESH  I hope you have connected to the port configured for your cluster.Does the URL return successful response on browser? The responses need to be checked only during the time of issue.   The JMX is generated by datanode. Not getting a response means there are either issues with datanode or any network issues with the coomunication.       ... View more

@PDDF_VIGNESH    See if you are able to get successful response from the agent to the host reported in the logs below: http://datanode02.hadoop:1006/jmx Few checks: 1. curl http://datanode02.hadoop:1006/jmx 2. telnet datanode02.hadoop:1006   If this is successful, restart the agent. If there is issue with response, you need to review DN logs for issues/workarounds suggested previously.   Hope this helps, Paras Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button.   ... View more

@Juris     The default filter value of 7 days is hardcoded in Hue.  You can find this set in your cluster hosts /usr/lib/hue/apps/jobbrowser/src/jobbrowser/templates/job_browser.mako [default file] as shown below. As a workaround this file can be edited across all hosts followed by Hue restart but changes would persist for all users. We generally don't recommend to edit the install files but just providing you with the information here.   self.timeValueFilter  = ko.observable (7).extend({ throttle: 500 }); self.timeUnitFilter  = ko.observable ('days').extend({ throttle: 500 });   Hope this helps, Paras Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button. ... View more

@Jua    Cloudera expects HA solutions for RDBMS to be transparent to Cloudera software, and therefore are not supported and debugged by Cloudera.   Having said that you can try to modify the /etc/cloudera-scm-server/db.properties with the URL in below format and test it out. com.cloudera.cmf.db.type=oracle com.cloudera.cmf.orm.hibernate.connection.driver_class=oracle.jdbc.driver.OracleDriver com.cloudera.cmf.orm.hibernate.connection.url=jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=off)(FAILOVER=on) / (CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS=(PROTOCOL=TCP)(HOST=hostname1)(PORT=1521)) / (ADDRESS=(PROTOCOL=TCP)(HOST=hostname2)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=<Oracle-SID>))) com.cloudera.cmf.orm.hibernate.connection.username=<CM-Oracle-user> com.cloudera.cmf.orm.hibernate.connection.password=<password>   I suggest to check with your DB vendor to validate the jdbc URL if this still fails.   Hope this helps, Paras Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button. ... View more

@Zhaojie    The errors to focus here are the below ones which are causing unknown health alerts. This is being caused because CM agent is not able to connect to Host Monitor.   Please ensure the hosts generating the alerts have space available and are not overloaded in terms of COU and memory. You can also try to hard restart the CM agents if this is feasible option since hard restart will stop the services running on the host and clear any thread deadlocks in cluster services.   The health test result for HOST_SCM_HEALTH has become bad: This host is in contact with the Cloudera Manager Server. This host is not in contact with the Host Monitor. The health test result for HOST_AGENT_LOG_DIRECTORY_FREE_SPACE has become unknown: Not enough data to test: Test of whether the Cloudera Manager Agent's log directory has enough free space.   Hope this helps, Paras Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button.   ... View more

@akshay0103    Please check the Hue.ini content under field [useradmin] if there are any non default permissions being used? Are you adding the user using create home directory permissions?   ... View more