Cloudera Docs

Known Issues in Cloudera Manager 7.1.1

CDPD-4139: A cluster with indices stored on HDFS that was created before enabling TLS, will get the following error message after enabling TLS and starting the cluster:
Will not load SolrCore SOLR_CORE_NAME because it has been replaced due to failover.
Workaround: Recreate the collection after enabling TLS. New collections created after enabling TLS are not affected.
CDPD-10352: Hive on Tez cannot run certain queries on tables stored in encryption zones. This only happens when the KMS connection is SSL encrypted and a self-signed certificate is used. Users may see a SSLHandshakeException in the Hive logs.
Workaround: There are two workarounds:
  • Install a self signed SSL certificate into the cacerts file on all hosts.
  • Copy the ssl-client.xml file to a directory that is available to all hosts. Then set the the following configuration, tez.aux.uris=path-to-ssl-client.xml in the Hive on Tez Service Environment Advanced Configuration Snippet (Safety Valve).
OPSAPS-56286: If you are running multiple instances of the Schema Registry Server role, an incorrect health state will be displayed for the Schema Registry service even if the underlying role instances are healthy. This is caused by health tests being disabled for the Schema Registry Server due to an invalid configuration.
Workaround:
  1. Log in to the Cloudera Manager Server host.
  2. Delete or move the Schema Registry CDH 5 compatible CSD from /opt/cloudera/cm/csd/.For example:
    $ rm /opt/cloudera/cm/csd/SCHEMAREGISTRY_C5-[VERSION_NUMBER].jar
  3. Restart the Cloudera Manager server:
    $ service cloudera-scm-server restart
CDPD-12060: ID Broker is not supported in Cloudera Manager 7.1.1
OPSAPS-56404: On an upgraded cluster, if the Knox service is added post upgrade and the Ranger Knox plugin is enabled, audits to HDFS for the Knox Ranger plugin fail with permission error on HDFS.
Workaround: When we add Knox service post upgrade, and Ranger Knox plugin is enabled, in the Cloudera Manager Admin Console, go to the Knox service and select Action menu > Create Ranger Knox Plugin Audit Directory, this action should be performed to create the HDFS audit directory.
OPSAPS-56397: When restarting the cluster or performing a cluster upgrade, you may encounter an error when starting a role because there is a pending command running on that role. This can happen if a diagnostic bundle collection is running.
Workaround: If this occurs, you can resume the upgrade once the collection finishes. To avoid this scenario, do not run or schedule diagnostic bundle collection before starting a role or performing a cluster upgrade.
Cloudera Bug: OPSAPS-55785: Upgrade of compute clusters from 7.0.3 -> 7.1.1 is not supported
Upgrades of compute clusters, and of base clusters with one or more associated data contexts, from Cloudera Runtime 7.0 to Cloudera Runtime 7.1 is not supported. The user must first delete their compute clusters, remove any data contexts, upgrade the base cluster and then rebuild.
Cloudera Bug: OPSAPS-55671: Rolling upgrades from Cloudera Runtime 7.0 to Cloudera Runtime 7.1 are not supported
Cluster downtime is required for upgrade.
CDPD-11765, CDPD-11718: Replication Manager cloud replication with Auto-TLS enabled cluster may not function properly due to some functional outage in Hive with cloud storage in CDP Private Cloud Base Auto-TLS enabled cluster.
CDPD-12123: HDFS replication performance is either slowed down or not on the expected lines with CDH/CM 7.1.1. Post-upgrade, queue which the user is running workloads cannot grow beyond the configured capacity till its maximum capacity.
Workaround: Once the cluster is upgraded to CDP Private Cloud Base 7.1.1, user may need to tune yarn.scheduler.capacity.<queuepath>.user-limit-factor to a value greater than 1. This configuration enables the queue usage to grow beyond its configured capacity, till its maximum capacity configured.
OPSAPS-54477 Flume not supported in CDP Private Cloud Base
You must remove the Flume service before upgrading to CDP Private Cloud Base.
OPSAPS-54299 – Installing Hive on Tez and HMS in the incorrect order causes HiveServer failure
You need to install Hive on Tez and HMS in the correct order; otherwise, HiveServer fails. You need to install additional HiveServer roles to Hive on Tez, not the Hive service; otherwise, HiveServer fails. See Installing Hive on Tez for the correct procedures.
OPSAPS-65189: Accessing Cloudera Manager through Knox displays the following error:

Bad Message 431 reason: Request Header Fields Too Large

Workaround: Modify the Cloudera Manager Server configuration /etc/default/cloudera-scm-server file to increase the header size from 8 KB, which is the default value, to 65 KB in the Java options as shown below:
export CMF_JAVA_OPTS="...existing options...
-Dcom.cloudera.server.cmf.WebServerImpl.HTTP_HEADER_SIZE_BYTES=65536
-Dcom.cloudera.server.cmf.WebServerImpl.HTTPS_HEADER_SIZE_BYTES=65536"

Technical Service Bulletins

TSB-431: Cloudera Manager 6.x issue with the service role Resume
If a selected service role on a node is restarted and fails, and the customer clicks the "Resume" button in Cloudera Manager, the service role on all of the nodes will be restarted concurrently.
Action required
Workaround
  • Instead of performing a restart we recommend performing a stop/start of the services.
  • The issue is addressed in Cloudera Manager 7.2.1 and higher versions
Knowledge article
For more information about this issue, see the corresponding Knowledge article:

Cloudera Customer Advisory: Cloudera Manager 6.x issue with service role Resume

TSB 2021-488: Cloudera Manager is vulnerable to Cross-Site-Scripting attack
Cloudera Manager may be vulnerable to Cross-Site-Scripting vulnerabilities identified by CVE-2021-29243 and CVE-2021-32482. A remote attacker can exploit this vulnerability and execute malicious code in the affected application.
CVE
  • CVE-2021-29243
  • CVE-2021-32482
Impact
This is an XSS issue. An administrator could be tricked to click on a link that may expose certain information such as session cookies.
Action required
  • Upgrade (recommended)
    Upgrade to a version containing the fix.
  • Workaround
    None
Knowledge article
For the latest update on this issue see the corresponding Knowledge article:

TSB 2021-488: Cloudera Manager vulnerable to Cross-Site-Scripting attack (CVE-2021-29243 and ​​CVE-2021-32482)

TSB 2021-530: Local File Inclusion (LFI) Vulnerability in Navigator
After successful user authentication to the Navigator Metadata Server and enabling dev mode of Navigator Metadata Server, local file inclusion can be performed through the Navigator’s embedded Solr web UI. All files can be accessed for reading which can be opened as cloudera-scm OS user. This is related to Apache Solr CVE-2020-13941.
Impact
  • Attackers can read files on the Navigator Metadata Server host with the OS user privileges running the Navigator Metadata Server.
  • How to confirm the vulnerability
    • Open https://<navigator_host>:<navigator_port>/debug

      Please check for Dev-mode status. To make the exploit work, dev-mode must be enabled. Please note that restarting the NMS automatically disables dev-mode.

Action required
  • Upgrade (recommended)
    • Upgrade to Cloudera Manager 7.4.4 or higher
    • Please contact Cloudera Support for patched version of Cloudera Manager 6.3.4
  • Workaround
    • For Cloudera Manager 6.x:
      • Login to the Navigator Metadata Server host and edit these files: 
        /opt/cloudera/cm/cloudera-navigator-server/search-schema/solr/2900/nav_elements/conf/solrconfig.xml
/opt/cloudera/cm/cloudera-navigator-server/search-schema/solr/2900/nav_relations/conf/solrconfig.xml
      • Remove the entry: 
        <requestHandler name="/replication" class="solr.ReplicationHandler" startup="lazy" />
    • For Cloudera Manager 5.x:
      • Login to the Navigator Metadata Server host and edit these files: 
        /usr/share/cmf/cloudera-navigator-server/search-schema/solr/2900/nav_elements/conf/solrconfig.xml
/usr/share/cmf/cloudera-navigator-server/search-schema/solr/2900/nav_relations/conf/solrconfig.xml
      • Remove the entry:
        <requestHandler name="/replication" class="solr.ReplicationHandler" startup="lazy" />
    • Restart Navigator Metadata Server
    • This is a temporary solution and has to be followed-up with the recommended long term solution below.
Knowledge article
For the latest update on this issue see the corresponding Knowledge article:

TSB 2021-530: CVE-2021-30131 - Local File Inclusion (LFI) Vulnerability in Navigator