Created on 06-14-2024 08:33 AM - edited 06-14-2024 08:47 AM
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 -
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'] The current path, ?doAs=userid, didn't match any of these. |
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>
Created 07-05-2024 09:25 AM
Hi @caisch
From your provided settings, I see the port for Load balancer is wrong.
<role>HUE</role>
<url>https://hue_loadbalancer_host.mydomain.com:8888<
The HUE load balancer port has been set to 8888 which is the HUE service port and 8889 is the HUE load balancer port. Kindly change to 8889 and verify .
Thanks
Created on 07-30-2024 01:46 AM - edited 07-30-2024 01:47 AM
Hello,
changing the ports was not sufficient.
We found out, as long as inside Hue the Impala sessions have not been closed, the first start of Hue with Knox will fail.
So, when we closed them manually, the first start of Hue in Knox is successful.
Any idea on how to configure Hue to close Impala sessions automatically?
Created 07-31-2024 03:31 PM
Hello @caisch
Did you add the Hue LB in the Knox Proxy Hosts as mentioned in the documentation?
https://docs.cloudera.com/cdp-private-cloud-upgrade/latest/upgrade-hdp/topics/hue-upg-integrate-hue-...
By default, Hue will try to close the Impala query when the user leaves the editor page, this will free all the query resources in Impala, but also make its results inaccessible, however, if you want to ensure that Hue close the Impala queries by adding the following settings to the Hue Service Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini configuration property:
[impala]
close_queries=true
query_timeout_s=
session_timeout_s=
By default query_timeout_s=300 and session_timeout_s=900, you can setup those based on your requirements.
Created 08-08-2024 10:01 PM
@caisch Did any of the responses help resolve your query? If it did, kindly mark the relevant reply as the solution, as it will aid others in locating the answer more easily in the future.
Regards,
Vidya Sargur,Created 08-09-2024 01:30 AM
I think this issue is caused by something else.
My suspicion is a wrong behavior of org.apache.shiro.web.filter.InvalidRequestFilter (we are using).