Cloudera Docs

Cloudera Manager 7.13.1.400 Cumulative hotfix 4

Know more about the Cloudera Manager 7.13.1.400 cumulative hotfixes 4.

This cumulative hotfix was released on June 27, 2025.

New features and changed behavior for Cloudera Manager 7.13.1.400 CHF 4 (version: 7.13.1.400-68000784):
OPSAPS-70909: Use specified users instead of "hive" for Ozone replication-related commands

Starting from Cloudera Manager 7.11.3 CHF15, Ozone commands executed by Ozone replication policies are run by 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. The bucket access for OBS-to-OBS replication depends on the user with 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, specific permissions are required for Ozone replication to replicate Ozone data using Ozone replication policies. For information about the permissions, see Preparing clusters to replicate Ozone data.
OPSAPS-73075: Added Safety Valve for hadoop-metrics2.properties for Ozone roles
Safety Valve for hadoop-metrics2.properties is now available for Ozone roles to enable tuning metrics collection.
Following are the list of known issues and their corresponding workarounds that are shipped for Cloudera Manager 7.13.1.400 CHF 4 (version: 7.13.1.400-68000784):
OPSAPS-74341: NodeManagers might fail to start during the cluster restart after the Cloudera Manager 7.13.1.x upgrade

Cgroup v2 support is enabled in CDP 7.1.9 SP1 CHF5 and higher versions. However, if the user upgrades from Cloudera Manager 7.11.3.x to Cloudera Manager 7.13.1.x, and the environment is using cgroup v2, the NodeManagers might fail to start during the cluster restart after the Cloudera Manager 7.13.1.x upgrade.

To resolve this issue temporarily, you must perform the following steps:

  1. Go to the YARN service page on the Cloudera Manager UI.

  2. Navigate to the Configuration tab.

  3. Search for NodeManager Advanced Configuration Snippet (Safety Valve) for yarn-site.xml.

  4. Add the following entry:

    1. Add yarn.nodemanager.linux-container-executor.cgroups.v2.enabled=true

  5. Restart the Nodemanagers. Nodemanagers restart successfully.

OPSAPS-73546: Service Monitor fails to perform Canary tests on HMS / HBASE / ZooKeeper due to missing dependencies

Due to a missing dependency caused by an incomplete build and packaging in certain OS releases, the HMS (Hive Metastore) Canary health test fails, logging a ClassNotFoundException in the Service Monitor log. This problem relates to all deliveries using runtime cluster version 7.1.x or 7.2.x, while the Cloudera Manager version is 7.13.1.x and the OS is NOT RHEL8.

In case your OS is either RHEL 9 or SLES 15 or Ubuntu 2004 or Ubuntu 2204 and if you install the Cloudera Manager 7.13.1.x version, then create a symbolic link using root user privileges on the node that host the Service Monitor service (cloudera-scm-firehose) at /opt/cloudera/cm/lib/cdh71/cdh71-hive-client-7.13.1-shaded.jar, pointing to /opt/cloudera/cm/lib/cdh7/cdh7-hive-client-7.13.1-shaded.jar.

Restart the Service Monitor service post the change. This will allow the Service Monitor to perform Canary testing correctly on the HMS (Hive Metastore) service.

OPSAPS-73211: Cloudera Manager 7.13.1 does not clean up Python Path impacting Hue to start

When you upgrade from Cloudera Manager 7.7.1 or lower versions to Cloudera Manager 7.13.1 or higher versions with CDP Private Cloud Base 7.1.7.x Hue does not start because Cloudera Manager forces Hue to start with Python 3.8, and Hue needs Python 2.7.

The reason for this issue is because Cloudera Manager does not clean up the Python Path at any time, so when Hue tries to start the Python Path points to 3.8, which is not supported in CDP Private Cloud Base 7.1.7.x version by Hue.

To resolve this issue temporarily, you must perform the following steps:

  1. Locate the hue.sh in /opt/cloudera/cm-agent/service/hue/.
  2. Add the following line after export HADOOP_CONF_DIR=$CONF_DIR/hadoop-conf:
    export PYTHONPATH=/opt/cloudera/parcels/CDH/lib/hue/build/env/lib64/python2.7/site-packages
OPSAPS-60346: Upgrading Cloudera Manager Agent triggers cert rotation in Auto-TLS use case 1

Upgrading Cloudera Manager Agent nodes from the Cloudera Manager UI wizard as part of a Cloudera Manager upgrade causes the host to get new certificates, which becomes disruptive.

The issue happens with use case 1 and Cloudera Manager DB is because Cloudera Manager always regenerates the host cert as part of the host install or host upgrade step. However, with use case 3, Cloudera Manager does not regenerate the cert as it comes from the user.

Currently, there are three following possible workarounds:
  • Rotate all CMCA certs again using the generateCmca API command, and using the "location" argument to specify a directory on disk. This will revert to the old behavior of storing the certs on disk instead of the DB.
  • Switch to Auto-TLS Use Case 3 (Customer CA-signed Certificates).
  • Manual upgrade of Cloudera Manager Agents, instead of upgrading from Cloudera Manager GUI.
OPSAPS-72447, 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-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
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-71897: Finalize Upgrade command fails after upgrading the cluster with CustomKerberos setup causing INTERNAL_ERROR with EC writes.
After the UI FinalizeCommand fails, you must manually run the finalize commands through the Ozone Admin CLI:
  1. kinit with the scm custom kerberos principal
  2. ozone admin scm finalizeupgrade
  3. ozone admin scm finalizationstatus
OPSAPS-72204: HMS compaction configuration not updated through Cloudera Manager UI
The hive.compactor.initiator.on checkbox in Cloudera Manager UI for Hive Metastore (HMS) does not reflect the actual configuration value in cloud deployments. The default value is false, causing the compactor to not run.
To update the hive.compactor.initiator.on value:
  1. In the Cloudera Manager, go to Hive > Configuration
  2. Add the value for hive.compactor.initiator.on to true in the "Hive Service Advanced Configuration Snippet (Safety Valve) for hive-site.xml"
  3. Save the changes and Restart.
Once applied, the compaction process will run as expected.
OPSAPS-70702: Ranger replication policies fail if the clusters do not use AutoTLS
Ranger replication policies fail during the Exporting services, policies and roles from Ranger remote step.
  • Log in to the Ranger Admin host(s) on the source cluster.
  • Identify the Cloudera Manager agent PEM file using the # cat /etc/cloudera-scm-agent/config.ini | grep -i client_cert_file command. For example, the file might reside in client_cert_file=/myTLSpath/cm_server-cert.pem location.
  • Create the path for the new PEM file using the # mkdir -p /var/lib/cloudera-scm-agent/agent-cert/ command.
  • Copy the client_cert_file from config.ini as cm-auto-global_cacerts.pem file using the # cp /myTLSpath/cm_server-cert.pem /var/lib/cloudera-scm-agent/agent-cert/cm-auto-global_cacerts.pem command.
  • Change the ownership to 644 using the # chmod 644 /var/lib/cloudera-scm-agent/agent-cert/cm-auto-global_cacerts.pem command.

  • Resume the Ranger replication policy in Replication Manager.

OPSAPS-71403: Ozone replication policy creation wizard shows "Listing Type" field in source Cloudera Private Cloud Base versions lower than 7.1.9
When the source Cloudera Private Cloud Base cluster version is lower than 7.1.9 and the Cloudera Manager version is 7.11.3, the Ozone replication policy creation wizard shows Listing Type and its options. These options are not available in Cloudera Private Cloud Base 7.1.8x versions.
OPSAPS-71414: Permission denied for Ozone replication policy jobs if the source and target bucket names are identical
The OBS-to-OBS Ozone replication policy job fails with the com.amazonaws.services.s3.model.AmazonS3Exception: Forbidden or Permission denied error when the bucket names on the source and target clusters are identical and the job uses S3 delegation tokens. Note that the Ozone replication jobs use the delegation tokens when the S3 connector service is enabled in the cluster.
You can use one of the following workarounds to mitigate the issue:
  • Use different bucket names on the source and target clusters.
  • Set the fs.s3a.delegation.token.binding property to an empty value in ozone_replication_core_site_safety_valve to disable the delegation tokens for Ozone replication policy jobs.
OPSAPS-71067: Wrong interval sent from the Replication Manager UI after Ozone replication policy submit or edit process.
When you edit the existing Ozone replication policies, the schedule frequency changes unexpectedly.
OPSAPS-71005: RemoteCmdWork uses a singlethreaded executor
Replication Manager runs the remote commands for a replication policy through a single-thread executor.
OPSAPS-59553: SMM's bootstrap server config should be updated based on Kafka's listeners
SMM does not show any metrics for Kafka or Kafka Connect when multiple listeners are set in Kafka.
Workaround: SMM cannot identify multiple listeners and still points to bootstrap server using the default broker port (9093 for SASL_SSL). You need to override the bootstrap server URL by performing the following steps:
  1. In Cloudera Manager, go to SMM > Configuration > Streams Messaging Manager Rest Admin Server Advanced Configuration Snippet (Safety Valve)
  2. Override bootstrap server URL (hostname:port as set in the listeners for broker) for streams-messaging-manager.yaml.
  3. Save your changes.
  4. Restart SMM.
OPSAPS-69317: Kafka Connect Rolling Restart Check fails if SSL Client authentication is required
The rolling restart action does not work in Kafka Connect when the ssl.client.auth option is set to required. The health check fails with a timeout which blocks restarting the subsequent Kafka Connect instances.
You can set ssl.client.auth to requested instead of required and initiate a rolling restart again. Alternatively, you can perform the rolling restart manually by restarting the Kafka Connect instances one-by-one and checking periodically whether the service endpoint is available before starting the next one.
OPSAPS-70971: Schema Registry does not have permissions to use Atlas after an upgrade
Following an upgrade, Schema Registry might not have the required permissions in Ranger to access Atlas. As a result, Schema Registry's integration with Atlas might not function in secure clusters where Ranger authorization is enabled.
  1. Access the Ranger Console (Ranger Admin web UI).
  2. Click the cm_atlas resource-based service.
  3. Add the schemaregistry user to the all - * policies.
  4. Click Manage Service > Edit Service.
  5. Add the schemaregistry user to the default.policy.users property.
OPSAPS-59597: SMM UI logs are not supported by Cloudera Manager
Cloudera Manager does not display a Log Files menu for SMM UI role (and SMM UI logs cannot be displayed in the Cloudera Manager UI) because the logging type used by SMM UI is not supported by Cloudera Manager.
View the SMM UI logs on the host.
OPSAPS-72298: Impala metadata replication is mandatory and UDF functions parameters are not mapped to the destination
Impala metadata replication is enabled by default but the legacy Impala C/C++ UDF's (user-defined functions) are not replicated as expected during the Hive external table replication policy run.
Edit the location of the UDF functions after the replication run is complete. To accomplish this task, you can edit the “path of the UDF function” to map it to the new cluster address, or you can use a script.
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
OPSAPS-72470: Hive ACID replication policies fail when target cluster uses Dell EMC Isilon storage and supports JDK17
Hive ACID replication policies fail if the target cluster is deployed with Dell EMC Isilon storage and also supports JDK17.
None
Following are the list of fixed issues that were shipped for Cloudera Manager 7.13.1.400 CHF 4 (version: 7.13.1.400-68000784):
OPSAPS-60642: Host header injection issue on /j_spring_security_check internal endpoint
/j_spring_security_check is internal endpoint which is vulnerable to Host header injection. This issue occurs if the user disabled PREVENT_HOST_HEADER_INJECTION feature flag.
Host header injection: In an incoming HTTP request, web servers often dispatch the request to the target virtual host based on the value supplied in the Host header. Without proper validation of the header value, the attacker can supply invalid input to cause the web server to:
  • Dispatch requests to the first virtual host on the list
  • Redirect to an attacker-controlled domain
  • Perform web cache poisoning
  • Manipulate password reset functionality
This issue is resolved now by adding Feature Flag PREVENT_HOST_HEADER_INJECTION to prevent host header injection vulnerability on /j_spring_security_check internal endpoint. This feature flag is by default enabled and it enables additional logic to block potential Host Header Injection attacks targeting the /j_spring_security_check endpoint in Cloudera Manager.
OPSAPS-74019/OPSAPS-72739: Query execution stability with temporary directories
Queries previously failed with an execution error when using a compression library. Although /tmp is a default temporary folder, its use for script execution was blocked due to security restrictions, causing queries to fail.
This issue was resolved by configuring Hive to use a different default temporary folder, /var/lib/hive, instead of /tmp.
OPSAPS-74141: Hive service setup on reused databases
During 7.3.1 base cluster installations, the Hive service setup failed when attempting to validate the Hive Metastore Schema. This happened specifically when the new cluster used a database that had been previously used by an older installation, causing the schema validation to fail due to a version mismatch with the newer Hive components.
This issue was resolved by modifying the Hive script in Cloudera Manager to use the -initOrUpgradeSchema argument instead of -initSchema for the hive_metastore_create_tables command. This change allows the Hive Metastore schema to be properly initialized or upgraded even when connecting to a database that was previously used by an older installation.
OPSAPS-73370 and OPSAPS-73585: Cloudera Observability does not report Spark workloads when Spark event log compression is enabled by setting spark.eventLog.compress enabled to true.
Cloudera Observability now accurately handles compressed event log files. This issue is now resolved.
OPSAPS-73011: Wrong parameter in the /etc/default/cloudera-scm-server file

In case the Cloudera Manager needs to be installed in High Availability (2 nodes or more as explained here), the parameter CMF_SERVER_ARGS in the /etc/default/cloudera-scm-server file is missing the word "export" before it (on the file there is only CMF_SERVER_ARGS= and not export CMF_SERVER_ARGS=), so the parameter cannot be utilized correctly.

This issue is fixed now.

OPSAPS-72756:The runOzoneCommand API endpoint fails during the Ozone replication policy run
The /clusters/{clusterName}/runOzoneCommand Cloudera Manager API endpoint fails when the API is called with the getOzoneBucketInfo command. In this scenario, the Ozone replication policy runs also fail if the following conditions are true:
  • The source Cloudera Manager version is 7.11.3 CHF11 or 7.11.3 CHF12.
  • The target Cloudera Manager is version 7.11.3 through 7.11.3 CHF10 or 7.13.0.0 or later where the feature flag API_OZONE_REPLICATION_USING_PROXY_USER is disabled.

This issue is fixed now.

OPSAPS-72710: Marking the snapshots created by incremental replication policies differently
In the Ozone bucket browser, the snapshots created by an Ozone replication are marked. When the snapshots are deleted, a confirmation modal window appears before the deletion. The restore bucket modal window now displays information about how the restore operation is implemented in Ozone and how this operation affects Ozone replications.
OPSAPS-72447, 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.

This issue is fixed now.

OPSAPS-71046: The jstack logs collected on Cloudera Manager 7.11.3 are not in the right format
On viewing the jstack logs in the user cluster, the jstack logs for ozone and other services on Cloudera Manager 7.11.3 and CDP Private Cloud Base 7.1.9 are not in the right format. This issue is fixed now.
OPSAPS-65377: Cloudera Manager - Host Inspector not finding Psycopg2 on Ubuntu 20 or Redhat 8.x when Psycopg2 version 2.9.3 is installed.

Host Inspector fails with Psycopg2 version error while upgrading to Cloudera Manager 7.13.1.x versions. When you run the Host Inspector, you get an error Not finding Psycopg2, even though it is installed on all hosts. This issue is fixed now.

OPSAPS-70226: Atlas uses the Solr configuration directory available in ATLAS_PROCESS/conf/solr instead of the Cloudera Manager provided directory
This issue is fixed now and Atlas uses the correct configuration directory in /var/run/cloudera-scm-agent/process/151-atlas-ATLAS_SERVER/solrconf.xml.
OPSAPS-74147: Atlas rolling upgrade related to Zero Downtime Upgrade (ZDU) fails from 7.1.7.SP3 to (7.3.1.0 or 7.3.1.100 CHF1 or 7.3.1.200 SP1 or 7.3.1.300 SP1 CHF1)
The issue causing ZDU failures during upgrades from Cloudera Runtime 7.1.7 SP3 to (7.3.1.0 or 7.3.1.100 CHF1 or 7.3.1.200 SP1 or 7.3.1.300 SP1 CHF1) is resolved now. Previously, the Atlas rolling upgrade was failing because the RoleState for Atlas was not checked, and the upgradeCommand was not set correctly.
OPSAPS-73900: Port OPSAPS-73624 to 7.13.1.400
Fixed a bug in ZooKeeper start command to verify if the service is already running.
OPSAPS-73954: Port OPSAPS-73937 to 7.13.1.400
Bad commit has been reverted.
OPSAPS-71105: Expose or set YARN cgroup v2 settings in CM
cgroup v2 support is enabled by default, now YARN will detect and use the correct cgroup handling code.
OPSAPS-73174: Autoscaling fails when any of the RM hosts are down
When a master node hosting RM abruptly goes down, CM can proceed with the NM commission/decommission command-flow.
Fixed Common Vulnerabilities and Exposures
For information about Common Vulnerabilities and Exposures (CVE) that are fixed in Cloudera Manager 7.13.1 cumulative hotfix 4, see Fixed Common Vulnerabilities and Exposures in Cloudera Manager 7.13.1 and Cloudera Manager 7.13.1 cumulative hotfixes.

Cloudera Manager 7.13.1.400 CHF 4 download information

The repositories for Cloudera Manager 7.13.1.400-CHF 4 are listed in the following table:

Repository Type Repository Location
RHEL 9 Compatible Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/redhat9/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/redhat9/yum/cloudera-manager.repo
RHEL 8 Compatible Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/redhat8/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/redhat8/yum/cloudera-manager.repo
SLES 15 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/sles15/yum
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/sles15/yum/cloudera-manager.repo
Ubuntu 22 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/ubuntu2204/apt
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/ubuntu2204/apt/cloudera-manager.list
Ubuntu 20 Repository:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/ubuntu2004/apt
Repository File:
https://username:password@archive.cloudera.com/p/cm7/7.13.1.400/ubuntu2004/apt/cloudera-manager.list