[jira] [Work started] (KNOX-2210) Gateway-level configuration for server-managed Knox token state
[ https://issues.apache.org/jira/browse/KNOX-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-2210 started by Phil Zampino. -- > Gateway-level configuration for server-managed Knox token state > --- > > Key: KNOX-2210 > URL: https://issues.apache.org/jira/browse/KNOX-2210 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.4.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > > Currently, use of the token state service by Knox Token service deployments > and JWT providers is configured independently. This is due to the fact that > there can be multiple deployments of the Knox Token service (i.e., multiple > topologies), and each can choose whether server-management of token state is > desired. > However, in the simplest deployment scenarios, there is a single topology > providing the Knox Token service, and one or more topologies with providers > that verify those tokens for authentication. In these cases, would be simpler > to have a single gateway-level configuration property that enables/disables > the use of the TokenStateService for all KnoxToken service deployments and > JWT provider deployments. > The KnoxToken service and the providers should check for a topology-level > override (e.g., service param, provider param), which should be applied if > present. In the absence of an topology-level override, the gateway-level > configuration property should be referenced and applied. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KNOX-1914) Dynamic population of Admin UI service discovery type options
[ https://issues.apache.org/jira/browse/KNOX-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16927596#comment-16927596 ] Phil Zampino commented on KNOX-1914: [~smolnar] This looks like what I had in mind, where the JSON is built from the Java service loader mechanism. The distinction of _test_ implementations will be good, and not something I had considered. > Dynamic population of Admin UI service discovery type options > - > > Key: KNOX-1914 > URL: https://issues.apache.org/jira/browse/KNOX-1914 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Sandor Molnar >Priority: Major > Fix For: 1.4.0 > > > The Discovery Details section of the Admin UI for working with descriptors > includes a drop-down list of supported discovery providers (e.g., Ambari, > ClouderaManager). Currently, this list is statically defined in the Admin UI. > It should be possible to expose an API from the Knox host for determining the > list of supported discovery providers. > This API could leverage the same Java service loader mechanism that is used > by the discovery runtime to load discovery providers. > This would be nice for two closely-related reasons: > # Subsequent additional discovery providers implemented in the Knox project > itself won't require further Admin UI changes. > # User/Customer discovery provider extensions would get Admin UI support > automatically. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (KNOX-2001) KnoxSession should log a warning message when useSubjectCredsOnly is false
[ https://issues.apache.org/jira/browse/KNOX-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-2001. Resolution: Fixed > KnoxSession should log a warning message when useSubjectCredsOnly is false > -- > > Key: KNOX-2001 > URL: https://issues.apache.org/jira/browse/KNOX-2001 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > KnoxSession should log a warning when the > javax.security.auth.useSubjectCredsOnly system property is set to false. This > message will help diagnose unexpected Kerberos authentication behavior when > this configuration is relaxing the default requirement. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Work started] (KNOX-2001) KnoxSession should log a warning message when useSubjectCredsOnly is false
[ https://issues.apache.org/jira/browse/KNOX-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-2001 started by Phil Zampino. -- > KnoxSession should log a warning message when useSubjectCredsOnly is false > -- > > Key: KNOX-2001 > URL: https://issues.apache.org/jira/browse/KNOX-2001 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > KnoxSession should log a warning when the > javax.security.auth.useSubjectCredsOnly system property is set to false. This > message will help diagnose unexpected Kerberos authentication behavior when > this configuration is relaxing the default requirement. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (KNOX-2001) KnoxSession should log a warning message when useSubjectCredsOnly is false
Phil Zampino created KNOX-2001: -- Summary: KnoxSession should log a warning message when useSubjectCredsOnly is false Key: KNOX-2001 URL: https://issues.apache.org/jira/browse/KNOX-2001 Project: Apache Knox Issue Type: Bug Components: KnoxShell Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.4.0 KnoxSession should log a warning when the javax.security.auth.useSubjectCredsOnly system property is set to false. This message will help diagnose unexpected Kerberos authentication behavior when this configuration is relaxing the default requirement. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (KNOX-2000) KnoxSession should not set javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/KNOX-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-2000. Resolution: Fixed > KnoxSession should not set javax.security.auth.useSubjectCredsOnly > -- > > Key: KNOX-2000 > URL: https://issues.apache.org/jira/browse/KNOX-2000 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > KnoxSession sets the _javax.security.auth.useSubjectCredsOnly_ system > property based on the client context with which it is created. It should not > be setting this property to any value, leaving the control of that > configuration up to the environment in which the session is being employed. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Work started] (KNOX-2000) KnoxSession should not set javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/KNOX-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-2000 started by Phil Zampino. -- > KnoxSession should not set javax.security.auth.useSubjectCredsOnly > -- > > Key: KNOX-2000 > URL: https://issues.apache.org/jira/browse/KNOX-2000 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > KnoxSession sets the _javax.security.auth.useSubjectCredsOnly_ system > property based on the client context with which it is created. It should not > be setting this property to any value, leaving the control of that > configuration up to the environment in which the session is being employed. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (KNOX-2000) KnoxSession should not set javax.security.auth.useSubjectCredsOnly
Phil Zampino created KNOX-2000: -- Summary: KnoxSession should not set javax.security.auth.useSubjectCredsOnly Key: KNOX-2000 URL: https://issues.apache.org/jira/browse/KNOX-2000 Project: Apache Knox Issue Type: Bug Components: KnoxShell Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.4.0 KnoxSession sets the _javax.security.auth.useSubjectCredsOnly_ system property based on the client context with which it is created. It should not be setting this property to any value, leaving the control of that configuration up to the environment in which the session is being employed. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (KNOX-1930) CM discovery - JOBTRACKER URLs not discovered
[ https://issues.apache.org/jira/browse/KNOX-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1930. Resolution: Fixed > CM discovery - JOBTRACKER URLs not discovered > - > > Key: KNOX-1930 > URL: https://issues.apache.org/jira/browse/KNOX-1930 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work started] (KNOX-1926) Cloudera Manager discovery improvements
[ https://issues.apache.org/jira/browse/KNOX-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1926 started by Phil Zampino. -- > Cloudera Manager discovery improvements > --- > > Key: KNOX-1926 > URL: https://issues.apache.org/jira/browse/KNOX-1926 > Project: Apache Knox > Issue Type: Improvement > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Kevin Risden >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > KNOX-1875 implemented initial Cloudera Manager discovery. There are > improvements that can be made. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work started] (KNOX-1930) CM discovery - JOBTRACKER URLs not discovered
[ https://issues.apache.org/jira/browse/KNOX-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1930 started by Phil Zampino. -- > CM discovery - JOBTRACKER URLs not discovered > - > > Key: KNOX-1930 > URL: https://issues.apache.org/jira/browse/KNOX-1930 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KNOX-1921) CM discovery - Hue Load balancer HTTP/HTTPS scheme
[ https://issues.apache.org/jira/browse/KNOX-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895564#comment-16895564 ] Phil Zampino commented on KNOX-1921: What property of the HUE_LOAD_BALANCER role can be employed for determining the scheme? The HUE_SERVER role config includes a property named ssl_enabled; Is there a similar property for the LB role config? > CM discovery - Hue Load balancer HTTP/HTTPS scheme > -- > > Key: KNOX-1921 > URL: https://issues.apache.org/jira/browse/KNOX-1921 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Jean-Francois Desjeans Gauthier >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > With KNOX-1875, the Hue scheme is determined dynamically, but the Hue load > balancer scheme is not. Is it possible to enable the same dynamic scheme > determination for the load balancer? > [https://gitbox.apache.org/repos/asf?p=knox.git;a=blob;f=gateway-discovery-cm/src/main/java/org/apache/knox/gateway/topology/discovery/cm/model/hue/HueLBServiceModelGenerator.java;h=63eb0b690c9635230285bb84a7c939b0f4cfcf44;hb=248f08c#l45] > [https://gitbox.apache.org/repos/asf?p=knox.git;a=blob;f=gateway-discovery-cm/src/main/java/org/apache/knox/gateway/topology/discovery/cm/model/hue/HueServiceModelGenerator.java;h=12e4eb314d730193430745b480bcf77081375a59;hb=248f08c#l48] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KNOX-1935) CM discovery - Hue should not have both LB and non LB
[
https://issues.apache.org/jira/browse/KNOX-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895320#comment-16895320
]
Phil Zampino commented on KNOX-1935:
Is the expectation here that the LB endpoint (if defined) should be the only
one included in the topology?
> CM discovery - Hue should not have both LB and non LB
> -
>
> Key: KNOX-1935
> URL: https://issues.apache.org/jira/browse/KNOX-1935
> Project: Apache Knox
> Issue Type: Sub-task
> Components: cm-discovery
>Affects Versions: 1.3.0
>Reporter: Kevin Risden
>Assignee: Phil Zampino
>Priority: Major
> Fix For: 1.4.0
>
>
> Here is an example of what was generated.
> {code:java}
>
> HUE
>
> haEnabled
> true
>
> https://HUE_HOST:
> http://HUE_HOST:8889
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (KNOX-1957) gateway.sh doesn't handle KNOX_GATEWAY_DBG_OPTS env var correctly
Phil Zampino created KNOX-1957: -- Summary: gateway.sh doesn't handle KNOX_GATEWAY_DBG_OPTS env var correctly Key: KNOX-1957 URL: https://issues.apache.org/jira/browse/KNOX-1957 Project: Apache Knox Issue Type: Bug Components: Server Affects Versions: 1.4.0 Reporter: Phil Zampino Fix For: 1.4.0 It seems KNOX-1816 caused a regression wrt the way options are handled in the scripts (e.g., gateway.sh). Specifically, if the KNOX_GATEWAY_DBG_OPTS env var is set, even though the value is included in the resulting command, the JVM does not listen on the configured port. The issue appears to be the double-quoting of $APP_JAVA_OPTS in knox-functions.sh, specifically in the appStart function (for this particular error). This shellcheck doc may be helpful in resolving this issue: [https://github.com/koalaman/shellcheck/wiki/SC2086] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (KNOX-1929) CM discovery - HIVE URLs not discovered when HIVE_ON_TEZ is deployed
[ https://issues.apache.org/jira/browse/KNOX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1929. Resolution: Fixed > CM discovery - HIVE URLs not discovered when HIVE_ON_TEZ is deployed > > > Key: KNOX-1929 > URL: https://issues.apache.org/jira/browse/KNOX-1929 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > When HIVESERVER2 is deployed as HIVE_ON_TEZ, the CM discovery implementation > does not correctly identify it, and thusly fails to generate a valid URL for > Knox to proxy. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (KNOX-1929) CM discovery - HIVE URLs not discovered when HIVE_ON_TEZ is deployed
[ https://issues.apache.org/jira/browse/KNOX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino updated KNOX-1929: --- Description: When HIVESERVER2 is deployed as HIVE_ON_TEZ, the CM discovery implementation does not correctly identify it, and thusly fails to generate a valid URL for Knox to proxy. (was: When HIVESERVER2 is deployed as HIVE_ON_TEZ, the CM discovery implementation does not correctly identify it, and thusly fails to generate a valid URL for Knox to proxy. It looks like the implementation should consider only role type (i.e., HIVESERVER2), rather than the service type (i.e., HIVE, HIVE_ON_TEZ) to determine if it should "handle" the config.) > CM discovery - HIVE URLs not discovered when HIVE_ON_TEZ is deployed > > > Key: KNOX-1929 > URL: https://issues.apache.org/jira/browse/KNOX-1929 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > When HIVESERVER2 is deployed as HIVE_ON_TEZ, the CM discovery implementation > does not correctly identify it, and thusly fails to generate a valid URL for > Knox to proxy. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work started] (KNOX-1929) CM discovery - HIVE URLs not discovered when HIVE_ON_TEZ is deployed
[ https://issues.apache.org/jira/browse/KNOX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1929 started by Phil Zampino. -- > CM discovery - HIVE URLs not discovered when HIVE_ON_TEZ is deployed > > > Key: KNOX-1929 > URL: https://issues.apache.org/jira/browse/KNOX-1929 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > When HIVESERVER2 is deployed as HIVE_ON_TEZ, the CM discovery implementation > does not correctly identify it, and thusly fails to generate a valid URL for > Knox to proxy. > It looks like the implementation should consider only role type (i.e., > HIVESERVER2), rather than the service type (i.e., HIVE, HIVE_ON_TEZ) to > determine if it should "handle" the config. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (KNOX-1949) CM discovery - Improve efficiency of discovery
[ https://issues.apache.org/jira/browse/KNOX-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1949. Resolution: Fixed > CM discovery - Improve efficiency of discovery > -- > > Key: KNOX-1949 > URL: https://issues.apache.org/jira/browse/KNOX-1949 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > Currently, the service loader mechanism is employed multiple times to get the > available service model generators; this should be done only once at > initialization time. > Currently, the implementation iterates of every available service model > generator for each service role encountered in the CM configuration. It > should alternatively iterate over a more tightly-scoped set of service model > generators. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (KNOX-1949) CM discovery - Improve efficiency of discovery
Phil Zampino created KNOX-1949: -- Summary: CM discovery - Improve efficiency of discovery Key: KNOX-1949 URL: https://issues.apache.org/jira/browse/KNOX-1949 Project: Apache Knox Issue Type: Sub-task Components: cm-discovery Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.4.0 Currently, the service loader mechanism is employed multiple times to get the available service model generators; this should be done only once at initialization time. Currently, the implementation iterates of every available service model generator for each service role encountered in the CM configuration. It should alternatively iterate over a more tightly-scoped set of service model generators. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work started] (KNOX-1949) CM discovery - Improve efficiency of discovery
[ https://issues.apache.org/jira/browse/KNOX-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1949 started by Phil Zampino. -- > CM discovery - Improve efficiency of discovery > -- > > Key: KNOX-1949 > URL: https://issues.apache.org/jira/browse/KNOX-1949 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > Currently, the service loader mechanism is employed multiple times to get the > available service model generators; this should be done only once at > initialization time. > Currently, the implementation iterates of every available service model > generator for each service role encountered in the CM configuration. It > should alternatively iterate over a more tightly-scoped set of service model > generators. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (KNOX-1927) CM discovery - ZEPPELINUI / ZEPPELINWS urls are not discovered
[ https://issues.apache.org/jira/browse/KNOX-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1927. Resolution: Fixed > CM discovery - ZEPPELINUI / ZEPPELINWS urls are not discovered > -- > > Key: KNOX-1927 > URL: https://issues.apache.org/jira/browse/KNOX-1927 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Kevin Risden >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > ZEPPELINUI/ZEPPELINWS is added to the descriptor but urls are empty? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (KNOX-1928) CM discovery - Multiple of same url are added to descriptor?
[ https://issues.apache.org/jira/browse/KNOX-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1928. Resolution: Fixed > CM discovery - Multiple of same url are added to descriptor? > > > Key: KNOX-1928 > URL: https://issues.apache.org/jira/browse/KNOX-1928 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Kevin Risden >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > In the generated topology, sometimes there are multiple of the same exact > url. SOLR exhibited this behavior but there looked to be others. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work started] (KNOX-1927) CM discovery - ZEPPELINUI / ZEPPELINWS urls are not discovered
[ https://issues.apache.org/jira/browse/KNOX-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1927 started by Phil Zampino. -- > CM discovery - ZEPPELINUI / ZEPPELINWS urls are not discovered > -- > > Key: KNOX-1927 > URL: https://issues.apache.org/jira/browse/KNOX-1927 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Kevin Risden >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > ZEPPELINUI/ZEPPELINWS is added to the descriptor but urls are empty? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work started] (KNOX-1928) CM discovery - Multiple of same url are added to descriptor?
[ https://issues.apache.org/jira/browse/KNOX-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1928 started by Phil Zampino. -- > CM discovery - Multiple of same url are added to descriptor? > > > Key: KNOX-1928 > URL: https://issues.apache.org/jira/browse/KNOX-1928 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Kevin Risden >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > In the generated topology, sometimes there are multiple of the same exact > url. SOLR exhibited this behavior but there looked to be others. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KNOX-1929) CM discovery - HIVE URLs not discovered when HIVE_ON_TEZ is deployed
[ https://issues.apache.org/jira/browse/KNOX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889529#comment-16889529 ] Phil Zampino commented on KNOX-1929: I was wondering about the multiplicity of HS2 instances. Need to understand what it means to have both HIVE and HIVE_ON_TEZ HS2 in the same cluster. > CM discovery - HIVE URLs not discovered when HIVE_ON_TEZ is deployed > > > Key: KNOX-1929 > URL: https://issues.apache.org/jira/browse/KNOX-1929 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > When HIVESERVER2 is deployed as HIVE_ON_TEZ, the CM discovery implementation > does not correctly identify it, and thusly fails to generate a valid URL for > Knox to proxy. > It looks like the implementation should consider only role type (i.e., > HIVESERVER2), rather than the service type (i.e., HIVE, HIVE_ON_TEZ) to > determine if it should "handle" the config. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (KNOX-1931) CM discovery - WEBHBASE URLs not discovered
[ https://issues.apache.org/jira/browse/KNOX-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino updated KNOX-1931: --- Description: This may be because the required REST server role (HBASERESTSERVER role type) hasn't been configured, but this needs to be confirmed. (was: This may be because the required REST server component hasn't been configured, but this needs to be confirmed.) > CM discovery - WEBHBASE URLs not discovered > --- > > Key: KNOX-1931 > URL: https://issues.apache.org/jira/browse/KNOX-1931 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > This may be because the required REST server role (HBASERESTSERVER role type) > hasn't been configured, but this needs to be confirmed. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (KNOX-1931) CM discovery - WEBHBASE URLs not discovered
[ https://issues.apache.org/jira/browse/KNOX-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino updated KNOX-1931: --- Description: This may be because the required REST server component hasn't been configured, but this needs to be confirmed. > CM discovery - WEBHBASE URLs not discovered > --- > > Key: KNOX-1931 > URL: https://issues.apache.org/jira/browse/KNOX-1931 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > This may be because the required REST server component hasn't been > configured, but this needs to be confirmed. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (KNOX-1932) CM discovery - WEBHCAT URLs not discovered
[ https://issues.apache.org/jira/browse/KNOX-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino reassigned KNOX-1932: -- Assignee: Phil Zampino Affects Version/s: 1.3.0 Fix Version/s: 1.4.0 Component/s: cm-discovery > CM discovery - WEBHCAT URLs not discovered > -- > > Key: KNOX-1932 > URL: https://issues.apache.org/jira/browse/KNOX-1932 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (KNOX-1932) CM discovery - WEBHCAT URLs not discovered
Phil Zampino created KNOX-1932: -- Summary: CM discovery - WEBHCAT URLs not discovered Key: KNOX-1932 URL: https://issues.apache.org/jira/browse/KNOX-1932 Project: Apache Knox Issue Type: Sub-task Reporter: Phil Zampino -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (KNOX-1931) CM discovery - WEBHBASE URLs not discovered
Phil Zampino created KNOX-1931: -- Summary: CM discovery - WEBHBASE URLs not discovered Key: KNOX-1931 URL: https://issues.apache.org/jira/browse/KNOX-1931 Project: Apache Knox Issue Type: Sub-task Components: cm-discovery Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.4.0 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (KNOX-1930) CM discovery - JOBTRACKER URLs not discovered
Phil Zampino created KNOX-1930: -- Summary: CM discovery - JOBTRACKER URLs not discovered Key: KNOX-1930 URL: https://issues.apache.org/jira/browse/KNOX-1930 Project: Apache Knox Issue Type: Sub-task Components: cm-discovery Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.4.0 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KNOX-1928) CM discovery - Multiple of same url are added to descriptor?
[ https://issues.apache.org/jira/browse/KNOX-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887316#comment-16887316 ] Phil Zampino commented on KNOX-1928: RANGER and ATLAS-API behave similarly. > CM discovery - Multiple of same url are added to descriptor? > > > Key: KNOX-1928 > URL: https://issues.apache.org/jira/browse/KNOX-1928 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Kevin Risden >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > In the generated topology, sometimes there are multiple of the same exact > url. SOLR exhibited this behavior but there looked to be others. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (KNOX-1929) HIVE URLs not discovered when HIVE_ON_TEZ is deployed
[ https://issues.apache.org/jira/browse/KNOX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino reassigned KNOX-1929: -- Assignee: Phil Zampino > HIVE URLs not discovered when HIVE_ON_TEZ is deployed > - > > Key: KNOX-1929 > URL: https://issues.apache.org/jira/browse/KNOX-1929 > Project: Apache Knox > Issue Type: Sub-task > Components: cm-discovery >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > When HIVESERVER2 is deployed as HIVE_ON_TEZ, the CM discovery implementation > does not correctly identify it, and thusly fails to generate a valid URL for > Knox to proxy. > It looks like the implementation should consider only role type (i.e., > HIVESERVER2), rather than the service type (i.e., HIVE, HIVE_ON_TEZ) to > determine if it should "handle" the config. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (KNOX-1929) HIVE URLs not discovered when HIVE_ON_TEZ is deployed
Phil Zampino created KNOX-1929: -- Summary: HIVE URLs not discovered when HIVE_ON_TEZ is deployed Key: KNOX-1929 URL: https://issues.apache.org/jira/browse/KNOX-1929 Project: Apache Knox Issue Type: Sub-task Components: cm-discovery Affects Versions: 1.3.0 Reporter: Phil Zampino Fix For: 1.4.0 When HIVESERVER2 is deployed as HIVE_ON_TEZ, the CM discovery implementation does not correctly identify it, and thusly fails to generate a valid URL for Knox to proxy. It looks like the implementation should consider only role type (i.e., HIVESERVER2), rather than the service type (i.e., HIVE, HIVE_ON_TEZ) to determine if it should "handle" the config. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KNOX-1875) Cloudera Manager service discovery
[ https://issues.apache.org/jira/browse/KNOX-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883279#comment-16883279 ] Phil Zampino commented on KNOX-1875: [~jgauthier] Please file an issue for that request. If the configuration exists, such that the scheme can be determined dynamically, then it can surely be done. > Cloudera Manager service discovery > -- > > Key: KNOX-1875 > URL: https://issues.apache.org/jira/browse/KNOX-1875 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > Attachments: KNOX-1875.patch > > > Knox should support the ability to discover topology details from Cloudera > Manager, as it already does for Ambari. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (KNOX-1914) Dynamic population of Admin UI service discovery type options
[ https://issues.apache.org/jira/browse/KNOX-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino updated KNOX-1914: --- Description: The Discovery Details section of the Admin UI for working with descriptors includes a drop-down list of supported discovery providers (e.g., Ambari, ClouderaManager). Currently, this list is statically defined in the Admin UI. It should be possible to expose an API from the Knox host for determining the list of supported discovery providers. This API could leverage the same Java service loader mechanism that is used by the discovery runtime to load discovery providers. This would be nice for two closely-related reasons: # Subsequent additional discovery providers implemented in the Knox project itself won't require further Admin UI changes. # User/Customer discovery provider extensions would get Admin UI support automatically. was: The Discovery Details section of the Admin UI for working with descriptors includes a drop-down list of supported discovery providers (e.g., Ambari, ClouderaManager). Currently, this list is statically defined in the Admin UI. It should be possible to expose an API from the Knox host for determining the list of supported discovery providers. This API could leverage the same Java service loader mechanism that is used by the discovery runtime to load discovery providers. This would be nice for two reasons: # Subsequent additional discovery providers implemented in Knox won't require further Admin UI changes. # User/Customer discovery provider extensions would get Admin UI support automatically. > Dynamic population of Admin UI service discovery type options > - > > Key: KNOX-1914 > URL: https://issues.apache.org/jira/browse/KNOX-1914 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Priority: Major > Fix For: 1.4.0 > > > The Discovery Details section of the Admin UI for working with descriptors > includes a drop-down list of supported discovery providers (e.g., Ambari, > ClouderaManager). Currently, this list is statically defined in the Admin UI. > It should be possible to expose an API from the Knox host for determining the > list of supported discovery providers. > This API could leverage the same Java service loader mechanism that is used > by the discovery runtime to load discovery providers. > This would be nice for two closely-related reasons: > # Subsequent additional discovery providers implemented in the Knox project > itself won't require further Admin UI changes. > # User/Customer discovery provider extensions would get Admin UI support > automatically. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1914) Dynamic population of Admin UI service discovery type options
Phil Zampino created KNOX-1914: -- Summary: Dynamic population of Admin UI service discovery type options Key: KNOX-1914 URL: https://issues.apache.org/jira/browse/KNOX-1914 Project: Apache Knox Issue Type: Bug Components: AdminUI Affects Versions: 1.3.0 Reporter: Phil Zampino Fix For: 1.4.0 The Discovery Details section of the Admin UI for working with descriptors includes a drop-down list of supported discovery providers (e.g., Ambari, ClouderaManager). Currently, this list is statically defined in the Admin UI. It should be possible to expose an API from the Knox host for determining the list of supported discovery providers. This API could leverage the same Java service loader mechanism that is used by the discovery runtime to load discovery providers. This would be nice for two reasons: # Subsequent additional discovery providers implemented in Knox won't require further Admin UI changes. # User/Customer discovery provider extensions would get Admin UI support automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1911) Support ClouderaManager Service Discovery in Admin UI
[ https://issues.apache.org/jira/browse/KNOX-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1911. Resolution: Fixed Assignee: Phil Zampino Fix Version/s: 1.3.0 > Support ClouderaManager Service Discovery in Admin UI > - > > Key: KNOX-1911 > URL: https://issues.apache.org/jira/browse/KNOX-1911 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > The Discovery Details part of the descriptor authoring / editing facilities > in the Admin UI assume Ambari-based discovery. As such, there is currently no > way to specify the discovery type. > The Discovery Details UI should include a drop-down based on the available > supported discovery implementations. Ideally, this will be dynamically > populated (via the service loader facility, or an API that depends on it?), > rather than a static list. > It also should be possible to exclude any discovery configuration from the > associated descriptor. > A _no discovery_ option should be included in the drop-down list of > discovery types. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KNOX-1911) Support ClouderaManager Service Discovery in Admin UI
[ https://issues.apache.org/jira/browse/KNOX-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino updated KNOX-1911: --- Summary: Support ClouderaManager Service Discovery in Admin UI (was: Support ClouderManager Service Discovery in Admin UI) > Support ClouderaManager Service Discovery in Admin UI > - > > Key: KNOX-1911 > URL: https://issues.apache.org/jira/browse/KNOX-1911 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Priority: Major > > The Discovery Details part of the descriptor authoring / editing facilities > in the Admin UI assume Ambari-based discovery. As such, there is currently no > way to specify the discovery type. > The Discovery Details UI should include a drop-down based on the available > supported discovery implementations. Ideally, this will be dynamically > populated (via the service loader facility, or an API that depends on it?), > rather than a static list. > It also should be possible to exclude any discovery configuration from the > associated descriptor. > A _no discovery_ option should be included in the drop-down list of > discovery types. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KNOX-1911) Support ClouderManager Service Discovery in Admin UI
[ https://issues.apache.org/jira/browse/KNOX-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino updated KNOX-1911: --- Description: The Discovery Details part of the descriptor authoring / editing facilities in the Admin UI assume Ambari-based discovery. As such, there is currently no way to specify the discovery type. The Discovery Details UI should include a drop-down based on the available supported discovery implementations. Ideally, this will be dynamically populated (via the service loader facility, or an API that depends on it?), rather than a static list. It also should be possible to exclude any discovery configuration from the associated descriptor. A _no discovery_ option should be included in the drop-down list of discovery types. was: The Discovery Details part of the descriptor authoring / editing facilities in the Admin UI assume Ambari-based discovery. As such, there is currently no way to specify the discovery type. The Discovery Details UI should include a drop-down based on the available supported discovery implementations. It also should be possible to exclude any discovery configuration from the associated descriptor. A _no discovery_ option should be included in the drop-down list of discovery types. > Support ClouderManager Service Discovery in Admin UI > > > Key: KNOX-1911 > URL: https://issues.apache.org/jira/browse/KNOX-1911 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Priority: Major > > The Discovery Details part of the descriptor authoring / editing facilities > in the Admin UI assume Ambari-based discovery. As such, there is currently no > way to specify the discovery type. > The Discovery Details UI should include a drop-down based on the available > supported discovery implementations. Ideally, this will be dynamically > populated (via the service loader facility, or an API that depends on it?), > rather than a static list. > It also should be possible to exclude any discovery configuration from the > associated descriptor. > A _no discovery_ option should be included in the drop-down list of > discovery types. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1911) Support ClouderManager Service Discovery in Admin UI
Phil Zampino created KNOX-1911: -- Summary: Support ClouderManager Service Discovery in Admin UI Key: KNOX-1911 URL: https://issues.apache.org/jira/browse/KNOX-1911 Project: Apache Knox Issue Type: Bug Components: AdminUI Affects Versions: 1.3.0 Reporter: Phil Zampino The Discovery Details part of the descriptor authoring / editing facilities in the Admin UI assume Ambari-based discovery. As such, there is currently no way to specify the discovery type. The Discovery Details UI should include a drop-down based on the available supported discovery implementations. It also should be possible to exclude any discovery configuration from the associated descriptor. A _no discovery_ option should be included in the drop-down list of discovery types. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1880) Support doAs for Cloudera Manager service discovery API interactions
[ https://issues.apache.org/jira/browse/KNOX-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1880. Resolution: Fixed > Support doAs for Cloudera Manager service discovery API interactions > > > Key: KNOX-1880 > URL: https://issues.apache.org/jira/browse/KNOX-1880 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > When Knox is configured as a trusted proxy for Cloudera Manager, the Cloudera > Manager service discovery implementation should employ the doAs option for > the CM API interactions, where the doAs user is the CM user configured as the > _discovery-user_ in the descriptor for which discovery is being performed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1880) Support doAs for Cloudera Manager service discovery API interactions
[ https://issues.apache.org/jira/browse/KNOX-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1880 started by Phil Zampino. -- > Support doAs for Cloudera Manager service discovery API interactions > > > Key: KNOX-1880 > URL: https://issues.apache.org/jira/browse/KNOX-1880 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > When Knox is configured as a trusted proxy for Cloudera Manager, the Cloudera > Manager service discovery implementation should employ the doAs option for > the CM API interactions, where the doAs user is the CM user configured as the > _discovery-user_ in the descriptor for which discovery is being performed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1880) Support doAs for Cloudera Manager service discovery API interactions
Phil Zampino created KNOX-1880: -- Summary: Support doAs for Cloudera Manager service discovery API interactions Key: KNOX-1880 URL: https://issues.apache.org/jira/browse/KNOX-1880 Project: Apache Knox Issue Type: Bug Components: Server Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.3.0 When Knox is configured as a trusted proxy for Cloudera Manager, the Cloudera Manager service discovery implementation should employ the doAs option for the CM API interactions, where the doAs user is the CM user configured as the _discovery-user_ in the descriptor for which discovery is being performed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KNOX-1875) Cloudera Manager service discovery
[ https://issues.apache.org/jira/browse/KNOX-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866881#comment-16866881 ] Phil Zampino commented on KNOX-1875: I've added the necessary repo to the pom for the new module, and the build should be fixed now. > Cloudera Manager service discovery > -- > > Key: KNOX-1875 > URL: https://issues.apache.org/jira/browse/KNOX-1875 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > Attachments: KNOX-1875.patch > > > Knox should support the ability to discover topology details from Cloudera > Manager, as it already does for Ambari. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KNOX-1875) Cloudera Manager service discovery
[ https://issues.apache.org/jira/browse/KNOX-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino updated KNOX-1875: --- Attachment: KNOX-1875.patch > Cloudera Manager service discovery > -- > > Key: KNOX-1875 > URL: https://issues.apache.org/jira/browse/KNOX-1875 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > Attachments: KNOX-1875.patch > > > Knox should support the ability to discover topology details from Cloudera > Manager, as it already does for Ambari. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1875) Cloudera Manager service discovery
[ https://issues.apache.org/jira/browse/KNOX-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1875 started by Phil Zampino. -- > Cloudera Manager service discovery > -- > > Key: KNOX-1875 > URL: https://issues.apache.org/jira/browse/KNOX-1875 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > Knox should support the ability to discover topology details from Cloudera > Manager, as it already does for Ambari. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1875) Cloudera Manager service discovery
Phil Zampino created KNOX-1875: -- Summary: Cloudera Manager service discovery Key: KNOX-1875 URL: https://issues.apache.org/jira/browse/KNOX-1875 Project: Apache Knox Issue Type: Bug Components: Server Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.3.0 Knox should support the ability to discover topology details from Cloudera Manager, as it already does for Ambari. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1861) KnoxSession should support configurable useSubjectCredsOnly system property setting
[ https://issues.apache.org/jira/browse/KNOX-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1861. Resolution: Fixed > KnoxSession should support configurable useSubjectCredsOnly system property > setting > --- > > Key: KNOX-1861 > URL: https://issues.apache.org/jira/browse/KNOX-1861 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > KnoxSession#createClient(ClientContext) always sets the > javax.security.auth.useSubjectCredsOnly system property to false. The > ClientContext should offer the ability to specify this value, and default to > false if not explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1861) KnoxSession should support configurable useSubjectCredsOnly system property setting
[ https://issues.apache.org/jira/browse/KNOX-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1861 started by Phil Zampino. -- > KnoxSession should support configurable useSubjectCredsOnly system property > setting > --- > > Key: KNOX-1861 > URL: https://issues.apache.org/jira/browse/KNOX-1861 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > KnoxSession#createClient(ClientContext) always sets the > javax.security.auth.useSubjectCredsOnly system property to false. The > ClientContext should offer the ability to specify this value, and default to > false if not explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1861) KnoxSession should support configurable useSubjectCredsOnly system property setting
Phil Zampino created KNOX-1861: -- Summary: KnoxSession should support configurable useSubjectCredsOnly system property setting Key: KNOX-1861 URL: https://issues.apache.org/jira/browse/KNOX-1861 Project: Apache Knox Issue Type: Bug Components: KnoxShell Affects Versions: 1.2.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.3.0 KnoxSession#createClient(ClientContext) always sets the javax.security.auth.useSubjectCredsOnly system property to false. The ClientContext should offer the ability to specify this value, and default to false if not explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1860) Need redirect to login when SSO cookie expires
Phil Zampino created KNOX-1860: -- Summary: Need redirect to login when SSO cookie expires Key: KNOX-1860 URL: https://issues.apache.org/jira/browse/KNOX-1860 Project: Apache Knox Issue Type: Bug Components: AdminUI Affects Versions: 1.2.0 Reporter: Phil Zampino Fix For: 1.3.0 When Knox SSO is in play, the Admin UI can become unusable when the SSO cookie expires. All of the underlying API calls fail, and content is not displayed; the behavior is confusing to users who really need to know that they need to login again. Reloading the app/page is the simple work-around if the user understands what is happening, but it will be better if the app itself could recognize this state, and redirect the user to the login screen. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-840) Admin UI add ability to create a new topology based on a template
[ https://issues.apache.org/jira/browse/KNOX-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-840. --- Resolution: Fixed IMO, this issue has essentially been resolved with the addition of descriptor and provider configuration authoring functionality added to the Admin UI. > Admin UI add ability to create a new topology based on a template > - > > Key: KNOX-840 > URL: https://issues.apache.org/jira/browse/KNOX-840 > Project: Apache Knox > Issue Type: Improvement > Components: AdminUI >Reporter: Sumit Gupta >Assignee: Sumit Gupta >Priority: Major > > Admin user should be able to use the Admin UI to create new topologies based > on one of the template files that we ship with Knox. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1854) Admin UI read-only topology message typo
[ https://issues.apache.org/jira/browse/KNOX-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1854. Resolution: Fixed > Admin UI read-only topology message typo > > > Key: KNOX-1854 > URL: https://issues.apache.org/jira/browse/KNOX-1854 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > The header for read-only topologies reads "Read*y* Only", rather than "Read > Only" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1854) Admin UI read-only topology message typo
[ https://issues.apache.org/jira/browse/KNOX-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1854 started by Phil Zampino. -- > Admin UI read-only topology message typo > > > Key: KNOX-1854 > URL: https://issues.apache.org/jira/browse/KNOX-1854 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > The header for read-only topologies reads "Read*y* Only", rather than "Read > Only" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1854) Admin UI read-only topology message typo
Phil Zampino created KNOX-1854: -- Summary: Admin UI read-only topology message typo Key: KNOX-1854 URL: https://issues.apache.org/jira/browse/KNOX-1854 Project: Apache Knox Issue Type: Bug Components: AdminUI Affects Versions: 1.2.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.3.0 The header for read-only topologies reads "Read*y* Only", rather than "Read Only" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (KNOX-1851) NPE on startup when Zookeeper Remote Alias Service is configured
[
https://issues.apache.org/jira/browse/KNOX-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814471#comment-16814471
]
Phil Zampino edited comment on KNOX-1851 at 4/10/19 2:07 PM:
-
[~krisden] I believe the service is init'd in gateway services, no?
https://github.com/apache/knox/blob/master/gateway-server/src/main/java/org/apache/knox/gateway/services/DefaultGatewayServices.java#L80
was (Author: pzampino):
[~krisden] I believe the service is init'd in gateway services, no?
> NPE on startup when Zookeeper Remote Alias Service is configured
>
>
> Key: KNOX-1851
> URL: https://issues.apache.org/jira/browse/KNOX-1851
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.3.0
>Reporter: Sandeep More
>Priority: Major
> Fix For: 1.3.0
>
>
> When ZK remote alias service is configured Knox fails to start with the
> following NPE
> {code:java}
> 2019-04-09 16:34:47,894 FATAL knox.gateway (GatewayServer.java:main(177)) -
> Failed to start gateway: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.knox.gateway.services.security.impl.ZookeeperRemoteAliasService.ensureEntry(ZookeeperRemoteAliasService.java:120)
> at
> org.apache.knox.gateway.services.security.impl.ZookeeperRemoteAliasService.ensureEntries(ZookeeperRemoteAliasService.java:408)
> at
> org.apache.knox.gateway.services.security.impl.ZookeeperRemoteAliasService.init(ZookeeperRemoteAliasService.java:326)
> at
> org.apache.knox.gateway.services.security.impl.RemoteAliasService.init(RemoteAliasService.java:260)
> at
> org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:91)
> at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:168)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KNOX-1851) NPE on startup when Zookeeper Remote Alias Service is configured
[
https://issues.apache.org/jira/browse/KNOX-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814471#comment-16814471
]
Phil Zampino commented on KNOX-1851:
[~krisden] I believe the service is init'd in gateway services, no?
> NPE on startup when Zookeeper Remote Alias Service is configured
>
>
> Key: KNOX-1851
> URL: https://issues.apache.org/jira/browse/KNOX-1851
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.3.0
>Reporter: Sandeep More
>Priority: Major
> Fix For: 1.3.0
>
>
> When ZK remote alias service is configured Knox fails to start with the
> following NPE
> {code:java}
> 2019-04-09 16:34:47,894 FATAL knox.gateway (GatewayServer.java:main(177)) -
> Failed to start gateway: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.knox.gateway.services.security.impl.ZookeeperRemoteAliasService.ensureEntry(ZookeeperRemoteAliasService.java:120)
> at
> org.apache.knox.gateway.services.security.impl.ZookeeperRemoteAliasService.ensureEntries(ZookeeperRemoteAliasService.java:408)
> at
> org.apache.knox.gateway.services.security.impl.ZookeeperRemoteAliasService.init(ZookeeperRemoteAliasService.java:326)
> at
> org.apache.knox.gateway.services.security.impl.RemoteAliasService.init(RemoteAliasService.java:260)
> at
> org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:91)
> at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:168)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (KNOX-1850) KnoxSession should honor the current subject for Kerberos login
[ https://issues.apache.org/jira/browse/KNOX-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1850. Resolution: Fixed > KnoxSession should honor the current subject for Kerberos login > --- > > Key: KNOX-1850 > URL: https://issues.apache.org/jira/browse/KNOX-1850 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > Currently, for Kerberos logins, KnoxSession requires some kind of JAAS > config. It should also honor the current Subject, supporting doAs() > invocations from already-authenticated subjects. > I'm proposing that the current Subject be used if it exists, and fall back to > a JAAS configuration otherwise. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KNOX-1850) KnoxSession should honor the current subject for Kerberos login
[ https://issues.apache.org/jira/browse/KNOX-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino updated KNOX-1850: --- Description: Currently, for Kerberos logins, KnoxSession requires some kind of JAAS config. It should also honor the current Subject, supporting doAs() invocations from already-authenticated subjects. I'm proposing that the current Subject be used if it exists, and fall back to a JAAS configuration otherwise. was:Currently, for Kerberos logins, KnoxSession requires some kind of JAAS config. It should also honor the current Subject, supporting doAs() invocations from already-authenticated subjects. > KnoxSession should honor the current subject for Kerberos login > --- > > Key: KNOX-1850 > URL: https://issues.apache.org/jira/browse/KNOX-1850 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > Currently, for Kerberos logins, KnoxSession requires some kind of JAAS > config. It should also honor the current Subject, supporting doAs() > invocations from already-authenticated subjects. > I'm proposing that the current Subject be used if it exists, and fall back to > a JAAS configuration otherwise. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1850) KnoxSession should honor the current subject for Kerberos login
[ https://issues.apache.org/jira/browse/KNOX-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1850 started by Phil Zampino. -- > KnoxSession should honor the current subject for Kerberos login > --- > > Key: KNOX-1850 > URL: https://issues.apache.org/jira/browse/KNOX-1850 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > Currently, for Kerberos logins, KnoxSession requires some kind of JAAS > config. It should also honor the current Subject, supporting doAs() > invocations from already-authenticated subjects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1850) KnoxSession should honor the current subject for Kerberos login
Phil Zampino created KNOX-1850: -- Summary: KnoxSession should honor the current subject for Kerberos login Key: KNOX-1850 URL: https://issues.apache.org/jira/browse/KNOX-1850 Project: Apache Knox Issue Type: Bug Components: KnoxShell Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.3.0 Currently, for Kerberos logins, KnoxSession requires some kind of JAAS config. It should also honor the current Subject, supporting doAs() invocations from already-authenticated subjects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1832) KnoxSession handling of JAAS config for kerberos auth is not deterministic
[ https://issues.apache.org/jira/browse/KNOX-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1832. Resolution: Fixed > KnoxSession handling of JAAS config for kerberos auth is not deterministic > -- > > Key: KNOX-1832 > URL: https://issues.apache.org/jira/browse/KNOX-1832 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.3.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > The KnoxShell kerberos authentication support depends on the default facility > for locating the JAAS Configuration to apply, defaulting to the jaas.conf > file packaged in its own JAR. In some cases, an alternative JAAS conf has > been set (overriding the internal one), which likely does not have the > expected entry (i.e., "com.sun.security.jgss.initiate"). > Instead, a Configuration instance based explicitly on this internal jaas.conf > file can be created and employed, making the behavior much more deterministic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1832) KnoxSession handling of JAAS config for kerberos auth is not deterministic
Phil Zampino created KNOX-1832: -- Summary: KnoxSession handling of JAAS config for kerberos auth is not deterministic Key: KNOX-1832 URL: https://issues.apache.org/jira/browse/KNOX-1832 Project: Apache Knox Issue Type: Bug Components: KnoxShell Affects Versions: 1.3.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.3.0 The KnoxShell kerberos authentication support depends on the default facility for locating the JAAS Configuration to apply, defaulting to the jaas.conf file packaged in its own JAR. In some cases, an alternative JAAS conf has been set (overriding the internal one), which likely does not have the expected entry (i.e., "com.sun.security.jgss.initiate"). Instead, a Configuration instance based explicitly on this internal jaas.conf file can be created and employed, making the behavior much more deterministic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1788) Add HTTP X-XSS-Protection to WebAppSec provider config wizard
Phil Zampino created KNOX-1788: -- Summary: Add HTTP X-XSS-Protection to WebAppSec provider config wizard Key: KNOX-1788 URL: https://issues.apache.org/jira/browse/KNOX-1788 Project: Apache Knox Issue Type: Bug Components: AdminUI Affects Versions: 1.3.0 Reporter: Phil Zampino Fix For: 1.3.0 KNOX-1779 adds support for the HTTP X-XSS-Protection response header via the WebAppSec provider. The Admin UI wizard for the same should include this option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1750) Unable to view descriptor service params
Phil Zampino created KNOX-1750: -- Summary: Unable to view descriptor service params Key: KNOX-1750 URL: https://issues.apache.org/jira/browse/KNOX-1750 Project: Apache Knox Issue Type: Bug Components: AdminUI Affects Versions: 1.3.0 Reporter: Phil Zampino Fix For: 1.3.0 It is not possible to view descriptor service params in the Admin UI. The javascript console reveals the following error: ERROR TypeError: t.component.descriptor.getServiceParamNames is not a function -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work stopped] (KNOX-1737) Remote configuration monitor start should not be attempted if config is not defined
[ https://issues.apache.org/jira/browse/KNOX-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1737 stopped by Phil Zampino. -- > Remote configuration monitor start should not be attempted if config is not > defined > --- > > Key: KNOX-1737 > URL: https://issues.apache.org/jira/browse/KNOX-1737 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > Currently, if the configured remote configuration monitor can't access the > necessary config, an attempt is still made to start it, which results in a > confusing warning message. Instead, starting the monitor should not be > attempted unless the necessary config is defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1737) Remote configuration monitor start should not be attempted if config is not defined
[ https://issues.apache.org/jira/browse/KNOX-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1737. Resolution: Fixed > Remote configuration monitor start should not be attempted if config is not > defined > --- > > Key: KNOX-1737 > URL: https://issues.apache.org/jira/browse/KNOX-1737 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > Currently, if the configured remote configuration monitor can't access the > necessary config, an attempt is still made to start it, which results in a > confusing warning message. Instead, starting the monitor should not be > attempted unless the necessary config is defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1737) Remote configuration monitor start should not be attempted if config is not defined
[ https://issues.apache.org/jira/browse/KNOX-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1737 started by Phil Zampino. -- > Remote configuration monitor start should not be attempted if config is not > defined > --- > > Key: KNOX-1737 > URL: https://issues.apache.org/jira/browse/KNOX-1737 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > Currently, if the configured remote configuration monitor can't access the > necessary config, an attempt is still made to start it, which results in a > confusing warning message. Instead, starting the monitor should not be > attempted unless the necessary config is defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1737) Remote configuration monitor start should not be attempted if config is not defined
Phil Zampino created KNOX-1737: -- Summary: Remote configuration monitor start should not be attempted if config is not defined Key: KNOX-1737 URL: https://issues.apache.org/jira/browse/KNOX-1737 Project: Apache Knox Issue Type: Bug Components: Server Affects Versions: 1.2.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.3.0 Currently, if the configured remote configuration monitor can't access the necessary config, an attempt is still made to start it, which results in a confusing warning message. Instead, starting the monitor should not be attempted unless the necessary config is defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1680) KnoxTokenCredentialCollector results in IndexOutOfBounds exception
[ https://issues.apache.org/jira/browse/KNOX-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1680 started by Phil Zampino. -- > KnoxTokenCredentialCollector results in IndexOutOfBounds exception > -- > > Key: KNOX-1680 > URL: https://issues.apache.org/jira/browse/KNOX-1680 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > KnoxTokenCredentialCollector collect() can result in an > IndexOutOfBoundsException if the token cache exists, but is empty because it > assumes that it's non-empty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1680) KnoxTokenCredentialCollector results in IndexOutOfBounds exception
[ https://issues.apache.org/jira/browse/KNOX-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1680. Resolution: Fixed > KnoxTokenCredentialCollector results in IndexOutOfBounds exception > -- > > Key: KNOX-1680 > URL: https://issues.apache.org/jira/browse/KNOX-1680 > Project: Apache Knox > Issue Type: Bug > Components: KnoxShell >Affects Versions: 1.2.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.3.0 > > > KnoxTokenCredentialCollector collect() can result in an > IndexOutOfBoundsException if the token cache exists, but is empty because it > assumes that it's non-empty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1680) KnoxTokenCredentialCollector results in IndexOutOfBounds exception
Phil Zampino created KNOX-1680: -- Summary: KnoxTokenCredentialCollector results in IndexOutOfBounds exception Key: KNOX-1680 URL: https://issues.apache.org/jira/browse/KNOX-1680 Project: Apache Knox Issue Type: Bug Components: KnoxShell Affects Versions: 1.2.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.3.0 KnoxTokenCredentialCollector collect() can result in an IndexOutOfBoundsException if the token cache exists, but is empty because it assumes that it's non-empty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KNOX-1670) ZK Tests IllegalArgument and IllegalState errors
[
https://issues.apache.org/jira/browse/KNOX-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16717934#comment-16717934
]
Phil Zampino commented on KNOX-1670:
What's the original IllegalArgument error?
> ZK Tests IllegalArgument and IllegalState errors
>
>
> Key: KNOX-1670
> URL: https://issues.apache.org/jira/browse/KNOX-1670
> Project: Apache Knox
> Issue Type: Test
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 1.3.0
>
>
> I've seen the following failure a few times and not entirely sure what causes
> it. Would be good to track down. I think it can happen in most of the ZK
> related tests.
> {code:java}
> [ERROR] Errors:
> [ERROR]
> org.apache.knox.gateway.topology.monitor.RemoteConfigurationMonitorTest.testZooKeeperConfigMonitorSASLNodesExistWithAcceptableACL(org.apache.knox.gateway.topology.monitor.RemoteConfigurationMonitorTest)
> [ERROR] Run 1:
> RemoteConfigurationMonitorTest.setupTest:111->configureAndStartZKCluster:168
> » IllegalArgument
> [ERROR] Run 2: RemoteConfigurationMonitorTest.tearDownTest:118 »
> IllegalState instance must b...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (KNOX-1577) Knox automatically derived dispatch whitelist doesn't seem to actually match the knox domain
[
https://issues.apache.org/jira/browse/KNOX-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Zampino updated KNOX-1577:
---
Attachment: KNOX-1577.patch
> Knox automatically derived dispatch whitelist doesn't seem to actually match
> the knox domain
>
>
> Key: KNOX-1577
> URL: https://issues.apache.org/jira/browse/KNOX-1577
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.0
>Reporter: Kat Petre
>Assignee: Vipin Rathor
>Priority: Critical
> Fix For: 1.2.0
>
> Attachments: CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png, KNOX-1577.patch
>
>
> When the dispatch whitelist is not explicitly configured, Knox attempts to
> derive this whitelist based on the domain of the knox host. We can see this
> in the logs as follows:
> {code:java}
> 2018-11-08 20:57:34,173 INFO knox.gateway
> (WhitelistUtils.java:getDispatchWhitelist(63)) - Applying a derived dispatch
> whitelist because none is configured in gateway-site:
> ^/.*$;^https?://(.+\.honeypot\.hortonworks\.site):[0-9]+/?.*$
> {code}
> However, login via knox sso with this configuration is not possible. Upon
> closer inspection (with a regex editor) we see there are 4 unescaped forward
> slashes which cause the knox hostname (or hostname of another host on the
> same domain as knox) to not match the auto-configured whitelist.
> !CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png!
> (Thanks [~vrathor-hw] helping find this)
> Escaping the forward slashes and explicitly configuring the whitelist with
> following example values seems to solve the problem, and allow login via knox
> sso.
> {code:java}
>
> knoxsso.redirect.whitelist.regex
>
> ^https?:\/\/(.*\.honeypot\.hortonworks\.site|localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*$
>
> {code}
> If escaping the / as I did above is the correct workaround for this solution,
> should we configure the automatically derived whitelists to do this also?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KNOX-1577) Knox automatically derived dispatch whitelist doesn't seem to actually match the knox domain
[
https://issues.apache.org/jira/browse/KNOX-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681848#comment-16681848
]
Phil Zampino commented on KNOX-1577:
I've attached a patch that includes a test. [~vrathor-hw], if it differs
greatly from yours, then let's discuss those differences.
> Knox automatically derived dispatch whitelist doesn't seem to actually match
> the knox domain
>
>
> Key: KNOX-1577
> URL: https://issues.apache.org/jira/browse/KNOX-1577
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.0
>Reporter: Kat Petre
>Assignee: Vipin Rathor
>Priority: Critical
> Fix For: 1.2.0
>
> Attachments: CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png, KNOX-1577.patch
>
>
> When the dispatch whitelist is not explicitly configured, Knox attempts to
> derive this whitelist based on the domain of the knox host. We can see this
> in the logs as follows:
> {code:java}
> 2018-11-08 20:57:34,173 INFO knox.gateway
> (WhitelistUtils.java:getDispatchWhitelist(63)) - Applying a derived dispatch
> whitelist because none is configured in gateway-site:
> ^/.*$;^https?://(.+\.honeypot\.hortonworks\.site):[0-9]+/?.*$
> {code}
> However, login via knox sso with this configuration is not possible. Upon
> closer inspection (with a regex editor) we see there are 4 unescaped forward
> slashes which cause the knox hostname (or hostname of another host on the
> same domain as knox) to not match the auto-configured whitelist.
> !CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png!
> (Thanks [~vrathor-hw] helping find this)
> Escaping the forward slashes and explicitly configuring the whitelist with
> following example values seems to solve the problem, and allow login via knox
> sso.
> {code:java}
>
> knoxsso.redirect.whitelist.regex
>
> ^https?:\/\/(.*\.honeypot\.hortonworks\.site|localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*$
>
> {code}
> If escaping the / as I did above is the correct workaround for this solution,
> should we configure the automatically derived whitelists to do this also?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (KNOX-1577) Knox automatically derived dispatch whitelist doesn't seem to actually match the knox domain
[
https://issues.apache.org/jira/browse/KNOX-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-1577 started by Phil Zampino.
--
> Knox automatically derived dispatch whitelist doesn't seem to actually match
> the knox domain
>
>
> Key: KNOX-1577
> URL: https://issues.apache.org/jira/browse/KNOX-1577
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.0
>Reporter: Kat Petre
>Assignee: Phil Zampino
>Priority: Critical
> Fix For: 1.2.0
>
> Attachments: CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png
>
>
> When the dispatch whitelist is not explicitly configured, Knox attempts to
> derive this whitelist based on the domain of the knox host. We can see this
> in the logs as follows:
> {code:java}
> 2018-11-08 20:57:34,173 INFO knox.gateway
> (WhitelistUtils.java:getDispatchWhitelist(63)) - Applying a derived dispatch
> whitelist because none is configured in gateway-site:
> ^/.*$;^https?://(.+\.honeypot\.hortonworks\.site):[0-9]+/?.*$
> {code}
> However, login via knox sso with this configuration is not possible. Upon
> closer inspection (with a regex editor) we see there are 4 unescaped forward
> slashes which cause the knox hostname (or hostname of another host on the
> same domain as knox) to not match the auto-configured whitelist.
> !CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png!
> (Thanks [~vrathor-hw] helping find this)
> Escaping the forward slashes and explicitly configuring the whitelist with
> following example values seems to solve the problem, and allow login via knox
> sso.
> {code:java}
>
> knoxsso.redirect.whitelist.regex
>
> ^https?:\/\/(.*\.honeypot\.hortonworks\.site|localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*$
>
> {code}
> If escaping the / as I did above is the correct workaround for this solution,
> should we configure the automatically derived whitelists to do this also?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KNOX-1577) Knox automatically derived dispatch whitelist doesn't seem to actually match the knox domain
[
https://issues.apache.org/jira/browse/KNOX-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681774#comment-16681774
]
Phil Zampino commented on KNOX-1577:
[~vrathor-hw] I can't seem to assign it to you, but if you share the patch,
I'll commit it, and give you credit.
> Knox automatically derived dispatch whitelist doesn't seem to actually match
> the knox domain
>
>
> Key: KNOX-1577
> URL: https://issues.apache.org/jira/browse/KNOX-1577
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.0
>Reporter: Kat Petre
>Priority: Critical
> Fix For: 1.2.0
>
> Attachments: CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png
>
>
> When the dispatch whitelist is not explicitly configured, Knox attempts to
> derive this whitelist based on the domain of the knox host. We can see this
> in the logs as follows:
> {code:java}
> 2018-11-08 20:57:34,173 INFO knox.gateway
> (WhitelistUtils.java:getDispatchWhitelist(63)) - Applying a derived dispatch
> whitelist because none is configured in gateway-site:
> ^/.*$;^https?://(.+\.honeypot\.hortonworks\.site):[0-9]+/?.*$
> {code}
> However, login via knox sso with this configuration is not possible. Upon
> closer inspection (with a regex editor) we see there are 4 unescaped forward
> slashes which cause the knox hostname (or hostname of another host on the
> same domain as knox) to not match the auto-configured whitelist.
> !CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png!
> (Thanks [~vrathor-hw] helping find this)
> Escaping the forward slashes and explicitly configuring the whitelist with
> following example values seems to solve the problem, and allow login via knox
> sso.
> {code:java}
>
> knoxsso.redirect.whitelist.regex
>
> ^https?:\/\/(.*\.honeypot\.hortonworks\.site|localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*$
>
> {code}
> If escaping the / as I did above is the correct workaround for this solution,
> should we configure the automatically derived whitelists to do this also?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (KNOX-1577) Knox automatically derived dispatch whitelist doesn't seem to actually match the knox domain
[
https://issues.apache.org/jira/browse/KNOX-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Zampino reassigned KNOX-1577:
--
Assignee: Phil Zampino
> Knox automatically derived dispatch whitelist doesn't seem to actually match
> the knox domain
>
>
> Key: KNOX-1577
> URL: https://issues.apache.org/jira/browse/KNOX-1577
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.0
>Reporter: Kat Petre
>Assignee: Phil Zampino
>Priority: Critical
> Fix For: 1.2.0
>
> Attachments: CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png
>
>
> When the dispatch whitelist is not explicitly configured, Knox attempts to
> derive this whitelist based on the domain of the knox host. We can see this
> in the logs as follows:
> {code:java}
> 2018-11-08 20:57:34,173 INFO knox.gateway
> (WhitelistUtils.java:getDispatchWhitelist(63)) - Applying a derived dispatch
> whitelist because none is configured in gateway-site:
> ^/.*$;^https?://(.+\.honeypot\.hortonworks\.site):[0-9]+/?.*$
> {code}
> However, login via knox sso with this configuration is not possible. Upon
> closer inspection (with a regex editor) we see there are 4 unescaped forward
> slashes which cause the knox hostname (or hostname of another host on the
> same domain as knox) to not match the auto-configured whitelist.
> !CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png!
> (Thanks [~vrathor-hw] helping find this)
> Escaping the forward slashes and explicitly configuring the whitelist with
> following example values seems to solve the problem, and allow login via knox
> sso.
> {code:java}
>
> knoxsso.redirect.whitelist.regex
>
> ^https?:\/\/(.*\.honeypot\.hortonworks\.site|localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*$
>
> {code}
> If escaping the / as I did above is the correct workaround for this solution,
> should we configure the automatically derived whitelists to do this also?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KNOX-1577) Knox automatically derived dispatch whitelist doesn't seem to actually match the knox domain
[
https://issues.apache.org/jira/browse/KNOX-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681509#comment-16681509
]
Phil Zampino commented on KNOX-1577:
[~thekat] if the derived whitelist is incorrect, then we should certainly fix
that.
> Knox automatically derived dispatch whitelist doesn't seem to actually match
> the knox domain
>
>
> Key: KNOX-1577
> URL: https://issues.apache.org/jira/browse/KNOX-1577
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.0
>Reporter: Kat Petre
>Priority: Critical
> Attachments: CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png
>
>
> When the dispatch whitelist is not explicitly configured, Knox attempts to
> derive this whitelist based on the domain of the knox host. We can see this
> in the logs as follows:
> {code:java}
> 2018-11-08 20:57:34,173 INFO knox.gateway
> (WhitelistUtils.java:getDispatchWhitelist(63)) - Applying a derived dispatch
> whitelist because none is configured in gateway-site:
> ^/.*$;^https?://(.+\.honeypot\.hortonworks\.site):[0-9]+/?.*$
> {code}
> However, login via knox sso with this configuration is not possible. Upon
> closer inspection (with a regex editor) we see there are 4 unescaped forward
> slashes which cause the knox hostname (or hostname of another host on the
> same domain as knox) to not match the auto-configured whitelist.
> !CDC05871-10A2-43CE-8190-E6AAC51AC3D9.png!
> (Thanks [~vrathor-hw] helping find this)
> Escaping the forward slashes and explicitly configuring the whitelist with
> following example values seems to solve the problem, and allow login via knox
> sso.
> {code:java}
>
> knoxsso.redirect.whitelist.regex
>
> ^https?:\/\/(.*\.honeypot\.hortonworks\.site|localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*$
>
> {code}
> If escaping the / as I did above is the correct workaround for this solution,
> should we configure the automatically derived whitelists to do this also?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (KNOX-1558) KnoxToken service returns wrong content type and content length values
[
https://issues.apache.org/jira/browse/KNOX-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Zampino resolved KNOX-1558.
Resolution: Fixed
> KnoxToken service returns wrong content type and content length values
> --
>
> Key: KNOX-1558
> URL: https://issues.apache.org/jira/browse/KNOX-1558
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.0
>Reporter: Phil Zampino
>Assignee: Phil Zampino
>Priority: Major
> Fix For: 1.2.0
>
>
> The TokenResource class mixes the use of the JAX-RS Response builder and an
> injected HttpServletResponse context object. These really can't be mixed.
> The entity content is written to the injected HttpServletResponse, but the
> JAX-RS Response object is returned separately. The result is that the entity
> gets to the client, but the content-related headers don't reflect that
> content because they're written by the Response object (which doesn't know
> anything about the content).
> Rather than using the injected HttpServletResponse object, TokenResource
> should use ONLY the JAX-RS facility for writing the response content.
> {code:java}
> //
> return Response.ok().entity(jsonResponse).build();
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (KNOX-1558) KnoxToken service returns wrong content type and content length values
[
https://issues.apache.org/jira/browse/KNOX-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KNOX-1558 started by Phil Zampino.
--
> KnoxToken service returns wrong content type and content length values
> --
>
> Key: KNOX-1558
> URL: https://issues.apache.org/jira/browse/KNOX-1558
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.0
>Reporter: Phil Zampino
>Assignee: Phil Zampino
>Priority: Major
> Fix For: 1.2.0
>
>
> The TokenResource class mixes the use of the JAX-RS Response builder and an
> injected HttpServletResponse context object. These really can't be mixed.
> The entity content is written to the injected HttpServletResponse, but the
> JAX-RS Response object is returned separately. The result is that the entity
> gets to the client, but the content-related headers don't reflect that
> content because they're written by the Response object (which doesn't know
> anything about the content).
> Rather than using the injected HttpServletResponse object, TokenResource
> should use ONLY the JAX-RS facility for writing the response content.
> {code:java}
> //
> return Response.ok().entity(jsonResponse).build();
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (KNOX-1558) KnoxToken service returns wrong content type and content length values
Phil Zampino created KNOX-1558:
--
Summary: KnoxToken service returns wrong content type and content
length values
Key: KNOX-1558
URL: https://issues.apache.org/jira/browse/KNOX-1558
Project: Apache Knox
Issue Type: Bug
Components: Server
Affects Versions: 1.1.0
Reporter: Phil Zampino
Assignee: Phil Zampino
Fix For: 1.2.0
The TokenResource class mixes the use of the JAX-RS Response builder and an
injected HttpServletResponse context object. These really can't be mixed.
The entity content is written to the injected HttpServletResponse, but the
JAX-RS Response object is returned separately. The result is that the entity
gets to the client, but the content-related headers don't reflect that content
because they're written by the Response object (which doesn't know anything
about the content).
Rather than using the injected HttpServletResponse object, TokenResource should
use ONLY the JAX-RS facility for writing the response content.
{code:java}
//
return Response.ok().entity(jsonResponse).build();
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (KNOX-1545) KnoxTokenCredentialCollector should expose the type of the collected token
[ https://issues.apache.org/jira/browse/KNOX-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1545. Resolution: Fixed > KnoxTokenCredentialCollector should expose the type of the collected token > -- > > Key: KNOX-1545 > URL: https://issues.apache.org/jira/browse/KNOX-1545 > Project: Apache Knox > Issue Type: Improvement > Components: KnoxShell >Affects Versions: 1.1.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.2.0 > > > Currently, the KnoxTokenCredentialCollector provides access to the > access_token and target_url attributes of the persisted token. It should also > provide access to the token_type attribute via a method named getTokenType(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1545) KnoxTokenCredentialCollector should expose the type of the collected token
Phil Zampino created KNOX-1545: -- Summary: KnoxTokenCredentialCollector should expose the type of the collected token Key: KNOX-1545 URL: https://issues.apache.org/jira/browse/KNOX-1545 Project: Apache Knox Issue Type: Improvement Components: KnoxShell Affects Versions: 1.1.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.2.0 Currently, the KnoxTokenCredentialCollector provides access to the access_token and target_url attributes of the persisted token. It should also provide access to the token_type attribute via a method named getTokenType(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1545) KnoxTokenCredentialCollector should expose the type of the collected token
[ https://issues.apache.org/jira/browse/KNOX-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1545 started by Phil Zampino. -- > KnoxTokenCredentialCollector should expose the type of the collected token > -- > > Key: KNOX-1545 > URL: https://issues.apache.org/jira/browse/KNOX-1545 > Project: Apache Knox > Issue Type: Improvement > Components: KnoxShell >Affects Versions: 1.1.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.2.0 > > > Currently, the KnoxTokenCredentialCollector provides access to the > access_token and target_url attributes of the persisted token. It should also > provide access to the token_type attribute via a method named getTokenType(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1544) KnoxTokenCredentialCollector should not call System.exit()
[ https://issues.apache.org/jira/browse/KNOX-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1544. Resolution: Fixed > KnoxTokenCredentialCollector should not call System.exit() > -- > > Key: KNOX-1544 > URL: https://issues.apache.org/jira/browse/KNOX-1544 > Project: Apache Knox > Issue Type: Improvement > Components: KnoxShell >Affects Versions: 1.1.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.2.0 > > > There are conditions that cause KnoxTokenCredentialCollector#collect() to > invoke System.exit(1). > Instead, it should throw a CredentialCollectionException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1544) KnoxTokenCredentialCollector should not call System.exit()
[ https://issues.apache.org/jira/browse/KNOX-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1544 started by Phil Zampino. -- > KnoxTokenCredentialCollector should not call System.exit() > -- > > Key: KNOX-1544 > URL: https://issues.apache.org/jira/browse/KNOX-1544 > Project: Apache Knox > Issue Type: Improvement > Components: KnoxShell >Affects Versions: 1.1.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.2.0 > > > There are conditions that cause KnoxTokenCredentialCollector#collect() to > invoke System.exit(1). > Instead, it should throw a CredentialCollectionException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1544) KnoxTokenCredentialCollector should not call System.exit()
Phil Zampino created KNOX-1544: -- Summary: KnoxTokenCredentialCollector should not call System.exit() Key: KNOX-1544 URL: https://issues.apache.org/jira/browse/KNOX-1544 Project: Apache Knox Issue Type: Improvement Components: KnoxShell Affects Versions: 1.1.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.2.0 There are conditions that cause KnoxTokenCredentialCollector#collect() to invoke System.exit(1). Instead, it should throw a CredentialCollectionException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KNOX-1535) Remove custom gzip helper stream - use commons-compress
[ https://issues.apache.org/jira/browse/KNOX-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660765#comment-16660765 ] Phil Zampino commented on KNOX-1535: [~risdenk] This looks like a good change to me, provided KNOX-1518 is still resolved thereby. > Remove custom gzip helper stream - use commons-compress > --- > > Key: KNOX-1535 > URL: https://issues.apache.org/jira/browse/KNOX-1535 > Project: Apache Knox > Issue Type: Sub-task >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > Fix For: 1.2.0 > > Attachments: KNOX-1535.patch, KNOX-1535.patch > > > commons-compress has a gzip input stream that handles the multiple > concatenated gzip files. We should use that instead of the workaround from > KNOX-1518 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (KNOX-400) Administrative user interface for Knox
[ https://issues.apache.org/jira/browse/KNOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658052#comment-16658052 ] Phil Zampino edited comment on KNOX-400 at 10/21/18 2:16 AM: - [~risdenk] I would say it's mostly done now. The Admin UI does *+not+* yet provide the ability to: * View logs * View gateway config * Modify gateway config * Restart the gateway IMO, we could close this one, and log new individual issues for each of these. was (Author: pzampino): [~risdenk] I would say it's mostly done now. The Admin UI does *+not+* yet provide the ability to: * View logs * View gateway config * Modify gateway config * Restart the gateway > Administrative user interface for Knox > -- > > Key: KNOX-400 > URL: https://issues.apache.org/jira/browse/KNOX-400 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Affects Versions: 0.4.0 >Reporter: Kevin Minder >Priority: Major > Fix For: Future > > > Initially only read only operations > Build information > Deployed topologies > Consider reading config? > Consider reading logs? > Eventually write operations > Deploy/Undeploy topologies > Modify Configuration > Restart server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KNOX-400) Administrative user interface for Knox
[ https://issues.apache.org/jira/browse/KNOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658052#comment-16658052 ] Phil Zampino commented on KNOX-400: --- [~risdenk] I would say it's mostly done now. The Admin UI does *+not+* yet provide the ability to: * View logs * View gateway config * Modify gateway config * Restart the gateway > Administrative user interface for Knox > -- > > Key: KNOX-400 > URL: https://issues.apache.org/jira/browse/KNOX-400 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Affects Versions: 0.4.0 >Reporter: Kevin Minder >Priority: Major > Fix For: Future > > > Initially only read only operations > Build information > Deployed topologies > Consider reading config? > Consider reading logs? > Eventually write operations > Deploy/Undeploy topologies > Modify Configuration > Restart server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KNOX-1518) Large HDFS file downloads are incomplete when content is gzipped
[ https://issues.apache.org/jira/browse/KNOX-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Zampino resolved KNOX-1518. Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=knox.git;a=commitdiff;h=bcb2e1f0196548d9cc54ca94e8fe79198ef61906 > Large HDFS file downloads are incomplete when content is gzipped > > > Key: KNOX-1518 > URL: https://issues.apache.org/jira/browse/KNOX-1518 > Project: Apache Knox > Issue Type: Improvement > Components: Server >Affects Versions: 1.1.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.2.0 > > > org.apache.knox.gateway.filter.rewrite.impl.UrlRewriteResponse employs > java.util.zip.GZIPInputStream for gzipped content streams. > There appears to be an expectation in the GZIPInputStream of the > InputStream#available() method, for which the behavior is varied across > InputStream implementations. InputStream implementations that do not satisfy > this expectation cause the GZIPInputStream to terminate prematurely, > resulting in only partial reads. > There is an OpenJDK bug ([https://bugs.openjdk.java.net/browse/JDK-8081450]) > for this, and the Oracle JDK suffers from the same. > This can be overcome in Knox with code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KNOX-1518) Large HDFS file downloads are incomplete when content is gzipped
Phil Zampino created KNOX-1518: -- Summary: Large HDFS file downloads are incomplete when content is gzipped Key: KNOX-1518 URL: https://issues.apache.org/jira/browse/KNOX-1518 Project: Apache Knox Issue Type: Improvement Components: Server Affects Versions: 1.1.0 Reporter: Phil Zampino Assignee: Phil Zampino Fix For: 1.2.0 org.apache.knox.gateway.filter.rewrite.impl.UrlRewriteResponse employs java.util.zip.GZIPInputStream for gzipped content streams. There appears to be an expectation in the GZIPInputStream of the InputStream#available() method, for which the behavior is varied across InputStream implementations. InputStream implementations that do not satisfy this expectation cause the GZIPInputStream to terminate prematurely, resulting in only partial reads. There is an OpenJDK bug ([https://bugs.openjdk.java.net/browse/JDK-8081450]) for this, and the Oracle JDK suffers from the same. This can be overcome in Knox with code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KNOX-1518) Large HDFS file downloads are incomplete when content is gzipped
[ https://issues.apache.org/jira/browse/KNOX-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KNOX-1518 started by Phil Zampino. -- > Large HDFS file downloads are incomplete when content is gzipped > > > Key: KNOX-1518 > URL: https://issues.apache.org/jira/browse/KNOX-1518 > Project: Apache Knox > Issue Type: Improvement > Components: Server >Affects Versions: 1.1.0 >Reporter: Phil Zampino >Assignee: Phil Zampino >Priority: Major > Fix For: 1.2.0 > > > org.apache.knox.gateway.filter.rewrite.impl.UrlRewriteResponse employs > java.util.zip.GZIPInputStream for gzipped content streams. > There appears to be an expectation in the GZIPInputStream of the > InputStream#available() method, for which the behavior is varied across > InputStream implementations. InputStream implementations that do not satisfy > this expectation cause the GZIPInputStream to terminate prematurely, > resulting in only partial reads. > There is an OpenJDK bug ([https://bugs.openjdk.java.net/browse/JDK-8081450]) > for this, and the Oracle JDK suffers from the same. > This can be overcome in Knox with code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KNOX-1505) Knox should close CuratorFramework clients when finished
[ https://issues.apache.org/jira/browse/KNOX-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638709#comment-16638709 ] Phil Zampino commented on KNOX-1505: [~risdenk] The patch looks good to me. > Knox should close CuratorFramework clients when finished > > > Key: KNOX-1505 > URL: https://issues.apache.org/jira/browse/KNOX-1505 > Project: Apache Knox > Issue Type: Bug >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 1.2.0 > > Attachments: KNOX-1505.patch > > > While looking at KNOX-1488, found that the CuratorFramework clients are not > always closed. This can cause resource leaks like a StackOverflow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KNOX-1505) Knox should close CuratorFramework clients when finished
[ https://issues.apache.org/jira/browse/KNOX-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637456#comment-16637456 ] Phil Zampino commented on KNOX-1505: I'll look over the patch...thanks for the catch and the notice. > Knox should close CuratorFramework clients when finished > > > Key: KNOX-1505 > URL: https://issues.apache.org/jira/browse/KNOX-1505 > Project: Apache Knox > Issue Type: Bug >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 1.2.0 > > Attachments: KNOX-1505.patch > > > While looking at KNOX-1488, found that the CuratorFramework clients are not > always closed. This can cause resource leaks like a StackOverflow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KNOX-1093) KNOX Not Handling safemode state of one of the NameNode In HA state
[
https://issues.apache.org/jira/browse/KNOX-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632073#comment-16632073
]
Phil Zampino commented on KNOX-1093:
I've updated the broken "retry" tests to "failover" tests.
> KNOX Not Handling safemode state of one of the NameNode In HA state
>
>
> Key: KNOX-1093
> URL: https://issues.apache.org/jira/browse/KNOX-1093
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.10.0
>Reporter: Rajesh Chandramohan
>Assignee: Matthew Sharp
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: KNOX-1093.patch
>
>
> per your code WebHdfsHaDispatch.java , When Safemode exception happened it
> calls the retryRequest() method. which also calls executeRequest() method as
> like failover request but the namenode info is not changing for the thread
> for all of its iteration until maxRetryAttempts=300
> and retrySleep=1000 ( 1 sec )
> After Max 5 minutes , client retries should pick the right namenode atleast
> in next attempt.
> But in this case if we need to copy a set of files in stipulated time there
> is X% of connections falls into these namenode and fails. Can we handle that
> better
> {code:java}
> try {
> inboundResponse = executeOutboundRequest(outboundRequest);
> writeOutboundResponse(outboundRequest, inboundRequest,
> outboundResponse, inboundResponse);
> } catch (StandbyException e) {
> LOG.errorReceivedFromStandbyNode(e);
> failoverRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> } catch (SafeModeException e) {
> LOG.errorReceivedFromSafeModeNode(e);
> retryRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> } catch (IOException e) {
> LOG.errorConnectingToServer(outboundRequest.getURI().toString(), e);
> failoverRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> }
>}
> {code}
> Need to change the logic in SafeModeexception state in KNOX HADispatch code
> to flag the namenode which is stuck in safemode and maintain don't try queue
> and redirect all further connection only to healthy active namenode . This
> way X5 of failures we can handle. What do we think
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (KNOX-1093) KNOX Not Handling safemode state of one of the NameNode In HA state
[
https://issues.apache.org/jira/browse/KNOX-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631800#comment-16631800
]
Phil Zampino edited comment on KNOX-1093 at 9/28/18 1:20 PM:
-
[~risdenk] Thanks for bringing this to my attention. I suspect the tests need
to be modified/removed since we've concluded that retry should not be attempted
when a host is in SafeMode. I'll examine the tests though, to make sure.
cc [~MatthewSharp]
was (Author: pzampino):
[~risdenk] Thanks for bringing this to my attention. I suspect the tests need
to be modified/removed since we've concluded that retry should not be supported
for DataNode IO failures. I'll examine the tests though, to make sure.
cc [~MatthewSharp]
> KNOX Not Handling safemode state of one of the NameNode In HA state
>
>
> Key: KNOX-1093
> URL: https://issues.apache.org/jira/browse/KNOX-1093
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.10.0
>Reporter: Rajesh Chandramohan
>Assignee: Matthew Sharp
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: KNOX-1093.patch
>
>
> per your code WebHdfsHaDispatch.java , When Safemode exception happened it
> calls the retryRequest() method. which also calls executeRequest() method as
> like failover request but the namenode info is not changing for the thread
> for all of its iteration until maxRetryAttempts=300
> and retrySleep=1000 ( 1 sec )
> After Max 5 minutes , client retries should pick the right namenode atleast
> in next attempt.
> But in this case if we need to copy a set of files in stipulated time there
> is X% of connections falls into these namenode and fails. Can we handle that
> better
> {code:java}
> try {
> inboundResponse = executeOutboundRequest(outboundRequest);
> writeOutboundResponse(outboundRequest, inboundRequest,
> outboundResponse, inboundResponse);
> } catch (StandbyException e) {
> LOG.errorReceivedFromStandbyNode(e);
> failoverRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> } catch (SafeModeException e) {
> LOG.errorReceivedFromSafeModeNode(e);
> retryRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> } catch (IOException e) {
> LOG.errorConnectingToServer(outboundRequest.getURI().toString(), e);
> failoverRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> }
>}
> {code}
> Need to change the logic in SafeModeexception state in KNOX HADispatch code
> to flag the namenode which is stuck in safemode and maintain don't try queue
> and redirect all further connection only to healthy active namenode . This
> way X5 of failures we can handle. What do we think
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KNOX-1093) KNOX Not Handling safemode state of one of the NameNode In HA state
[
https://issues.apache.org/jira/browse/KNOX-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631800#comment-16631800
]
Phil Zampino commented on KNOX-1093:
[~risdenk] Thanks for bringing this to my attention. I suspect the tests need
to be modified/removed since we've concluded that retry should not be supported
for DataNode IO failures. I'll examine the tests though, to make sure.
cc [~MatthewSharp]
> KNOX Not Handling safemode state of one of the NameNode In HA state
>
>
> Key: KNOX-1093
> URL: https://issues.apache.org/jira/browse/KNOX-1093
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.10.0
>Reporter: Rajesh Chandramohan
>Assignee: Matthew Sharp
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: KNOX-1093.patch
>
>
> per your code WebHdfsHaDispatch.java , When Safemode exception happened it
> calls the retryRequest() method. which also calls executeRequest() method as
> like failover request but the namenode info is not changing for the thread
> for all of its iteration until maxRetryAttempts=300
> and retrySleep=1000 ( 1 sec )
> After Max 5 minutes , client retries should pick the right namenode atleast
> in next attempt.
> But in this case if we need to copy a set of files in stipulated time there
> is X% of connections falls into these namenode and fails. Can we handle that
> better
> {code:java}
> try {
> inboundResponse = executeOutboundRequest(outboundRequest);
> writeOutboundResponse(outboundRequest, inboundRequest,
> outboundResponse, inboundResponse);
> } catch (StandbyException e) {
> LOG.errorReceivedFromStandbyNode(e);
> failoverRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> } catch (SafeModeException e) {
> LOG.errorReceivedFromSafeModeNode(e);
> retryRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> } catch (IOException e) {
> LOG.errorConnectingToServer(outboundRequest.getURI().toString(), e);
> failoverRequest(outboundRequest, inboundRequest, outboundResponse,
> inboundResponse, e);
> }
>}
> {code}
> Need to change the logic in SafeModeexception state in KNOX HADispatch code
> to flag the namenode which is stuck in safemode and maintain don't try queue
> and redirect all further connection only to healthy active namenode . This
> way X5 of failures we can handle. What do we think
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
