Cloudera Docs

Cloudera Manager 7.11.3 Cumulative hotfix 11

Know more about the Cloudera Manager 7.11.3 cumulative hotfixes 11.

This cumulative hotfix was released on December 19, 2024.

New features and changed behavior for Cloudera Manager 7.11.3 CHF 11 (version: 7.11.3.28-60766845):
Enhancements to Replication Manager
The Ozone commands for Ozone replication policy are run impersonating the users that you specify in the Run as Username and Run on Peer as Username fields in the Create Ozone replication policy wizard when the Ozone replication policy is run. The user accessing the buckets for OBS-to-OBS replication is determined by the access key specified in the fs.s3a.access.key property.

When the source and target clusters are secure, and Ranger is enabled for Ozone, you must set the required permissions for Ozone replication using Ozone replication policies. For more information, see Preparing to create Ozone replication policies.

Following are the list of known issues and their corresponding workarounds that are shipped for Cloudera Manager 7.11.3 CHF 11 (version: 7.11.3.28-60766845):
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-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.
DMX-3973: Ozone replication policy with linked bucket as destination fails intermittently
When you create an Ozone replication policy using a linked/non-linked source cluster bucket and a linked target bucket, the replication policy fails during the "Trigger a OZONE replication job on one of the available OZONE roles" step.
None
OPSAPS-68143:Ozone replication policy fails for empty source OBS bucket
An Ozone incremental replication policy for an OBS bucket fails during the “Run File Listing on Peer cluster” step when the source bucket is empty.
None
CDPD-76705: Ozone incremental replication fails to copy renamed directory
Ozone incremental replication using Ozone replication policies succeed but might fail to sync nested renames for FSO buckets.
When a directory and its contents are renamed between the replication runs, the outer level rename synced but did not sync the contents with the previous name.
None
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
OPSAPS-72468: Subsequent Ozone OBS-to-OBS replication policy do not skip replicated files during replication
The first Ozone replication policy run is a bootstrap run. Sometimes, the subsequent runs might also be bootstrap jobs if the incremental replication fails and the job runs fall back to bootstrap replication. In this scenario, the bootstrap replication jobs might replicate the files that were already replicated because modification time is different for a file on the source and the target cluster.
None
Following are the list of fixed issues that were shipped for Cloudera Manager 7.11.3 CHF 11 (version: 7.11.3.28-60766845):
OPSAPS-66996: When Cloudera Manager is creating home directories for service accounts, it will skip creating directories for those accounts that are already defined through an external LDAP or SAML service connected to the operating system on the host. This occurs because the attempt to create the service user account fails, causing follow on actions such as home directory creation to be skipped.
Cloudera Manager now detects when the external authentication services connected to the host operating system (through PAM or SSSD or other methods) have pre-created service accounts and will proceed with service account home directory creation if the directory is missing on the local host filesystem.
OPSAPS-72369: Update the default snapshot configuration for enabling ordered snapshot deletion.
This issue is now resolved by changing the default configuration value on Cloudera Manager. Now the ozone.snapshot.deep.cleaning.enabled is disabled by default and ozone.snapshot.ordered.deletion.enabled enabled by default on Cloudera Manager.
OPSAPS-72323: Cloudera Manager UI is down with bootstrap failure due to ConfigGenExecutor throwing exception
This issue is fixed now.
OPSAPS-72181: Currently Apply Host Template checks for active command on the service, if the active command is taking time (like a long-running replication command) then Apply Host Template operation will also get delayed.
This issue is fixed now for certain scenario like when host template has only gateway role then the Apply Host Template operation will not check for active command on service. If host template has other roles than gateway then the behaviour remains same. Apply Host Template with gateway roles only will not wait for any active service command.
OPSAPS-72249: Oozie database dump fails on JDK17
Oozie database dump and load commands couldn't be executed from Cloudera Manager with JDK 17. This issue is now resolved.
OPSAPS-72105: Kafka, SRM, and SMM cannot process messages compressed with Zstd or Snappy if /tmp is mounted as noexec
The issue is fixed now by using JVM flags that point to a different temporary folder for extracting the native library.
OPSAPS-71931: Ranger-HDFS plugin resource lookup is not working with JDK 17 on Isilon cluster
The issue is fixed now by adding the sun.net.util package to Ranger Admin Java opts for jdk 17.
OPSAPS-71256: The “Create Ranger replication policy” action shows 'TypeError' if no peer exists
When you click target Cloudera Manager > Replication Manager > Replication Policies > Create Replication Policy > Ranger replication policy, the TypeError: Cannot read properties of undefined error appears. This issue is fixed.
OPSAPS-71093: Validation on source for Ranger replication policy fails
The Cloudera Manager page would be logged out automatically when you created a Ranger replication policy. This is because the source cluster did not support the getUsersFromRanger or getPoliciesFromRanger API requests. The issue is fixed, and the required validation on the source completes successfully as expected.
OPSAPS-70752: The "MapReduce Service" field shows incorrect services during the Ranger replication creation process
This issue is fixed. The MapReduce service field shows the MapReduce services in the destination cluster when you choose the Replicate Ranger audit logs in HDFS option in the Create Ranger replication policy wizard in Replication Manager.
OPSAPS-72229: Atlas replication policies consider active and inactive Atlas server instances during the replication policy runs
This issue is resolved. Replication Manager now only considers the active Atlas server instances during the Atlas replication policy runs.
OPSAPS-71853: The Replication Policies page does not load the replication policies’ history
When the sourceService is null for a Hive ACID replication policy, the Cloudera Manager UI fails to load the existing replication policies’ history details and the current state of the replication policies on the Replication Policies page. This issue is resolved.
OPSAPS-72208: Set YARN cgroup v2 settings in Cloudera Manager
Cgroup v2 support is now enabled by default. This support is backward compatible, therefore cgroup v1 is automatically detected and used if required.
OPSAPS-70721: QueueManagementDynamicEditPolicy is not enabled with Auto Queue Deletion enabled
Whenever Auto Queue Deletion is enabled, the QueueManagementDynamicEdit policy is not enabled. This issue is now resolved and when there are no applications running in a queue, then its capacity is set to zero.
Fixed Common Vulnerabilities and Exposures
For information about Common Vulnerabilities and Exposures (CVE) that are fixed in Cloudera Manager 7.11.3 cumulative hotfix 11, see Fixed Common Vulnerabilities and Exposures in Cloudera Manager 7.11.3 cumulative hotfixes.

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

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