Cloudera Manager 7.11.3 Cumulative hotfix 4

Know more about the Cloudera Manager 7.11.3 cumulative hotfixes 4.

This cumulative hotfix was released on March 8, 2024.

New features and changed behavior for Cloudera Manager 7.11.3 CHF4 (version: 7.11.3.6-50817646):

FIPS support for JDK11 in Zeppelin: Added FIPS support for JDK11 in Zeppelin.

Following are the list of known issues and their corresponding workarounds that are shipped for Cloudera Manager 7.11.3 CHF4 (version: 7.11.3.6-50817646):

OPSAPS-68340: Zeppelin paragraph execution fails with the User not allowed to impersonate error.

Starting from Cloudera Manager 7.11.3, Cloudera Manager auto-configures the livy_admin_users configuration when Livy is run for the first time. If you add Zeppelin or Knox services later to the existing cluster and do not manually update the service user, the User not allowed to impersonate error is displayed.

If you add Zeppelin or Knox services later to the existing cluster, you must manually add the respective service user to the livy_admin_users configuration in the Livy configuration page.

OPSAPS-69342: Access issues identified in MariaDB 10.6 were causing discrepancies in High Availability (HA) mode

MariaDB 10.6, by default, includes the property require_secure_transport=ON in the configuration file (/etc/my.cnf), which is absent in MariaDB 10.4. This setting prohibits non-TLS connections, leading to access issues. This problem is observed in High Availability (HA) mode, where certain operations may not be using the same connection.

To resolve the issue temporarily, you can either comment out or disable the line require_secure_transport in the configuration file located at /etc/my.cnf.

OPSAPS-68452: Azul Open JDK 8 and 11 are not supported with Cloudera Manager

Azul Open JDK 8 and 11 are not supported with Cloudera Manager. To use Azul Open JDK 8 or 11 for Cloudera Manager RPM/DEBs, you must manually create a symlink between the Zulu JDK installation path and the default JDK path.

After installing Azul Open JDK8 or 11, you must run the following commands on all the hosts in the cluster:

Azul Open JDK 8

RHEL or SLES

# sudo ln -s /usr/lib/jvm/java-8-zulu-openjdk-jdk /usr/lib/jvm/java-8-openjdk

Ubuntu or Debian

# sudo ln -s /usr/lib/jvm/zulu-8-amd64 /usr/lib/jvm/java-8-openjdk

Azul Open JDK 11

For DEBs only

# sudo ln -s /usr/lib/jvm/zulu-11-amd64 /usr/lib/jvm/java-11

CDPD-62834: Status of the deleted table is seen as ACTIVE in Atlas after the completion of navigator2atlas migration process

The status of the deleted table displays as ACTIVE.

None

CDPD-62837: During the navigator2atlas process, the hive_storagedesc is incomplete in Atlas

For the hive_storagedesc entity, some of the attributes are not getting populated.

None

OPSAPS-69897: NPE in Ozone replication from CM 7.7.1 to CM 7.11.3

When you use source Cloudera Manager 7.7.1 and target Cloudera Manager 7.11.3 for Ozone replication policies, the policies fail with Failure during PreOzoneCopyListingCheck execution: null error. This is because the target Cloudera Manager 7.11.3 does not retrieve the required source bucket information for validation from the source Cloudera Manager 7.7.1 during the PreCopyListingCheck command phase. You come across this error when you use source Cloudera Manager versions lower than 7.10.1 and target Cloudera Manager versions higher than or equal to 7.10.1 in an Ozone replication policy.

Upgrade the source Cloudera Manager to 7.11.3 or higher version.

Following are the list of fixed issues that were shipped for Cloudera Manager 7.11.3 CHF4 (version: 7.11.3.6-50817646):

OPSAPS-69387: Update Spark 3 parcel CSD's repository URL to point to CDP 7.1.9.x cluster in CM: Updated the Spark 3 parcel's repository URL to point to https://archive.cloudera.com/p/spark3/3.3.7190.0/parcels/ instead of https://archive.cloudera.com/p/spark3/3.3.7180.0/parcels/.
OPSAPS-69711: Cloudera Manager - ECS Server host on RHEL 9.1 keeps getting entropy alerts: The host level entropy health test turns into BAD state if the OS version is among RHEL, Cent OS. OEL 9.x. That can cause BAD health state for the services deployed into these hosts. This issue is fixed now.
OPSAPS-69458: Custom properties atlas.jaas.KafkaClient.option.password appears in a clear text in CDP cluster services.: CDP Private Cloud Base 7.1.9 cluster had a configuration property with a clear text password which is a Information security breach. The password is now masked or encrypted in the cluster.
OPSAPS-69480: Hardcode MR add-opens-as-default config: Cloudera Manager uses fixed runtime versions when determining clients, instead of using the one connected to the deployed runtime version, which can cause issues. During an upgrade if an app is submitted with a client containing MAPREDUCE-7449 to a runtime that doesn't contain MAPREDUCE-7449's related changes, the application submission fails. To fix this issue MAPREDUCE-7468 changes the default behaviour of the feature to avoid including the placeholder by default. Cloudera Manager has a hardcoded property from the runtime versions where the replacement is correctly done in NM code.
OPSAPS-69481: Some Kafka connect metrics missing from Cloudera Manager due to conflicting definitions: Cloudera Manager now registers kafka_connect_connector_task_metrics_batch_size_avg and kafka_connect_connector_task_metrics_batch_size_max metrics correctly.
OPSAPS-69556: While upgrading from CDP Private Cloud Data Services 1.5.1 to 1.5.2, the public registry with public bits fails with ImagePull Errors, and the docker registry modified to point to docker-private during the upgrade: Previously, when upgrading using the Cloudera public registry with public bits, the Docker registry would incorrectly change to point to docker-private.infra.cloudera.com. This issue is now fixed to point to the correct registry.
OPSAPS-69357: Yarn application bundle script needs to be backwards compatible with python 2.7.: Application bundle collection has been fixed to support both Python2 and Python3 environments.
OPSAPS-68288: Cloudera Manager waits on "Refreshing Resource manager" during the time when the node-manager is being decommissioned: The decommission now works as expected.
OPSAPS-69502: Upgrade failures from CDH6 to 7.1.7 SP3 because ACL is not the expected for znode: Updated the zk-client.sh to follow the output change of the ZK CLI during upgrade so that the upgrade no longer fails.

The repositories for Cloudera Manager 7.11.3-CHF4 are listed in the following table:

Table 1. Cloudera Manager 7.11.3-CHF4
Repository Type	Repository Location
RHEL 9 Compatible	Repository: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/redhat9/yum` Repository File: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/redhat9/yum/cloudera-manager.repo`
RHEL 8 Compatible	Repository: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/redhat8/yum` Repository File: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/redhat8/yum/cloudera-manager.repo`
RHEL 7 Compatible	Repository: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/redhat7/yum` Repository File: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/redhat7/yum/cloudera-manager.repo`
SLES 15	Repository: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/sles15/yum` Repository File: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/sles15/yum/cloudera-manager.repo`
SLES 12	Repository: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/sles12/yum` Repository File: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/sles12/yum/cloudera-manager.repo`
Ubuntu 20	Repository: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/ubuntu2004/apt` Repository File: `https://username:password@archive.cloudera.com/p/cm7/7.11.3.6/ubuntu2004/apt/cloudera-manager.list`