Support Question How to solve the following issue? We run CDP 7.1.7 SP2 CHF 18. We followed Cloudera's description "CDP 7.1.7 / Authenticating Hue users with Knox SSO". - The details given below are redacted - Issue With a newly started browser Knox was called, having no Cookies cached. When connecting the service Hue a second time by clicking the appropriate icon in Knox, it works fine. The URL https://knox.mydomain.com/gateway/Business/hue/hue/editor/?type=impala is used. The first connection to Hue via Knox fails, and the browser calls the URL https://knox.mydomain.com/gateway/Business/hue/%3FdoAs%3Duserid. We get an HTTP error 404 (Page not found) with following details: Request Method: GET Request URL: https://hue_loadbalancer.mydomain.com:8888/%3FdoAs%3Duserid?doAs=userid followed by the message Using the URLconf defined in desktop.urls, Django tried these URL patterns, in this order:   1. ^hue/accounts/login [name='desktop_auth_views_dt_login']   2. ^accounts/login/?$   3. ^accounts/logout/?$   4. ^profile$   5. ^login/oauth/?$ ...   102.  ^kafka/   103.  ^static\/(?P<path>.*)$ The current path, ?doAs=userid, didn't match any of these. Configuration Excerpt of XML configuration file of the default topology (we called it "Business.xml"):   <?xml version="1.0" encoding="utf-8"?> <!--==============================================--> <!-- DO NOT EDIT. This is an auto-generated file. --> <!--==============================================--> <topology> <generated>true</generated> <gateway> <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> <param> <name>sso.authentication.provider.url</name> <value>https://knox_host.mydomain.com:8443/gateway/knoxsso/api/v1/websso</value> </param> </provider> <provider> <role>identity-assertion</role> <name>HadoopGroupProvider</name> <enabled>true</enabled> <param> <name>CENTRAL_GROUP_CONFIG_PREFIX</name> <value>gateway.group.config.</value> </param> </provider> <provider> <role>authorization</role> <name>XASecurePDPKnox</name> <enabled>true</enabled> </provider> <provider> <role>ha</role> <name>HaProvider</name> <enabled>true</enabled> <!-- ... --> <param> <name>HUE</name> <value>enabled=true;maxFailoverAttempts=3;failoverSleep=1000;maxRetryAttempts=300;retrySleep=1000</value> </param> <!-- ... --> </provider> </gateway> <service> <role>HUE</role> <url>https://hue_loadbalancer_host.mydomain.com:8888</url> <param> <name>httpclient.connectionTimeout</name> <value>5m</value> </param> <param> <name>httpclient.socketTimeout</name> <value>5m</value> </param> </service> <!-- ... --> </topology>                     ... View more

Is there any way to e.g. keep the ttl for the service HDFS at 90 DAYS, and set the ttl for the other services to 14 DAYS?   --- Related articles: Support Question "How to define the retention period for Ranger Audits in CDP INFRA Solr?" https://community.cloudera.com/t5/Support-Questions/How-to-define-the-retention-period-for-Ranger-Audits-in-CDP/td-p/318759   solrctl Reference https://docs.cloudera.com/runtime/7.1.0/search-managing/topics/search-solrctl-ref.html ... View more

Hello,   in our local filesystem we see thousands of subdirectories like "????????-????-????-????-????????????_resources" older than 5 days (and this is for guarantee nothing from any still running process). Additionally there are thousands of files and hundreds of subdirectories in "/tmp/hive" older than 5 days. Where do those relicts come from? How to get rid of them in an automated way?   $ find -O1 /tmp -type d -name "????????-????-????-????-????????????_resources" -mtime +5 | wc -l 26263 $ find /tmp/hive -type d -mtime +5 | wc -l 538 $ find /tmp/hive -type f -mtime +5 | wc -l 5784   Best Regards Carsten ... View more