[jira] [Updated] (KNOX-2688) Perf test - Knox does not honour token limit per user
[
https://issues.apache.org/jira/browse/KNOX-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2688:
Summary: Perf test - Knox does not honour token limit per user (was: Knox
does not honour token limit per user)
> Perf test - Knox does not honour token limit per user
> -
>
> Key: KNOX-2688
> URL: https://issues.apache.org/jira/browse/KNOX-2688
> Project: Apache Knox
> Issue Type: Bug
>Affects Versions: 1.6.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
>
> *Steps to reproduce:*
> * configure Knox's performance test tool as follows:
> ** perf.test.usecase.knoxtoken.numOfThreads = 20
> ** perf.test.usecase.knoxtoken.topology.gateway=homepage
> ** perf.test.usecase.knoxtoken.requestDelayLowerBoundInSecs=1
> ** perf.test.usecase.knoxtoken.requestDelayUpperBoundInSecs=3
> * run the tool
> Observation: Knox allows more than 10 tokens to be created for the {{guest
> }}user. This should not be the case because the default token limit is 10.
> *RCA:*
> there is a gap between the token limit check and the actual place where the
> token metadata is saved in the underlying token backend. Thus - in the case
> of several threads are acquiring tokens - the flow lets this check pass and
> Knox continues to create the token.
> *Additional information:*
> This issue cannot be reproduced by generating tokens on the Token Generation
> page since tit requires a multi-threaded and highly concurrent ENV to happen.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KNOX-2849) Document necessary steps for being able to commit in GitHub
[ https://issues.apache.org/jira/browse/KNOX-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863179#comment-17863179 ] Sandor Molnar commented on KNOX-2849: - Hi [~marci] - Could you please document these steps on Knox's public Wiki? Thanks! > Document necessary steps for being able to commit in GitHub > --- > > Key: KNOX-2849 > URL: https://issues.apache.org/jira/browse/KNOX-2849 > Project: Apache Knox > Issue Type: Task > Components: Document > Reporter: Sandor Molnar >Assignee: Tamás Marcinkovics >Priority: Major > > [~MrtnBalazs] became a Knox Comitter last week and he needs to execute > several steps to be able to commit changes in GitHub. > Unfortunately, Knox does not have any public documentation about these steps. > A good sample is: > https://cwiki.apache.org/confluence/display/OPENWHISK/Accessing+Apache+GitHub+as+a+Committer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (KNOX-2849) Document necessary steps for being able to commit in GitHub
[ https://issues.apache.org/jira/browse/KNOX-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar reassigned KNOX-2849: --- Assignee: Tamás Marcinkovics (was: Sandor Molnar) > Document necessary steps for being able to commit in GitHub > --- > > Key: KNOX-2849 > URL: https://issues.apache.org/jira/browse/KNOX-2849 > Project: Apache Knox > Issue Type: Task > Components: Document > Reporter: Sandor Molnar >Assignee: Tamás Marcinkovics >Priority: Major > > [~MrtnBalazs] became a Knox Comitter last week and he needs to execute > several steps to be able to commit changes in GitHub. > Unfortunately, Knox does not have any public documentation about these steps. > A good sample is: > https://cwiki.apache.org/confluence/display/OPENWHISK/Accessing+Apache+GitHub+as+a+Committer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3021) Http connection properties are not applied when SSL is disabled
[
https://issues.apache.org/jira/browse/KNOX-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3021:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Http connection properties are not applied when SSL is disabled
> ---
>
> Key: KNOX-3021
> URL: https://issues.apache.org/jira/browse/KNOX-3021
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 2.0.0, 1.6.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is what we have now:
> {noformat}
> HttpConfiguration httpConfig = new HttpConfiguration();
> httpConfig.setRequestHeaderSize(
> config.getHttpServerRequestHeaderBuffer() );
> httpConfig.setResponseHeaderSize(
> config.getHttpServerResponseHeaderBuffer() );
> httpConfig.setOutputBufferSize( config.getHttpServerResponseBuffer() );
> if (config.isSSLEnabled()) {
> HttpConfiguration httpsConfig = new HttpConfiguration( httpConfig );
> ...
> connector = new ServerConnector( server, sslContextFactory, new
> HttpConnectionFactory( httpsConfig ) );
> } else {
> connector = new ServerConnector( server );
> } {noformat}
> When SSL is not enabled, the previously created {{httpConfig}} is not set in
> the created {{ServerConnector}} instance. Therefore, those properties do not
> take effect in those clusters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3024) Fix findJava in knox-functions.sh
[
https://issues.apache.org/jira/browse/KNOX-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3024:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Fix findJava in knox-functions.sh
> -
>
> Key: KNOX-3024
> URL: https://issues.apache.org/jira/browse/KNOX-3024
> Project: Apache Knox
> Issue Type: Bug
> Components: Release
>Affects Versions: 1.4.0, 1.5.0, 2.0.0, 1.6.0, 1.6.1, 1.6.2
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Blocker
> Fix For: 2.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> 5 years ago, when I added {{shellcheck}} support to our build in the scope of
> KNOX-1816, I introduced a bug in the {{findJava}} function in
> {{{}knox-functions.sh{}}}: when $JAVA_HOME is not set, and Java is not
> available on the path, the function tries to find java executables under
> {{{}/usr{}}}. However, the current implementation is wrong:
> {noformat}
> $ which java
> /usr/bin/which: no java in
> (/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
> $ echo $JAVA_HOME
> $ bin/knoxcli.sh export-cert --type JKS
> Warning: JAVA is not set and could not be found.
> ... {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3002) KnoxCLI command for generating descriptor for a role type from a list of hosts
[ https://issues.apache.org/jira/browse/KNOX-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3002: Fix Version/s: 2.1.0 Resolution: Fixed Status: Resolved (was: Patch Available) > KnoxCLI command for generating descriptor for a role type from a list of hosts > -- > > Key: KNOX-3002 > URL: https://issues.apache.org/jira/browse/KNOX-3002 > Project: Apache Knox > Issue Type: New Feature > Components: KnoxCLI >Reporter: Attila Magyar >Assignee: Attila Magyar >Priority: Major > Fix For: 2.1.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3007) Make http client cookie spec parameter configurable
[
https://issues.apache.org/jira/browse/KNOX-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3007:
Fix Version/s: 2.1.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Make http client cookie spec parameter configurable
> ---
>
> Key: KNOX-3007
> URL: https://issues.apache.org/jira/browse/KNOX-3007
> Project: Apache Knox
> Issue Type: Improvement
>Reporter: Attila Magyar
>Assignee: Attila Magyar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The apache http client rejects cookies if the expiration date doesn't have
> the expected format (EEE, dd-MMM-yy HH:mm:ss z).
> {code}
> 2023-11-20 17:58:51,189 XXX WARN protocol.ResponseProcessCookies
> (ResponseProcessCookies.java:processCookies(130)) - Invalid cookie header:
> "Set-Cookie: sessionid=XXX; expires=Mon, 20 Nov 2023 23:03:51 GMT; HttpOnly;
> Max-Age=300; Path=/; SameSite=Lax; Secure". Invalid 'expires' attribute: Mon,
> 20 Nov 2023 23:03:51 GMT
> {code}
> This can be reconfigured by setting different cookiespec types:
> https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/client/config/CookieSpecs.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3038) OAuth resource tokens are short-lived
[ https://issues.apache.org/jira/browse/KNOX-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3038: Resolution: Fixed Status: Resolved (was: Patch Available) > OAuth resource tokens are short-lived > - > > Key: KNOX-3038 > URL: https://issues.apache.org/jira/browse/KNOX-3038 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 2.1.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Blocker > Fix For: 2.1.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The tokens generated using the new OAuth resource (see KNOX-3028 for details) > have their expiration time in a format that indicates the time (in > milliseconds) from the epoch. This is wrong because the reaper thread will > eliminate them as soon as the next time it's triggered. > It's also important to emphasize, that tokens generated on the path need some > sort of indication of this value in the response. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3037) Wrong usage of client secret should not be accepted
[ https://issues.apache.org/jira/browse/KNOX-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3037: Resolution: Fixed Status: Resolved (was: Patch Available) > Wrong usage of client secret should not be accepted > --- > > Key: KNOX-3037 > URL: https://issues.apache.org/jira/browse/KNOX-3037 > Project: Apache Knox > Issue Type: Bug >Affects Versions: 2.1.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Critical > Fix For: 2.1.0 > > Time Spent: 50m > Remaining Estimate: 0h > > KNOX-3016 added the ability to support OAuth client credentials flow in Knox. > However, the current implementation expects those new parameters to be added > as query parameters. This approach can lead to a serious security issue. > In the scope of this item, we should update the existing implementation to > accept the grant type and client secret parameters in the request body only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3037) Wrong usage of client secret should not be accepted
[ https://issues.apache.org/jira/browse/KNOX-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3037: Affects Version/s: 2.1.0 Assignee: Sandor Molnar Status: Patch Available (was: Open) > Wrong usage of client secret should not be accepted > --- > > Key: KNOX-3037 > URL: https://issues.apache.org/jira/browse/KNOX-3037 > Project: Apache Knox > Issue Type: Bug >Affects Versions: 2.1.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Critical > Fix For: 2.1.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > KNOX-3016 added the ability to support OAuth client credentials flow in Knox. > However, the current implementation expects those new parameters to be added > as query parameters. This approach can lead to a serious security issue. > In the scope of this item, we should update the existing implementation to > accept the grant type and client secret parameters in the request body only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3038) OAuth resource tokens are short-lived
[ https://issues.apache.org/jira/browse/KNOX-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3038: Status: Patch Available (was: In Progress) > OAuth resource tokens are short-lived > - > > Key: KNOX-3038 > URL: https://issues.apache.org/jira/browse/KNOX-3038 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 2.1.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Blocker > Fix For: 2.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The tokens generated using the new OAuth resource (see KNOX-3028 for details) > have their expiration time in a format that indicates the time (in > milliseconds) from the epoch. This is wrong because the reaper thread will > eliminate them as soon as the next time it's triggered. > It's also important to emphasize, that tokens generated on the path need some > sort of indication of this value in the response. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (KNOX-3038) OAuth resource tokens are short-lived
[ https://issues.apache.org/jira/browse/KNOX-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-3038 started by Sandor Molnar. --- > OAuth resource tokens are short-lived > - > > Key: KNOX-3038 > URL: https://issues.apache.org/jira/browse/KNOX-3038 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 2.1.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Blocker > Fix For: 2.1.0 > > > The tokens generated using the new OAuth resource (see KNOX-3028 for details) > have their expiration time in a format that indicates the time (in > milliseconds) from the epoch. This is wrong because the reaper thread will > eliminate them as soon as the next time it's triggered. > It's also important to emphasize, that tokens generated on the path need some > sort of indication of this value in the response. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KNOX-3038) OAuth resource tokens are short-lived
Sandor Molnar created KNOX-3038: --- Summary: OAuth resource tokens are short-lived Key: KNOX-3038 URL: https://issues.apache.org/jira/browse/KNOX-3038 Project: Apache Knox Issue Type: Bug Components: Server Affects Versions: 2.1.0 Reporter: Sandor Molnar Assignee: Sandor Molnar Fix For: 2.1.0 The tokens generated using the new OAuth resource (see KNOX-3028 for details) have their expiration time in a format that indicates the time (in milliseconds) from the epoch. This is wrong because the reaper thread will eliminate them as soon as the next time it's triggered. It's also important to emphasize, that tokens generated on the path need some sort of indication of this value in the response. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3037) Wrong usage of client secret should not be accepted
[ https://issues.apache.org/jira/browse/KNOX-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3037: Description: KNOX-3016 added the ability to support OAuth client credentials flow in Knox. However, the current implementation expects those new parameters to be added as query parameters. This approach can lead to a serious security issue. In the scope of this item, we should update the existing implementation to accept the grant type and client secret parameters in the request body only. was: KNOX-3016 added the ability to support OAuth client credentials flow in Knox. However, the current implementation expects those new parameters to be added as query parameters. This approach can lead to a serious security issue because it means the client secret would be logged in gateway-audit.log. In the scope of this item, we should update the existing implementation to accept the grant type and client secret parameters in the request body only. > Wrong usage of client secret should not be accepted > --- > > Key: KNOX-3037 > URL: https://issues.apache.org/jira/browse/KNOX-3037 > Project: Apache Knox > Issue Type: Bug > Reporter: Sandor Molnar >Priority: Critical > Fix For: 2.1.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > KNOX-3016 added the ability to support OAuth client credentials flow in Knox. > However, the current implementation expects those new parameters to be added > as query parameters. This approach can lead to a serious security issue. > In the scope of this item, we should update the existing implementation to > accept the grant type and client secret parameters in the request body only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3037) Wrong usage of client secret should not be accepted
[ https://issues.apache.org/jira/browse/KNOX-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3037: Summary: Wrong usage of client secret should not be accepted (was: Exposed client secret in gateway-audit.log) > Wrong usage of client secret should not be accepted > --- > > Key: KNOX-3037 > URL: https://issues.apache.org/jira/browse/KNOX-3037 > Project: Apache Knox > Issue Type: Bug > Reporter: Sandor Molnar >Priority: Critical > Fix For: 2.1.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > KNOX-3016 added the ability to support OAuth client credentials flow in Knox. > However, the current implementation expects those new parameters to be added > as query parameters. This approach can lead to a serious security issue > because it means the client secret would be logged in gateway-audit.log. > In the scope of this item, we should update the existing implementation to > accept the grant type and client secret parameters in the request body only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KNOX-3037) Exposed client secret in gateway-audit.log
Sandor Molnar created KNOX-3037: --- Summary: Exposed client secret in gateway-audit.log Key: KNOX-3037 URL: https://issues.apache.org/jira/browse/KNOX-3037 Project: Apache Knox Issue Type: Bug Reporter: Sandor Molnar Fix For: 2.1.0 KNOX-3016 added the ability to support OAuth client credentials flow in Knox. However, the current implementation expects those new parameters to be added as query parameters. This approach can lead to a serious security issue because it means the client secret would be logged in gateway-audit.log. In the scope of this item, we should update the existing implementation to accept the grant type and client secret parameters in the request body only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (KNOX-3032) Passcode token verification doesn't return error when TSS is disabled
[
https://issues.apache.org/jira/browse/KNOX-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar resolved KNOX-3032.
-
Resolution: Fixed
> Passcode token verification doesn't return error when TSS is disabled
> -
>
> Key: KNOX-3032
> URL: https://issues.apache.org/jira/browse/KNOX-3032
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: proxy-token.xml
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *Steps to reproduce:*
> * configure a new topology (e.g. proxy-token) with {{JWTProvider}} where
> {{knox.token.exp.server-managed}} is set to {{false}} (see an example in the
> attachment)
> * acquire a Knox Token using the Token Generation UI
> * use the {{Passcode}} field in a {{curl}} request against a service
> endpoint in the new topology
> *Current results:*
> Knox returns an HTTP response with 200 status code
> {noformat}
> $ curl -iku
> Passcode:TkdVd1l6VTBPR0l0TmpVMk9DMDBNRFl4TFdFelpHTXROakk1TURnd09EYzJOVEJoOjpNREV6T0dGaFpXUXRZMkV5WVMwME4yWXhMVGhsWkRndFpUQmpNemszTlRrMlpqazE=
> https://localhost:8443/gateway/proxy-token/health/v1/gateway-status
> HTTP/1.1 200 OK
> Date: Mon, 29 Apr 2024 08:33:06 GMT
> Content-Length: 0
> {noformat}
> *Expected results:*
> An HTTP response should have been received with 401 and the proper error
> message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3032) Passcode token verification doesn't return error when TSS is disabled
[
https://issues.apache.org/jira/browse/KNOX-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3032:
Attachment: proxy-token.xml
> Passcode token verification doesn't return error when TSS is disabled
> -
>
> Key: KNOX-3032
> URL: https://issues.apache.org/jira/browse/KNOX-3032
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: proxy-token.xml
>
>
> *Steps to reproduce:*
> * configure a new topology (e.g. proxy-token) with {{JWTProvider}} where
> {{knox.token.exp.server-managed}} is set to {{false}} (see an example in the
> attachment)
> * acquire a Knox Token using the Token Generation UI
> * use the {{Passcode}} field in a {{curl}} request against a service
> endpoint in the new topology
> *Current results:*
> Knox returns an HTTP response with 200 status code
> {noformat}
> $ curl -iku
> Passcode:TkdVd1l6VTBPR0l0TmpVMk9DMDBNRFl4TFdFelpHTXROakk1TURnd09EYzJOVEJoOjpNREV6T0dGaFpXUXRZMkV5WVMwME4yWXhMVGhsWkRndFpUQmpNemszTlRrMlpqazE=
> https://localhost:8443/gateway/proxy-token/health/v1/gateway-status
> HTTP/1.1 200 OK
> Date: Mon, 29 Apr 2024 08:33:06 GMT
> Content-Length: 0
> {noformat}
> *Expected results:*
> An HTTP response should have been received with 401 and the proper error
> message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3032) Passcode token verification doesn't return error when TSS is disabled
Sandor Molnar created KNOX-3032:
---
Summary: Passcode token verification doesn't return error when TSS
is disabled
Key: KNOX-3032
URL: https://issues.apache.org/jira/browse/KNOX-3032
Project: Apache Knox
Issue Type: Bug
Components: Server
Affects Versions: 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
*Steps to reproduce:*
* configure a new topology (e.g. proxy-token) with {{JWTProvider}} where
{{knox.token.exp.server-managed}} is set to {{false}} (see an example in the
attachment)
* acquire a Knox Token using the Token Generation UI
* use the {{Passcode}} field in a {{curl}} request against a service endpoint
in the new topology
*Current results:*
Knox returns an HTTP response with 200 status code
{noformat}
$ curl -iku
Passcode:TkdVd1l6VTBPR0l0TmpVMk9DMDBNRFl4TFdFelpHTXROakk1TURnd09EYzJOVEJoOjpNREV6T0dGaFpXUXRZMkV5WVMwME4yWXhMVGhsWkRndFpUQmpNemszTlRrMlpqazE=
https://localhost:8443/gateway/proxy-token/health/v1/gateway-status
HTTP/1.1 200 OK
Date: Mon, 29 Apr 2024 08:33:06 GMT
Content-Length: 0
{noformat}
*Expected results:*
An HTTP response should have been received with 401 and the proper error
message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3030) SAXException occurs while parsing old topology on the descriptor handle path
[
https://issues.apache.org/jira/browse/KNOX-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3030:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> SAXException occurs while parsing old topology on the descriptor handle path
>
>
> Key: KNOX-3030
> URL: https://issues.apache.org/jira/browse/KNOX-3030
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In highly concurrent environments Knox may fail to parse the generated
> topology from descriptors/shared providers thus topology deployment fails
> with the following error:
> {noformat}
> 2024-01-26 10:35:25,173 ERROR topology.simple
> (SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
> comparing the generated cdp-proxy topology with the existing version:
> org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at
> line 35 char 20: class org.apache.knox.gateway.topology.Provider cannot be
> cast to class org.apache.knox.gateway.topology.Param
> (org.apache.knox.gateway.topology.Provider and
> org.apache.knox.gateway.topology.Param are in unnamed module of loader
> java.net.URLClassLoader @668bc3d5)
> 2024-01-26 10:35:25,173 INFO topology.simple
> (SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment
> of the cdp-proxy topology because it already exists and has not changed.
> {noformat}
> This will lead to unreachable end-user endpoints.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3030) SAXException occurs while parsing old topology on the descriptor handle path
[
https://issues.apache.org/jira/browse/KNOX-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3030:
Status: Patch Available (was: In Progress)
> SAXException occurs while parsing old topology on the descriptor handle path
>
>
> Key: KNOX-3030
> URL: https://issues.apache.org/jira/browse/KNOX-3030
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In highly concurrent environments Knox may fail to parse the generated
> topology from descriptors/shared providers thus topology deployment fails
> with the following error:
> {noformat}
> 2024-01-26 10:35:25,173 ERROR topology.simple
> (SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
> comparing the generated cdp-proxy topology with the existing version:
> org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at
> line 35 char 20: class org.apache.knox.gateway.topology.Provider cannot be
> cast to class org.apache.knox.gateway.topology.Param
> (org.apache.knox.gateway.topology.Provider and
> org.apache.knox.gateway.topology.Param are in unnamed module of loader
> java.net.URLClassLoader @668bc3d5)
> 2024-01-26 10:35:25,173 INFO topology.simple
> (SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment
> of the cdp-proxy topology because it already exists and has not changed.
> {noformat}
> This will lead to unreachable end-user endpoints.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3030) SAXException occurs while parsing old topology on the descriptor handle path
[
https://issues.apache.org/jira/browse/KNOX-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3030:
Description:
In highly concurrent environments Knox may fail to parse the generated
topology from descriptors/shared providers thus topology deployment fails with
the following error:
{noformat}
2024-01-26 10:35:25,173 ERROR topology.simple
(SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
comparing the generated cdp-proxy topology with the existing version:
org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at line
35 char 20: class org.apache.knox.gateway.topology.Provider cannot be cast to
class org.apache.knox.gateway.topology.Param
(org.apache.knox.gateway.topology.Provider and
org.apache.knox.gateway.topology.Param are in unnamed module of loader
java.net.URLClassLoader @668bc3d5)
2024-01-26 10:35:25,173 INFO topology.simple
(SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment of
the cdp-proxy topology because it already exists and has not changed. {noformat}
This will lead to unreachable end-user endpoints.
was:
In highly concurrent environments Knox may fail to parse degenrated topology
from descriptors/shared providers thus topology deployment fails with the
following error:
{noformat}
2024-01-26 10:35:25,173 ERROR topology.simple
(SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
comparing the generated cdp-proxy topology with the existing version:
org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at line
35 char 20: class org.apache.knox.gateway.topology.Provider cannot be cast to
class org.apache.knox.gateway.topology.Param
(org.apache.knox.gateway.topology.Provider and
org.apache.knox.gateway.topology.Param are in unnamed module of loader
java.net.URLClassLoader @668bc3d5)
2024-01-26 10:35:25,173 INFO topology.simple
(SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment of
the cdp-proxy topology because it already exists and has not changed. {noformat}
This will lead to unreachable end-user endpoints.
> SAXException occurs while parsing old topology on the descriptor handle path
>
>
> Key: KNOX-3030
> URL: https://issues.apache.org/jira/browse/KNOX-3030
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In highly concurrent environments Knox may fail to parse the generated
> topology from descriptors/shared providers thus topology deployment fails
> with the following error:
> {noformat}
> 2024-01-26 10:35:25,173 ERROR topology.simple
> (SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
> comparing the generated cdp-proxy topology with the existing version:
> org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at
> line 35 char 20: class org.apache.knox.gateway.topology.Provider cannot be
> cast to class org.apache.knox.gateway.topology.Param
> (org.apache.knox.gateway.topology.Provider and
> org.apache.knox.gateway.topology.Param are in unnamed module of loader
> java.net.URLClassLoader @668bc3d5)
> 2024-01-26 10:35:25,173 INFO topology.simple
> (SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment
> of the cdp-proxy topology because it already exists and has not changed.
> {noformat}
> This will lead to unreachable end-user endpoints.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3030) SAXException occurs while parsing old topology on the descriptor handle path
[
https://issues.apache.org/jira/browse/KNOX-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3030:
Description:
In highly concurrent environments Knox may fail to parse degenrated topology
from descriptors/shared providers thus topology deployment fails with the
following error:
{noformat}
2024-01-26 10:35:25,173 ERROR topology.simple
(SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
comparing the generated cdp-proxy topology with the existing version:
org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at line
35 char 20: class org.apache.knox.gateway.topology.Provider cannot be cast to
class org.apache.knox.gateway.topology.Param
(org.apache.knox.gateway.topology.Provider and
org.apache.knox.gateway.topology.Param are in unnamed module of loader
java.net.URLClassLoader @668bc3d5)
2024-01-26 10:35:25,173 INFO topology.simple
(SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment of
the cdp-proxy topology because it already exists and has not changed. {noformat}
This will lead to unreachable end-user endpoints.
was:
In highly concurrent environments Knox may fail to parse descriptors/shared
providers thus topology deployment fails with the following error:
{noformat}
2024-01-26 10:35:25,173 ERROR topology.simple
(SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
comparing the generated cdp-proxy topology with the existing version:
org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at line
35 char 20: class org.apache.knox.gateway.topology.Provider cannot be cast to
class org.apache.knox.gateway.topology.Param
(org.apache.knox.gateway.topology.Provider and
org.apache.knox.gateway.topology.Param are in unnamed module of loader
java.net.URLClassLoader @668bc3d5)
2024-01-26 10:35:25,173 INFO topology.simple
(SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment of
the cdp-proxy topology because it already exists and has not changed. {noformat}
This will lead to unreachable end-user endpoints.
> SAXException occurs while parsing old topology on the descriptor handle path
>
>
> Key: KNOX-3030
> URL: https://issues.apache.org/jira/browse/KNOX-3030
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In highly concurrent environments Knox may fail to parse degenrated topology
> from descriptors/shared providers thus topology deployment fails with the
> following error:
> {noformat}
> 2024-01-26 10:35:25,173 ERROR topology.simple
> (SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
> comparing the generated cdp-proxy topology with the existing version:
> org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at
> line 35 char 20: class org.apache.knox.gateway.topology.Provider cannot be
> cast to class org.apache.knox.gateway.topology.Param
> (org.apache.knox.gateway.topology.Provider and
> org.apache.knox.gateway.topology.Param are in unnamed module of loader
> java.net.URLClassLoader @668bc3d5)
> 2024-01-26 10:35:25,173 INFO topology.simple
> (SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment
> of the cdp-proxy topology because it already exists and has not changed.
> {noformat}
> This will lead to unreachable end-user endpoints.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (KNOX-3030) SAXException occurs while parsing old topology on the descriptor handle path
[
https://issues.apache.org/jira/browse/KNOX-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-3030 started by Sandor Molnar.
---
> SAXException occurs while parsing old topology on the descriptor handle path
>
>
> Key: KNOX-3030
> URL: https://issues.apache.org/jira/browse/KNOX-3030
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
>
> In highly concurrent environments Knox may fail to parse descriptors/shared
> providers thus topology deployment fails with the following error:
> {noformat}
> 2024-01-26 10:35:25,173 ERROR topology.simple
> (SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
> comparing the generated cdp-proxy topology with the existing version:
> org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at
> line 35 char 20: class org.apache.knox.gateway.topology.Provider cannot be
> cast to class org.apache.knox.gateway.topology.Param
> (org.apache.knox.gateway.topology.Provider and
> org.apache.knox.gateway.topology.Param are in unnamed module of loader
> java.net.URLClassLoader @668bc3d5)
> 2024-01-26 10:35:25,173 INFO topology.simple
> (SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment
> of the cdp-proxy topology because it already exists and has not changed.
> {noformat}
> This will lead to unreachable end-user endpoints.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3030) SAXException occurs while parsing old topology on the descriptor handle path
Sandor Molnar created KNOX-3030:
---
Summary: SAXException occurs while parsing old topology on the
descriptor handle path
Key: KNOX-3030
URL: https://issues.apache.org/jira/browse/KNOX-3030
Project: Apache Knox
Issue Type: Bug
Components: Server
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
In highly concurrent environments Knox may fail to parse descriptors/shared
providers thus topology deployment fails with the following error:
{noformat}
2024-01-26 10:35:25,173 ERROR topology.simple
(SimpleDescriptorHandler.java:shouldPersistGeneratedTopology(682)) - Error
comparing the generated cdp-proxy topology with the existing version:
org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 20; Error at line
35 char 20: class org.apache.knox.gateway.topology.Provider cannot be cast to
class org.apache.knox.gateway.topology.Param
(org.apache.knox.gateway.topology.Provider and
org.apache.knox.gateway.topology.Param are in unnamed module of loader
java.net.URLClassLoader @668bc3d5)
2024-01-26 10:35:25,173 INFO topology.simple
(SimpleDescriptorHandler.java:generateTopology(622)) - Skipping redeployment of
the cdp-proxy topology because it already exists and has not changed. {noformat}
This will lead to unreachable end-user endpoints.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (KNOX-3027) CM discovery cache improvements
[ https://issues.apache.org/jira/browse/KNOX-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar reassigned KNOX-3027: --- Assignee: Sandeep More (was: Sandor Molnar) > CM discovery cache improvements > --- > > Key: KNOX-3027 > URL: https://issues.apache.org/jira/browse/KNOX-3027 > Project: Apache Knox > Issue Type: Improvement > Components: cm-discovery, Server >Affects Versions: 2.0.0, 1.6.0 > Reporter: Sandor Molnar >Assignee: Sandeep More >Priority: Critical > Fix For: 2.1.0 > > > With KNOX-2680 in place, Knox maintains an in-memory cache that stores CM > service discovery data. This repository was a huge improvement and solved > some of the performance issues around CM service discovery, but there are > some drawback: > * administrators are required to fine-tune the cache entry TTL as the > default 10 minutes can be low in many cases > * the repository does not survive Knox restarts > I propose to implement the following changes: > * entries in that repository shall not be invalidated. They would live in > memory throughout the entire lifetime of the Knox Gateway. The existing > PollingConfigAnalyzer logic must be updated to keep that repository in synch. > * the repository should be serialized in the DATA_DIR during the shutdown of > the Knox Gateway. It should also be populated from the previously persisted > data at startup time. If there was a change on the cluster when Knox was > down, PollingConfigurationAnalyzer will eventually sync the repository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KNOX-3027) CM discovery cache improvements
Sandor Molnar created KNOX-3027: --- Summary: CM discovery cache improvements Key: KNOX-3027 URL: https://issues.apache.org/jira/browse/KNOX-3027 Project: Apache Knox Issue Type: Improvement Components: cm-discovery, Server Affects Versions: 1.6.0, 2.0.0 Reporter: Sandor Molnar Assignee: Sandor Molnar Fix For: 2.1.0 With KNOX-2680 in place, Knox maintains an in-memory cache that stores CM service discovery data. This repository was a huge improvement and solved some of the performance issues around CM service discovery, but there are some drawback: * administrators are required to fine-tune the cache entry TTL as the default 10 minutes can be low in many cases * the repository does not survive Knox restarts I propose to implement the following changes: * entries in that repository shall not be invalidated. They would live in memory throughout the entire lifetime of the Knox Gateway. The existing PollingConfigAnalyzer logic must be updated to keep that repository in synch. * the repository should be serialized in the DATA_DIR during the shutdown of the Knox Gateway. It should also be populated from the previously persisted data at startup time. If there was a change on the cluster when Knox was down, PollingConfigurationAnalyzer will eventually sync the repository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KNOX-3025) Use newer browser features in knoxauth.js + Removal of used variables
[
https://issues.apache.org/jira/browse/KNOX-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830976#comment-17830976
]
Sandor Molnar commented on KNOX-3025:
-
Hi [~redyetidev] !
First of all, thanks for your contribution to Apache Knox.
Second, could you please elaborate on the above items and explain to us why
your suggested improvements are better than what we have now?
Why is one technic is more efficient than the other? Etc...
Thanks!
> Use newer browser features in knoxauth.js + Removal of used variables
> -
>
> Key: KNOX-3025
> URL: https://issues.apache.org/jira/browse/KNOX-3025
> Project: Apache Knox
> Issue Type: Improvement
>Reporter: Aviv Keller
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The knoxauth.js file currently utilizes outdated and inefficient browser
> features. It could be optimized by leveraging newer, more efficient
> alternatives.
> Details:
> - Rename the 'get' function to 'getQueryParam' and implement it using
> URLSearchParams for clarity and efficiency.
> - Update the 'isSameOrigin' function to utilize URL instead of
> document.create("a") for improved performance.
> - Fully rely on window.location.replace for redirect operations to enhance
> efficiency and reliability.
> - Implement newer techniques in the 'login' function to achieve the desired
> outcome more efficiently.
> - Replace jQuery usage with native features to improve speed and reduce
> complexity in the codebase.
> - And more
> [https://github.com/apache/knox/pull/892/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3024) Fix findJava in knox-functions.sh
[
https://issues.apache.org/jira/browse/KNOX-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3024:
Status: Patch Available (was: Open)
> Fix findJava in knox-functions.sh
> -
>
> Key: KNOX-3024
> URL: https://issues.apache.org/jira/browse/KNOX-3024
> Project: Apache Knox
> Issue Type: Bug
> Components: Release
>Affects Versions: 1.6.0, 1.5.0, 1.4.0, 2.0.0, 1.6.1, 1.6.2
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Blocker
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 5 years ago, when I added {{shellcheck}} support to our build in the scope of
> KNOX-1816, I introduced a bug in the {{findJava}} function in
> {{{}knox-functions.sh{}}}: when $JAVA_HOME is not set, and Java is not
> available on the path, the function tries to find java executables under
> {{{}/usr{}}}. However, the current implementation is wrong:
> {noformat}
> $ which java
> /usr/bin/which: no java in
> (/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
> $ echo $JAVA_HOME
> $ bin/knoxcli.sh export-cert --type JKS
> Warning: JAVA is not set and could not be found.
> ... {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3024) Fix findJava in knox-functions.sh
Sandor Molnar created KNOX-3024:
---
Summary: Fix findJava in knox-functions.sh
Key: KNOX-3024
URL: https://issues.apache.org/jira/browse/KNOX-3024
Project: Apache Knox
Issue Type: Bug
Components: Release
Affects Versions: 1.6.0, 1.5.0, 1.4.0, 2.0.0, 1.6.1, 1.6.2
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
5 years ago, when I added {{shellcheck}} support to our build in the scope of
KNOX-1816, I introduced a bug in the {{findJava}} function in
{{{}knox-functions.sh{}}}: when $JAVA_HOME is not set, and Java is not
available on the path, the function tries to find java executables under
{{{}/usr{}}}. However, the current implementation is wrong:
{noformat}
$ which java
/usr/bin/which: no java in
(/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
$ echo $JAVA_HOME
$ bin/knoxcli.sh export-cert --type JKS
Warning: JAVA is not set and could not be found.
... {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3022) Possible NPE at CM cluster configuration monitor startup due to cluster configuration file issues
[
https://issues.apache.org/jira/browse/KNOX-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3022:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Possible NPE at CM cluster configuration monitor startup due to cluster
> configuration file issues
> -
>
> Key: KNOX-3022
> URL: https://issues.apache.org/jira/browse/KNOX-3022
> Project: Apache Knox
> Issue Type: Bug
> Components: cm-discovery
>Affects Versions: 2.0.0, 1.6.0
> Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In KNOX-2869, we handled the case where
> {{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.conf}} file was empty.
> However, it might be the same for the
> {{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.ver}} file where
> previously persisted cluster configuration (with service/role details) is
> stored.
> If that file is empty, the following error is thrown:
> {noformat}
> 2024-03-18 19:01:34,840 ERROR discovery.cm
> (ClusterConfigurationFileStore.java:get(106)) - Failed to load persisted
> service configuration data for cluster monitor CM :
> com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to
> map due to end-of-input
> at [Source: (sun.nio.ch.ChannelInputStream); line: 1, column: 0]
> 2024-03-18 19:01:34,841 FATAL knox.gateway (GatewayServer.java:main(193)) -
> Failed to start gateway: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.loadServiceConfiguration(ClouderaManagerClusterConfigurationMonitor.java:196)
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.(ClouderaManagerClusterConfigurationMonitor.java:103)
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitorProvider.newInstance(ClouderaManagerClusterConfigurationMonitorProvider.java:35)
> at
> org.apache.knox.gateway.services.topology.impl.DefaultClusterConfigurationMonitorService.init(DefaultClusterConfigurationMonitorService.java:44)
> at
> org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:137)
> at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:184)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.knox.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:68)
> at org.apache.knox.gateway.launcher.Invoker.invoke(Invoker.java:39)
> at org.apache.knox.gateway.launcher.Command.run(Command.java:99)
> at org.apache.knox.gateway.launcher.Launcher.run(Launcher.java:75)
> at org.apache.knox.gateway.launcher.Launcher.main(Launcher.java:52)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3022) Possible NPE at CM cluster configuration monitor startup due to cluster configuration file issues
[
https://issues.apache.org/jira/browse/KNOX-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3022:
Status: Patch Available (was: In Progress)
> Possible NPE at CM cluster configuration monitor startup due to cluster
> configuration file issues
> -
>
> Key: KNOX-3022
> URL: https://issues.apache.org/jira/browse/KNOX-3022
> Project: Apache Knox
> Issue Type: Bug
> Components: cm-discovery
>Affects Versions: 1.6.0, 2.0.0
> Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In KNOX-2869, we handled the case where
> {{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.conf}} file was empty.
> However, it might be the same for the
> {{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.ver}} file where
> previously persisted cluster configuration (with service/role details) is
> stored.
> If that file is empty, the following error is thrown:
> {noformat}
> 2024-03-18 19:01:34,840 ERROR discovery.cm
> (ClusterConfigurationFileStore.java:get(106)) - Failed to load persisted
> service configuration data for cluster monitor CM :
> com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to
> map due to end-of-input
> at [Source: (sun.nio.ch.ChannelInputStream); line: 1, column: 0]
> 2024-03-18 19:01:34,841 FATAL knox.gateway (GatewayServer.java:main(193)) -
> Failed to start gateway: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.loadServiceConfiguration(ClouderaManagerClusterConfigurationMonitor.java:196)
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.(ClouderaManagerClusterConfigurationMonitor.java:103)
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitorProvider.newInstance(ClouderaManagerClusterConfigurationMonitorProvider.java:35)
> at
> org.apache.knox.gateway.services.topology.impl.DefaultClusterConfigurationMonitorService.init(DefaultClusterConfigurationMonitorService.java:44)
> at
> org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:137)
> at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:184)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.knox.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:68)
> at org.apache.knox.gateway.launcher.Invoker.invoke(Invoker.java:39)
> at org.apache.knox.gateway.launcher.Command.run(Command.java:99)
> at org.apache.knox.gateway.launcher.Launcher.run(Launcher.java:75)
> at org.apache.knox.gateway.launcher.Launcher.main(Launcher.java:52)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (KNOX-3022) Possible NPE at CM cluster configuration monitor startup due to cluster configuration file issues
[
https://issues.apache.org/jira/browse/KNOX-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-3022 started by Sandor Molnar.
---
> Possible NPE at CM cluster configuration monitor startup due to cluster
> configuration file issues
> -
>
> Key: KNOX-3022
> URL: https://issues.apache.org/jira/browse/KNOX-3022
> Project: Apache Knox
> Issue Type: Bug
> Components: cm-discovery
>Affects Versions: 2.0.0, 1.6.0
> Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
>
> In KNOX-2869, we handled the case where
> {{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.conf}} file was empty.
> However, it might be the same for the
> {{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.ver}} file where
> previously persisted cluster configuration (with service/role details) is
> stored.
> If that file is empty, the following error is thrown:
> {noformat}
> 2024-03-18 19:01:34,840 ERROR discovery.cm
> (ClusterConfigurationFileStore.java:get(106)) - Failed to load persisted
> service configuration data for cluster monitor CM :
> com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to
> map due to end-of-input
> at [Source: (sun.nio.ch.ChannelInputStream); line: 1, column: 0]
> 2024-03-18 19:01:34,841 FATAL knox.gateway (GatewayServer.java:main(193)) -
> Failed to start gateway: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.loadServiceConfiguration(ClouderaManagerClusterConfigurationMonitor.java:196)
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.(ClouderaManagerClusterConfigurationMonitor.java:103)
> at
> org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitorProvider.newInstance(ClouderaManagerClusterConfigurationMonitorProvider.java:35)
> at
> org.apache.knox.gateway.services.topology.impl.DefaultClusterConfigurationMonitorService.init(DefaultClusterConfigurationMonitorService.java:44)
> at
> org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:137)
> at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:184)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.knox.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:68)
> at org.apache.knox.gateway.launcher.Invoker.invoke(Invoker.java:39)
> at org.apache.knox.gateway.launcher.Command.run(Command.java:99)
> at org.apache.knox.gateway.launcher.Launcher.run(Launcher.java:75)
> at org.apache.knox.gateway.launcher.Launcher.main(Launcher.java:52)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3022) Possible NPE at CM cluster configuration monitor startup due to cluster configuration file issues
[
https://issues.apache.org/jira/browse/KNOX-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3022:
Description:
In KNOX-2869, we handled the case where
{{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.conf}} file was empty.
However, it might be the same for the
{{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.ver}} file where
previously persisted cluster configuration (with service/role details) is
stored.
If that file is empty, the following error is thrown:
{noformat}
2024-03-18 19:01:34,840 ERROR discovery.cm
(ClusterConfigurationFileStore.java:get(106)) - Failed to load persisted
service configuration data for cluster monitor CM :
com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to map
due to end-of-input
at [Source: (sun.nio.ch.ChannelInputStream); line: 1, column: 0]
2024-03-18 19:01:34,841 FATAL knox.gateway (GatewayServer.java:main(193)) -
Failed to start gateway: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.loadServiceConfiguration(ClouderaManagerClusterConfigurationMonitor.java:196)
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.(ClouderaManagerClusterConfigurationMonitor.java:103)
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitorProvider.newInstance(ClouderaManagerClusterConfigurationMonitorProvider.java:35)
at
org.apache.knox.gateway.services.topology.impl.DefaultClusterConfigurationMonitorService.init(DefaultClusterConfigurationMonitorService.java:44)
at
org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:137)
at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.knox.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:68)
at org.apache.knox.gateway.launcher.Invoker.invoke(Invoker.java:39)
at org.apache.knox.gateway.launcher.Command.run(Command.java:99)
at org.apache.knox.gateway.launcher.Launcher.run(Launcher.java:75)
at org.apache.knox.gateway.launcher.Launcher.main(Launcher.java:52)
{noformat}
was:
In KNOX-2689, we handled the case where
{{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.conf}} file was empty.
However, it might be the same for the
{{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.ver}} file where
previously persisted cluster configuration (with service/role details) is
stored.
If that file is empty, the following error is thrown:
{noformat}
2024-03-18 19:01:34,840 ERROR discovery.cm
(ClusterConfigurationFileStore.java:get(106)) - Failed to load persisted
service configuration data for cluster monitor CM :
com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to map
due to end-of-input
at [Source: (sun.nio.ch.ChannelInputStream); line: 1, column: 0]
2024-03-18 19:01:34,841 FATAL knox.gateway (GatewayServer.java:main(193)) -
Failed to start gateway: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.loadServiceConfiguration(ClouderaManagerClusterConfigurationMonitor.java:196)
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.(ClouderaManagerClusterConfigurationMonitor.java:103)
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitorProvider.newInstance(ClouderaManagerClusterConfigurationMonitorProvider.java:35)
at
org.apache.knox.gateway.services.topology.impl.DefaultClusterConfigurationMonitorService.init(DefaultClusterConfigurationMonitorService.java:44)
at
org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:137)
at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.knox.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:68)
at org.apache.knox.gateway.launcher.Invoker.invoke(Invoker.java:39)
at org.apache.knox.gateway.launcher.Command.run
[jira] [Created] (KNOX-3022) Possible NPE at CM cluster configuration monitor startup due to cluster configuration file issues
Sandor Molnar created KNOX-3022:
---
Summary: Possible NPE at CM cluster configuration monitor startup
due to cluster configuration file issues
Key: KNOX-3022
URL: https://issues.apache.org/jira/browse/KNOX-3022
Project: Apache Knox
Issue Type: Bug
Components: cm-discovery
Affects Versions: 1.6.0, 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
In KNOX-2689, we handled the case where
{{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.conf}} file was empty.
However, it might be the same for the
{{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.ver}} file where
previously persisted cluster configuration (with service/role details) is
stored.
If that file is empty, the following error is thrown:
{noformat}
2024-03-18 19:01:34,840 ERROR discovery.cm
(ClusterConfigurationFileStore.java:get(106)) - Failed to load persisted
service configuration data for cluster monitor CM :
com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to map
due to end-of-input
at [Source: (sun.nio.ch.ChannelInputStream); line: 1, column: 0]
2024-03-18 19:01:34,841 FATAL knox.gateway (GatewayServer.java:main(193)) -
Failed to start gateway: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.loadServiceConfiguration(ClouderaManagerClusterConfigurationMonitor.java:196)
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.(ClouderaManagerClusterConfigurationMonitor.java:103)
at
org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitorProvider.newInstance(ClouderaManagerClusterConfigurationMonitorProvider.java:35)
at
org.apache.knox.gateway.services.topology.impl.DefaultClusterConfigurationMonitorService.init(DefaultClusterConfigurationMonitorService.java:44)
at
org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:137)
at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.knox.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:68)
at org.apache.knox.gateway.launcher.Invoker.invoke(Invoker.java:39)
at org.apache.knox.gateway.launcher.Command.run(Command.java:99)
at org.apache.knox.gateway.launcher.Launcher.run(Launcher.java:75)
at org.apache.knox.gateway.launcher.Launcher.main(Launcher.java:52)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3020) Introduce type Knox Token metadata
[
https://issues.apache.org/jira/browse/KNOX-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3020:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Introduce type Knox Token metadata
> --
>
> Key: KNOX-3020
> URL: https://issues.apache.org/jira/browse/KNOX-3020
> Project: Apache Knox
> Issue Type: Task
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With KNOX-3016, there is a need to distinguish different Knox Token types as
> follows:
> * JWT (default)
> * KNOXSSO_COOKIE
> * CLIENT_ID
> This little refactor will allow us to handle every type-related decision
> within the scope of the\{{TokenMetadata}} class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3021) Http connection properties are not applied when SSL is disabled
[
https://issues.apache.org/jira/browse/KNOX-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3021:
Status: Patch Available (was: In Progress)
> Http connection properties are not applied when SSL is disabled
> ---
>
> Key: KNOX-3021
> URL: https://issues.apache.org/jira/browse/KNOX-3021
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.6.0, 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is what we have now:
> {noformat}
> HttpConfiguration httpConfig = new HttpConfiguration();
> httpConfig.setRequestHeaderSize(
> config.getHttpServerRequestHeaderBuffer() );
> httpConfig.setResponseHeaderSize(
> config.getHttpServerResponseHeaderBuffer() );
> httpConfig.setOutputBufferSize( config.getHttpServerResponseBuffer() );
> if (config.isSSLEnabled()) {
> HttpConfiguration httpsConfig = new HttpConfiguration( httpConfig );
> ...
> connector = new ServerConnector( server, sslContextFactory, new
> HttpConnectionFactory( httpsConfig ) );
> } else {
> connector = new ServerConnector( server );
> } {noformat}
> When SSL is not enabled, the previously created {{httpConfig}} is not set in
> the created {{ServerConnector}} instance. Therefore, those properties do not
> take effect in those clusters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3021) Http connection properties are not applied when SSL is disabled
Sandor Molnar created KNOX-3021:
---
Summary: Http connection properties are not applied when SSL is
disabled
Key: KNOX-3021
URL: https://issues.apache.org/jira/browse/KNOX-3021
Project: Apache Knox
Issue Type: Bug
Components: Server
Affects Versions: 1.6.0, 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
This is what we have now:
{noformat}
HttpConfiguration httpConfig = new HttpConfiguration();
httpConfig.setRequestHeaderSize(
config.getHttpServerRequestHeaderBuffer() );
httpConfig.setResponseHeaderSize(
config.getHttpServerResponseHeaderBuffer() );
httpConfig.setOutputBufferSize( config.getHttpServerResponseBuffer() );
if (config.isSSLEnabled()) {
HttpConfiguration httpsConfig = new HttpConfiguration( httpConfig );
...
connector = new ServerConnector( server, sslContextFactory, new
HttpConnectionFactory( httpsConfig ) );
} else {
connector = new ServerConnector( server );
} {noformat}
When SSL is not enabled, the previously created {{httpConfig}} is not set in
the created {{ServerConnector}} instance. Therefore, those properties do not
take effect in those clusters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (KNOX-3021) Http connection properties are not applied when SSL is disabled
[
https://issues.apache.org/jira/browse/KNOX-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-3021 started by Sandor Molnar.
---
> Http connection properties are not applied when SSL is disabled
> ---
>
> Key: KNOX-3021
> URL: https://issues.apache.org/jira/browse/KNOX-3021
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 2.0.0, 1.6.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
>
> This is what we have now:
> {noformat}
> HttpConfiguration httpConfig = new HttpConfiguration();
> httpConfig.setRequestHeaderSize(
> config.getHttpServerRequestHeaderBuffer() );
> httpConfig.setResponseHeaderSize(
> config.getHttpServerResponseHeaderBuffer() );
> httpConfig.setOutputBufferSize( config.getHttpServerResponseBuffer() );
> if (config.isSSLEnabled()) {
> HttpConfiguration httpsConfig = new HttpConfiguration( httpConfig );
> ...
> connector = new ServerConnector( server, sslContextFactory, new
> HttpConnectionFactory( httpsConfig ) );
> } else {
> connector = new ServerConnector( server );
> } {noformat}
> When SSL is not enabled, the previously created {{httpConfig}} is not set in
> the created {{ServerConnector}} instance. Therefore, those properties do not
> take effect in those clusters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3020) Introduce type Knox Token metadata
[
https://issues.apache.org/jira/browse/KNOX-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3020:
Status: Patch Available (was: Open)
> Introduce type Knox Token metadata
> --
>
> Key: KNOX-3020
> URL: https://issues.apache.org/jira/browse/KNOX-3020
> Project: Apache Knox
> Issue Type: Task
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With KNOX-3016, there is a need to distinguish different Knox Token types as
> follows:
> * JWT (default)
> * KNOXSSO_COOKIE
> * CLIENT_ID
> This little refactor will allow us to handle every type-related decision
> within the scope of the\{{TokenMetadata}} class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (KNOX-3019) Allow tokens to be renewed any times
[
https://issues.apache.org/jira/browse/KNOX-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar resolved KNOX-3019.
-
Resolution: Fixed
> Allow tokens to be renewed any times
>
>
> Key: KNOX-3019
> URL: https://issues.apache.org/jira/browse/KNOX-3019
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server, TokenGenerationUI
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Setting the TTL to {{-1}} results in tokens that never expire. If the TTL is
> configured to a positive number, renewing the token is the only way to extend
> its expiration time. By default, there is a cap on this event: a token cannot
> be renewed after it reaches the configured maximum lifetime (defaults to
> {{{}7 days{}}}).
> This task aims to provide end-users with a way to bypass this check and let
> tokens be renewed whenever they want. The logic would be similar to the
> {{Unlimited token}} handling: if the maximum lifetime is set to {{{}-1{}}},
> tokens would be subject to renewal without checking the maximum lifetime.
> Please note that token renewal still must be configured with a list of
> trusted users via the {{knox.token.renewer.whitelist}} configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3020) Introduce type Knox Token metadata
Sandor Molnar created KNOX-3020:
---
Summary: Introduce type Knox Token metadata
Key: KNOX-3020
URL: https://issues.apache.org/jira/browse/KNOX-3020
Project: Apache Knox
Issue Type: Task
Affects Versions: 2.1.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
With KNOX-3016, there is a need to distinguish different Knox Token types as
follows:
* JWT (default)
* KNOXSSO_COOKIE
* CLIENT_ID
This little refactor will allow us to handle every type-related decision within
the scope of the\{{TokenMetadata}} class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (KNOX-3019) Allow tokens to be renewed any times
[
https://issues.apache.org/jira/browse/KNOX-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-3019 started by Sandor Molnar.
---
> Allow tokens to be renewed any times
>
>
> Key: KNOX-3019
> URL: https://issues.apache.org/jira/browse/KNOX-3019
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server, TokenGenerationUI
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
>
> Setting the TTL to {{-1}} results in tokens that never expire. If the TTL is
> configured to a positive number, renewing the token is the only way to extend
> its expiration time. By default, there is a cap on this event: a token cannot
> be renewed after it reaches the configured maximum lifetime (defaults to
> {{{}7 days{}}}).
> This task aims to provide end-users with a way to bypass this check and let
> tokens be renewed whenever they want. The logic would be similar to the
> {{Unlimited token}} handling: if the maximum lifetime is set to {{{}-1{}}},
> tokens would be subject to renewal without checking the maximum lifetime.
> Please note that token renewal still must be configured with a list of
> trusted users via the {{knox.token.renewer.whitelist}} configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3019) Allow tokens to be renewed any times
Sandor Molnar created KNOX-3019:
---
Summary: Allow tokens to be renewed any times
Key: KNOX-3019
URL: https://issues.apache.org/jira/browse/KNOX-3019
Project: Apache Knox
Issue Type: Improvement
Components: Server, TokenGenerationUI
Affects Versions: 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
Setting the TTL to {{-1}} results in tokens that never expire. If the TTL is
configured to a positive number, renewing the token is the only way to extend
its expiration time. By default, there is a cap on this event: a token cannot
be renewed after it reaches the configured maximum lifetime (defaults to {{{}7
days{}}}).
This task aims to provide end-users with a way to bypass this check and let
tokens be renewed whenever they want. The logic would be similar to the
{{Unlimited token}} handling: if the maximum lifetime is set to {{{}-1{}}},
tokens would be subject to renewal without checking the maximum lifetime.
Please note that token renewal still must be configured with a list of trusted
users via the {{knox.token.renewer.whitelist}} configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3018) Unlimited token generation - Wrong expiration time is shown
[
https://issues.apache.org/jira/browse/KNOX-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3018:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Unlimited token generation - Wrong expiration time is shown
> ---
>
> Key: KNOX-3018
> URL: https://issues.apache.org/jira/browse/KNOX-3018
> Project: Apache Knox
> Issue Type: Bug
> Components: TokenGenerationUI
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: Screenshot 2024-03-11 at 14.25.04.png, Screenshot
> 2024-03-11 at 14.25.27.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Steps to reproduce*
> * set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
> {{KNOXTOKEN}} service
> * set {{knox.token.lifespan.input.enabled = false}} in the {{homepage}}
> topology for the {{KNOXTOKEN}} service
> *Actual results*
> With KNOX-3017 in place, the token is generated, but the expiration is wrong,
> see attached screenshots.
> In addition to this UI bug, the background reaper thread removes this token
> the next time it's triggered. This is also incorrect: unlimited tokens should
> never be removed automatically as they never expire.
> *Expected result*
> Token expiration should indicate an unlimited lifespan and unlimited tokens
> should not be revoked automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3017) Unlimited token generation - invalid warning poopup
[
https://issues.apache.org/jira/browse/KNOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3017:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Unlimited token generation - invalid warning poopup
> ---
>
> Key: KNOX-3017
> URL: https://issues.apache.org/jira/browse/KNOX-3017
> Project: Apache Knox
> Issue Type: Bug
> Components: TokenGenerationUI
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: Screenshot 2024-03-11 at 12.57.12.png, Screenshot
> 2024-03-11 at 12.57.35.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Steps to reproduce*
> * set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
> {{KNOXTOKEN}} service
> * go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
> *Actual results*
> The lifespan adjusting warning popup says that 365 days is greater than the
> configured maximum lifetime. This is not true, because, as you can see in the
> screenshot, we are creating tokens with {{unlimited lifetime}}
> *Expected result*
> The popup should not be displayed in case of unlimited token lifetime
> configurations.
> *Note*
> After clicking the {{Generate token anyway}} button, the token was created
> with the correct expiration time (1 year from today).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3018) Unlimited token generation - Wrong expiration time is shown
[
https://issues.apache.org/jira/browse/KNOX-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3018:
Status: Patch Available (was: Open)
> Unlimited token generation - Wrong expiration time is shown
> ---
>
> Key: KNOX-3018
> URL: https://issues.apache.org/jira/browse/KNOX-3018
> Project: Apache Knox
> Issue Type: Bug
> Components: TokenGenerationUI
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: Screenshot 2024-03-11 at 14.25.04.png, Screenshot
> 2024-03-11 at 14.25.27.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Steps to reproduce*
> * set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
> {{KNOXTOKEN}} service
> * set {{knox.token.lifespan.input.enabled = false}} in the {{homepage}}
> topology for the {{KNOXTOKEN}} service
> *Actual results*
> With KNOX-3017 in place, the token is generated, but the expiration is wrong,
> see attached screenshots.
> In addition to this UI bug, the background reaper thread removes this token
> the next time it's triggered. This is also incorrect: unlimited tokens should
> never be removed automatically as they never expire.
> *Expected result*
> Token expiration should indicate an unlimited lifespan and unlimited tokens
> should not be revoked automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3017) Unlimited token generation - invalid warning poopup
[
https://issues.apache.org/jira/browse/KNOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3017:
Status: Patch Available (was: In Progress)
> Unlimited token generation - invalid warning poopup
> ---
>
> Key: KNOX-3017
> URL: https://issues.apache.org/jira/browse/KNOX-3017
> Project: Apache Knox
> Issue Type: Bug
> Components: TokenGenerationUI
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: Screenshot 2024-03-11 at 12.57.12.png, Screenshot
> 2024-03-11 at 12.57.35.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Steps to reproduce*
> * set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
> {{KNOXTOKEN}} service
> * go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
> *Actual results*
> The lifespan adjusting warning popup says that 365 days is greater than the
> configured maximum lifetime. This is not true, because, as you can see in the
> screenshot, we are creating tokens with {{unlimited lifetime}}
> *Expected result*
> The popup should not be displayed in case of unlimited token lifetime
> configurations.
> *Note*
> After clicking the {{Generate token anyway}} button, the token was created
> with the correct expiration time (1 year from today).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3018) Unlimited token generation - Wrong expiration time is shown
Sandor Molnar created KNOX-3018:
---
Summary: Unlimited token generation - Wrong expiration time is
shown
Key: KNOX-3018
URL: https://issues.apache.org/jira/browse/KNOX-3018
Project: Apache Knox
Issue Type: Bug
Components: TokenGenerationUI
Affects Versions: 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
Attachments: Screenshot 2024-03-11 at 14.25.04.png, Screenshot
2024-03-11 at 14.25.27.png
*Steps to reproduce*
* set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
{{KNOXTOKEN}} service
* set {{knox.token.lifespan.input.enabled = false}} in the {{homepage}}
topology for the {{KNOXTOKEN}} service
*Actual results*
With KNOX-3017 in place, the token is generated, but the expiration is wrong,
see attached screenshots.
In addition to this UI bug, the background reaper thread removes this token the
next time it's triggered. This is also incorrect: unlimited tokens should never
be removed automatically as they never expire.
*Expected result*
Token expiration should indicate an unlimited lifespan and unlimited tokens
should not be revoked automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3017) Unlimited token generation - invalid warning poopup
[
https://issues.apache.org/jira/browse/KNOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3017:
Component/s: TokenGenerationUI
> Unlimited token generation - invalid warning poopup
> ---
>
> Key: KNOX-3017
> URL: https://issues.apache.org/jira/browse/KNOX-3017
> Project: Apache Knox
> Issue Type: Bug
> Components: TokenGenerationUI
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: Screenshot 2024-03-11 at 12.57.12.png, Screenshot
> 2024-03-11 at 12.57.35.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Steps to reproduce*
> * set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
> {{KNOXTOKEN}} service
> * go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
> *Actual results*
> The lifespan adjusting warning popup says that 365 days is greater than the
> configured maximum lifetime. This is not true, because, as you can see in the
> screenshot, we are creating tokens with {{unlimited lifetime}}
> *Expected result*
> The popup should not be displayed in case of unlimited token lifetime
> configurations.
> *Note*
> After clicking the {{Generate token anyway}} button, the token was created
> with the correct expiration time (1 year from today).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (KNOX-3017) Unlimited token generation - invalid warning poopup
[
https://issues.apache.org/jira/browse/KNOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-3017 started by Sandor Molnar.
---
> Unlimited token generation - invalid warning poopup
> ---
>
> Key: KNOX-3017
> URL: https://issues.apache.org/jira/browse/KNOX-3017
> Project: Apache Knox
> Issue Type: Bug
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: Screenshot 2024-03-11 at 12.57.12.png, Screenshot
> 2024-03-11 at 12.57.35.png
>
>
> *Steps to reproduce*
> * set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
> {{KNOXTOKEN}} service
> * go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
> *Actual results*
> The lifespan adjusting warning popup says that 365 days is greater than the
> configured maximum lifetime. This is not true, because, as you can see in the
> screenshot, we are creating tokens with {{unlimited lifetime}}
> *Expected result*
> The popup should not be displayed in case of unlimited token lifetime
> configurations.
> *Note*
> After clicking the {{Generate token anyway}} button, the token was created
> with the correct expiration time (1 year from today).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3017) Unlimited token generation - invalid warning poopup
[
https://issues.apache.org/jira/browse/KNOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3017:
Attachment: Screenshot 2024-03-11 at 12.57.12.png
Screenshot 2024-03-11 at 12.57.35.png
> Unlimited token generation - invalid warning poopup
> ---
>
> Key: KNOX-3017
> URL: https://issues.apache.org/jira/browse/KNOX-3017
> Project: Apache Knox
> Issue Type: Bug
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: Screenshot 2024-03-11 at 12.57.12.png, Screenshot
> 2024-03-11 at 12.57.35.png
>
>
> *Steps to reproduce*
> * set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
> {{KNOXTOKEN}} service
> * go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
> *Actual results*
> The lifespan adjusting warning popup says that 365 days is greater than the
> configured maximum lifetime. This is not true, because, as you can see in the
> screenshot, we are creating tokens with {{unlimited lifetime}}
> *Expected result*
> The popup should not be displayed in case of unlimited token lifetime
> configurations.
> *Note*
> After clicking the {{Generate token anyway}} button, the token was created
> with the correct expiration time (1 year from today).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3017) Unlimited token generation - invalid warning poopup
[
https://issues.apache.org/jira/browse/KNOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3017:
Description:
*Steps to reproduce*
* set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
{{KNOXTOKEN}} service
* go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
*Actual results*
The lifespan adjusting warning popup says that 365 days is greater than the
configured maximum lifetime. This is not true, because, as you can see in the
screenshot, we are creating tokens with {{unlimited lifetime}}
*Expected result*
The popup should not be displayed in case of unlimited token lifetime
configurations.
*Note*
After clicking the {{Generate token anyway}} button, the token was created with
the correct expiration time (1 year from today).
was:
*Steps to reproduce*
* set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
{{KNOXTOKEN}} service
* go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
*Actual results*
The lifespan adjusting warning popup says that 365 days is greater than the
configured maximum lifetime. This is not true, because, as you can see in the
screenshot, we are creating tokens with {{unlimited lifetime}}
*Expected result*
The popup should not be displayed in case of unlimited token lifetime
configurations.
> Unlimited token generation - invalid warning poopup
> ---
>
> Key: KNOX-3017
> URL: https://issues.apache.org/jira/browse/KNOX-3017
> Project: Apache Knox
> Issue Type: Bug
>Affects Versions: 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: Screenshot 2024-03-11 at 12.57.12.png, Screenshot
> 2024-03-11 at 12.57.35.png
>
>
> *Steps to reproduce*
> * set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
> {{KNOXTOKEN}} service
> * go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
> *Actual results*
> The lifespan adjusting warning popup says that 365 days is greater than the
> configured maximum lifetime. This is not true, because, as you can see in the
> screenshot, we are creating tokens with {{unlimited lifetime}}
> *Expected result*
> The popup should not be displayed in case of unlimited token lifetime
> configurations.
> *Note*
> After clicking the {{Generate token anyway}} button, the token was created
> with the correct expiration time (1 year from today).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3017) Unlimited token generation - invalid warning poopup
Sandor Molnar created KNOX-3017:
---
Summary: Unlimited token generation - invalid warning poopup
Key: KNOX-3017
URL: https://issues.apache.org/jira/browse/KNOX-3017
Project: Apache Knox
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
*Steps to reproduce*
* set the {{knox.token.ttl}} to {{-1}} in the {{homepage}} topology for the
{{KNOXTOKEN}} service
* go to the {{Token Generation UI}} and set the {{Lifetime}} to 365 days
*Actual results*
The lifespan adjusting warning popup says that 365 days is greater than the
configured maximum lifetime. This is not true, because, as you can see in the
screenshot, we are creating tokens with {{unlimited lifetime}}
*Expected result*
The popup should not be displayed in case of unlimited token lifetime
configurations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [DISCUSS] Release Apache Knox v2.1.0
Now, that Attila updated his JIRAs too, the previously mentioned 50+ items are a huge underestimation as there are almost 90 issues fixed since our last release. I also forgot to indicate that I'm volunteering for being the release manager of v2.1.0. On Tue, Feb 27, 2024 at 3:35 PM Phil Zampino wrote: > There are a number of good improvements included in that list of closed > JIRAs, so I agree that releasing v2.1.0 in March is a good goal. > > +1 > > On Tue, Feb 27, 2024 at 4:19 AM Sandor Molnar > > wrote: > > > Hi folks! > > > > There have been more than 12 months or so since we released 2.0.0. > > > > We have a bit more than 50 resolved/closed JIRAs: > > > > > https://issues.apache.org/jira/issues/?filter=-1=project%20%3D%20KNOX%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%202.1.0%20order%20by%20updated%20DESC > > > > Our dependabot integration was paused due to the lack of recent > activities. > > Today, I resumed that by merging one of the dependabot changes and now > I'm > > going through all of those open PRs and reviewing/merging them one by > one. > > Once those changes are merged I cannot see any obstacles preventing us > from > > releasing v2.1.0. > > > > I think we should release v2.1.0 over the next couple of weeks and aim > for > > a release in March 2024. > > > > Thoughts? > > > > Thanks, > > Sandor > > >
[jira] [Resolved] (KNOX-3011) Resolve duplicated SL4J on classpath issue
[
https://issues.apache.org/jira/browse/KNOX-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar resolved KNOX-3011.
-
Resolution: Fixed
> Resolve duplicated SL4J on classpath issue
> --
>
> Key: KNOX-3011
> URL: https://issues.apache.org/jira/browse/KNOX-3011
> Project: Apache Knox
> Issue Type: Improvement
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Any time I run a KnoxCLI command, it always starts with the following warning
> messages displayed on my terminal:
> {noformat}
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
> [jar:file:/Users/sandormolnar/test/knoxGateway/bin/../dep/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
> [jar:file:/Users/sandormolnar/test/knoxGateway/bin/../dep/logback-classic-1.2.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
> SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
> {noformat}
> The reason behind this warning is that Zookeeper pulls in outdated
> {{logback}} dependencies which we should exclude.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3011) Resolve duplicated SL4J on classpath issue
Sandor Molnar created KNOX-3011:
---
Summary: Resolve duplicated SL4J on classpath issue
Key: KNOX-3011
URL: https://issues.apache.org/jira/browse/KNOX-3011
Project: Apache Knox
Issue Type: Improvement
Affects Versions: 2.1.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
Any time I run a KnoxCLI command, it always starts with the following warning
messages displayed on my terminal:
{noformat}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/Users/sandormolnar/test/knoxGateway/bin/../dep/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/Users/sandormolnar/test/knoxGateway/bin/../dep/logback-classic-1.2.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
{noformat}
The reason behind this warning is that Zookeeper pulls in outdated {{logback}}
dependencies which we should exclude.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (KNOX-3008) Add a new banner on the top of Knox UIs
[
https://issues.apache.org/jira/browse/KNOX-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar resolved KNOX-3008.
-
Resolution: Fixed
> Add a new banner on the top of Knox UIs
> ---
>
> Key: KNOX-3008
> URL: https://issues.apache.org/jira/browse/KNOX-3008
> Project: Apache Knox
> Issue Type: New Feature
> Components: AdminUI, Homepage, TokenGenerationUI, TokenManagementUI
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I got to know that Hue has a simple, but really cool feature: it can show a
> [custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top
> of the Hue UI. Implementing a similar feature in Knox can help end-users to:
> # Share a message of the day like hints, tips, or planned outages.
> # Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
> enough.
> An additional improvement would be identifying which Knox gateway is in use,
> in case of HA deployments and if it's behind a load balancer, which can help
> with troubleshooting. This information fits perfectly into the existing
> {{General Proxy Information}} section on the Knox home page; we just need to
> add this new information as a new row in the table.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[DISCUSS] Release Apache Knox v2.1.0
Hi folks! There have been more than 12 months or so since we released 2.0.0. We have a bit more than 50 resolved/closed JIRAs: https://issues.apache.org/jira/issues/?filter=-1=project%20%3D%20KNOX%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%202.1.0%20order%20by%20updated%20DESC Our dependabot integration was paused due to the lack of recent activities. Today, I resumed that by merging one of the dependabot changes and now I'm going through all of those open PRs and reviewing/merging them one by one. Once those changes are merged I cannot see any obstacles preventing us from releasing v2.1.0. I think we should release v2.1.0 over the next couple of weeks and aim for a release in March 2024. Thoughts? Thanks, Sandor
[jira] [Updated] (KNOX-3008) Add a new banner on the top of Knox UIs
[
https://issues.apache.org/jira/browse/KNOX-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3008:
Description:
I got to know that Hue has a simple, but really cool feature: it can show a
[custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top of
the Hue UI. Implementing a similar feature in Knox can help end-users to:
# Share a message of the day like hints, tips, or planned outages.
# Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
enough.
An additional improvement would be identifying which Knox gateway is in use, in
case of HA deployments and if it's behind a load balancer, which can help with
troubleshooting. This information fits perfectly into the existing {{General
Proxy Information}} section on the Knox home page; we just need to add this new
information as a new row in the table.
was:
I got to know that Hue has a simple, but really cool feature: it can show a
[custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top of
the Hue UI. Implementing a similar feature in Knox can help end-users to:
# Share a message of the day like hints, tips, or planned outages.
# Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
enough.
An additional improvement would be identifying which Knox gateway is in use, in
case of HA deployments and if it's behind a load balancer, which can help with
troubleshooting. This information fits perfectly into the existing {{General
Proxy Information}} section on the Knox home page; we just need to ad this new
information as a new row in the table.
> Add a new banner on the top of Knox UIs
> ---
>
> Key: KNOX-3008
> URL: https://issues.apache.org/jira/browse/KNOX-3008
> Project: Apache Knox
> Issue Type: New Feature
> Components: AdminUI, Homepage, TokenGenerationUI, TokenManagementUI
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
>
> I got to know that Hue has a simple, but really cool feature: it can show a
> [custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top
> of the Hue UI. Implementing a similar feature in Knox can help end-users to:
> # Share a message of the day like hints, tips, or planned outages.
> # Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
> enough.
> An additional improvement would be identifying which Knox gateway is in use,
> in case of HA deployments and if it's behind a load balancer, which can help
> with troubleshooting. This information fits perfectly into the existing
> {{General Proxy Information}} section on the Knox home page; we just need to
> add this new information as a new row in the table.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (KNOX-3008) Add a new banner on the top of Knox UIs
[
https://issues.apache.org/jira/browse/KNOX-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-3008 started by Sandor Molnar.
---
> Add a new banner on the top of Knox UIs
> ---
>
> Key: KNOX-3008
> URL: https://issues.apache.org/jira/browse/KNOX-3008
> Project: Apache Knox
> Issue Type: New Feature
> Components: AdminUI, Homepage, TokenGenerationUI, TokenManagementUI
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
>
> I got to know that Hue has a simple, but really cool feature: it can show a
> [custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top
> of the Hue UI. Implementing a similar feature in Knox can help end-users to:
> # Share a message of the day like hints, tips, or planned outages.
> # Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
> enough.
> An additional improvement would be identifying which Knox gateway is in use,
> in case of HA deployments and if it's behind a load balancer, which can help
> with troubleshooting. This information fits perfectly into the existing
> {{General Proxy Information}} section on the Knox home page; we just need to
> add this new information as a new row in the table.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3008) Add a new banner on the top of Knox UIs
Sandor Molnar created KNOX-3008:
---
Summary: Add a new banner on the top of Knox UIs
Key: KNOX-3008
URL: https://issues.apache.org/jira/browse/KNOX-3008
Project: Apache Knox
Issue Type: New Feature
Components: AdminUI, Homepage, TokenGenerationUI, TokenManagementUI
Affects Versions: 2.1.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
I got to know that Hue has a simple, but really cool feature: it can show a
[custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top of
the Hue UI. Implementing a similar feature in Knox can help end-users to:
# Share a message of the day like hints, tips, or planned outages.
# Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
enough.
An additional improvement would be identifying which Knox gateway is in use, in
case of HA deployments and if it's behind a load balancer, which can help with
troubleshooting. This information fits perfectly into the existing {{General
Proxy Information}} section on the Knox home page; we just need to ad this new
information as a new raw in the table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3008) Add a new banner on the top of Knox UIs
[
https://issues.apache.org/jira/browse/KNOX-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3008:
Description:
I got to know that Hue has a simple, but really cool feature: it can show a
[custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top of
the Hue UI. Implementing a similar feature in Knox can help end-users to:
# Share a message of the day like hints, tips, or planned outages.
# Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
enough.
An additional improvement would be identifying which Knox gateway is in use, in
case of HA deployments and if it's behind a load balancer, which can help with
troubleshooting. This information fits perfectly into the existing {{General
Proxy Information}} section on the Knox home page; we just need to ad this new
information as a new row in the table.
was:
I got to know that Hue has a simple, but really cool feature: it can show a
[custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top of
the Hue UI. Implementing a similar feature in Knox can help end-users to:
# Share a message of the day like hints, tips, or planned outages.
# Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
enough.
An additional improvement would be identifying which Knox gateway is in use, in
case of HA deployments and if it's behind a load balancer, which can help with
troubleshooting. This information fits perfectly into the existing {{General
Proxy Information}} section on the Knox home page; we just need to ad this new
information as a new raw in the table.
> Add a new banner on the top of Knox UIs
> ---
>
> Key: KNOX-3008
> URL: https://issues.apache.org/jira/browse/KNOX-3008
> Project: Apache Knox
> Issue Type: New Feature
> Components: AdminUI, Homepage, TokenGenerationUI, TokenManagementUI
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
>
> I got to know that Hue has a simple, but really cool feature: it can show a
> [custom HTML banner|https://gethue.com/add-a-top-banner-to-hue/] on the top
> of the Hue UI. Implementing a similar feature in Knox can help end-users to:
> # Share a message of the day like hints, tips, or planned outages.
> # Identify the cluster (e.g. Prod/Test/Dev) in case the URL is not clear
> enough.
> An additional improvement would be identifying which Knox gateway is in use,
> in case of HA deployments and if it's behind a load balancer, which can help
> with troubleshooting. This information fits perfectly into the existing
> {{General Proxy Information}} section on the Knox home page; we just need to
> ad this new information as a new row in the table.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3005) Implement Knox idle session time
[ https://issues.apache.org/jira/browse/KNOX-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3005: Resolution: Fixed Status: Resolved (was: Patch Available) > Implement Knox idle session time > > > Key: KNOX-3005 > URL: https://issues.apache.org/jira/browse/KNOX-3005 > Project: Apache Knox > Issue Type: New Feature > Components: KnoxSSO >Affects Versions: 2.1.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Critical > Fix For: 2.1.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > With the recent work of KNOX-2961, the new SSO token invalidation > functionality, Knox could provide idle session timeout behavior for UIs. > It will likely not include the usual UI pop-up approach (like when the > end-user is informed about being idle too long), but it would effectively > terminate idle SSO sessions and force an explicit login. > It's also worth mentioning the idleness measurement solely depends on backend > activities through the KnoxSSO Cookie federation filter. and will not take > any client-side action (such as scrolling on the page, client-side > pagination, etc..) into account. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3003) Group UI services of the same type
[ https://issues.apache.org/jira/browse/KNOX-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3003: Fix Version/s: 2.1.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Group UI services of the same type > -- > > Key: KNOX-3003 > URL: https://issues.apache.org/jira/browse/KNOX-3003 > Project: Apache Knox > Issue Type: Improvement > Components: Homepage >Affects Versions: 2.0.0, 1.6.0, 1.6.1 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Critical > Fix For: 2.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, if a UI service has multiple instances with different URLs in a > given topology, that UI service will be listed on the Knox Home page as many > times as the number of URLs it has. This makes the user experience a lot > worse if we are talking about hundreds of occurrences of this case. > We learned from some real-life use cases that IMPALA is one of these > services, and there are 1000+ node clusters out there with more than 100 > Impala Daemon roles. In that particular case, the Knox Home page was a mess. > To address this issue, the following UI improvement should be implemented: > * if a UI service has more than one URL in the given topology, individual > tiles should not be displayed. Instead, one "group" tile must be added with a > clear indication this is a group of URLs of the same service. > * clicking the group tile should open a modal window with separate tiles for > each service URL > * in this modal window, a search field will be added to give our end-users > the chance to narrow down results (by hostname for instance) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-2990) TokenStateService implementation cleanup
[
https://issues.apache.org/jira/browse/KNOX-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2990:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> TokenStateService implementation cleanup
>
>
> Key: KNOX-2990
> URL: https://issues.apache.org/jira/browse/KNOX-2990
> Project: Apache Knox
> Issue Type: Task
> Components: Server
>Affects Versions: 2.0.0, 1.6.0, 1.6.1
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> This issue is driven by a [DISCUSS] thread initiated on Knox's DEV mailing
> list [here|https://lists.apache.org/thread/fs9nkl6l45o330ttvgvqxj3jnxt63bcs].
> As a result of that discussion, the following needs to be implemented:
> * deprecate the following TSS implementations:
> ** AliasBasedTokenStateService
> ** ZookeeperTokenStateService
> ** JournalBasedTokenStateService
> * document the deprecation of these TSS implementations in v2.1.0 and
> highlight that they will be removed in the upcoming release (v2.2.0?).
> * implement a DerbyDB storage that will store tokens in
> {{$DATA_DIR/security/tokens}} (encrypted or not, it'll be decided later)
> * make sure appropriate file permissions are set on that folder
> * have the {{homepage}} topology configured with JDBC TSS pointing to this
> DerbyDB storage
> * implement a new KnoxCLI command that migrates existing tokens from
> credential stores to the DerbyDB storage
> * automate this new KnoxCLI command in a way such that it runs when Knox
> Gateway is started, token management is enabled, and DerbyDB storage is
> configured
> * ensure that the previous automated step can be controlled (E.g. in case of
> unforeseen errors it can be turned off)
> * document possible data replication scenarios when, in the case of HA
> deployments, existing tokens from one Knox node should be made available in
> other Knox node(s) and there is no other centralized RDBMS in use
> (PostgreSQL, MySQL for instance)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3005) Implement Knox idle session time
[ https://issues.apache.org/jira/browse/KNOX-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3005: Description: With the recent work of KNOX-2961, the new SSO token invalidation functionality, Knox could provide idle session timeout behavior for UIs. It will likely not include the usual UI pop-up approach (like when the end-user is informed about being idle too long), but it would effectively terminate idle SSO sessions and force an explicit login. It's also worth mentioning the idleness measurement solely depends on backend activities through the KnoxSSO Cookie federation filter. and will not take any client-side action (such as scrolling on the page, client-side pagination, etc..) into account. was: With the recent work of KNOX-2961, the new SSO token invalidation functionality, Knox could provide idle session timeout behavior for UIs. It will likely not include the usual UI pop-up approach (like when the end-user is informed about being idle too long), but it would effectively terminate idle SSO sessions and force an explicit login. It's also worth mentioning the idleness measurement solely depends on backend activities through the KnoxSSO Cookie federation filter. and will not take any client-side action (such as scrolling on the page, client-side pagination, etc..) into account. [|https://jira.cloudera.com/secure/AddComment!default.jspa?id=1374564] > Implement Knox idle session time > > > Key: KNOX-3005 > URL: https://issues.apache.org/jira/browse/KNOX-3005 > Project: Apache Knox > Issue Type: New Feature > Components: KnoxSSO >Affects Versions: 2.1.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Critical > Fix For: 2.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > With the recent work of KNOX-2961, the new SSO token invalidation > functionality, Knox could provide idle session timeout behavior for UIs. > It will likely not include the usual UI pop-up approach (like when the > end-user is informed about being idle too long), but it would effectively > terminate idle SSO sessions and force an explicit login. > It's also worth mentioning the idleness measurement solely depends on backend > activities through the KnoxSSO Cookie federation filter. and will not take > any client-side action (such as scrolling on the page, client-side > pagination, etc..) into account. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3005) Implement Knox idle session time
[ https://issues.apache.org/jira/browse/KNOX-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3005: Status: Patch Available (was: Open) > Implement Knox idle session time > > > Key: KNOX-3005 > URL: https://issues.apache.org/jira/browse/KNOX-3005 > Project: Apache Knox > Issue Type: New Feature > Components: KnoxSSO >Affects Versions: 2.1.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Critical > Fix For: 2.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > With the recent work of KNOX-2961, the new SSO token invalidation > functionality, Knox could provide idle session timeout behavior for UIs. > It will likely not include the usual UI pop-up approach (like when the > end-user is informed about being idle too long), but it would effectively > terminate idle SSO sessions and force an explicit login. > It's also worth mentioning the idleness measurement solely depends on backend > activities through the KnoxSSO Cookie federation filter. and will not take > any client-side action (such as scrolling on the page, client-side > pagination, etc..) into account. > [|https://jira.cloudera.com/secure/AddComment!default.jspa?id=1374564] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KNOX-3005) Implement Knox idle session time
Sandor Molnar created KNOX-3005: --- Summary: Implement Knox idle session time Key: KNOX-3005 URL: https://issues.apache.org/jira/browse/KNOX-3005 Project: Apache Knox Issue Type: New Feature Components: KnoxSSO Affects Versions: 2.1.0 Reporter: Sandor Molnar Assignee: Sandor Molnar Fix For: 2.1.0 With the recent work of KNOX-2961, the new SSO token invalidation functionality, Knox could provide idle session timeout behavior for UIs. It will likely not include the usual UI pop-up approach (like when the end-user is informed about being idle too long), but it would effectively terminate idle SSO sessions and force an explicit login. It's also worth mentioning the idleness measurement solely depends on backend activities through the KnoxSSO Cookie federation filter. and will not take any client-side action (such as scrolling on the page, client-side pagination, etc..) into account. [|https://jira.cloudera.com/secure/AddComment!default.jspa?id=1374564] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3003) Group UI services of the same type
[ https://issues.apache.org/jira/browse/KNOX-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-3003: Status: Patch Available (was: In Progress) > Group UI services of the same type > -- > > Key: KNOX-3003 > URL: https://issues.apache.org/jira/browse/KNOX-3003 > Project: Apache Knox > Issue Type: Improvement > Components: Homepage >Affects Versions: 1.6.0, 2.0.0, 1.6.1 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > Currently, if a UI service has multiple instances with different URLs in a > given topology, that UI service will be listed on the Knox Home page as many > times as the number of URLs it has. This makes the user experience a lot > worse if we are talking about hundreds of occurrences of this case. > We learned from some real-life use cases that IMPALA is one of these > services, and there are 1000+ node clusters out there with more than 100 > Impala Daemon roles. In that particular case, the Knox Home page was a mess. > To address this issue, the following UI improvement should be implemented: > * if a UI service has more than one URL in the given topology, individual > tiles should not be displayed. Instead, one "group" tile must be added with a > clear indication this is a group of URLs of the same service. > * clicking the group tile should open a modal window with separate tiles for > each service URL > * in this modal window, a search field will be added to give our end-users > the chance to narrow down results (by hostname for instance) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3004) Impala connection string should be a valid JDBC connection URL
[
https://issues.apache.org/jira/browse/KNOX-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3004:
Fix Version/s: 2.1.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Impala connection string should be a valid JDBC connection URL
> --
>
> Key: KNOX-3004
> URL: https://issues.apache.org/jira/browse/KNOX-3004
> Project: Apache Knox
> Issue Type: Task
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, on the Knox Home page, the Impala URL is a simple {{http(s)}} URL
> that cannot be used as a JDBC connection string (like the one we provide for
> Hive).
> A sample valid URL looks like this:
> {code:java}
> jdbc:impala://sup-758082-datahub2-master0.repro-az.a465-9q4k.cloudera.site:443/;ssl=1;transportMode=http;httpPath=sup-758082-datahub2/cdp-proxy-api/impala;AuthMech=3;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-3004) Impala connection string should be a valid JDBC connection URL
[
https://issues.apache.org/jira/browse/KNOX-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3004:
Status: Patch Available (was: Open)
> Impala connection string should be a valid JDBC connection URL
> --
>
> Key: KNOX-3004
> URL: https://issues.apache.org/jira/browse/KNOX-3004
> Project: Apache Knox
> Issue Type: Task
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
>
> Currently, on the Knox Home page, the Impala URL is a simple {{http(s)}} URL
> that cannot be used as a JDBC connection string (like the one we provide for
> Hive).
> A sample valid URL looks like this:
> {code:java}
> jdbc:impala://sup-758082-datahub2-master0.repro-az.a465-9q4k.cloudera.site:443/;ssl=1;transportMode=http;httpPath=sup-758082-datahub2/cdp-proxy-api/impala;AuthMech=3;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3004) Impala connection string should be a valid JDBC connection URL
Sandor Molnar created KNOX-3004:
---
Summary: Impala connection string should be a valid JDBC
connection URL
Key: KNOX-3004
URL: https://issues.apache.org/jira/browse/KNOX-3004
Project: Apache Knox
Issue Type: Task
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Currently, on the Knox Home page, the Impala URL is a simple {{http(s)}} URL
that cannot be used as a JDBC connection string (like the one we provide for
Hive).
A sample valid URL looks like this:
{code:java}
jdbc:impala://sup-758082-datahub2-master0.repro-az.a465-9q4k.cloudera.site:443/;ssl=1;transportMode=http;httpPath=sup-758082-datahub2/cdp-proxy-api/impala;AuthMech=3;
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-3003) Group UI services of the same type
Sandor Molnar created KNOX-3003: --- Summary: Group UI services of the same type Key: KNOX-3003 URL: https://issues.apache.org/jira/browse/KNOX-3003 Project: Apache Knox Issue Type: Improvement Components: Homepage Affects Versions: 1.6.0, 2.0.0, 1.6.1 Reporter: Sandor Molnar Assignee: Sandor Molnar Currently, if a UI service has multiple instances with different URLs in a given topology, that UI service will be listed on the Knox Home page as many times as the number of URLs it has. This makes the user experience a lot worse if we are talking about hundreds of occurrences of this case. We learned from some real-life use cases that IMPALA is one of these services, and there are 1000+ node clusters out there with more than 100 Impala Daemon roles. In that particular case, the Knox Home page was a mess. To address this issue, the following UI improvement should be implemented: * if a UI service has more than one URL in the given topology, individual tiles should not be displayed. Instead, one "group" tile must be added with a clear indication this is a group of URLs of the same service. * clicking the group tile should open a modal window with separate tiles for each service URL * in this modal window, a search field will be added to give our end-users the chance to narrow down results (by hostname for instance) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (KNOX-3003) Group UI services of the same type
[ https://issues.apache.org/jira/browse/KNOX-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-3003 started by Sandor Molnar. --- > Group UI services of the same type > -- > > Key: KNOX-3003 > URL: https://issues.apache.org/jira/browse/KNOX-3003 > Project: Apache Knox > Issue Type: Improvement > Components: Homepage >Affects Versions: 2.0.0, 1.6.0, 1.6.1 > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Critical > > Currently, if a UI service has multiple instances with different URLs in a > given topology, that UI service will be listed on the Knox Home page as many > times as the number of URLs it has. This makes the user experience a lot > worse if we are talking about hundreds of occurrences of this case. > We learned from some real-life use cases that IMPALA is one of these > services, and there are 1000+ node clusters out there with more than 100 > Impala Daemon roles. In that particular case, the Knox Home page was a mess. > To address this issue, the following UI improvement should be implemented: > * if a UI service has more than one URL in the given topology, individual > tiles should not be displayed. Instead, one "group" tile must be added with a > clear indication this is a group of URLs of the same service. > * clicking the group tile should open a modal window with separate tiles for > each service URL > * in this modal window, a search field will be added to give our end-users > the chance to narrow down results (by hostname for instance) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-3001) Avoid double XML escaping in SimpleDescriptorHandler
[
https://issues.apache.org/jira/browse/KNOX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3001:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Avoid double XML escaping in SimpleDescriptorHandler
>
>
> Key: KNOX-3001
> URL: https://issues.apache.org/jira/browse/KNOX-3001
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> KNOX-2804 added a beneficial improvement in Knox's logic when dealing with
> JSON files and turned them into XML topologies: before the generated topology
> persisted, the possible values are XML-escaped to avoid errors in SAXParser.
> However, this might cause backward-compatible issues in deployments, where
> the data in the given shared provider config or descriptor is already given
> in XML-friendy way.
> For instance, using the following shared provider config will result in a bad
> XML topology:
> {noformat}
> {
> "providers" : [ {
> "role" : "webappsec",
> "name" : "WebAppSec",
> "enabled" : true,
> "params" : {
> "xframe.options.enabled" : "true"
> }
> }, {
> "role" : "authentication",
> "name" : "ShiroProvider",
> "enabled" : true,
> "params" : {
> "main.ldapContextFactory" :
> "org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory",
> "main.ldapRealm" : "org.apache.knox.gateway.shirorealm.KnoxLdapRealm",
> "main.ldapRealm.authenticationCachingEnabled" : "false",
> "main.ldapRealm.contextFactory" : "$ldapContextFactory",
> "main.ldapRealm.contextFactory.authenticationMechanism" : "simple",
> "main.ldapRealm.contextFactory.url" : "ldap://localhost:33389;,
> "main.ldapRealm.userDnTemplate" :
> "uid=0ou=people,dc=hadoop,dc=apache,dc=org",
> "main.ldapRealm.userSearchFilter" :
> "(((objectclass=person)(sAMAccountName={0}))(|(memberOf=CN=SecXX-users,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)(memberOf=CN=SecXX-rls-serviceuser,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)))",
> "redirectToUrl" : "/${GATEWAY_PATH}/knoxsso/knoxauth/login.html",
> "restrictedCookies" : "rememberme,WWW-Authenticate",
> "sessionTimeout" : "30",
> "urls./**" : "authcBasic"
> }
> }, {
> "role" : "identity-assertion",
> "name" : "Default",
> "enabled" : true,
> "params" : { }
> } ],
> "readOnly" : true
> } {noformat}
> The generated XML:
> {noformat}
>
>
>
>
>
> true
>
>
> webappsec
> WebAppSec
> true
>
> xframe.options.enabled
> true
>
>
>
> authentication
> ShiroProvider
> true
>
> main.ldapContextFactory
>
> org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory
>
>
> main.ldapRealm
>
> org.apache.knox.gateway.shirorealm.KnoxLdapRealm
>
>
> main.ldapRealm.authenticationCachingEnabled
> false
>
>
> main.ldapRealm.contextFactory
> $ldapContextFactory
>
>
>
> main.ldapRealm.contextFactory.authenticationMechanism
> simple
>
>
> main.ldapRealm.contextFactory.url
> ldap://localhost:33389
>
>
> main.ldapRealm.userDnTemplate
> uid=0ou=people,dc=hadoop,dc=apache,dc=org
>
>
> main.ldapRealm.userSearchFilter
>
> (amp;(amp;(objectclass=perso
[jira] [Updated] (KNOX-3001) Avoid double XML escaping in SimpleDescriptorHandler
[
https://issues.apache.org/jira/browse/KNOX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3001:
Summary: Avoid double XML escaping in SimpleDescriptorHandler (was: XML
escaping should be configurable in SimpleDescriptorHandler)
> Avoid double XML escaping in SimpleDescriptorHandler
>
>
> Key: KNOX-3001
> URL: https://issues.apache.org/jira/browse/KNOX-3001
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> KNOX-2804 added a beneficial improvement in Knox's logic when dealing with
> JSON files and turned them into XML topologies: before the generated topology
> persisted, the possible values are XML-escaped to avoid errors in SAXParser.
> However, this might cause backward-compatible issues in deployments, where
> the data in the given shared provider config or descriptor is already given
> in XML-friendy way.
> For instance, using the following shared provider config will result in a bad
> XML topology:
> {noformat}
> {
> "providers" : [ {
> "role" : "webappsec",
> "name" : "WebAppSec",
> "enabled" : true,
> "params" : {
> "xframe.options.enabled" : "true"
> }
> }, {
> "role" : "authentication",
> "name" : "ShiroProvider",
> "enabled" : true,
> "params" : {
> "main.ldapContextFactory" :
> "org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory",
> "main.ldapRealm" : "org.apache.knox.gateway.shirorealm.KnoxLdapRealm",
> "main.ldapRealm.authenticationCachingEnabled" : "false",
> "main.ldapRealm.contextFactory" : "$ldapContextFactory",
> "main.ldapRealm.contextFactory.authenticationMechanism" : "simple",
> "main.ldapRealm.contextFactory.url" : "ldap://localhost:33389;,
> "main.ldapRealm.userDnTemplate" :
> "uid=0ou=people,dc=hadoop,dc=apache,dc=org",
> "main.ldapRealm.userSearchFilter" :
> "(((objectclass=person)(sAMAccountName={0}))(|(memberOf=CN=SecXX-users,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)(memberOf=CN=SecXX-rls-serviceuser,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)))",
> "redirectToUrl" : "/${GATEWAY_PATH}/knoxsso/knoxauth/login.html",
> "restrictedCookies" : "rememberme,WWW-Authenticate",
> "sessionTimeout" : "30",
> "urls./**" : "authcBasic"
> }
> }, {
> "role" : "identity-assertion",
> "name" : "Default",
> "enabled" : true,
> "params" : { }
> } ],
> "readOnly" : true
> } {noformat}
> The generated XML:
> {noformat}
>
>
>
>
>
> true
>
>
> webappsec
> WebAppSec
> true
>
> xframe.options.enabled
> true
>
>
>
> authentication
> ShiroProvider
> true
>
> main.ldapContextFactory
>
> org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory
>
>
> main.ldapRealm
>
> org.apache.knox.gateway.shirorealm.KnoxLdapRealm
>
>
> main.ldapRealm.authenticationCachingEnabled
> false
>
>
> main.ldapRealm.contextFactory
> $ldapContextFactory
>
>
>
> main.ldapRealm.contextFactory.authenticationMechanism
> simple
>
>
> main.ldapRealm.contextFactory.url
> ldap://localhost:33389
>
>
> main.ldapRealm.userDnTemplate
> uid=0ou=people,dc=hadoop,dc=apache,dc=org
>
>
> main.ldapRealm.userSe
[jira] [Updated] (KNOX-3001) XML escaping should be configurable in SimpleDescriptorHandler
[
https://issues.apache.org/jira/browse/KNOX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3001:
Summary: XML escaping should be configurable in SimpleDescriptorHandler
(was: XML escaping should be configurable in SimpleDescriptorHandle)
> XML escaping should be configurable in SimpleDescriptorHandler
> --
>
> Key: KNOX-3001
> URL: https://issues.apache.org/jira/browse/KNOX-3001
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> KNOX-2804 added a beneficial improvement in Knox's logic when dealing with
> JSON files and turned them into XML topologies: before the generated topology
> persisted, the possible values are XML-escaped to avoid errors in SAXParser.
> However, this might cause backward-compatible issues in deployments, where
> the data in the given shared provider config or descriptor is already given
> in XML-friendy way.
> For instance, using the following shared provider config will result in a bad
> XML topology:
> {noformat}
> {
> "providers" : [ {
> "role" : "webappsec",
> "name" : "WebAppSec",
> "enabled" : true,
> "params" : {
> "xframe.options.enabled" : "true"
> }
> }, {
> "role" : "authentication",
> "name" : "ShiroProvider",
> "enabled" : true,
> "params" : {
> "main.ldapContextFactory" :
> "org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory",
> "main.ldapRealm" : "org.apache.knox.gateway.shirorealm.KnoxLdapRealm",
> "main.ldapRealm.authenticationCachingEnabled" : "false",
> "main.ldapRealm.contextFactory" : "$ldapContextFactory",
> "main.ldapRealm.contextFactory.authenticationMechanism" : "simple",
> "main.ldapRealm.contextFactory.url" : "ldap://localhost:33389;,
> "main.ldapRealm.userDnTemplate" :
> "uid=0ou=people,dc=hadoop,dc=apache,dc=org",
> "main.ldapRealm.userSearchFilter" :
> "(((objectclass=person)(sAMAccountName={0}))(|(memberOf=CN=SecXX-users,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)(memberOf=CN=SecXX-rls-serviceuser,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)))",
> "redirectToUrl" : "/${GATEWAY_PATH}/knoxsso/knoxauth/login.html",
> "restrictedCookies" : "rememberme,WWW-Authenticate",
> "sessionTimeout" : "30",
> "urls./**" : "authcBasic"
> }
> }, {
> "role" : "identity-assertion",
> "name" : "Default",
> "enabled" : true,
> "params" : { }
> } ],
> "readOnly" : true
> } {noformat}
> The generated XML:
> {noformat}
>
>
>
>
>
> true
>
>
> webappsec
> WebAppSec
> true
>
> xframe.options.enabled
> true
>
>
>
> authentication
> ShiroProvider
> true
>
> main.ldapContextFactory
>
> org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory
>
>
> main.ldapRealm
>
> org.apache.knox.gateway.shirorealm.KnoxLdapRealm
>
>
> main.ldapRealm.authenticationCachingEnabled
> false
>
>
> main.ldapRealm.contextFactory
> $ldapContextFactory
>
>
>
> main.ldapRealm.contextFactory.authenticationMechanism
> simple
>
>
> main.ldapRealm.contextFactory.url
> ldap://localhost:33389
>
>
> main.ldapRealm.userDnTemplate
> uid=0ou=people,dc=hadoop,dc=apache,dc=org
>
>
&g
[jira] [Updated] (KNOX-3001) XML escaping should be configurable in SimpleDescriptorHandle
[
https://issues.apache.org/jira/browse/KNOX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3001:
Status: Patch Available (was: Open)
> XML escaping should be configurable in SimpleDescriptorHandle
> -
>
> Key: KNOX-3001
> URL: https://issues.apache.org/jira/browse/KNOX-3001
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
>Affects Versions: 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> KNOX-2804 added a beneficial improvement in Knox's logic when dealing with
> JSON files and turned them into XML topologies: before the generated topology
> persisted, the possible values are XML-escaped to avoid errors in SAXParser.
> However, this might cause backward-compatible issues in deployments, where
> the data in the given shared provider config or descriptor is already given
> in XML-friendy way.
> For instance, using the following shared provider config will result in a bad
> XML topology:
> {noformat}
> {
> "providers" : [ {
> "role" : "webappsec",
> "name" : "WebAppSec",
> "enabled" : true,
> "params" : {
> "xframe.options.enabled" : "true"
> }
> }, {
> "role" : "authentication",
> "name" : "ShiroProvider",
> "enabled" : true,
> "params" : {
> "main.ldapContextFactory" :
> "org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory",
> "main.ldapRealm" : "org.apache.knox.gateway.shirorealm.KnoxLdapRealm",
> "main.ldapRealm.authenticationCachingEnabled" : "false",
> "main.ldapRealm.contextFactory" : "$ldapContextFactory",
> "main.ldapRealm.contextFactory.authenticationMechanism" : "simple",
> "main.ldapRealm.contextFactory.url" : "ldap://localhost:33389;,
> "main.ldapRealm.userDnTemplate" :
> "uid=0ou=people,dc=hadoop,dc=apache,dc=org",
> "main.ldapRealm.userSearchFilter" :
> "(((objectclass=person)(sAMAccountName={0}))(|(memberOf=CN=SecXX-users,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)(memberOf=CN=SecXX-rls-serviceuser,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)))",
> "redirectToUrl" : "/${GATEWAY_PATH}/knoxsso/knoxauth/login.html",
> "restrictedCookies" : "rememberme,WWW-Authenticate",
> "sessionTimeout" : "30",
> "urls./**" : "authcBasic"
> }
> }, {
> "role" : "identity-assertion",
> "name" : "Default",
> "enabled" : true,
> "params" : { }
> } ],
> "readOnly" : true
> } {noformat}
> The generated XML:
> {noformat}
>
>
>
>
>
> true
>
>
> webappsec
> WebAppSec
> true
>
> xframe.options.enabled
> true
>
>
>
> authentication
> ShiroProvider
> true
>
> main.ldapContextFactory
>
> org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory
>
>
> main.ldapRealm
>
> org.apache.knox.gateway.shirorealm.KnoxLdapRealm
>
>
> main.ldapRealm.authenticationCachingEnabled
> false
>
>
> main.ldapRealm.contextFactory
> $ldapContextFactory
>
>
>
> main.ldapRealm.contextFactory.authenticationMechanism
> simple
>
>
> main.ldapRealm.contextFactory.url
> ldap://localhost:33389
>
>
> main.ldapRealm.userDnTemplate
> uid=0ou=people,dc=hadoop,dc=apache,dc=org
>
>
> main.ldapRealm.userSearchFilter
>
> (amp;(amp;(objectclass=perso
[jira] [Created] (KNOX-3001) XML escaping should be configurable in SimpleDescriptorHandle
Sandor Molnar created KNOX-3001:
---
Summary: XML escaping should be configurable in
SimpleDescriptorHandle
Key: KNOX-3001
URL: https://issues.apache.org/jira/browse/KNOX-3001
Project: Apache Knox
Issue Type: Improvement
Components: Server
Affects Versions: 2.1.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
KNOX-2804 added a beneficial improvement in Knox's logic when dealing with JSON
files and turned them into XML topologies: before the generated topology
persisted, the possible values are XML-escaped to avoid errors in SAXParser.
However, this might cause backward-compatible issues in deployments, where the
data in the given shared provider config or descriptor is already given in
XML-friendy way.
For instance, using the following shared provider config will result in a bad
XML topology:
{noformat}
{
"providers" : [ {
"role" : "webappsec",
"name" : "WebAppSec",
"enabled" : true,
"params" : {
"xframe.options.enabled" : "true"
}
}, {
"role" : "authentication",
"name" : "ShiroProvider",
"enabled" : true,
"params" : {
"main.ldapContextFactory" :
"org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory",
"main.ldapRealm" : "org.apache.knox.gateway.shirorealm.KnoxLdapRealm",
"main.ldapRealm.authenticationCachingEnabled" : "false",
"main.ldapRealm.contextFactory" : "$ldapContextFactory",
"main.ldapRealm.contextFactory.authenticationMechanism" : "simple",
"main.ldapRealm.contextFactory.url" : "ldap://localhost:33389;,
"main.ldapRealm.userDnTemplate" :
"uid=0ou=people,dc=hadoop,dc=apache,dc=org",
"main.ldapRealm.userSearchFilter" :
"(((objectclass=person)(sAMAccountName={0}))(|(memberOf=CN=SecXX-users,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)(memberOf=CN=SecXX-rls-serviceuser,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)))",
"redirectToUrl" : "/${GATEWAY_PATH}/knoxsso/knoxauth/login.html",
"restrictedCookies" : "rememberme,WWW-Authenticate",
"sessionTimeout" : "30",
"urls./**" : "authcBasic"
}
}, {
"role" : "identity-assertion",
"name" : "Default",
"enabled" : true,
"params" : { }
} ],
"readOnly" : true
} {noformat}
The generated XML:
{noformat}
true
webappsec
WebAppSec
true
xframe.options.enabled
true
authentication
ShiroProvider
true
main.ldapContextFactory
org.apache.knox.gateway.shirorealm.KnoxLdapContextFactory
main.ldapRealm
org.apache.knox.gateway.shirorealm.KnoxLdapRealm
main.ldapRealm.authenticationCachingEnabled
false
main.ldapRealm.contextFactory
$ldapContextFactory
main.ldapRealm.contextFactory.authenticationMechanism
simple
main.ldapRealm.contextFactory.url
ldap://localhost:33389
main.ldapRealm.userDnTemplate
uid=0ou=people,dc=hadoop,dc=apache,dc=org
main.ldapRealm.userSearchFilter
(amp;(amp;(objectclass=person)(sAMAccountName={0}))(|(memberOf=CN=SecXX-users,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)(memberOf=CN=SecXX-rls-serviceuser,OU=ManagedGroups,OU=Groups,OU=XX,OU=xx,DC=xx,DC=int)))
redirectToUrl
/${GATEWAY_PATH}/knoxsso/knoxauth/login.html
restrictedCookies
rememberme,WWW-Authenticate
sessionTimeout
30
urls./**
authcBasic
identity-assertion
Default
true
KNOXSSO
knoxsso.token.ttl
8640
knoxsso.token.sigalg
knoxsso.redirect.whitelist.regex
^https?:\/\/(.*smolnar\.root\.xyz\.com)(?::[0-9]+)?(?:\/.*)?$
knoxauth
{noformat}
As you can see, the value of {{main.ldapRealm.userSearchFilter}} is
double-escaped that makes the topology invalid.
Moreover, the previously added XML escape function is meant for XML 1.1
documents whereas this code generates XML 1.0, so that this should be changed
too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [DISCUSS] Token State Service implementation cleanup
Hi folks! The change is ready for review in GitHub: https://github.com/apache/knox/pull/826 Thanks, @Attilla Magyar for reviewing it already. I'd like to ask for at least one more from someone. Thanks! On Thu, Nov 30, 2023 at 12:03 PM Sandor Molnar wrote: > FYI: https://issues.apache.org/jira/browse/KNOX-2990 > > On Thu, Nov 30, 2023 at 9:05 AM Sandor Molnar > wrote: > >> Hello folks! >> >> After an offline discussion with Larry, we agreed on the following (as an >> extension to the action plan I listed above): >> - the migration tool will be run automatically when the Knox Gateway >> starts, and it will run on the main thread (i.e. not in the background). >> - there will be a config to control this step: in case of an error/bug, >> this automated migration could be turned off >> - when the first version of this newly configured DerbyDB JDBC TSS is >> implemented, I'll run some performance tests to see if encryption should be >> enabled by default >> - we'll make sure to protect the DerbyDB data folder with proper file >> permissions >> >> I'll submit the required JIRAs soon. >> >> Cheers, >> Sandor >> >> >> On Thu, Nov 23, 2023 at 11:59 PM larry mccay wrote: >> >>> If we can determine whether there is already an alias based TSS in place >>> and continue to use that for upgrades but derby for new clusters, I would >>> be in favor of that. >>> On whether to enable encryption, if we are only storing a hash of the >>> passcode token then that should be okay. >>> The persistence should be protected appropriately with file permissions >>> for >>> the knox user. >>> >>> NOTE: We will need to have some idea of how this may affect management >>> applications like Cloudera Manager and Ambari, if at all, and get out in >>> front of it. >>> >>> On Fri, Nov 17, 2023 at 8:27 AM Sandor Molnar >>> >>> wrote: >>> >>> > Hi folks! >>> > >>> > Let me try to summarize what we have so far: >>> > 1. we are all in favor of removing the JournalBased and Zookeeper TSS >>> > implementations >>> > 2. we all agreed that removing the AliasBasedTSS implementation >>> requires >>> > extra caution >>> > 3. Larry raised the following concerns >>> > 3.1 clear data storage in Derby -> ANSWER: Attila and I also >>> indicated >>> > Derby provides data encryption OOTB >>> > 3.2 token hashes -> ANSWER: we do not store JWTs, only metadata. We >>> > persist the passcode tokens though. It's hashed and stored using the >>> > "knox.token.hash.key" secret and "gateway.knox.token.hash.algorithm" >>> HMAC >>> > algorithm which defaults to HmacSHA256. >>> > 3.3 token synchronization across multiple Knox instances. -> >>> ANSWER: >>> > Derby has data replication capabilities. However, in HA environments, >>> I'd >>> > strongly recommend using Postgres/MySQL in those Knox instances >>> > 4. Sandeep and Phil articulated the importance of deprecation -> we all >>> > agree on this point >>> > 5. Phil asked whether data encryption should be the default in the >>> > Derby-configured JDBC TSS --> IMO, encryption should be turned on by >>> > default. The required "bootPassword" should be auto-generated and >>> stored in >>> > __gateway-credentials.jks >>> > 6. I recommended that the migration tool should be automated: when >>> token >>> > state service is initiated and it's using the pre-configured Derby >>> > database, we may check if there is any token stored in __gateway.jks >>> and >>> > migrate them. This way it'd be seamless for existing tokens. >>> > >>> > Action plan: >>> > - waiting for additional inputs on the above >>> > - implement the DerbyDB configuration using encryption >>> > - implement the migration tool in KnoxCLI and wire it in as a startup >>> step >>> > for the DerbyDB default implementation >>> > - make sure end-users will not need to change anything when switching >>> to >>> > the new DerbyDB configured JDBC TSS >>> > - make those three TSS implementations deprecated in v2.1.0, but leave >>> the >>> > AliasBasedTokenState service the default implementation >>> > - release v2.1.0 and document the changes in this area. It's crucial t
[jira] [Updated] (KNOX-2994) Postpone CM configuration change monitoring until the Knox GW is up
[
https://issues.apache.org/jira/browse/KNOX-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2994:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Postpone CM configuration change monitoring until the Knox GW is up
> ---
>
> Key: KNOX-2994
> URL: https://issues.apache.org/jira/browse/KNOX-2994
> Project: Apache Knox
> Issue Type: Improvement
> Components: cm-discovery, Server
>Affects Versions: 1.5.0, 2.0.0, 1.6.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now, Knox starts CM configuration change monitoring right away it
> starts the {{{}DefaultClusterConfigurationMonitorService{}}}. This action
> will trigger the {{PollingConfigurationAnalyzer}} even when descriptors with
> possible service discovery settings are not even initialized.
> My suggestion is to take advantage of the recently introduced
> {{GatewayStatusService}} and set the {{isActive}} flag to true based on the
> result of
> {{{}org.apache.knox.gateway.services.topology.impl.GatewayStatusService.status(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-2994) Postpone CM configuration change monitoring until the Knox GW is up
[
https://issues.apache.org/jira/browse/KNOX-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2994:
Status: Patch Available (was: Open)
> Postpone CM configuration change monitoring until the Knox GW is up
> ---
>
> Key: KNOX-2994
> URL: https://issues.apache.org/jira/browse/KNOX-2994
> Project: Apache Knox
> Issue Type: Improvement
> Components: cm-discovery, Server
>Affects Versions: 1.6.0, 1.5.0, 2.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now, Knox starts CM configuration change monitoring right away it
> starts the {{{}DefaultClusterConfigurationMonitorService{}}}. This action
> will trigger the {{PollingConfigurationAnalyzer}} even when descriptors with
> possible service discovery settings are not even initialized.
> My suggestion is to take advantage of the recently introduced
> {{GatewayStatusService}} and set the {{isActive}} flag to true based on the
> result of
> {{{}org.apache.knox.gateway.services.topology.impl.GatewayStatusService.status(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-2993) Show error stack trace when simple descriptor handler fails to parse a descriptor
[
https://issues.apache.org/jira/browse/KNOX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2993:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Show error stack trace when simple descriptor handler fails to parse a
> descriptor
> -
>
> Key: KNOX-2993
> URL: https://issues.apache.org/jira/browse/KNOX-2993
> Project: Apache Knox
> Issue Type: Task
> Components: Server
>Affects Versions: 2.0.0, 1.6.0
> Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, the error stack trace is shown in gateway.log only, if the
> {{org.apache.knox.gateway}} log level is set to {{DEBUG}}:
> {noformat}
> @Message( level = MessageLevel.ERROR, text = "An error occurred while
> processing {0} : {1}" )
> void simpleDescriptorHandlingError(String simpleDesc,
> @StackTrace(level = MessageLevel.DEBUG)
> Exception e);
> {noformat}
> This makes our lives hard when dealing with errors related to events coming
> from CM configuration monitoring.
> I recommend showing this information even on {{INFO}} level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-2993) Show error stack trace when simple descriptor handler fails to parse a descriptor
[
https://issues.apache.org/jira/browse/KNOX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2993:
Status: Patch Available (was: Open)
> Show error stack trace when simple descriptor handler fails to parse a
> descriptor
> -
>
> Key: KNOX-2993
> URL: https://issues.apache.org/jira/browse/KNOX-2993
> Project: Apache Knox
> Issue Type: Task
> Components: Server
>Affects Versions: 1.6.0, 2.0.0
> Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the error stack trace is shown in gateway.log only, if the
> {{org.apache.knox.gateway}} log level is set to {{DEBUG}}:
> {noformat}
> @Message( level = MessageLevel.ERROR, text = "An error occurred while
> processing {0} : {1}" )
> void simpleDescriptorHandlingError(String simpleDesc,
> @StackTrace(level = MessageLevel.DEBUG)
> Exception e);
> {noformat}
> This makes our lives hard when dealing with errors related to events coming
> from CM configuration monitoring.
> I recommend showing this information even on {{INFO}} level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-2990) TokenStateService implementation cleanup
[
https://issues.apache.org/jira/browse/KNOX-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2990:
Status: Patch Available (was: In Progress)
> TokenStateService implementation cleanup
>
>
> Key: KNOX-2990
> URL: https://issues.apache.org/jira/browse/KNOX-2990
> Project: Apache Knox
> Issue Type: Task
> Components: Server
>Affects Versions: 1.6.0, 2.0.0, 1.6.1
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This issue is driven by a [DISCUSS] thread initiated on Knox's DEV mailing
> list [here|https://lists.apache.org/thread/fs9nkl6l45o330ttvgvqxj3jnxt63bcs].
> As a result of that discussion, the following needs to be implemented:
> * deprecate the following TSS implementations:
> ** AliasBasedTokenStateService
> ** ZookeeperTokenStateService
> ** JournalBasedTokenStateService
> * document the deprecation of these TSS implementations in v2.1.0 and
> highlight that they will be removed in the upcoming release (v2.2.0?).
> * implement a DerbyDB storage that will store tokens in
> {{$DATA_DIR/security/tokens}} (encrypted or not, it'll be decided later)
> * make sure appropriate file permissions are set on that folder
> * have the {{homepage}} topology configured with JDBC TSS pointing to this
> DerbyDB storage
> * implement a new KnoxCLI command that migrates existing tokens from
> credential stores to the DerbyDB storage
> * automate this new KnoxCLI command in a way such that it runs when Knox
> Gateway is started, token management is enabled, and DerbyDB storage is
> configured
> * ensure that the previous automated step can be controlled (E.g. in case of
> unforeseen errors it can be turned off)
> * document possible data replication scenarios when, in the case of HA
> deployments, existing tokens from one Knox node should be made available in
> other Knox node(s) and there is no other centralized RDBMS in use
> (PostgreSQL, MySQL for instance)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (KNOX-2956) Refactor CM-specific advanced service discovery
[
https://issues.apache.org/jira/browse/KNOX-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar resolved KNOX-2956.
-
Resolution: Fixed
> Refactor CM-specific advanced service discovery
> ---
>
> Key: KNOX-2956
> URL: https://issues.apache.org/jira/browse/KNOX-2956
> Project: Apache Knox
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.6.0, 1.6.1
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Knox's Hadoop XML resource parser is tightly coupled with another feature
> called Advanced Service Discovery configuration in Cloudera Manager.
> There are several issues with that extension:
> - makes the code much harder to read, understand, and maintain
> - occupies a separate thread to monitor other files (we already have many
> file watchers, it's always good if we can do some cleanup)
> - One should really oversee the correlation between them and make the right
> decision when touching one or the other (for instance, when changing the
> ordering of these services)
> - Since this is CM specific, lots of properties were added in the relevant
> Knox [CSD
> files|https://github.com/cloudera/cm_ext/wiki/Service-Descriptor-Language-Reference]
> to give the flexibility for our users to enable/disable services during CM
> service discovery. The management of those configurations is way too complex
> and has a really negative effect on user experience on Knox's configuration
> page within Cloudera Manager
> Therefore, I came up with an idea that will still allow us to keep the
> original idea of excluding/including certain services to be
> discovered/included in the generated topology files. I plan to implement the
> following:
> - Remove the entire {{AdvancedServiceDiscoveryConfig*}} code
> - Former {{gateway.auto.discovery.address}} and
> {{gateway.auto.discovery.cluster}} parameters are already taken care of in
> HXR parser where descriptors are handled (they need to be set in upstream
> configuration locations such as the Knox CSD)
> - By default, all services are disabled even if a service available service
> found in the given discovery address/cluster will be added to the descriptor.
> This is because of the nature of the existing logic in
> {{{}SimpleDescriptorHandler{}}}. I'll add a new parameter suffix for service
> called "{{{}services{}}}" which end-users can set to "{{{}a comma-separated
> list of services"{}}} to include services in the generated topology (this new
> HXR parameter is similar to the existing 'discoveryAddress' or
> 'providerConfigRef' configs)
> - since this is CM-specific, Cloudera Manager users need to make sure to
> adopt their CSD files accordingly
> As a result, the {{.hxr}} file(s) will be self-contained and can achieve the
> same functionality as we have now with the complementary
> {{auto-discovery-advanced-configuration-*}} files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-2994) Postpone CM configuration change monitoring until the Knox GW is up
Sandor Molnar created KNOX-2994:
---
Summary: Postpone CM configuration change monitoring until the
Knox GW is up
Key: KNOX-2994
URL: https://issues.apache.org/jira/browse/KNOX-2994
Project: Apache Knox
Issue Type: Improvement
Components: cm-discovery, Server
Affects Versions: 1.6.0, 1.5.0, 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
As of now, Knox starts CM configuration change monitoring right away it starts
the {{{}DefaultClusterConfigurationMonitorService{}}}. This action will trigger
the {{PollingConfigurationAnalyzer}} even when descriptors with possible
service discovery settings are not even initialized.
My suggestion is to take advantage of the recently introduced
{{GatewayStatusService}} and set the {{isActive}} flag to true based on the
result of
{{{}org.apache.knox.gateway.services.topology.impl.GatewayStatusService.status(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-2993) Show error stack trace when simple descriptor handler fails to parse a descriptor
Sandor Molnar created KNOX-2993:
---
Summary: Show error stack trace when simple descriptor handler
fails to parse a descriptor
Key: KNOX-2993
URL: https://issues.apache.org/jira/browse/KNOX-2993
Project: Apache Knox
Issue Type: Task
Components: Server
Affects Versions: 1.6.0, 2.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Currently, the error stack trace is shown in gateway.log only, if the
{{org.apache.knox.gateway}} log level is set to {{DEBUG}}:
{noformat}
@Message( level = MessageLevel.ERROR, text = "An error occurred while
processing {0} : {1}" )
void simpleDescriptorHandlingError(String simpleDesc,
@StackTrace(level = MessageLevel.DEBUG)
Exception e);
{noformat}
This makes our lives hard when dealing with errors related to events coming
from CM configuration monitoring.
I recommend showing this information even on {{INFO}} level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (KNOX-2990) TokenStateService implementation cleanup
[
https://issues.apache.org/jira/browse/KNOX-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-2990 started by Sandor Molnar.
---
> TokenStateService implementation cleanup
>
>
> Key: KNOX-2990
> URL: https://issues.apache.org/jira/browse/KNOX-2990
> Project: Apache Knox
> Issue Type: Task
> Components: Server
>Affects Versions: 2.0.0, 1.6.0, 1.6.1
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
>Priority: Critical
> Fix For: 2.1.0
>
>
> This issue is driven by a [DISCUSS] thread initiated on Knox's DEV mailing
> list [here|https://lists.apache.org/thread/fs9nkl6l45o330ttvgvqxj3jnxt63bcs].
> As a result of that discussion, the following needs to be implemented:
> * deprecate the following TSS implementations:
> ** AliasBasedTokenStateService
> ** ZookeeperTokenStateService
> ** JournalBasedTokenStateService
> * document the deprecation of these TSS implementations in v2.1.0 and
> highlight that they will be removed in the upcoming release (v2.2.0?).
> * implement a DerbyDB storage that will store tokens in
> {{$DATA_DIR/security/tokens}} (encrypted or not, it'll be decided later)
> * make sure appropriate file permissions are set on that folder
> * have the {{homepage}} topology configured with JDBC TSS pointing to this
> DerbyDB storage
> * implement a new KnoxCLI command that migrates existing tokens from
> credential stores to the DerbyDB storage
> * automate this new KnoxCLI command in a way such that it runs when Knox
> Gateway is started, token management is enabled, and DerbyDB storage is
> configured
> * ensure that the previous automated step can be controlled (E.g. in case of
> unforeseen errors it can be turned off)
> * document possible data replication scenarios when, in the case of HA
> deployments, existing tokens from one Knox node should be made available in
> other Knox node(s) and there is no other centralized RDBMS in use
> (PostgreSQL, MySQL for instance)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KNOX-2992) Token impersonation config cleanup
[ https://issues.apache.org/jira/browse/KNOX-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-2992: Resolution: Fixed Status: Resolved (was: Patch Available) > Token impersonation config cleanup > -- > > Key: KNOX-2992 > URL: https://issues.apache.org/jira/browse/KNOX-2992 > Project: Apache Knox > Issue Type: Task > Components: Server, TokenGenerationUI > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Major > Fix For: 2.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to make some changes in the token impersonation config to be better > suited in Knox's existing configuration defaults. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-2992) Token impersonation config cleanup
[ https://issues.apache.org/jira/browse/KNOX-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandor Molnar updated KNOX-2992: Status: Patch Available (was: Open) > Token impersonation config cleanup > -- > > Key: KNOX-2992 > URL: https://issues.apache.org/jira/browse/KNOX-2992 > Project: Apache Knox > Issue Type: Task > Components: Server, TokenGenerationUI > Reporter: Sandor Molnar > Assignee: Sandor Molnar >Priority: Major > Fix For: 2.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to make some changes in the token impersonation config to be better > suited in Knox's existing configuration defaults. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KNOX-2991) Sanitise Oozie rewrite rules
[
https://issues.apache.org/jira/browse/KNOX-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791604#comment-17791604
]
Sandor Molnar commented on KNOX-2991:
-
Thanks, [~dionusos] for filing this important JIRA!
> Sanitise Oozie rewrite rules
>
>
> Key: KNOX-2991
> URL: https://issues.apache.org/jira/browse/KNOX-2991
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.6.0
>Reporter: Dénes Bodó
>Assignee: Dénes Bodó
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Testing Oozie through Knox proxy I found that there are some strange rewrite
> rule which seems outdated:
> {noformat}
>
>
>
>
>
>
> {noformat}
> This ticket is intended to track the work removing them.
> *inputDir* and *outputDir* are frequently used in Oozie's job.properties as a
> single directory name instead of a full HDFS path so in these cases the Oozie
> workflow fails running due to incorrect variable resolution:
> Configuration in job.properties:
> {noformat}
> nameNode=WILL_BE_UPDATED_BY_KNOX
> outputDir=my_custom_output_dir {noformat}
> workflow.xml:
> {code:xml}
>
> path="${nameNode}/user/${wf:user()}/examples/output-data/${outputDir}"/>
> {code}
> Error in Oozie launcher:
> {noformat}
> Launcher AM execution failed
> java.lang.IllegalArgumentException: java.net.URISyntaxException: Expected
> scheme-specific part at index 5: hdfs:
> at org.apache.hadoop.fs.Path.initialize(Path.java:259)
> at org.apache.hadoop.fs.Path.(Path.java:217)
> at org.apache.hadoop.fs.Path.(Path.java:125)
> at org.apache.hadoop.fs.Globber.doGlob(Globber.java:285)
> at org.apache.hadoop.fs.Globber.glob(Globber.java:202)
> at org.apache.hadoop.fs.FileSystem.globStatus(FileSystem.java:2107)
> at
> org.apache.oozie.action.hadoop.FSLauncherURIHandler.delete(FSLauncherURIHandler.java:59)
> at
> org.apache.oozie.action.hadoop.PrepareActionsHandler.execute(PrepareActionsHandler.java:83)
> at
> org.apache.oozie.action.hadoop.PrepareActionsHandler.prepareAction(PrepareActionsHandler.java:74)
> at
> org.apache.oozie.action.hadoop.LauncherAM.executePrepare(LauncherAM.java:378)
> at
> org.apache.oozie.action.hadoop.LauncherAM.access$100(LauncherAM.java:55)
> at org.apache.oozie.action.hadoop.LauncherAM$2.run(LauncherAM.java:229)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1899)
> at org.apache.oozie.action.hadoop.LauncherAM.run(LauncherAM.java:226)
> at org.apache.oozie.action.hadoop.LauncherAM$1.run(LauncherAM.java:156)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1899)
> at org.apache.oozie.action.hadoop.LauncherAM.main(LauncherAM.java:144)
> Caused by: java.net.URISyntaxException: Expected scheme-specific part at
> index 5: hdfs:
> at java.net.URI$Parser.fail(URI.java:2847)
> at java.net.URI$Parser.failExpecting(URI.java:2853)
> at java.net.URI$Parser.parse(URI.java:3056)
> at java.net.URI.(URI.java:746)
> at org.apache.hadoop.fs.Path.initialize(Path.java:256)
> ... 20 more {noformat}
>
> Found the real HDFS path after debugging the Oozie action:
> {noformat}
> hdfs://a.b.c.d:8020/user/test/examples/output-data/hdfs://a.b.c.d:8020/my_custom_output_dir{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KNOX-2992) Token impersonation config cleanup
Sandor Molnar created KNOX-2992: --- Summary: Token impersonation config cleanup Key: KNOX-2992 URL: https://issues.apache.org/jira/browse/KNOX-2992 Project: Apache Knox Issue Type: Task Components: Server, TokenGenerationUI Reporter: Sandor Molnar Assignee: Sandor Molnar Fix For: 2.1.0 We need to make some changes in the token impersonation config to be better suited in Knox's existing configuration defaults. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [DISCUSS] Token State Service implementation cleanup
FYI: https://issues.apache.org/jira/browse/KNOX-2990 On Thu, Nov 30, 2023 at 9:05 AM Sandor Molnar wrote: > Hello folks! > > After an offline discussion with Larry, we agreed on the following (as an > extension to the action plan I listed above): > - the migration tool will be run automatically when the Knox Gateway > starts, and it will run on the main thread (i.e. not in the background). > - there will be a config to control this step: in case of an error/bug, > this automated migration could be turned off > - when the first version of this newly configured DerbyDB JDBC TSS is > implemented, I'll run some performance tests to see if encryption should be > enabled by default > - we'll make sure to protect the DerbyDB data folder with proper file > permissions > > I'll submit the required JIRAs soon. > > Cheers, > Sandor > > > On Thu, Nov 23, 2023 at 11:59 PM larry mccay wrote: > >> If we can determine whether there is already an alias based TSS in place >> and continue to use that for upgrades but derby for new clusters, I would >> be in favor of that. >> On whether to enable encryption, if we are only storing a hash of the >> passcode token then that should be okay. >> The persistence should be protected appropriately with file permissions >> for >> the knox user. >> >> NOTE: We will need to have some idea of how this may affect management >> applications like Cloudera Manager and Ambari, if at all, and get out in >> front of it. >> >> On Fri, Nov 17, 2023 at 8:27 AM Sandor Molnar >> >> wrote: >> >> > Hi folks! >> > >> > Let me try to summarize what we have so far: >> > 1. we are all in favor of removing the JournalBased and Zookeeper TSS >> > implementations >> > 2. we all agreed that removing the AliasBasedTSS implementation requires >> > extra caution >> > 3. Larry raised the following concerns >> > 3.1 clear data storage in Derby -> ANSWER: Attila and I also >> indicated >> > Derby provides data encryption OOTB >> > 3.2 token hashes -> ANSWER: we do not store JWTs, only metadata. We >> > persist the passcode tokens though. It's hashed and stored using the >> > "knox.token.hash.key" secret and "gateway.knox.token.hash.algorithm" >> HMAC >> > algorithm which defaults to HmacSHA256. >> > 3.3 token synchronization across multiple Knox instances. -> ANSWER: >> > Derby has data replication capabilities. However, in HA environments, >> I'd >> > strongly recommend using Postgres/MySQL in those Knox instances >> > 4. Sandeep and Phil articulated the importance of deprecation -> we all >> > agree on this point >> > 5. Phil asked whether data encryption should be the default in the >> > Derby-configured JDBC TSS --> IMO, encryption should be turned on by >> > default. The required "bootPassword" should be auto-generated and >> stored in >> > __gateway-credentials.jks >> > 6. I recommended that the migration tool should be automated: when token >> > state service is initiated and it's using the pre-configured Derby >> > database, we may check if there is any token stored in __gateway.jks and >> > migrate them. This way it'd be seamless for existing tokens. >> > >> > Action plan: >> > - waiting for additional inputs on the above >> > - implement the DerbyDB configuration using encryption >> > - implement the migration tool in KnoxCLI and wire it in as a startup >> step >> > for the DerbyDB default implementation >> > - make sure end-users will not need to change anything when switching to >> > the new DerbyDB configured JDBC TSS >> > - make those three TSS implementations deprecated in v2.1.0, but leave >> the >> > AliasBasedTokenState service the default implementation >> > - release v2.1.0 and document the changes in this area. It's crucial to >> > emphasize we are going to remove them in the upcoming release (v2.2.0?) >> and >> > encourage end-users to switch to the DerbyDB JDBC TSS ASAP >> > - once v2.1.0 is released, remove the deprecated implementations and >> have >> > the new DerbyDB JDBC TSS the default one >> > >> > As always, feel free to add your comments and insights on the above >> > subject. >> > >> > Cheers, >> > Sandor >> > >> > On Tue, Nov 14, 2023 at 3:41 PM Phil Zampino >> wrote: >> > >> > > First and foremost, I'll echo the comments about deprecatio
[jira] [Created] (KNOX-2990) TokenStateService implementation cleanup
Sandor Molnar created KNOX-2990:
---
Summary: TokenStateService implementation cleanup
Key: KNOX-2990
URL: https://issues.apache.org/jira/browse/KNOX-2990
Project: Apache Knox
Issue Type: Task
Components: Server
Affects Versions: 1.6.0, 2.0.0, 1.6.1
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 2.1.0
This issue is driven by a [DISCUSS] thread initiated on Knox's DEV mailing list
[here|https://lists.apache.org/thread/fs9nkl6l45o330ttvgvqxj3jnxt63bcs].
As a result of that discussion, the following needs to be implemented:
* deprecate the following TSS implementations:
** AliasBasedTokenStateService
** ZookeeperTokenStateService
** JournalBasedTokenStateService
* document the deprecation of these TSS implementations in v2.1.0 and
highlight that they will be removed in the upcoming release (v2.2.0?).
* implement a DerbyDB storage that will store tokens in
{{$DATA_DIR/security/tokens}} (encrypted or not, it'll be decided later)
* make sure appropriate file permissions are set on that folder
* have the {{homepage}} topology configured with JDBC TSS pointing to this
DerbyDB storage
* implement a new KnoxCLI command that migrates existing tokens from
credential stores to the DerbyDB storage
* automate this new KnoxCLI command in a way such that it runs when Knox
Gateway is started, token management is enabled, and DerbyDB storage is
configured
* ensure that the previous automated step can be controlled (E.g. in case of
unforeseen errors it can be turned off)
* document possible data replication scenarios when, in the case of HA
deployments, existing tokens from one Knox node should be made available in
other Knox node(s) and there is no other centralized RDBMS in use (PostgreSQL,
MySQL for instance)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [DISCUSS] Token State Service implementation cleanup
Hello folks! After an offline discussion with Larry, we agreed on the following (as an extension to the action plan I listed above): - the migration tool will be run automatically when the Knox Gateway starts, and it will run on the main thread (i.e. not in the background). - there will be a config to control this step: in case of an error/bug, this automated migration could be turned off - when the first version of this newly configured DerbyDB JDBC TSS is implemented, I'll run some performance tests to see if encryption should be enabled by default - we'll make sure to protect the DerbyDB data folder with proper file permissions I'll submit the required JIRAs soon. Cheers, Sandor On Thu, Nov 23, 2023 at 11:59 PM larry mccay wrote: > If we can determine whether there is already an alias based TSS in place > and continue to use that for upgrades but derby for new clusters, I would > be in favor of that. > On whether to enable encryption, if we are only storing a hash of the > passcode token then that should be okay. > The persistence should be protected appropriately with file permissions for > the knox user. > > NOTE: We will need to have some idea of how this may affect management > applications like Cloudera Manager and Ambari, if at all, and get out in > front of it. > > On Fri, Nov 17, 2023 at 8:27 AM Sandor Molnar > > wrote: > > > Hi folks! > > > > Let me try to summarize what we have so far: > > 1. we are all in favor of removing the JournalBased and Zookeeper TSS > > implementations > > 2. we all agreed that removing the AliasBasedTSS implementation requires > > extra caution > > 3. Larry raised the following concerns > > 3.1 clear data storage in Derby -> ANSWER: Attila and I also > indicated > > Derby provides data encryption OOTB > > 3.2 token hashes -> ANSWER: we do not store JWTs, only metadata. We > > persist the passcode tokens though. It's hashed and stored using the > > "knox.token.hash.key" secret and "gateway.knox.token.hash.algorithm" HMAC > > algorithm which defaults to HmacSHA256. > > 3.3 token synchronization across multiple Knox instances. -> ANSWER: > > Derby has data replication capabilities. However, in HA environments, I'd > > strongly recommend using Postgres/MySQL in those Knox instances > > 4. Sandeep and Phil articulated the importance of deprecation -> we all > > agree on this point > > 5. Phil asked whether data encryption should be the default in the > > Derby-configured JDBC TSS --> IMO, encryption should be turned on by > > default. The required "bootPassword" should be auto-generated and stored > in > > __gateway-credentials.jks > > 6. I recommended that the migration tool should be automated: when token > > state service is initiated and it's using the pre-configured Derby > > database, we may check if there is any token stored in __gateway.jks and > > migrate them. This way it'd be seamless for existing tokens. > > > > Action plan: > > - waiting for additional inputs on the above > > - implement the DerbyDB configuration using encryption > > - implement the migration tool in KnoxCLI and wire it in as a startup > step > > for the DerbyDB default implementation > > - make sure end-users will not need to change anything when switching to > > the new DerbyDB configured JDBC TSS > > - make those three TSS implementations deprecated in v2.1.0, but leave > the > > AliasBasedTokenState service the default implementation > > - release v2.1.0 and document the changes in this area. It's crucial to > > emphasize we are going to remove them in the upcoming release (v2.2.0?) > and > > encourage end-users to switch to the DerbyDB JDBC TSS ASAP > > - once v2.1.0 is released, remove the deprecated implementations and have > > the new DerbyDB JDBC TSS the default one > > > > As always, feel free to add your comments and insights on the above > > subject. > > > > Cheers, > > Sandor > > > > On Tue, Nov 14, 2023 at 3:41 PM Phil Zampino > wrote: > > > > > First and foremost, I'll echo the comments about deprecation. IMO, we > > must > > > deprecate these implementations in a release before completely removing > > > them in a subsequent release. > > > > > > I agree that the ZK and Journal implementations should be deprecated > for > > > the reasons stated. > > > > > > Concerning replacing the alias-based implementation with Derby, I > > > share some of the same concerns expressed by Larry: > > > - Attila has mentioned that Derby
[jira] [Comment Edited] (KNOX-2988) Documentation for KNOX-2983
[ https://issues.apache.org/jira/browse/KNOX-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791029#comment-17791029 ] Sandor Molnar edited comment on KNOX-2988 at 11/29/23 11:47 AM: LGTM! [~moresandeep] , [~pzampino] - could you please check [~amagyar]'s document about the new expression-based principal mapping? was (Author: smolnar): LGTM! [~moresandeep] , [~pzampino] - could you please check [~amagyar] 's document about the new expression based principal mapping? > Documentation for KNOX-2983 > --- > > Key: KNOX-2988 > URL: https://issues.apache.org/jira/browse/KNOX-2988 > Project: Apache Knox > Issue Type: Improvement >Reporter: Attila Magyar >Assignee: Attila Magyar >Priority: Major > Attachments: KNOX-2983.patch, Screenshot 2023-11-20 at 12.22.28.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KNOX-2988) Documentation for KNOX-2983
[ https://issues.apache.org/jira/browse/KNOX-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791029#comment-17791029 ] Sandor Molnar commented on KNOX-2988: - LGTM! [~moresandeep] , [~pzampino] - could you please check [~amagyar] 's document about the new expression based principal mapping? > Documentation for KNOX-2983 > --- > > Key: KNOX-2988 > URL: https://issues.apache.org/jira/browse/KNOX-2988 > Project: Apache Knox > Issue Type: Improvement >Reporter: Attila Magyar >Assignee: Attila Magyar >Priority: Major > Attachments: KNOX-2983.patch, Screenshot 2023-11-20 at 12.22.28.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KNOX-2956) Refactor CM-specific advanced service discovery
[
https://issues.apache.org/jira/browse/KNOX-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2956:
Description:
Knox's Hadoop XML resource parser is tightly coupled with another feature
called Advanced Service Discovery configuration in Cloudera Manager.
There are several issues with that extension:
- makes the code much harder to read, understand, and maintain
- occupies a separate thread to monitor other files (we already have many file
watchers, it's always good if we can do some cleanup)
- One should really oversee the correlation between them and make the right
decision when touching one or the other (for instance, when changing the
ordering of these services)
- Since this is CM specific, lots of properties were added in the relevant
Knox [CSD
files|https://github.com/cloudera/cm_ext/wiki/Service-Descriptor-Language-Reference]
to give the flexibility for our users to enable/disable services during CM
service discovery. The management of those configurations is way too complex
and has a really negative effect on user experience on Knox's configuration
page within Cloudera Manager
Therefore, I came up with an idea that will still allow us to keep the original
idea of excluding/including certain services to be discovered/included in the
generated topology files. I plan to implement the following:
- Remove the entire {{AdvancedServiceDiscoveryConfig*}} code
- Former {{gateway.auto.discovery.address}} and
{{gateway.auto.discovery.cluster}} parameters are already taken care of in HXR
parser where descriptors are handled (they need to be set in upstream
configuration locations such as the Knox CSD)
- By default, all services are disabled even if a service available service
found in the given discovery address/cluster will be added to the descriptor.
This is because of the nature of the existing logic in
{{{}SimpleDescriptorHandler{}}}. I'll add a new parameter suffix for service
called "{{{}services{}}}" which end-users can set to "{{{}a comma-separated
list of services"{}}} to include services in the generated topology (this new
HXR parameter is similar to the existing 'discoveryAddress' or
'providerConfigRef' configs)
- since this is CM-specific, Cloudera Manager users need to make sure to adopt
their CSD files accordingly
As a result, the {{.hxr}} file(s) will be self-contained and can achieve the
same functionality as we have now with the complementary
{{auto-discovery-advanced-configuration-*}} files.
was:
Knox's Hadoop XML resource parser is tightly coupled with another feature
called Advanced Service Discovery configuration in Cloudera Manager.
There are several issues with that extension:
- makes the code much harder to read, understand, and maintain
- occupies a separate thread to monitor other files (we already have many file
watchers, it's always good if we can do some cleanup)
- One should really oversee the correlation between them and make the right
decision when touching one or the other (for instance, when changing the
ordering of these services)
- Since this is CM specific, lots of properties were added in the relevant
Knox [CSD
files|https://github.com/cloudera/cm_ext/wiki/Service-Descriptor-Language-Reference]
to give the flexibility for our users to enable/disable services during CM
service discovery. The management of those configurations is way too complex
and has a really negative effect on user experience on Knox's configuration
page within Cloudera Manager
Therefore, I came up with an idea that will still allow us to keep the original
idea of excluding/including certain services to be discovered/included in the
generated topology files. I plan to implement the following:
- Remove the entire {{AdvancedServiceDiscoveryConfig*}} code
- Former {{gateway.auto.discovery.address}} and
{{gateway.auto.discovery.cluster}} parameters are already taken care of in HXR
parser where descriptors are handled (they need to be set in upstream
configuration locations such as the Knox CSD)
- By default, all services are enabled, thus every available service found in
the given discovery address/cluster will be added to the descriptor. I'll add a
new parameter suffix for service called "{{{}exclude{}}}" which end-users can
set to {{true}} if they want to exclude a particular service from the generated
topology (this new service parameter suffix is similar to the existing 'url' or
'version' suffixes)
As a result, the {{.hxr}} file(s) will be self-contained and can achieve the
same functionality as we have now with the complementary
{{auto-discovery-advanced-configuration-*}} files.
> Refactor CM-specific advanced service discovery
> ---
>
> Key: KNOX-2956
> URL: https://issues.apache.org/jira/browse/KNOX-2956
>
