Known Issues in Cloudera Manager 7.2.1

Learn about the known issues in Cloudera Manager 7.2.1, the impact or changes to the functionality, and the workaround.

OPSAPS-65189: Accessing Cloudera Manager through Knox displays the following error:

Bad Message 431 reason: Request Header Fields Too Large

Workaround: Modify the Cloudera Manager Server configuration /etc/default/cloudera-scm-server file to increase the header size from 8 KB, which is the default value, to 65 KB in the Java options as shown below:
export CMF_JAVA_OPTS="...existing options...
-Dcom.cloudera.server.cmf.WebServerImpl.HTTP_HEADER_SIZE_BYTES=65536
-Dcom.cloudera.server.cmf.WebServerImpl.HTTPS_HEADER_SIZE_BYTES=65536"

Technical Service Bulletins (TSB)

TSB 2021-472: Customer Advisory for Navigator Metadata Server startup issue
If the Navigator Metadata Server is executing purge, and the clean up process is interrupted, the Navigator Metadata Server will not be able to restart.
Impact

Navigator Metadata Server cannot be restarted if the process is killed or crashes during executing a purge. Error message:

[Update NAV_EXTRACTOR_STATUS set ENABLED_FOR_NEXT_EXTRACTION = 'true']; SQL state [72000]; error code [12899]; ORA-12899: value too large for column "NAVMS"."NAV_EXTRACTOR_STATUS"."ENABLED_FOR_NEXT_EXTRACTION" (actual: 4, maximum: 1; nested exception is java.sql.SQLException: ORA-12899: value too large for column "NAVMS"."NAV_EXTRACTOR_STATUS"."ENABLED_FOR_NEXT_EXTRACTION" (actual: 4, maximum: 1)

Action required
  • Upgrade:
    • Cloudera Manager 6.3.4: Request a patch (PATCH-4489).
    • Cloudera Manager 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6 and 7.3.0: Upgrade to a Cloudera Manager version containing the fix.
  • Workaround:
    1. Log in to the Navigator Metadata Server database.
    2. Update NAV_MAINTENANCE_HISTORY set STATUS = "INCOMPLETE" where STATUS like 'IN_PROGRESS'.
    3. Update NAV_EXTRACTOR_STATUS set ENABLED_FOR_NEXT_EXTRACTION = 1 where ENABLED_FOR_NEXT_EXTRACTION = 0.
    4. NMS is able to start and extractors are enabled.
Knowledge article
For the latest update on this issue see the corresponding Knowledge article:

Cloudera Customer Advisory-472: Navigator Metadata Server startup issue

TSB 2021-481: Lineage is not extracted with Cloudera Manager 7.2.x and 7.3.1 managing CDH6 or CDH5
Cloudera Manager - Upgrade to Guava 28.1 to avoid CVE-2018-10237 triggered a Guava method version mismatch causing an exception in Navigator Metadata Server. As a result no new lineage and metadata is extracted with Cloudera Manager 7.2.4 and later with CDH6 and CDH5.
Impact
Lineage and metadata are no longer updated in Cloudera Navigator after upgrading to Cloudera Manager 7.2.x or Cloudera Manager 7.3.1 when managing CDH5 or CDH6.
Action required
Upgrade to the patched release of CM 7.3.1 available as PATCH-4822, or to an upcoming version later than 7.3.1. After upgrade, existing entities will have metadata extracted when extraction resumes and no lineage will be permanently lost.
Knowledge article
For the latest update on this issue see the corresponding Knowledge article:

Cloudera Customer Advisory-481: Lineage is not extracted with Cloudera Manager 7.2.x and 7.3.1 managing CDH 6 or CDH 5

TSB 2021-491: Authorization Bypass in Cloudera Manager (CVE-2021-30132/CVE-2021-32483
Cloudera Manager (CM) 7.4.0 and earlier versions have incorrect Access Control in place for certain endpoints. A user who has a knowledge to the direct path of a resource or a URL to call a particular function, can access it without having the proper role granted. The vulnerable endpoints were CVE-2021-30132 /cmf/alerts/config?task= and CVE-2021-32483 /cmf/views/view?viewName=.
CVE
Impact
A user with read only privilege is able to see configuration information in the UI.
Action required
Upgrade to a version containing the fix.
Knowledge article
For the latest update on this issue see the corresponding Knowledge article: TSB 2021-491: Authorization Bypass in Cloudera Manager (CVE-2021-30132 / CVE-2021-32483)
TSB 2022-507 Certificate expiry issue in CDP
The Transport Layer Security (TLS) keystore needs to be manually rotated due to an issue with certificate rotation.
The Root Cause Analysis is that the keystore path of the Cloudera Manager (CM) server is set to a directory based on the non-FQDN (Fully Qualified Domain Name) of the CM server. However, the certificate rotation on a directory happens based on the FQDN of the CM server. This results in a situation in which the keystore of the CM server does not get updated.
Impact
The clusters could experience downtime.
Action required
  • Workaround if the certificates have not yet expired:
    1. Back up the existing host keystore from the directory based on the hostname of the CM server. Example:
      cp -R /etc/cloudera-scm-server/certs/hosts-key-store/example-datalake-1-master0/ /etc/cloudera-scm-server/certs/hosts-key-store/example-datalake-1-master0.backup
    2. Copy the keystore from a directory based on the FQDN of the CM server. Example:
      cp -Rf /etc/cloudera-scm-server/certs/hosts-key-store/example-datalake-1-master0.domain.site/* /etc/cloudera-scm-server/certs/hosts-key-store/example-datalake-1-master0/ 
    3. Restart the CM server

    4. Confirm that OpenSSL now shows a certificate with the expected expiration time. Example:
      openssl s_client -connect $(grep "server_host" /etc/cloudera-scm-agent/config.ini | sed s/server_host=//):7182 </dev/null | openssl x509 -text -noout 
    5. Repeat these steps after each host certificate rotation.
  • Workaround if the certificates have already expired:
    1. You must run commands on each host with expired certificates to regenerate new ones.
    2. For each affected host (including the Cloudera Manager server host if necessary), let “<host_FQDN>” be the fully-qualified domain name of that host:

      1. Run the following command on the Cloudera Manager server host as root:
        /opt/cloudera/cm-agent/bin/certmanager --location 
        /etc/cloudera-scm-server/certs gen_node_cert --rotate --output=/tmp/<host_FQDN>.tar <host_FQDN>
      2. Copy /tmp/<host_FQDN>.tar to the affected host.
      3. Run the following commands on the affected host as root:
        • /opt/cloudera/cm-agent/bin/cm install_certs /tmp/<host_FQDN>.tar
        • chmod 755 /var/lib/cloudera-scm-agent/agent-cert/
    3. Restart Cloudera Manager by running the following command on the Cloudera Manager server host as root:
      service cloudera-scm-server restart
    4. Restart the Knox service by running the following commands on the Cloudera Manager server host as any user, replacing “UpdateWithYourUser” and “UpdateWithYourClusterName” with the workload user and cluster name, respectively:
      • WORKLOAD_USER="UpdateWithYourUser"
      • CM_SERVER="http://$(hostname -f):7180"
      • CM_API_VERSION=$(curl -s -L -k -u ${WORKLOAD_USER} -X GET
                      "${CM_SERVER}/api/version") && echo ${CM_API_VERSION}
      • CM_CLUSTER_NAME=<UpdateWithYourCusterName>
      • KNOX_SERVICE_NAME=$(curl -s -L -k -u ${WORKLOAD_USER} -X GET
                      "${CM_SERVER}/api/${CM_API_VERSION}/clusters/${CM_CLUSTER_NAME}/services/" | awk -F
                      "[ |:|,]" '/name.*knox/ {print $(NF - 1 )}' | sed 's|"||g') && echo
                      ${KNOX_SERVICE_NAME}
      • curl -s -L -k -u ${WORKLOAD_USER} -X POST
                      "${CM_SERVER}/api/${CM_API_VERSION}/clusters/${CM_CLUSTER_NAME}/services/${KNOX_SERVICE_NAME}/commands/restart"
    5. Follow the steps in the above section: “Workaround if the certificates have not yet expired”
Knowledge article
For the latest update on this issue, please see the corresponding Knowledge article: TSB 2022-507: Certificate expiry issue in CDP
TSB 2021-488: Cloudera Manager is vulnerable to Cross-Site-Scripting attack (CVE-2021-29243 and ​​CVE-2021-32482)
Cloudera Manager may be vulnerable to Cross-Site-Scripting vulnerabilities identified by CVE-2021-29243 and CVE-2021-32482. A remote attacker can exploit this vulnerability and execute malicious code in the affected application.
CVE
  • CVE-2021-29243
  • CVE-2021-32482
Impact
This is an XSS issue. An administrator could be tricked to click on a link that may expose certain information such as session cookies.
Action required
  • Upgrade (recommended)
    Upgrade to a version containing the fix.
  • Workaround
    None
Knowledge article
For the latest update on this issue see the corresponding Knowledge article:

TSB 2021-488: Cloudera Manager vulnerable to Cross-Site-Scripting attack (CVE-2021-29243 and ​​CVE-2021-32482)