Known Issues in Cloudera Manager 7.9.5
Known issues in Cloudera Manager 7.9.5.
- OPSAPS-67152: Cloudera Manager does not allow you to update some configuration parameters.
-
Cloudera Manager does not allow you to set to "0" for the
dfs_access_time_precisionanddfs_namenode_accesstime_precisionconfiguration parameters.You will not be able to update
dfs_access_time_precisionanddfs_namenode_accesstime_precisionto "0". If you try to enter "0" in these configuration input fields, then the field gets cleared off and results in a validation error: This field is required.
- OPSX-3716: Control Plane UI allows to upload a certificate which is undefined or type not selected. When uploading an additional CA certificate, form does not enforce to choose the certificate type and the certificate can be uploaded with 'undefined' type.
- Workaround: You must choose the given certificate type and upload the same.
- OPSX-3323: In the Custom Log Redaction Rules, the string is not getting redacted in the diagnostic bundle. The JSON files within the diagnostic bundle will not be redacted.
- Workaround: None.
- OPSAPS-65888: When the Cloudera Manager is deployed on a timezone different than the user's timezone, it is observed that the date time picker displays are not consistent with the user's timezone.
- As an example, the user is in the Pacific timezone. The server is deployed in UTC. From the Cloudera Manager UI, the user should choose a time in UTC. The selected date is actually assumed to be in the Pacific timezone. And later it gets translated to UTC timezone automatically.
- DOCS-15450: When the Cloudera Manager license is renewed, the imagePullSecret content gets stale. Currently, there is no automatic process to update imagePullSecret content all at once.
- Workaround: You must manually update the imagePullSecret content on every namespace.
- OPSAPS-68629: HDFS HTTPFS GateWay is not able to start with custom krb5.conf location set in Cloudera Manager.
- On a cluster with a custom krb5.conf file
location configured in Cloudera Manager, HDFS HTTPFS role is not able to start because it does
not have the custom Kerberos configuration file setting properly propagated to the service, and
therefore it fails with a Kerberos related exception:
in thread "main" java.io.IOException: Unable to initialize WebAppContext at org.apache.hadoop.http.HttpServer2.start(HttpServer2.java:1240) at org.apache.hadoop.fs.http.server.HttpFSServerWebServer.start(HttpFSServerWebServer.java:131) at org.apache.hadoop.fs.http.server.HttpFSServerWebServer.main(HttpFSServerWebServer.java:162) Caused by: java.lang.IllegalArgumentException: Can't get Kerberos realm at org.apache.hadoop.security.HadoopKerberosName.setConfiguration(HadoopKerberosName.java:71) at org.apache.hadoop.security.UserGroupInformation.initialize(UserGroupInformation.java:329) at org.apache.hadoop.security.UserGroupInformation.setConfiguration(UserGroupInformation.java:380) at org.apache.hadoop.lib.service.hadoop.FileSystemAccessService.init(FileSystemAccessService.java:166) at org.apache.hadoop.lib.server.BaseService.init(BaseService.java:71) at org.apache.hadoop.lib.server.Server.initServices(Server.java:581) at org.apache.hadoop.lib.server.Server.init(Server.java:377) at org.apache.hadoop.fs.http.server.HttpFSServerWebApp.init(HttpFSServerWebApp.java:100) at org.apache.hadoop.lib.servlet.ServerWebApp.contextInitialized(ServerWebApp.java:158) at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:1073) at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:572) at org.eclipse.jetty.server.handler.ContextHandler.contextInitialized(ContextHandler.java:1002) at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:765) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:379) at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1449) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1414) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:916) at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:288) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) at org.eclipse.jetty.server.Server.start(Server.java:423) at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110) at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) at org.eclipse.jetty.server.Server.doStart(Server.java:387) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) at org.apache.hadoop.http.HttpServer2.start(HttpServer2.java:1218) ... 2 more Caused by: java.lang.IllegalArgumentException: KrbException: Cannot locate default realm at java.security.jgss/javax.security.auth.kerberos.KerberosPrincipal.<init>(KerberosPrincipal.java:174) at org.apache.hadoop.security.authentication.util.KerberosUtil.getDefaultRealm(KerberosUtil.java:108) at org.apache.hadoop.security.HadoopKerberosName.setConfiguration(HadoopKerberosName.java:69) ...
