Cloudera Docs

What's New in Cloudera Manager

Learn about the new features and changed behavior of Cloudera Manager in Cloudera Manager 7.13.2 and its cumulative hotfixes.

You must be aware of the additional functionalities and improvements to features of Cloudera Manager in Cloudera Manager 7.13.2 and its cumulative hotfixes. Learn how the new features and improvements benefit you.

Cloudera Manager 7.13.2 introduces new features and includes all cumulative hotfixes from 7.13.1.100 through 7.13.1.700. For a comprehensive record of all updates in Cloudera Manager 7.13.1.x, see What's New in Cloudera Manager 7.13.1.x.

Cloudera Manager 7.13.2

Dual-Stack Support: IPv4 and IPv6 Address Visibility
Cloudera Manager now displays both IPv4 and IPv6 addresses for hosts in clusters where nodes are configured with dual-stack networking.

For more information, see IPv6 Support and Dual-Stack Configuration.

Python support for Cloudera Manager 7.13.2

Cloudera Manager 7.13.2 now supports only Python 3.11 version, when used in combination with Cloudera Runtime 7.3.2, 7.3.1.500 or higher versions, and 7.1.9 SP1 CHF11 or higher versions. For more information, see Installing Python 3.

Ubuntu 24.04 support for Cloudera Manager 7.13.2

Starting with the Cloudera Manager 7.13.2.0 release, Cloudera Manager provides support for Ubuntu 24.04. This update ensures seamless compatibility with Ubuntu version 24.04, offering greater flexibility and platform options.

Ubuntu 24.04 supports only the Python 3.11 version in the Cloudera Manager 7.13.2 release.

Managing Service Restarts on Ubuntu 24.04:

Overriding needrestart Automatic Restart Behaviour

Ubuntu 24.04 (Noble Numbat) introduced a significant change to the default behavior of the needrestart utility. By default, needrestart is now configured to automatically restart services any time apt updates underlying libraries (for example, libssl).

This behaviour is designed to apply security patches to running processes immediately. However, this can cause unplanned downtime for services like cloudera-scm-server.service (the Cloudera Manager Server).

To ensure service stability and to control all restarts, you can disable this automatic behaviour on all production Ubuntu 24.04 hosts. You can use multiple approaches to achieve this, as outlined in the Ubuntu Community Discourse: `needrestart` changes in Ubuntu 24.04: service restarts.

SLES 15 SP6 support for Cloudera Manager

Starting with the Cloudera Manager 7.13.2.0 release, Cloudera Manager provides support for SLES 15 SP6.

SLES 15 SP6 supports only the Python 3.11 version in the Cloudera Manager 7.13.2 release.

Kafka protocol and metadata version is set automatically during upgrades
When upgrading Kafka, Cloudera Manager now automatically sets the inter.broker.protocol.version property for ZooKeeper-based clusters and the metadata.version property for KRaft-based clusters. You no longer need to manually set these properties to the current protocol or metadata version before an upgrade. This feature is only available when upgrading to Cloudera Runtime 7.3.2 or higher.

After the upgrade, clearing these properties remains a manual task. However, in Cloudera Runtime 7.3.2 and higher, both inter.broker.protocol.version and metadata.version are now available for direct configuration in Cloudera Manager > Kafka > Configuration. The label names of the properties are Kafka Inter-Broker Protocol Version and Kafka Metadata Version. This means you can set or clear these properties directly from the UI, without needing to use advanced configuration snippets.

Enhancements to Iceberg replication policies in Cloudera Replication Manager
The following changes are available for Iceberg replication policies in Cloudera Replication Manager:
  • Added the following options to use during the Iceberg replication policy creation process:
    • JVM Options for Export –- You can enter comma-separated JVM options to use for the export process during the Iceberg replication policy run.
    • JVM Options for XFer –- You can enter comma-separated JVM options to use for the transfer process during the Iceberg replication policy.
    • JVM Options for Sync –- You can enter comma-separated JVM options to use for the sync process during the Iceberg replication policy.
    • Run as Username on Source –- You can enter the username if the peer cluster is configured with a different superuser. Ensure that the user is in the supergroup group on the HDFS NameNode host of the source cluster. This username acts as a proxy during the replication policy run.
  • Iceberg replication policies can replicate V1 and V2 Iceberg tables created using Hive.
  • You can replicate Iceberg tables stored on Ozone storage between Ozone buckets only using Iceberg replication policies. Complete the mandatory requirements before replicating the Iceberg tables stored in Ozone, and then configure the Source Storage Filter and Location Mapping options as required during the Iceberg replication policy creation process.
Unified Replication Manager App
You can deploy Unified Replication Manager App as a service in Cloudera Manager. You can manage this service as any other service in Cloudera Manager. You can create and manage HDFS, Hive external tables, and Ozone replication policies as well as HDFS and HBase snapshot policies in the Replication Manager service UI. For more details, contact your Cloudera Account Representative to access this feature.
Navigator Encrypt installed using Cloudera Manager
In Cloudera Runtime 7.3.2.0 and higher releases, the new Navigator Encrypt parcel centralizes the entire lifecycle management within Cloudera Manager. Previously, Navigator Encrypt required manual, host-by-host RPM installation and configuration. Administrators can now manage the installation, configuration, and upgrade of Navigator Encrypt across all cluster hosts directly from the Cloudera Manager interface. This new approach provides a significant improvement in usability, streamlining ongoing maintenance and lifecycle management.
Back up ranger_audits Solr collection
When upgrading to Cloudera Runtime 7.3.2.0 and later releases that update the Ranger Audits Solr schema, Cloudera Manager runs an internal service command to apply the schema changes safely.
Although the command is designed to be non-destructive, Cloudera strongly recommends creating a backup of the Ranger Audits Solr collection before starting the upgrade. This ensures a quick restoration of audit data if anything goes wrong during the upgrade.
For more information, see Back up ranger_audits Solr collection.
Included authz_export.tar.gz for Sentry to Ranger migration with Cloudera Manager package
For CDH‑to‑CDP upgrades that involve Sentry‑to‑Ranger migration, the authz_export.tar.gz package is now bundled with the Cloudera Manager installation, in the same location as authz-ingest.zip. This eliminates the need to contact Cloudera support to obtain the export archive from internal sources and simplifies authorization policy migration.
Ranger Admin logs to show the local timezone rather than UTC
Ranger Admin now records log timestamps in the local system timezone of the host instead of UTC. This aligns Ranger Admin logs with other Ranger components (such as UserSync and TagSync) and removes the need for manual log4j configuration, making troubleshooting and correlation with other system logs easier.
Cloudera Manager now sanitizes cluster names
Cloudera Manager now sanitizes cluster names that contain spaces when creating and evaluating Ranger plugin repositories that use the UNIQUE_PER_SERVICE naming strategy. Spaces in the derived Ranger repository (service) name are automatically replaced with underscores (_), ensuring compatibility with the Ranger constraint introduced in RANGER-2808 that disallows spaces in service names.
Improved Ranger Admin Diagnostic collection command from Cloudera Manager scripts
In Cloudera Manager 7.13.2.0, the Ranger Admin diagnostic collection command has been enhanced. A new configuration option, ranger.admin.diag.metrics.collection.type, allows you to control which types of Ranger metrics are collected during the Cloudera Manager diagnostics command. This helps avoid long‑running Ranger Admin metrics collection (for example, cases where collection could exceed 40 minutes and cause the Cloudera Manager diagnostic command to stop) by letting you limit or skip specific metrics types as needed.
Updated Ranger RMS, TAGSYNC, and USERSYNC CSDs
Updated Ranger RMS, TAGSYNC, and USERSYNC Cloudera Service Descriptors (CSDs) to support the new Ranger RMS high availability (HA) implementation used by the ranger-common-ha module. The RMS server and tagsync/usersync service port configs are now managed as first‑class CSD properties rather than via safety valves, improving HA configuration consistency and upgrade handling.
Cloudera Manager updates Ranger plugin service repositories with the correct cluster configurations
Cloudera Manager now updates Ranger plugin service repositories with the correct cluster configurations for test connection and resource lookup. For Ranger plugins on HBase, Knox, Atlas, and Ozone, Cloudera Manager automatically calculates and populates the required URLs, principals, and related settings instead of creating repositories with default, nonfunctional values. This reduces configuration errors and addresses frequent “Test connection” and lookup failures seen in customer deployments.
Enforce truststore configuration when Ranger plugin is enabled with Ranger admin SSL
When the Ranger plugin is configured to use Ranger Admin over SSL, Cloudera Manager now enforces truststore configuration for the plugin services. If the truststore settings are missing, the Ranger Plugin Services page displays a validation warning, helping prevent plugin sync failures caused by an unconfigured truststore.
Improved control of Ranger audit spooling to prevent disk exhaustion
Added Cloudera Manager configuration options for the Ranger plugins to control audit file spooling, including the spool file rollover interval and the maximum number of archived spool files. These settings are now exposed centrally for HDFS and Solr Ranger audits, reducing the risk of /var/log filling up when the audit destination is unavailable and eliminating the need for per-service safety‑valve configuration.
Ranger audits collection creation reliability improved
Updated the Ranger audit configuration so that the ranger.audit.solr.time.interval setting now uses a 60-second (60000 ms) delay between retries when creating the ranger_audits collection in Solr, improving reliability in environments where Solr starts later than Ranger.
Storage change for Ranger admin audit logs
Starting from Cloudera Runtime 7.3.2.0, Ranger admin audit logs are stored in the x_trx_log_v2 table in the Ranger database. In releases earlier than 7.3.2.0, Ranger admin audit logs were stored in the x_trx_log table in the Ranger database. Hence, if you upgrade to Cloudera Runtime 7.3.2.0 from any previous version and you want to retain your old data, you must migrate the Ranger admin audit logs from the x_trx_log table to the x_trx_log_v2 table.
Ranger Usersync LDAP referral handling improved
In Cloudera Runtime 7.3.2.0, the default value of the Ranger Usersync LDAP referral configuration has been changed from ignore to follow (ranger.usersync.ldap.referral=follow). This enables Ranger Usersync to follow LDAP referrals during group searches, which helps prevent javax.naming.PartialResultException: Unprocessed Continuation Reference(s) errors commonly seen with Active Directory LDAP and reduces the need for relying on the AD Global Catalog for referral resolution.
Ranger mixed case group comparison
When Ranger Usersync is configured with case conversion and special character replacement using Regular Expression (regex), Ranger Usersync transforms the original user or group names from the source, for example, AD or LDAP, before storing them in the Ranger Admin database. Previously, if a Ranger plugin used the original name during authorization checks, the check failed because the Ranger Admin only recognized the transformed name.

This issue is now fixed. The fix is configurable at the plugin level using the ranger.plugin.<serviceType>.supports.name.transformation property, allowing users to enable or disable transformation based on their environment needs. For more information, see Handling inconsistent username and group name conventions for consistent authorization.

Added new HDFS Canary health check timeout configuration
A new configuration option, hdfs_canary_timeout, has been introduced to allow users to tune the timeout duration for the HDFS Canary health check. By default, this timeout is set to 30 seconds.
Increased the HDFS DataNode block count alert threshold
In Cloudera Manager 7.13.2.0, the default warning threshold for the number of blocks on an HDFS DataNode (datanode_block_count_thresholds) has been increased from 1 million to 4 million blocks.
Added Knox Proxyuser configuration parameters for Ozone Recon
Two new configuration parameters have been added to the Ozone Recon role to improve Knox integration:
  • ozone.recon.http.auth.proxyuser.knox.hosts
  • ozone.recon.http.auth.proxyuser.knox.groups

Both parameters default to *.