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:
- Log in to the Navigator Metadata Server database.
- Update
NAV_MAINTENANCE_HISTORY set STATUS = "INCOMPLETE"
whereSTATUS
like'IN_PROGRESS'
. - Update
NAV_EXTRACTOR_STATUS set ENABLED_FOR_NEXT_EXTRACTION = 1
whereENABLED_FOR_NEXT_EXTRACTION = 0
. - NMS is able to start and extractors are enabled.
- Upgrade:
- 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:
- 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
-
- CVE-2021-30132
- Alerts config - 4.3 (Medium)
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
- CVE-2021-32483
- Views - 4.3 (Medium)
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
- CVE-2021-30132
- 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.
- Impact
- The clusters could experience downtime.
- Action required
-
- Workaround if the certificates have not yet expired:
- 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
-
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/
-
Restart the CM server
-
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
- Repeat these steps after each host certificate rotation.
- Back up the existing host keystore from the
directory based on the hostname of the CM server.
Example:
- Workaround if the certificates have already expired:
- You must run commands on each host with expired certificates to regenerate new ones.
-
For each affected host (including the Cloudera Manager server host if necessary), let “
<host_FQDN>
” be the fully-qualified domain name of that host:- 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>
- Copy
/tmp/<host_FQDN>.tar
to the affected host. - 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/
-
- Run the following command on the Cloudera
Manager server host as
root:
- Restart Cloudera Manager by running the
following command on the Cloudera Manager server host
as
root:
service cloudera-scm-server restart
- 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"
-
- Follow the steps in the above section: “Workaround if the certificates have not yet expired”
- 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: