@elifsurmeli,   This usually indicates that the Solr data is out of sync (version-wise) with what nav_upgrade_ordinal table in your Navigator Metadata Server database.   Please do the following to see if that is the cause:   (1)  on the Navigator Metadata host, run rpm -qa |grep cloudera and post the results (so we can confirm the version of Navigator   (2)  Run the following query in your Navigator Metadata Server database (via your favorite db tool):   select * from NAV_UPGRADE_ORDINAL;   NOTE:  The above assumes that you are "using" the Navigator Metadata Server database in your database server client.   With that information, we can see if they may be out of sync and we can decide if we need to adjust the values. ... View more

Also, for permissions, the file needs to be readable by any users accessing it. It is not a sensitive file since it does not contain private key material.  The role of the "trust store" is to allow clients to be able to define server certificates as "trusted" so the intent of the jssecacerts file is to only contain certificates of certificate authorities that are trusted. ... View more

@hamed2005,   The password should not be necessary since the keystore is only being used as a trust store (needing only read access).  Cloudera Manager would only need to read from the file.   Try removing -Djavax.net.ssl.trustStorePassword=changeit and then restart Cloudera Manager.   If that works fine for you, I'll work with the Cloudera documentation team to get our documentation updated to remove the password.   -Ben     ... View more

@ludof,   As mentioned, if JAVA_HOME is set, that is generally what java procesess on the hosts will use.  If JAVA_HOME is not set then the process will do its best to identify the release to use.   If you wish, you can remove the java versions you do not need.   The JVM versions you are using are old.  I recommend you consider installing the latest supported JVM release for your verison of CM/CDH.   For more information on supported JDKs:   https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#pcm_jdk   For more information regarding installation of a JDK:   https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_ig_jdk_installation.html   Steps to configure a CDH and Management Service to use a specific JDK:   https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_java_home_location.html#cmig_topic_16   We recommend removing any JDKs from your system if they are not what you want to use. The JDK versions you have now were installed from Cloudera's package repository, but they are older and Cloudera does not intend to supply newer releases in its repository.  Since JDK 1.6 is only installed to support legacy CDH 4 clusters, you can safely remove JDK 1.6.0_31 from your system unless you are using it for some other purpose (not CDH).   If you have specific questions, please let us know   ... View more

Hi @ludof,   If a third party vendor instructs you to add or remove files in their parcel, that's just fine; it is best to follow their instructions. Since you are using Cloudera Manager, you should follow the instructions here: https://www.cloudera.com/documentation/other/connectors/teradata/1-x/topics/cctd_topic_3.html#concept_kv1_cj2_4n   The instructions you reference regarding the XML configuration apply to installation when Cloudera Manager is not managing the cluster.   If the documentation is correct, you should only need to create a sqoop1 gateway on any hosts that will be using the teradata connector and then deploy client config.  After that, distribute and activate the connector parcel.   Note the following that may be relevant to the problem you describe: Important: The Sqoop 1 Client Gateway is required for the Teradata Connector to work correctly. Cloudera recommends installing the Sqoop 1 Client Gateway role on any host used to execute the Sqoop CLI. If you do not already have the Sqoop Client service running on your cluster, see Managing the Sqoop 1 Client for instructions on how to add the service using the Cloudera Manager Admin Console. ... View more

@DataCrunch,   If you use Cloudera Manager to manage your cluster, you can use the charts for that host to monitor resources more closely.  It is a great way of keeping an eye on who is taking up what IO, disk, memory, etc.   https://www.cloudera.com/documentation/enterprise/latest/topics/cm_dg_view_charts.html ... View more

@ludof,   Thank you for your question. When using Cloudera Manager to manage your cluster, configuration for all your services is stored centrally in Cloudera Manager.  When a service role is started, Cloudera Manager assembles the necessary configuration which the agents will download and distribute to a unique "process" directory.  Those are the /run/cloudera-scm-agent directories you found to contain oozie-site.xml.   If you wish to change configuration for a service or role, you do so in Cloudera Manager itself so it can deploy the necessary configuration files and set the environment variables to run the process.   The oozie-site.xml file you found in the /opt/cloudera/parcels... directory is a "stock" file that ships with the parcels.  It is not intended for use or editing and should not be modified unless instructed by Cloudera.   In order for you to run client commands on a host, you will need to have Cloudera Manager distribute Client Configuration files.   These topics are explained in more detail here: https://www.cloudera.com/documentation/enterprise/latest/topics/cm_mc_service_config_overview.html   Let us know if you have any other questions. ... View more

Awesome!  Thank you for following up with the good news! ... View more

@Arjen,   Thank you for sharing your solution.   Just so there is no confusion, though, the agent does not require ntpd to heartbeat.  By default, however, the agent does run healthchecks that test ntpd or chronyd to ensure that offset is within expected parameters.   While failure of the healthchecks will result in a host being shown in bad health, it is not a functional characteristic of the health check to prevent heartbeats.   If adding ntpd was the only action that allowed the agent to heartbeat, then it could be there was some problem where the agent was not able to progress with the heartbeat due to an unusual condition.  If you or anyone hits a problem like this where the agent cannot heartbeat, let us know again and we will take a closer look.   My reason for explaining this was to make sure everyone was aware that NTP is not required for heartbeating.  The root cause may have been related to NTP, but it was not an intended feature limitation.   Thanks again, for sharing.   Cheers.   Ben ... View more