[jira] [Resolved] (KNOX-417) Verify Knox User Guide Instructions

2014-11-11 Thread Larry McCay (JIRA)

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

Larry McCay resolved KNOX-417.
--
Resolution: Fixed

> Verify Knox User Guide Instructions
> ---
>
> Key: KNOX-417
> URL: https://issues.apache.org/jira/browse/KNOX-417
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Site
>Reporter: Vinay Shukla
>  Labels: documentation
> Fix For: 0.5.0
>
> Attachments: KNOX-417.patch
>
>
> Verify Knox User guide with 0.5.0 version of the product.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (KNOX-202) Diagnosability/troubleshooting when wrong protocol (http vs https) used

2014-11-11 Thread Larry McCay (JIRA)

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

Larry McCay resolved KNOX-202.
--
Resolution: Fixed

added to troubleshooting section of the users guide

> Diagnosability/troubleshooting when wrong protocol (http vs https) used
> ---
>
> Key: KNOX-202
> URL: https://issues.apache.org/jira/browse/KNOX-202
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server, Site
>Affects Versions: 0.2.0
>Reporter: Kevin Minder
> Fix For: 0.5.0
>
>
> When a request is made to 
> curl -i -k -u guest:guest-password -X GET 
> 'http://localhost:8443/gateway/sandbox/webhdfs/v1/?op=LISTSTATUS'
> the following error is returned
> curl: (52) Empty reply from server
> This needs to be added to the troubleshooting guide or possibly better we 
> need to include a HTTP endpoint that returns either redirects or returns an 
> error.  There may be ways in Jetty to handle this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (KNOX-263) Docs - User Guide list of Services missing straight MapReduce?

2014-11-11 Thread Larry McCay (JIRA)

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

Larry McCay updated KNOX-263:
-
Fix Version/s: (was: 0.5.0)
   0.6.0

> Docs - User Guide list of Services missing straight MapReduce?
> --
>
> Key: KNOX-263
> URL: https://issues.apache.org/jira/browse/KNOX-263
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Site
>Affects Versions: 0.3.0
>Reporter: Hari Sekhon
>Priority: Minor
> Fix For: 0.6.0
>
>
> Hi,
> In the Knox user guide should the list of Service Details (just under the 
> groovy DSL section) include MapReduce as one of the supported services and 
> document basic job submission via templeton/v1/mapreduce API as demonstrated 
> in the Hortonworks Technical Preview documentation? (I can't see that 
> demonstrated/documented there)
> I'm referring to the user guide documentation here:
> http://knox.incubator.apache.org/books/knox-incubating-0-3-0/knox-incubating-0-3-0.html#Service+Details
> and page 10 of the Hortonworks technical preview showing the MR job 
> submission here:
> http://public-repo-1.hortonworks.com/HDP-LABS/Projects/Knox/1.3.3.0-59/KnoxTechnicalPreview.pdf
> Thanks
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (KNOX-464) Location headers have wrong hostname when used behind load balancer

2014-11-11 Thread Kevin Minder (JIRA)

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

Kevin Minder edited comment on KNOX-464 at 11/11/14 6:59 PM:
-

All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.

{code}





{code}

in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.


was (Author: kminder):
All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.

{code:xml}





{code}

in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.

> Location headers have wrong hostname when used behind load balancer
> ---
>
> Key: KNOX-464
> URL: https://issues.apache.org/jira/browse/KNOX-464
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.5.0
>Reporter: Kevin Minder
>Assignee: Kevin Minder
>Priority: Critical
> Fix For: 0.6.0
>
> Attachments: KNOX-464.patch
>
>
> When you make a request like this that is routed through a load balancer 
> {code}
> curl -i -u guest:guest-password -X PUT 
> 'http://localhost:8080/gateway/default/webhdfs/v1/tmp/LICENSE?op=CREATE'
> {code}
> Knox currently will return something like this
> {code}
> https://backend:8443/gateway/default/webhdfs/data/v1/webhdfs/v1/tmp/LICENSE?_=CBCQccBhGqTbDtfqAt7vzK1H39SnCZo7W14qCIs67ctZAJDXr9fEyJbo1H9AO8prLGdV8Jmz5TO_novslggJwY7E9Vep4eFP0auaxVpfBz4QG-ktSuviEU5aHl8om_SkuGLOwSDjBRZASXrV1huqKU-K_mKkCaPnC0NkCpRQRL0LMkGvB8yrl6_1vNkaoXTxwjm0kp1EhgniovHJVmfcPbjKmmoh-boVy1cj
> {code}
> To avoid confusion the 'backend' in the URL above is in no way correct but is 
> in part caused because nginx is sending that value in the Host header.  That 
> is peculiar to nginx and could be fixed with nginx configuration.
> The issue here is that Knox used the hostname from the Host header and the 
> local port.  I'm not exactly sure what the right answer it but I'm sure 
> mixing is bad.  We should either be using the information from the Host 
> header or the information from the local endpoint of the socket.  The way 
> Knox was working before the fix for KNOX-439 was to use the local endpoint 
> information so I'm going to fix this issue making that assumption.  
> I used nginx to reproduce the issue.  This is the final configured I used to 
> verify the fix.  Note that the 'proxy_redirect' would need to be removed to 
> see exactly what Knox is returning and compare to what is shown above.
> {code}
> worker_processes  1;
> events {
> worker_connections  1024;
> }
> http {
> include   mime.types;
> default_type  application/octet-stream;
> sendfileon;
> keepalive_timeout  65;
> upstream backend {
> server c6402.ambari.apache.org:8443;
> }
> server {
> listen   8080;
> server_name  localhost;
> location / {
> proxy_pass  https://backend;
> proxy_redirect  https://c6402.ambari.apache.org:8443/ 
> http://$host:$server_port/;
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (KNOX-464) Location headers have wrong hostname when used behind load balancer

2014-11-11 Thread Kevin Minder (JIRA)

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

Kevin Minder edited comment on KNOX-464 at 11/11/14 6:57 PM:
-

All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.
{code}





{code}

in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.


was (Author: kminder):
All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.







in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.

> Location headers have wrong hostname when used behind load balancer
> ---
>
> Key: KNOX-464
> URL: https://issues.apache.org/jira/browse/KNOX-464
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.5.0
>Reporter: Kevin Minder
>Assignee: Kevin Minder
>Priority: Critical
> Fix For: 0.6.0
>
> Attachments: KNOX-464.patch
>
>
> When you make a request like this that is routed through a load balancer 
> {code}
> curl -i -u guest:guest-password -X PUT 
> 'http://localhost:8080/gateway/default/webhdfs/v1/tmp/LICENSE?op=CREATE'
> {code}
> Knox currently will return something like this
> {code}
> https://backend:8443/gateway/default/webhdfs/data/v1/webhdfs/v1/tmp/LICENSE?_=CBCQccBhGqTbDtfqAt7vzK1H39SnCZo7W14qCIs67ctZAJDXr9fEyJbo1H9AO8prLGdV8Jmz5TO_novslggJwY7E9Vep4eFP0auaxVpfBz4QG-ktSuviEU5aHl8om_SkuGLOwSDjBRZASXrV1huqKU-K_mKkCaPnC0NkCpRQRL0LMkGvB8yrl6_1vNkaoXTxwjm0kp1EhgniovHJVmfcPbjKmmoh-boVy1cj
> {code}
> To avoid confusion the 'backend' in the URL above is in no way correct but is 
> in part caused because nginx is sending that value in the Host header.  That 
> is peculiar to nginx and could be fixed with nginx configuration.
> The issue here is that Knox used the hostname from the Host header and the 
> local port.  I'm not exactly sure what the right answer it but I'm sure 
> mixing is bad.  We should either be using the information from the Host 
> header or the information from the local endpoint of the socket.  The way 
> Knox was working before the fix for KNOX-439 was to use the local endpoint 
> information so I'm going to fix this issue making that assumption.  
> I used nginx to reproduce the issue.  This is the final configured I used to 
> verify the fix.  Note that the 'proxy_redirect' would need to be removed to 
> see exactly what Knox is returning and compare to what is shown above.
> {code}
> worker_processes  1;
> events {
> worker_connections  1024;
> }
> http {
> include   mime.types;
> default_type  application/octet-stream;
> sendfileon;
> keepalive_timeout  65;
> upstream backend {
> server c6402.ambari.apache.org:8443;
> }
> server {
> listen   8080;
> server_name  localhost;
> location / {
> proxy_pass  https://backend;
> proxy_redirect  https://c6402.ambari.apache.org:8443/ 
> http://$host:$server_port/;
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (KNOX-464) Location headers have wrong hostname when used behind load balancer

2014-11-11 Thread Kevin Minder (JIRA)

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

Kevin Minder edited comment on KNOX-464 at 11/11/14 6:58 PM:
-

All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.

{code:xml}





{code}

in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.


was (Author: kminder):
All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.

{code}





{code}

in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.

> Location headers have wrong hostname when used behind load balancer
> ---
>
> Key: KNOX-464
> URL: https://issues.apache.org/jira/browse/KNOX-464
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.5.0
>Reporter: Kevin Minder
>Assignee: Kevin Minder
>Priority: Critical
> Fix For: 0.6.0
>
> Attachments: KNOX-464.patch
>
>
> When you make a request like this that is routed through a load balancer 
> {code}
> curl -i -u guest:guest-password -X PUT 
> 'http://localhost:8080/gateway/default/webhdfs/v1/tmp/LICENSE?op=CREATE'
> {code}
> Knox currently will return something like this
> {code}
> https://backend:8443/gateway/default/webhdfs/data/v1/webhdfs/v1/tmp/LICENSE?_=CBCQccBhGqTbDtfqAt7vzK1H39SnCZo7W14qCIs67ctZAJDXr9fEyJbo1H9AO8prLGdV8Jmz5TO_novslggJwY7E9Vep4eFP0auaxVpfBz4QG-ktSuviEU5aHl8om_SkuGLOwSDjBRZASXrV1huqKU-K_mKkCaPnC0NkCpRQRL0LMkGvB8yrl6_1vNkaoXTxwjm0kp1EhgniovHJVmfcPbjKmmoh-boVy1cj
> {code}
> To avoid confusion the 'backend' in the URL above is in no way correct but is 
> in part caused because nginx is sending that value in the Host header.  That 
> is peculiar to nginx and could be fixed with nginx configuration.
> The issue here is that Knox used the hostname from the Host header and the 
> local port.  I'm not exactly sure what the right answer it but I'm sure 
> mixing is bad.  We should either be using the information from the Host 
> header or the information from the local endpoint of the socket.  The way 
> Knox was working before the fix for KNOX-439 was to use the local endpoint 
> information so I'm going to fix this issue making that assumption.  
> I used nginx to reproduce the issue.  This is the final configured I used to 
> verify the fix.  Note that the 'proxy_redirect' would need to be removed to 
> see exactly what Knox is returning and compare to what is shown above.
> {code}
> worker_processes  1;
> events {
> worker_connections  1024;
> }
> http {
> include   mime.types;
> default_type  application/octet-stream;
> sendfileon;
> keepalive_timeout  65;
> upstream backend {
> server c6402.ambari.apache.org:8443;
> }
> server {
> listen   8080;
> server_name  localhost;
> location / {
> proxy_pass  https://backend;
> proxy_redirect  https://c6402.ambari.apache.org:8443/ 
> http://$host:$server_port/;
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (KNOX-464) Location headers have wrong hostname when used behind load balancer

2014-11-11 Thread Kevin Minder (JIRA)

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

Kevin Minder edited comment on KNOX-464 at 11/11/14 6:57 PM:
-

All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.

{code}





{code}

in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.


was (Author: kminder):
All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.
{code}





{code}

in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.

> Location headers have wrong hostname when used behind load balancer
> ---
>
> Key: KNOX-464
> URL: https://issues.apache.org/jira/browse/KNOX-464
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.5.0
>Reporter: Kevin Minder
>Assignee: Kevin Minder
>Priority: Critical
> Fix For: 0.6.0
>
> Attachments: KNOX-464.patch
>
>
> When you make a request like this that is routed through a load balancer 
> {code}
> curl -i -u guest:guest-password -X PUT 
> 'http://localhost:8080/gateway/default/webhdfs/v1/tmp/LICENSE?op=CREATE'
> {code}
> Knox currently will return something like this
> {code}
> https://backend:8443/gateway/default/webhdfs/data/v1/webhdfs/v1/tmp/LICENSE?_=CBCQccBhGqTbDtfqAt7vzK1H39SnCZo7W14qCIs67ctZAJDXr9fEyJbo1H9AO8prLGdV8Jmz5TO_novslggJwY7E9Vep4eFP0auaxVpfBz4QG-ktSuviEU5aHl8om_SkuGLOwSDjBRZASXrV1huqKU-K_mKkCaPnC0NkCpRQRL0LMkGvB8yrl6_1vNkaoXTxwjm0kp1EhgniovHJVmfcPbjKmmoh-boVy1cj
> {code}
> To avoid confusion the 'backend' in the URL above is in no way correct but is 
> in part caused because nginx is sending that value in the Host header.  That 
> is peculiar to nginx and could be fixed with nginx configuration.
> The issue here is that Knox used the hostname from the Host header and the 
> local port.  I'm not exactly sure what the right answer it but I'm sure 
> mixing is bad.  We should either be using the information from the Host 
> header or the information from the local endpoint of the socket.  The way 
> Knox was working before the fix for KNOX-439 was to use the local endpoint 
> information so I'm going to fix this issue making that assumption.  
> I used nginx to reproduce the issue.  This is the final configured I used to 
> verify the fix.  Note that the 'proxy_redirect' would need to be removed to 
> see exactly what Knox is returning and compare to what is shown above.
> {code}
> worker_processes  1;
> events {
> worker_connections  1024;
> }
> http {
> include   mime.types;
> default_type  application/octet-stream;
> sendfileon;
> keepalive_timeout  65;
> upstream backend {
> server c6402.ambari.apache.org:8443;
> }
> server {
> listen   8080;
> server_name  localhost;
> location / {
> proxy_pass  https://backend;
> proxy_redirect  https://c6402.ambari.apache.org:8443/ 
> http://$host:$server_port/;
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (KNOX-464) Location headers have wrong hostname when used behind load balancer

2014-11-11 Thread Kevin Minder (JIRA)

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

Kevin Minder commented on KNOX-464:
---

All of the magic is in 
gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/impl/UrlRewriteResponse.java
 method getGatewayParam. 
This is what ultimately ends up resolving the {gateway.url} in this rule.







in this ruleset.

gateway-service-webhdfs/src/main/resources/org/apache/hadoop/gateway/hdfs/WebHdfsDeploymentContributor/rewrite.xml

This was put into the code before I had implemented functions in rules so it is 
a bit wierd.

> Location headers have wrong hostname when used behind load balancer
> ---
>
> Key: KNOX-464
> URL: https://issues.apache.org/jira/browse/KNOX-464
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.5.0
>Reporter: Kevin Minder
>Assignee: Kevin Minder
>Priority: Critical
> Fix For: 0.6.0
>
> Attachments: KNOX-464.patch
>
>
> When you make a request like this that is routed through a load balancer 
> {code}
> curl -i -u guest:guest-password -X PUT 
> 'http://localhost:8080/gateway/default/webhdfs/v1/tmp/LICENSE?op=CREATE'
> {code}
> Knox currently will return something like this
> {code}
> https://backend:8443/gateway/default/webhdfs/data/v1/webhdfs/v1/tmp/LICENSE?_=CBCQccBhGqTbDtfqAt7vzK1H39SnCZo7W14qCIs67ctZAJDXr9fEyJbo1H9AO8prLGdV8Jmz5TO_novslggJwY7E9Vep4eFP0auaxVpfBz4QG-ktSuviEU5aHl8om_SkuGLOwSDjBRZASXrV1huqKU-K_mKkCaPnC0NkCpRQRL0LMkGvB8yrl6_1vNkaoXTxwjm0kp1EhgniovHJVmfcPbjKmmoh-boVy1cj
> {code}
> To avoid confusion the 'backend' in the URL above is in no way correct but is 
> in part caused because nginx is sending that value in the Host header.  That 
> is peculiar to nginx and could be fixed with nginx configuration.
> The issue here is that Knox used the hostname from the Host header and the 
> local port.  I'm not exactly sure what the right answer it but I'm sure 
> mixing is bad.  We should either be using the information from the Host 
> header or the information from the local endpoint of the socket.  The way 
> Knox was working before the fix for KNOX-439 was to use the local endpoint 
> information so I'm going to fix this issue making that assumption.  
> I used nginx to reproduce the issue.  This is the final configured I used to 
> verify the fix.  Note that the 'proxy_redirect' would need to be removed to 
> see exactly what Knox is returning and compare to what is shown above.
> {code}
> worker_processes  1;
> events {
> worker_connections  1024;
> }
> http {
> include   mime.types;
> default_type  application/octet-stream;
> sendfileon;
> keepalive_timeout  65;
> upstream backend {
> server c6402.ambari.apache.org:8443;
> }
> server {
> listen   8080;
> server_name  localhost;
> location / {
> proxy_pass  https://backend;
> proxy_redirect  https://c6402.ambari.apache.org:8443/ 
> http://$host:$server_port/;
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (KNOX-202) Diagnosability/troubleshooting when wrong protocol (http vs https) used

2014-11-11 Thread Larry McCay (JIRA)

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

Larry McCay updated KNOX-202:
-
Description: 
When a request is made to 
curl -i -k -u guest:guest-password -X GET 
'http://localhost:8443/gateway/sandbox/webhdfs/v1/?op=LISTSTATUS'
the following error is returned
curl: (52) Empty reply from server

This needs to be added to the troubleshooting guide or possibly better we need 
to include a HTTP endpoint that returns either redirects or returns an error.  
There may be ways in Jetty to handle this.

  was:
When a request is made to 
curl -i -k -u guest:guest-password -X GET 
'http://localhost:8443/gateway/sandbox/webhdfs/v1/?op=LISTSTATUS'
the following error is returned
curl: (52) Emty reply from server

This needs to be added to the troubleshooting guide or possibly better we need 
to include a HTTP endpoint that returns either redirects or returns an error.  
There may be ways in Jetty to handle this.


> Diagnosability/troubleshooting when wrong protocol (http vs https) used
> ---
>
> Key: KNOX-202
> URL: https://issues.apache.org/jira/browse/KNOX-202
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server, Site
>Affects Versions: 0.2.0
>Reporter: Kevin Minder
> Fix For: 0.5.0
>
>
> When a request is made to 
> curl -i -k -u guest:guest-password -X GET 
> 'http://localhost:8443/gateway/sandbox/webhdfs/v1/?op=LISTSTATUS'
> the following error is returned
> curl: (52) Empty reply from server
> This needs to be added to the troubleshooting guide or possibly better we 
> need to include a HTTP endpoint that returns either redirects or returns an 
> error.  There may be ways in Jetty to handle this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (KNOX-330) Consolidate Authentication, GroupLookup and Shiro Docs

2014-11-11 Thread Larry McCay (JIRA)

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

Larry McCay updated KNOX-330:
-
Fix Version/s: (was: 0.5.0)
   0.6.0

> Consolidate Authentication, GroupLookup and Shiro Docs
> --
>
> Key: KNOX-330
> URL: https://issues.apache.org/jira/browse/KNOX-330
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Site
>Reporter: Larry McCay
> Fix For: 0.6.0
>
>
> http://knox.incubator.apache.org/books/knox-incubating-0-4-0/knox-incubating-0-4-0-new.html#LDAPGroupLookup
> LDAPGroupLookup is really an aspect of the Shiro authentication provider. It 
> is not a general purpose group lookup. It should be rolled into Shiro 
> specific docs under the authentication section.
> This also requires a distinction between the docs in authentication between 
> general and Shiro specific.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (KNOX-295) Knox User guide to clearly outline Tested vs Untested configuration

2014-11-11 Thread Larry McCay (JIRA)

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

Larry McCay resolved KNOX-295.
--
Resolution: Fixed
  Assignee: Larry McCay

Documented PreauthSSO examples as not directly tested against products but have 
unit and functional testing to emulate it - in the users guide.

> Knox User guide to clearly outline Tested vs Untested configuration
> ---
>
> Key: KNOX-295
> URL: https://issues.apache.org/jira/browse/KNOX-295
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Vinay Shukla
>Assignee: Larry McCay
>  Labels: doc
> Fix For: 0.5.0
>
>
> Refer to 
> http://knox.incubator.apache.org/books/knox-incubating-0-4-0/knox-incubating-0-4-0.html#Preauthenticated+SSO+Provider
> Case in point, the Pre-authenticated SSO information.
> We need confirmation on what version of SiteMinder Or Tivoli Access Manager 
> was tested or not tested.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (KNOX-437) KnoxLdapContextFactory should be configured by default in all topology files and docs

2014-11-11 Thread Larry McCay (JIRA)

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

Larry McCay resolved KNOX-437.
--
Resolution: Fixed

Has been updated in LDAP docs in the users guide.

> KnoxLdapContextFactory should be configured by default in all topology files 
> and docs
> -
>
> Key: KNOX-437
> URL: https://issues.apache.org/jira/browse/KNOX-437
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server, Site
>Affects Versions: 0.4.0
>Reporter: Kevin Minder
>Assignee: Kevin Minder
>Priority: Blocker
> Fix For: 0.5.0
>
> Attachments: KNOX-437.patch
>
>
> In some cases the KnoxLdapRealm will not work unless the 
> KnoxLdapContextFactory is also configured.  In particular the use of an 
> ${ALIAS=...} in the >main.ldapRealm.contextFactory.systemPassword param.  As 
> this is such a common and important use cases the KnoxLdapContextFactory 
> should be included in all default topology files, all sample topology files 
> and all documented topology files.
> The snippet below shows what needs to be added to the topology files.
> {code:xml}
> 
> 
> 
> authentication
> ShiroProvider
> true
> ...
> 
> main.ldapRealm
> 
> org.apache.hadoop.gateway.shirorealm.KnoxLdapRealm
> 
> 
> main.ldapContextFactory
> 
> org.apache.hadoop.gateway.shirorealm.KnoxLdapContextFactory
> 
> 
> main.ldapRealm.contextFactory
> $ldapContextFactory
> 
> ...
> 
> ...
> 
> {code}
> Without this in particular there were exceptions in the gateway.log file at 
> startup when password indirection was used in the ShiroProvider section like 
> this.
> {code:xml}
> 
> main.ldapRealm.contextFactory.systemPassword
> ${ALIAS=adSysPwd}
> 
> {code}
> Those exceptions look like this.  Indicating that the wrong 
> LdapContextFactory was being used.  Specifically the default one that does 
> not have a setClusterName method.
> {code}
> 2014-10-02 13:25:09,888 ERROR env.EnvironmentLoader 
> (EnvironmentLoader.java:initEnvironment(146)) - Shiro environment in
> itialization failed
> org.apache.shiro.config.ConfigurationException: Property 
> 'contextFactory.clusterName' does not exist for object of type
> org.apache.hadoop.gateway.shirorealm.KnoxLdapRealm.
>at 
> org.apache.shiro.config.ReflectionBuilder.isTypedProperty(ReflectionBuilder.java:255)
>at 
> org.apache.shiro.config.ReflectionBuilder.applyProperty(ReflectionBuilder.java:544)
>at 
> org.apache.shiro.config.ReflectionBuilder.applySingleProperty(ReflectionBuilder.java:206)
>at 
> org.apache.shiro.config.ReflectionBuilder.applyProperty(ReflectionBuilder.java:167)
>at 
> org.apache.shiro.config.ReflectionBuilder.buildObjects(ReflectionBuilder.java:124)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (KNOX-428) Publish Knox release artifacts to Apache maven repo

2014-11-11 Thread Larry McCay (JIRA)

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

Larry McCay resolved KNOX-428.
--
Resolution: Fixed

> Publish Knox release artifacts to Apache maven repo
> ---
>
> Key: KNOX-428
> URL: https://issues.apache.org/jira/browse/KNOX-428
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 0.5.0
>Reporter: Kevin Minder
>Assignee: Kevin Minder
> Fix For: 0.5.0
>
> Attachments: KNOX-428-1.patch
>
>
> See the instructions provided here: 
> http://www.apache.org/dev/publishing-maven-artifacts.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (KNOX-470) Add README to Samples and Documentation

2014-11-11 Thread ASF subversion and git services (JIRA)

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

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

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

KNOX-470 - add README and site docs for samples

> Add README to Samples and Documentation
> ---
>
> Key: KNOX-470
> URL: https://issues.apache.org/jira/browse/KNOX-470
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server, Site
>Reporter: Larry McCay
>
> We need to ensure better OOTB experience with the samples provided with the 
> distribution. Let's add a README to the samples directory that points to a 
> new section in the users guide.
> The samples section in the users guide will describe the assumptions made by 
> the samples and the steps to ensure that they are fully installed and 
> configured in various deployment scenarios.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (KNOX-470) Add README to Samples and Documentation

2014-11-11 Thread Larry McCay (JIRA)
Larry McCay created KNOX-470:


 Summary: Add README to Samples and Documentation
 Key: KNOX-470
 URL: https://issues.apache.org/jira/browse/KNOX-470
 Project: Apache Knox
  Issue Type: Improvement
  Components: Server, Site
Reporter: Larry McCay


We need to ensure better OOTB experience with the samples provided with the 
distribution. Let's add a README to the samples directory that points to a new 
section in the users guide.

The samples section in the users guide will describe the assumptions made by 
the samples and the steps to ensure that they are fully installed and 
configured in various deployment scenarios.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)