Known Issues and Limitations in Cloudera Manager 6.0.0

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.

Products affected: Cloudera Manager

Releases affected:
  • Cloudera Manager 5.5 and later
  • Cloudera Manager 6.0 until 6.3.3
  • Cloudera Manager 7.1.x

Users affected: Users with admin role in Cloudera Manager can impact end users of the service.

Impact:In production clusters this can result in a cluster-wide service outage; Already observed for the YARN service and the HDFS service in a few clusters.

Severity: High

Action required:
  • A workaround exists where instead of performing a restart we recommend performing a stop/start of the services.
  • Issue is fixed in CM-6.3.4, CM-7.2.1 and above.

Knowledge article: For the latest update on this issue see the corresponding Knowledge article: Cloudera Customer Advisory: Cloudera Manager 6.x issue with service role Resume

Cloudera Manager installation fails on MariaDB 10.2.8 and later

When installing Cloudera Manager using MariaDB 10.2.8 or later, the Cloudera Manager web server doesn't come up and the install process ends with a failed status. The cloudera-scm-server.log includes the following SQL error:

2019-08-28 04:37:10,171 FATAL main:org.hsqldb.cmdline.SqlFile: SQL Error at 'UTF-8' line 57:
  "alter table ROLE_CONFIG_GROUPS
  drop column REVISION_ID"
  Key column 'REVISION_ID' doesn't exist in table
2019-08-28 04:37:10,171 FATAL main:org.hsqldb.cmdline.SqlFile: Rolling back SQL transaction.
2019-08-28 04:37:10,172 ERROR main:com.cloudera.enterprise.dbutil.SqlFileRunner: Exception while executing ddl scripts.
  com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Key column 'REVISION_ID' doesn't exist in table

Note that MariaDB 10.2.8 is provided by default in some operating systems, including SLES 12 SP4.

Workaround: Replace the default MariaDB 10.2.x version with MariaDB 10.2.7.

Affected Versions: MariaDB 10.2.8 and later

Cloudera Issue: OPSAPS-52340

ZooKeeper JMX did not support TLS when managed by Cloudera Manager

The ZooKeeper service optionally exposes a JMX port used for reporting and metrics. By default, Cloudera Manager enables this port, but prior to Cloudera Manager 6.1.0, it did not support mutual TLS authentication on this connection. While JMX has a password-based authentication mechanism that Cloudera Manager enables by default, weaknesses have been found in the authentication mechanism, and Oracle now advises JMX connections to enable mutual TLS authentication in addition to password-based authentication. A successful attack may leak data, cause denial of service, or even allow arbitrary code execution on the Java process that exposes a JMX port. Beginning in Cloudera Manager 6.1.0, it is possible to configure mutual TLS authentication on ZooKeeper’s JMX port.

Products affected: ZooKeeper

Releases affected: Cloudera Manager 6.1.0 and lower, Cloudera Manager 5.16 and lower

Users affected: All

Date/time of detection: June 7, 2018

Severity (Low/Medium/High): 9.8 High (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Impact: Remote code execution

CVE: CVE-2018-11744

Immediate action required: Upgrade to Cloudera Manager 6.1.0 and enable TLS for the ZooKeeper JMX port by turning on the configuration settings “Enable TLS/SSL for ZooKeeper JMX” and “Enable TLS client authentication for JMX port” on the ZooKeeper service and configuring the appropriate TLS settings. Alternatively, disable the ZooKeeper JMX port via the configuration setting “Enable JMX Agent” on the ZooKeeper service.

Addressed in release/refresh/patch: Cloudera Manager 6.1.0

The restart Cloudera Manager Agent command does not restart the Agent Listener

When you restart the Cloudera Manager Agent, the Agent Listener (the status_server process) does not restart. This can cause issues if you make changes to TLS for Agents after you have installed Cloudera Manager since the Agent Listener needs to be restarted for TLS changes to take effect.

Workaround: Run the following command on every Agent host with supervisorctl:
/opt/cloudera/cm-agent/bin/supervisorctl -c /var/run/cloudera-scm-agent/supervisor/supervisord.conf restart status_server

This command requires root access to the host. supervisorctl is owned by the cloudera-scm user, but supervisord.conf is owned by root.

Affected Versions: Cloudera Manager 6.0.x, 6.1.x

Cloudera Issue: OPSAPS-48886

Backup and Disaster Recovery (BDR) performance regression after upgrading to CDH 6.0.0

Hive replication with BDR experiences a performance regression when comparing CDH 6.0.0 and CDH 5.14.4. The slowdown occurs during the import step. For example, the performance regression may only be 10% for 4 million partitions. As the number of partitions goes down though, the performance impact becomes more visible. For example, 100,000 partitions may experience a 20% performance regression.

Affected Versions: Cloudera Manager 6.0.0, 6.01, 6.1.0; CDH 6.0.0, 6.0.1, 6.1.0

Cloudera Issue: OPSAPS-47520

Cloudera Manager allows more than a single space in YARN Admin ACLs

When adding a YARN Admin ACL in Cloudera Manager, you are allowed to enter multiple spaces in the entry. The space is the separator between the user and group lists, and only a single space should be allowed in the entry. All entries that appear after a second single space in a YARN Admin ACL will be ignored.

Affected Versions: Cloudera Manager 6.0.0, 6.0.1, 6.1.0

Cloudera Issue: OPSAPS-47688

Integer data types map to Float in Swagger API client

Integer data types show up as floating point numbers when using the Cloudera Manager API Python client.

Affected Versions: Cloudera Manager 6.0.0, 6.0.1, 6.1.0

Cloudera Issue: OPSAPS-45689

Solr Service reports stale configurations even after restart

Solr reports stale configurations, and the Solr Server role fails to start with the following error: Role failed to start due to error: The archive already contains creds.localjceks. The issue occurs if your deployment has Solr and HDFS uses LDAP Group Mapping.

Workaround: If you have a CDH 5 cluster and use LDAP Group Mapping, do not upgrade to CDH 6.0.0. If you have a CDH 6.0.0 cluster, disable LDAP Group Mappings.

Affected Versions: Cloudera Manager 6.0.0 and CDH 6.0.0

Fixed Versions: Cloudera Manager 6.0.1

Cloudera Issue: OPSAPS-47321

Apache Accumulo is not supported with Cloudera Manager

Running Apache Accumulo on top of a CDH 6.0.0 cluster is not currently supported. If you try to upgrade to CDH 6.0.0 you will be asked to remove the Accumulo service from your cluster. Running Accumulo on top of CDH 6 will be supported in a future release.

Affected Versions: Cloudera Manager 6.0.0, 6.0.1

Fixed Versions:Cloudera Manager 6.1.0

Cloudera Issue: OPSAPS-42807, OPSAPS-42814

Cloudera Data Science Workbench is not supported with Cloudera Manager 6.0.x

Cloudera Data Science Workbench is not supported with Cloudera Manager 6.0.x. Cloudera Data Science Workbench 1.5.0 (and higher) is supported with Cloudera Manager 6.1.x (and higher).

Affected Versions: Cloudera Manager 6.0.x

Cloudera Issue: DSE-2769

Externally authenticated users cannot view their roles or previous session

Usually, a user can see their assigned roles and most recent successful login by navigating to <Username> > My Profile in the Cloudera Manager Admin Console. The fields appear blank for users who use an external authentication method, such as SAML.

This issue is only a display issue and does not affect any functionality. The user can perform any tasks available to their assigned roles.

Workaround: User accounts with roles that can view the Roles page, such as a Full Administrator, can view the roles assigned to all Cloudera Manager user accounts and their session information.

Affected Versions: Cloudera Manager 6.0.0, 6.0.1

Fixed Versions: Cloudera Manager 6.1.0

Cloudera Issue: OPSAPS-46996, OPSAPS-47025

Package Installation of CDH Fails

When you install CDH with packages from a custom repository, ensure that the version of CDH you select for Select the version of CDH matches the version of CDH for the custom repository. Selecting the CDH version and specifying a custom repository are done during the Select Repository stage of installation.

If the versions do not match, installation fails.

Affected Versions: Cloudera Manager 6.x

Fixed Versions: N/A

Apache Issue: N/A

Cloudera Issue: OPSAPS-45703

Backup and Disaster Recovery replication to/from Cloudera Manager 6 clusters require Cloudera Manager 5.14.0 or higher

You can only use BDR to replicate to/from clusters managed by Cloudera Manager 6 with Cloudera Manager 5.14.0 or higher.

Affected versions: Cloudera Manager 6.x

Cloudera Issue: OPSAPS-42207