Cloudera Docs

Cloudera Manager 7.11.3 Cumulative hotfix 9.1

Know more about the Cloudera Manager 7.11.3 cumulative hotfixes 9.1.

This cumulative hotfix was released on October 10, 2024.

New features and changed behavior for Cloudera Manager 7.11.3 CHF 9.1 (version: 7.11.3.24-58365749):
Enhancements to the Observability page
The following changes have been made to the Observability page::
  • Added role-specific metrics to the Status and Charts Library tabs for component servers such as Pipelines, ADB, and SDX.
  • Added relevant metrics across all Observability component servers to the Status and Charts Library tabs for the Observability page.
Following are the list of known issues and their corresponding workarounds that are shipped for Cloudera Manager 7.11.3 CHF 9.1 (version: 7.11.3.24-58365749):
TSB 2024-806: Important upgrade required for Cloudera Manager versions 7.11.3 CHF8 and 7.11.3 CHF9
Cloudera recommends that customers running versions 7.11.3 with Cumulative Hotfix (CHF) 9 or 7.11.3 CHF8 of Cloudera Manager should upgrade to version 7.11.3 CHF9.1 to prevent issues with cluster management.
For the latest update on this issue see the corresponding Knowledge article: TSB 2024-806: Important upgrade required for Cloudera Manager versions 7.11.3 CHF8 and 7.11.3 CHF9.
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-69847:Replication policies might fail if source and target use different Kerberos encryption types

Replication policies might fail if the source and target Cloudera Manager instances use different encryption types in Kerberos because of different Java versions. For example, the Java 11 and higher versions might use the aes256-cts encryption type, and the versions lower than Java 11 might use the rc4-hmac encryption type.

Ensure that both the instances use the same Java version. If it is not possible to have the same Java versions on both the instances, ensure that they use the same encryption type for Kerberos. To check the encryption type in Cloudera Manager, search for krb_enc_types on the Cloudera Manager > Administration > Settings 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-70771: Running Ozone replication policy does not show performance reports
During an Ozone replication policy run, the A server error has occurred. See Cloudera Manager server log for details error message appears when you click:
  • Performance Reports > OZONE Performance Summary or Performance Reports > OZONE Performance Full on the Replication Policies page.
  • Download CSV on the Replication History page to download any report.
None
OPSAPS-70704: Kerberos connectivity check does not work as expected with JDK17 when you add Cloudera Manager peers
When you add a source Cloudera Manager that supports JDK17, the Kerberos connectivity check fails and the Error while reading /etc/krb5.conf on <hostname ; for all hosts>... error message appears.
None
OPSAPS-70713: Error appears when running Atlas replication policy if source or target clusters use Dell EMC Isilon storage
You cannot create an Atlas replication policy between clusters if one or both the clusters use Dell EMC Isilon storage.
None
CDPD-53185: Clear REPL_TXN_MAP table on target cluster when deleting a Hive ACID replication policy
The entry in REPL_TXN_MAP table on the target cluster is retained when the following conditions are true:
  1. A Hive ACID replication policy is replicating a transaction that requires multiple replication cycles to complete.
  2. The replication policy and databases used in it get deleted on the source and target cluster even before the transaction is completely replicated.

In this scenario, if you create a database using the same name as the deleted database on the source cluster, and then use the same name for the new Hive ACID replication policy to replicate the database, the replicated database on the target cluster is tagged as ‘database incompatible’. This happens after the housekeeper thread process (that runs every 11 days for an entry) deletes the retained entry.

Create another Hive ACID replication policy with a different name for the new database
OPSAPS-71592: Replication Manager does not read the default value of “ozone_replication_core_site_safety_valve” during Ozone replication policy run
During the Ozone replication policy run, Replication Manager does not read the value in the ozone_replication_core_site_safety_valve advanced configuration snippet if it is configured with the default value.
To mitigate this issue, you can use one of the following methods:
  • Remove some or all the properties in ozone_replication_core_site_safety_valve, and move them to ozone-conf/ozone-site.xml_service_safety_valve.
  • Add a dummy property with no value in ozone_replication_core_site_safety_valve. For example, add <property><name>dummy_property</name><value></value></property>, save the changes, and run the Ozone replication policy.
OPSAPS-72509, CDPD-32440: Hive metadata transfer to GCS fails with ClassNotFoundException
Hive replication policies from an on-premises cluster to cloud fails during the “Transfer Metadata Files” step if the following conditions are true:
  • the target is a GCS Data Lake
  • the source Cloudera Manager version is 7.11.3 CHF7, 7.11.3 CHF8, 7.11.3 CHF9, 7.11.3 CHF9.1, 7.11.3 CHF10, or 7.11.3 CHF11
This is because the fs.gs.delegation.token.binding property is already defined in the configuration and cannot be unset to disable the delegation tokens in the cloud connector service.
None
Following are the list of fixed issues that were shipped for Cloudera Manager 7.11.3 CHF 9.1 (version: 7.11.3.24-58365749):
OPSAPS-71249: Auto Action trigger for Impala Engine fails
Auto action triggers for the Impala engine do not work for Kerberos-enabled Private Cloud Base clusters. This issue is fixed now.
OPSAPS-71436: Telemetry publisher test Altus connection fails
An error occurred while running the test Altus connection action for Telemetry Publisher. This issue is fixed now.
OPSAPS-71210: Ozone Basic Canary displays an exception about loading S3 secret from keystore java.lang.RuntimeException: Encountered error when loading S3 secret from keystore: java.lang.NullPointerException.
This issue is now resolved.
OPSAPS-69603: Ozone CLI is not available to the CMON role if CMON is not installed on the same cluster as CDH.. This results in failure of Ozone Basic Canary because canary uses Ozone CLI to access Ozone.
This issue is now resolved. Ozone Basic Canary now runs successfully even if CMON and Ozone roles/gateway are running on different hosts or clusters.
OPSAPS-69692, OPSAPS-69693: Included filters for Ozone incremental replication in API endpoint
You can use the include filters in the POST /clusters/{clusterName}/services/{serviceName}/replications API to replicate only the filtered part of the Ozone bucket. You can use multiple path regular expressions to limit the data to be replicated for an Ozone bucket. For example, if you include the /path/to/data/.* and .*/data filters in the includeFilter field for the POST endpoint, the Ozone replication policy replicates only the keys that start with /path/to/data/.* or ends with .*/data in the Ozone bucket.
OPSAPS-70561: Improved page load performance of the “Bucket Browser” tab.
The Cloudera Manager > Clusters > [***OZONE SERVICE***] > Bucket Browser tab does not load all the entries of the bucket. Therefore, the page loads faster when you try to display the content of a large bucket with several keys in it.
OPSAPS-71067: Wrong interval sent from the Replication Manager UI after Ozone replication policy submit or edit process.
The schedule frequency works as expected after you edit the existing Ozone replication policies.
OPSAPS-71090: The spark.*.access.hadoopFileSystems gateway properties are not propagated to Livy.
Added new properties for configuring Spark 2 (spark.yarn.access.hadoopFileSystems) and Spark 3 (spark.kerberos.access.hadoopFileSystems) that propagate to Livy.
OPSAPS-71271: The precopylistingcheck script for Ozone replication policies uses the Ozone replication safety valve value.
The "Run Pre-Filelisting Check" step during Ozone replication uses the content of the ozone_replication_core_site_safety_valve" property value to configure the Ozone client for the source and the target Cloudera Manager.
OPSAPS-71615: Service monitor crashes due to an out-of-memory (OOM) error.
This issue is now resolved.
Fixed Common Vulnerabilities and Exposures
For information about Common Vulnerabilities and Exposures (CVE) that are fixed in Cloudera Manager 7.11.3 cumulative hotfix 9.1, see Fixed Common Vulnerabilities and Exposures in Cloudera Manager 7.11.3 cumulative hotfixes.

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

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