[jira] [Created] (KNOX-1084) Extend knoxcli to support multiple hostnames while generating self-signed certificates

2017-10-20 Thread Jesus Alvarez (JIRA) 
Jesus Alvarez created KNOX-1084:
---

 Summary: Extend knoxcli to support multiple hostnames while 
generating self-signed certificates
 Key: KNOX-1084
 URL: https://issues.apache.org/jira/browse/KNOX-1084
 Project: Apache Knox
  Issue Type: Bug
Reporter: Jesus Alvarez
Priority: Minor


In some multi-homed network environments, a knox gateway may have hostnames 
such as:


{code}
123-4-5-5-internal.example.com
pub2-west-re.example.com
{code}


While generating certificates in these types of environments, one approach to 
having host verification resolve on the external and internal CNs is the use of 
subjectAltNames http://wiki.cacert.org/FAQ/subjectAltName

{code}
 openssl x509 -in temp.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 123456 (0x1e240)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=pub2-west-re.example.com, O=EX, C=US
Validity
...
Subject: CN=pub2-west-re.example.com, O=EX, C=US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
 ...
X509v3 extensions:
X509v3 Subject Alternative Name: 
DNS:123-4-5-5-internal.example.com
{code}



It would be useful if knoxcli could be extended to support multiple hostnames, 
ex:

{code}
bin/knoxcli.sh create-cert --hostname pub2-west-re.example.com --hostname 
123-4-5-5-internal.example.com
{code}


Where the first name will continue to be the Issuer and Subject, and the 
2nd-Nth hostname will be added as a Subject Alternate Name DNS entry.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-842) Add support for Livy (Spark REST Service)

2017-10-20 Thread Jeffrey Rodriguez (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16213288#comment-16213288
 ] 

Jeffrey Rodriguez commented on KNOX-842:


I will revalidate the patch and if we approve  by reviewer I will commit it.

> Add support for Livy (Spark REST Service) 
> --
>
> Key: KNOX-842
> URL: https://issues.apache.org/jira/browse/KNOX-842
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Reporter: Sam Hjelmfelt
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.14.0
>
> Attachments: KNOX-842.001.patch
>
>
> http://livy.io/
> Here is an example of a Livy Knox service implementation:
> https://community.hortonworks.com/articles/70499/adding-livy-server-as-service-to-apache-knox.html
> The Livy service will need to support Kerberos and load balancing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (KNOX-842) Add support for Livy (Spark REST Service)

2017-10-20 Thread Jeffrey Rodriguez (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16213286#comment-16213286
 ] 

Jeffrey Rodriguez edited comment on KNOX-842 at 10/20/17 9:42 PM:
--

I will open a new Jira for adding the userProxy.
I think we should get the Livy servers push.
We should also open another Jira for the client and for doc.



was (Author: jeffrey...@gmail.com):
I will open a new Jira for adding the userProxy.
I think we should get the Livy servers push.
We should also open another Jira for the client .

> Add support for Livy (Spark REST Service) 
> --
>
> Key: KNOX-842
> URL: https://issues.apache.org/jira/browse/KNOX-842
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Reporter: Sam Hjelmfelt
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.14.0
>
> Attachments: KNOX-842.001.patch
>
>
> http://livy.io/
> Here is an example of a Livy Knox service implementation:
> https://community.hortonworks.com/articles/70499/adding-livy-server-as-service-to-apache-knox.html
> The Livy service will need to support Kerberos and load balancing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-842) Add support for Livy (Spark REST Service)

2017-10-20 Thread Jeffrey Rodriguez (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16213286#comment-16213286
 ] 

Jeffrey Rodriguez commented on KNOX-842:


I will open a new Jira for adding the userProxy.
I think we should get the Livy servers push.
We should also open another Jira for the client .

> Add support for Livy (Spark REST Service) 
> --
>
> Key: KNOX-842
> URL: https://issues.apache.org/jira/browse/KNOX-842
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Reporter: Sam Hjelmfelt
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.14.0
>
> Attachments: KNOX-842.001.patch
>
>
> http://livy.io/
> Here is an example of a Livy Knox service implementation:
> https://community.hortonworks.com/articles/70499/adding-livy-server-as-service-to-apache-knox.html
> The Livy service will need to support Kerberos and load balancing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KNOX-1083) HttpCleint default timeout should be a sensible value

2017-10-20 Thread Sandeep More (JIRA) 
Sandeep More created KNOX-1083:
--

 Summary: HttpCleint default timeout should be a sensible value 
 Key: KNOX-1083
 URL: https://issues.apache.org/jira/browse/KNOX-1083
 Project: Apache Knox
  Issue Type: Bug
  Components: Server
Reporter: Sandeep More
 Fix For: 0.14.0


Currently the default HttpClient had value -1, in some cases this will cause 
Knox connections to hang for e.g. using beeline. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1039) Add Support For Simple Descriptors and Policy Config to Knox Admin API

2017-10-20 Thread Sandeep More (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212775#comment-16212775
 ] 

Sandeep More commented on KNOX-1039:


Hello [~pzampino]
Looks like the patch does not apply cleanly, perhaps needs to be rebased ?
{code}
knox git:(master) git apply /Users/smore/dev/review-patches/KNOX-1039-001.patch
error: patch failed: 
gateway-server/src/main/java/org/apache/hadoop/gateway/services/topology/impl/DefaultTopologyService.java:481
error: 
gateway-server/src/main/java/org/apache/hadoop/gateway/services/topology/impl/DefaultTopologyService.java:
 patch does not apply
{code}

> Add Support For Simple Descriptors and Policy Config to Knox Admin API
> --
>
> Key: KNOX-1039
> URL: https://issues.apache.org/jira/browse/KNOX-1039
> Project: Apache Knox
>  Issue Type: Sub-task
>  Components: Server
>Reporter: Phil Zampino
>Assignee: Phil Zampino
>  Labels: kip-8
> Fix For: 0.14.0
>
> Attachments: KNOX-1039-001.patch, KNOX-1039.patch, 
> sandbox-providers.xml, sandbox.json
>
>
> The Knox admin API needs to support CRUD operations for simple descriptors 
> and externalized provider configurations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1053) Document Support for Apache SOLR + HA Support for HBase & Kafka

2017-10-20 Thread Sandeep More (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KNOX-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep More updated KNOX-1053:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Document Support for Apache SOLR + HA Support for HBase & Kafka
> ---
>
> Key: KNOX-1053
> URL: https://issues.apache.org/jira/browse/KNOX-1053
> Project: Apache Knox
>  Issue Type: Task
>  Components: Site
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 0.14.0
>
> Attachments: KNOX-1053.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1053) Document Support for Apache SOLR + HA Support for HBase & Kafka

2017-10-20 Thread Sandeep More (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212754#comment-16212754
 ] 

Sandeep More commented on KNOX-1053:


Thanks for the Docs [~rkellogg] !

> Document Support for Apache SOLR + HA Support for HBase & Kafka
> ---
>
> Key: KNOX-1053
> URL: https://issues.apache.org/jira/browse/KNOX-1053
> Project: Apache Knox
>  Issue Type: Task
>  Components: Site
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 0.14.0
>
> Attachments: KNOX-1053.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1053) Document Support for Apache SOLR + HA Support for HBase & Kafka

2017-10-20 Thread John McParland (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212746#comment-16212746
 ] 

John McParland commented on KNOX-1053:
--

Thank your for your message.  I am currently out of office on annual leave and 
shall return on Monday 23rd October 2017.
For enquiries about the RBC Loyalty Platform, please contact Stuart Batty 
(stuart.ba...@cgi.com).

Thanks,

John McParland MIET CEng | System Architect, ODSC
Health, Local and Scotland | CGI
CGI Ltd (UK)
Second floor, Inovo Building, 121 George St, Glasgow, UK, G1 1RD
M: +44 7920 183 019
john.mcparl...@cgi.com | 
www.cgi-group.co.uk

CGI IT UK Limited. A CGI Group Inc. Company
Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA,
United Kingdom. Registered in England & Wales - Number 947968

CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging to CGI 
Group Inc. and its affiliates may be contained in this message. If you are not 
a recipient indicated or intended in this message (or responsible for delivery 
of this message to such person), or you think for any reason that this message 
may have been addressed to you in error, you may not use or copy or deliver 
this message to anyone else. In such case, you should destroy this message and 
are asked to notify the sender by reply e-mail.


> Document Support for Apache SOLR + HA Support for HBase & Kafka
> ---
>
> Key: KNOX-1053
> URL: https://issues.apache.org/jira/browse/KNOX-1053
> Project: Apache Knox
>  Issue Type: Task
>  Components: Site
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 0.14.0
>
> Attachments: KNOX-1053.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1053) Document Support for Apache SOLR + HA Support for HBase & Kafka

2017-10-20 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212743#comment-16212743
 ] 

ASF subversion and git services commented on KNOX-1053:
---

Commit 1812752 from [~moresandeep]
[ https://svn.apache.org/r1812752 ]

KNOX-1053 - Document Support for Apache SOLR + HA Support for HBase & Kafka 
(Rick Kellogg via Sandeep More)

> Document Support for Apache SOLR + HA Support for HBase & Kafka
> ---
>
> Key: KNOX-1053
> URL: https://issues.apache.org/jira/browse/KNOX-1053
> Project: Apache Knox
>  Issue Type: Task
>  Components: Site
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 0.14.0
>
> Attachments: KNOX-1053.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1041) High Availability Support For Apache SOLR, HBase & Kafka

2017-10-20 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212721#comment-16212721
 ] 

ASF subversion and git services commented on KNOX-1041:
---

Commit a08aaf742a97a3c35c94e28406fc4b6ef3184005 in knox's branch 
refs/heads/master from [~moresandeep]
[ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=a08aaf7 ]

KNOX-1041 - High Availability Support For Apache SOLR, HBase & Kafka (Rick 
Kellogg via Sandeep More)


> High Availability Support For Apache SOLR, HBase & Kafka
> 
>
> Key: KNOX-1041
> URL: https://issues.apache.org/jira/browse/KNOX-1041
> Project: Apache Knox
>  Issue Type: New Feature
>  Components: Server
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
> Fix For: 0.14.0
>
> Attachments: KNOX-1041.patch
>
>
> Provide high-availability/fail-over between Knox and SOLR/HBase/Kafka using 
> the existing DefaultHaDispatch mechanism and a customized URLManager 
> implementation with knowledge of active hosts in Zookeeper.
> When SOLR Cloud is used the active hosts are stored in Zookeeper under the 
> /live_nodes path.  The attached custom URLManager implementation queries 
> Zookeeper for the active hosts upon startup.  In the event of fail-over, it 
> updates the internal list of hosts.
> The HS2ZookeeperURLManager implementation used to provide similar 
> functionality for Hive was used as a starting point.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1041) High Availability Support For Apache SOLR, HBase & Kafka

2017-10-20 Thread Sandeep More (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KNOX-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep More updated KNOX-1041:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> High Availability Support For Apache SOLR, HBase & Kafka
> 
>
> Key: KNOX-1041
> URL: https://issues.apache.org/jira/browse/KNOX-1041
> Project: Apache Knox
>  Issue Type: New Feature
>  Components: Server
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
> Fix For: 0.14.0
>
> Attachments: KNOX-1041.patch
>
>
> Provide high-availability/fail-over between Knox and SOLR/HBase/Kafka using 
> the existing DefaultHaDispatch mechanism and a customized URLManager 
> implementation with knowledge of active hosts in Zookeeper.
> When SOLR Cloud is used the active hosts are stored in Zookeeper under the 
> /live_nodes path.  The attached custom URLManager implementation queries 
> Zookeeper for the active hosts upon startup.  In the event of fail-over, it 
> updates the internal list of hosts.
> The HS2ZookeeperURLManager implementation used to provide similar 
> functionality for Hive was used as a starting point.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1041) High Availability Support For Apache SOLR, HBase & Kafka

2017-10-20 Thread Sandeep More (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212723#comment-16212723
 ] 

Sandeep More commented on KNOX-1041:


Thanks the contribution and being patient [~rkellogg] :)
I have committed the patch to master.

> High Availability Support For Apache SOLR, HBase & Kafka
> 
>
> Key: KNOX-1041
> URL: https://issues.apache.org/jira/browse/KNOX-1041
> Project: Apache Knox
>  Issue Type: New Feature
>  Components: Server
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
> Fix For: 0.14.0
>
> Attachments: KNOX-1041.patch
>
>
> Provide high-availability/fail-over between Knox and SOLR/HBase/Kafka using 
> the existing DefaultHaDispatch mechanism and a customized URLManager 
> implementation with knowledge of active hosts in Zookeeper.
> When SOLR Cloud is used the active hosts are stored in Zookeeper under the 
> /live_nodes path.  The attached custom URLManager implementation queries 
> Zookeeper for the active hosts upon startup.  In the event of fail-over, it 
> updates the internal list of hosts.
> The HS2ZookeeperURLManager implementation used to provide similar 
> functionality for Hive was used as a starting point.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1073) Upgrade PAC4J to a more recent version

2017-10-20 Thread Colm O hEigeartaigh (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KNOX-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated KNOX-1073:
--
Attachment: knox-pac4j.patch.3

Here's an updated patch that fixes the failing unit test.

> Upgrade PAC4J to a more recent version
> --
>
> Key: KNOX-1073
> URL: https://issues.apache.org/jira/browse/KNOX-1073
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 0.14.0
>
> Attachments: knox-pac4j.patch.3
>
>
> This task is to upgrade PAC4J to a more recent version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1073) Upgrade PAC4J to a more recent version

2017-10-20 Thread Colm O hEigeartaigh (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KNOX-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated KNOX-1073:
--
Attachment: (was: knox-pac4j.patch.2)

> Upgrade PAC4J to a more recent version
> --
>
> Key: KNOX-1073
> URL: https://issues.apache.org/jira/browse/KNOX-1073
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 0.14.0
>
> Attachments: knox-pac4j.patch.3
>
>
> This task is to upgrade PAC4J to a more recent version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Supporting delegation token service in Knox

2017-10-20 Thread larry mccay 
No, we only proxy HTTP resources.
If there is no proxyable REST API then we really can't get to it today.

Perhaps at some point, we may be able to leverage websockets to proxy other
protocols but AFAIK they still require an HTTP component which the existing
CLIs and RPC clients won't have.

On Fri, Oct 20, 2017 at 2:30 AM, Mohammad Islam  wrote:

> Thanks again Larry. One comment online.
>
> >We should be able to provide access to the same resources via proxied
> calls to the backend services that you require without leaking a credential
> that can be captured and replayed by anyone to spoof the original user.
>
> We are exactly looking something like this. Is there a way to support the
> proxying of RPC communications through Knox. For example, how can we run a
> traditional Spark job in Mesos cluster through Knox only for HDFS access?
> How can we use Hive java (thrift) API to go through Knox? I know Knox
> supports HTTP/JDBC. However, not sure how to support the
> RPC/TCP communication.
>
>
>
>
>
>
> On Thursday, October 19, 2017, 6:20:34 AM PDT, larry mccay <
> lmc...@apache.org> wrote:
>
>
> Thank you for the clarification.
> I did understand correctly.
>
> I think my characterization of this making Knox a delegation token factory
> was slightly off - we would be more of a delegation token broker. Which is
> just as inappropriate considering what I consider the charter of the Knox
> Gateway.
>
> If we are actually returning the delegation token to the client with
> webhdfs calls through knox then something is broken and we need to address
> that.
>
> While your assertion that the token is returned by the services through
> REST and Thrift calls is certainly true, this behavior is generally done
> within the cluster firewalls or controlled access through the firewall for
> trusted users/clients that would otherwise be able to authenticate via
> kerberos anyway. It is a means to offload the traffic from the KDC when
> there are thousands of datanodes and/or users.
>
> In deployments of Knox where users are authenticating without the need for
> kerberos or the more importantly, the restrictions of kerberos
> authentication from where they are, there is no reason to leak the
> delegation token to the end users.
>
> We should be able to provide access to the same resources via proxied
> calls to the backend services that you require without leaking a credential
> that can be captured and replayed by anyone to spoof the original user.
>
>
> On Thu, Oct 19, 2017 at 3:26 AM, Mohammad Islam 
> wrote:
>
> Hi Larry,
> thanks for your reply.
>
> I believe I didn't explain our use-case properly.  Let me give some
> contexts and addressing some concerns.
>
> Be warned - a long email :)
>
> We restrict the Kerberos access only within Hadoop cluster. Any access to
> Kerberos service from outside Hadoop is not recommended for different
> reasons. However our user wants to access HDFS/Hive/YARN etc.
>
> *Background* (that you already know):
>
> As far as I know, Hadoop provides two types of security for user
> applications.
>
> A) Kerberos ticket based : In this case, during job submission,  client
> *implicitly* gets the HDFS & RM Tokens while presenting her kerberos
> ticket.
>
> B) Delegation token based: In this case, the user "somehow" needs to get
> the delegation token from HDFS/YARN/Hive services. Then put the tokens into
> a local file and then expose the file's path with an environment variable
> called "HADOOP_TOKEN_FILE_LOCATIONS". After that, if the user submits any
> application w/o Kerberos ticket, it will able to connect to those services
> using delegation token. Oozie/Azkaban utilizes something similar like this.
>
>
> In our environment, we want to use the second option. User doesn't need
> the Kerberos ticket. She only needs the delegation token. The question is
> how she can get the delegation token. Most common approach is to use
> kerberos ticket and call appropriate REST or Thrift call to get the token.
>
> However, our proposal is :
> if Knox can provide the service where external user will first
> authenticate to Knox through LDAP or some other means and get the
> delegation token collected from actual services. In other words, we want to
> get the delegation token w/o "directly" using kerberos ticket. Knox can be
> an *intermediary* who can authenticate the user by non-kerberos way and
> then utilize its Kerberos credential to call the appropriate services (i.e.
> HDFS/YARN/Hive) and gets the delegation tokens from them and , finally,
> returns the tokens to the user.
>
> *Addressing Concerns:*
>
> Concern 1 : Regarding security compromise:  All other services (WebHDFS,
> YARN, Hive) are already exposing their delegation tokens to user through
> REST/Thrift/Java API. Only change is using non-Kerberos ways via Knox. Knox
> is just proxying.
>
> Concern 2: Knox be the factory of delegation token: I'm not asking  Knox
> to manage/create delegation token for the services. Rather Knox will gather

[jira] [Resolved] (KNOX-1022) Configuring knox token ttl to higher value generates an access token which is not valid

2017-10-20 Thread Colm O hEigeartaigh (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KNOX-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh resolved KNOX-1022.
---
Resolution: Fixed

> Configuring knox token ttl to higher value generates an access token which is 
> not valid
> ---
>
> Key: KNOX-1022
> URL: https://issues.apache.org/jira/browse/KNOX-1022
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Reporter: J.Andreina
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 0.14.0
>
>
> If TTL for Knox token is configured to negative value other than -1 or 
> configured to a value in milli seconds which when gets added to current time 
> in milli seconds to calculate the token expiry becomes > LONG.MAX_VALUE, then 
> token expiry will become negative value. In such cases there is no need to go 
> ahead and generate a token which will not be valid at all (already expired).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1022) Configuring knox token ttl to higher value generates an access token which is not valid

2017-10-20 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212465#comment-16212465
 ] 

ASF subversion and git services commented on KNOX-1022:
---

Commit aa62fa2dbdca59b175eefb62e97b5528f40d076b in knox's branch 
refs/heads/master from [~coheigea]
[ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=aa62fa2 ]

KNOX-1022 - Configuring knox token ttl to higher value generates an access 
token which is not valid


> Configuring knox token ttl to higher value generates an access token which is 
> not valid
> ---
>
> Key: KNOX-1022
> URL: https://issues.apache.org/jira/browse/KNOX-1022
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Reporter: J.Andreina
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 0.14.0
>
>
> If TTL for Knox token is configured to negative value other than -1 or 
> configured to a value in milli seconds which when gets added to current time 
> in milli seconds to calculate the token expiry becomes > LONG.MAX_VALUE, then 
> token expiry will become negative value. In such cases there is no need to go 
> ahead and generate a token which will not be valid at all (already expired).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1001) Knox Shell Sqoop.Request class is Package Private

2017-10-20 Thread Andrei Viaryshka (JIRA) 

[ 
https://issues.apache.org/jira/browse/KNOX-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16212294#comment-16212294
 ] 

Andrei Viaryshka commented on KNOX-1001:


Thank you!

> Knox Shell Sqoop.Request class is Package Private
> -
>
> Key: KNOX-1001
> URL: https://issues.apache.org/jira/browse/KNOX-1001
> Project: Apache Knox
>  Issue Type: Bug
>  Components: ClientDSL
>Reporter: Andrei Viaryshka
>Assignee: Andrei Viaryshka
> Fix For: 0.14.0
>
> Attachments: KNOX-1001.patch
>
>
> org.apache.hadoop.gateway.shell.job.Sqoop.Request class is package-private. 
> This causes compilation errors when trying to submit sqoop job from a class 
> in a different package.
> For example:
> {code}
> package test.knox.sqoop;
> import org.apache.hadoop.gateway.shell.Hadoop;
> import org.apache.hadoop.gateway.shell.job.Job;
> public class TestSqoop {
>   public static void main( String[] args ) {
> try {
>   Hadoop session = Hadoop.login( "test", "test", "test" );
>   String text = Job.submitSqoop( session ).command( "test command" 
> ).libdir( "libdir" ).now().getString();
>   session.shutdown();
> } catch ( Exception e ) {
>   e.printStackTrace();
> }
>   }
> }
> {code}
> It results in the following errors:
> {code}
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] 
> /home/andrei/knox-sqoop/src/main/java/test/knox/sqoop/TestSqoop.java:[10,47] 
> command(java.lang.String) in 
> org.apache.hadoop.gateway.shell.job.Sqoop.Request is defined in an 
> inaccessible class or interface
> [ERROR] 
> /home/andrei/knox-sqoop/src/main/java/test/knox/sqoop/TestSqoop.java:[10,73] 
> libdir(java.lang.String) in org.apache.hadoop.gateway.shell.job.Sqoop.Request 
> is defined in an inaccessible class or interface
> [ERROR] 
> /home/andrei/knox-sqoop/src/main/java/test/knox/sqoop/TestSqoop.java:[10,92] 
> now() in org.apache.hadoop.gateway.shell.AbstractRequest is defined in an 
> inaccessible class or interface
> [INFO] 3 errors
> {code}
> The Request class needs to be made public.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)