Hello Cloudera Community, During the same Test cluster upgrade from Cloudera Runtime 7.1.9 to 7.3.2.0 GA (before Prod rollout), we encountered a persistent issue with Ranger UserSync, which we were not able to resolve using supported configuration or migration steps. Environment Original Runtime: 7.1.9 Upgraded Runtime: 7.3.2.0 (GA) Parcel: CDH-7.3.2-1.cdh7.3.2.p0.77083870 Cloudera Manager: 7.11.3 OS: RHEL / Oracle Linux 8.7 Authentication: LDAP / Kerberos Upgrade type: Test cluster before Prod After upgrade to 7.3.2.0, Ranger UserSync and RMS does not start, while Ranger Admin and Ranger Tagsync starts and works normally. UserSync fails immediately with error: Error: Could not find or load main class org.apache.ranger.authentication.UnixAuthenticationService Caused by: java.lang.ClassNotFoundException We tried all supported and commonly recommended remediation steps: Deleting the existing Ranger UserSync role (originally created on 7.1.9); Re‑creating a new Ranger UserSync role; Configuring LDAP‑based UserSync in Cloudera Manager; Removing all legacy UNIX / PAM references from configuration; Reinstalling and redistributing parcels; Restarting CM agents and services; Moving UserSync role to another host; Result: UserSync continues to fail with the same error. While investigating the runtime, we found the following in the 7.3.2 UserSync parcel: $CDH/lib/ranger-usersync/install.properties SYNC_SOURCE = unix I think this indicates that Ranger UserSync still initializes in UNIX mode at parcel/bootstrap level. However, in 7.3.x: UNIX / PAM‑based UserSync is no longer supported Required UNIX authentication classes are removed At runtime, UserSync still attempts to load: org.apache.ranger.authentication.UnixAuthenticationService which no longer exists Changing install.properties does not affect runtime behavior, indicating that SYNC_SOURCE is not re‑evaluated at service start. Questions: Can this be confirmed as a known issue or limitation in 7.3.2.0 GA? Is a 7.3.2.x Runtime CHF planned to fix UserSync initialization? Should legacy UserSync roles be explicitly flagged during 7.1.x → 7.3.x upgrades? TIA and have a good day! ... View more

Hello Cloudera Community,   We upgraded a Test cluster from Cloudera Runtime 7.1.9 to 7.3.2.0 GA (before Prod rollout) and encountered an issue where Apache Atlas fails to start after the upgrade. Environment Original Runtime: 7.1.9 Upgraded Runtime: 7.3.2.0 (GA) Parcel: CDH-7.3.2-1.cdh7.3.2.p0.77083870 Cloudera Manager: 7.11.3 OS: RHEL / Oracle Linux 8.7 Cluster Java: OpenJDK 17 (required by 7.3.2) HDFS metadata upgrade: completed After upgrade, Atlas fails with: Unrecognized VM option 'CMSClassUnloadingEnabled' Error: Could not create the Java Virtual Machine The generated JVM command line contains CMS GC flags: -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled.    These flags are not supported on Java ≥ 9. Atlas in 7.3.2.0 GA is compiled with Java 17, so running Atlas on Java 8 or 11 is also not possible: UnsupportedClassVersionError (class file version 61.0). Looks like CMS GC flags are hard‑coded in the parcel . We attempted multiple supported CM‑level overrides, including: Atlas Server Environment Advanced Configuration Snippet (Safety Valve) (ATLAS_SERVER_role_env_safety_valve) Overriding ATLAS_SERVER_OPTS with clean, Java‑17‑compatible flags Cleaning process directories and restarting CM agents Although the CM configuration appears clean, the final JVM command still includes CMSClassUnloadingEnabled, and Atlas fails with the same error. This indicates that in 7.3.2.0 GA, parcel‑defined Atlas JVM options are merged after CM overrides, and cannot be fully replaced.   Therefore, there is currently no supported fix for this issue..   Any workaround on this issue? ... View more