knox-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From su...@apache.org
Subject svn commit: r1738573 - in /knox: site/books/knox-0-9-0/user-guide.html trunk/books/0.9.0/book_ui_service_details.md
Date Mon, 11 Apr 2016 12:01:46 GMT
Author: sumit
Date: Mon Apr 11 12:01:46 2016
New Revision: 1738573

URL: http://svn.apache.org/viewvc?rev=1738573&view=rev
Log:
KNOX-673 Docs for ambari and ranger ui

Modified:
    knox/site/books/knox-0-9-0/user-guide.html
    knox/trunk/books/0.9.0/book_ui_service_details.md

Modified: knox/site/books/knox-0-9-0/user-guide.html
URL: http://svn.apache.org/viewvc/knox/site/books/knox-0-9-0/user-guide.html?rev=1738573&r1=1738572&r2=1738573&view=diff
==============================================================================
--- knox/site/books/knox-0-9-0/user-guide.html (original)
+++ knox/site/books/knox-0-9-0/user-guide.html Mon Apr 11 12:01:46 2016
@@ -4653,6 +4653,8 @@ curl -ik -b ~/cookiejar.txt -c ~/cookiej
   <li><a href="#HBase+UI">HBase UI</a></li>
   <li><a href="#Yarn+UI">Yarn UI</a></li>
   <li><a href="#Spark+UI">Spark UI</a></li>
+  <li><a href="#Ambari+UI">Ambari UI</a></li>
+  <li><a href="#Ranger+Admin+Console">Ranger Admin Console</a></li>
 </ul><h3><a id="Assumptions">Assumptions</a> <a href="#Assumptions"><img
src="markbook-section-link.png"/></a></h3><p>This section assumes an
environment setup similar to the one in the REST services section <a href="#Service+Details">Service
Details</a></p><h3><a id="Name+Node+UI">Name Node UI</a> <a
href="#Name+Node+UI"><img src="markbook-section-link.png"/></a></h3><p>The
Name Node UI is available on the same host and port combination that WebHDFS is available
on. As mentioned in the WebHDFS REST service configuration section, the values for the host
and port can be obtained from the following properties in hdfs-site.xml</p>
 <pre><code>&lt;property&gt;
     &lt;name&gt;dfs.namenode.http-address&lt;/name&gt;
@@ -4801,7 +4803,89 @@ curl -ik -b ~/cookiejar.txt -c ~/cookiej
       <td><code>http://{spark-history-host}:18080</code> </td>
     </tr>
   </tbody>
-</table><h2><a id="Limitations">Limitations</a> <a href="#Limitations"><img
src="markbook-section-link.png"/></a></h2><h3><a id="Secure+Oozie+POST/PUT+Request+Payload+Size+Restriction">Secure
Oozie POST/PUT Request Payload Size Restriction</a> <a href="#Secure+Oozie+POST/PUT+Request+Payload+Size+Restriction"><img
src="markbook-section-link.png"/></a></h3><p>With one exception there
are no known size limits for requests or responses payloads that pass through the gateway.
The exception involves POST or PUT request payload sizes for Oozie in a Kerberos secured Hadoop
cluster. In this one case there is currently a 4Kb payload size limit for the first request
made to the Hadoop cluster. This is a result of how the gateway negotiates a trust relationship
between itself and the cluster via SPNego. There is an undocumented configuration setting
to modify this limit&rsquo;s value if required. In the future this will be made more easily
configurable and at that time it will be documented.</p
 ><h3><a id="Group+Membership+Propagation">Group Membership Propagation</a>
<a href="#Group+Membership+Propagation"><img src="markbook-section-link.png"/></a></h3><p>Groups
that are acquired via Shiro Group Lookup and/or Identity Assertion Group Principal Mapping
are not propagated to the Hadoop services. Therefore, groups used for Service Level Authorization
policy may not match those acquired within the cluster via GroupMappingServiceProvider plugins.</p><h2><a
id="Troubleshooting">Troubleshooting</a> <a href="#Troubleshooting"><img
src="markbook-section-link.png"/></a></h2><h3><a id="Finding+Logs">Finding
Logs</a> <a href="#Finding+Logs"><img src="markbook-section-link.png"/></a></h3><p>When
things aren&rsquo;t working the first thing you need to do is examine the diagnostic logs.
Depending upon how you are running the gateway these diagnostic logs will be output to different
locations.</p><h4><a id="java+-jar+bin/gateway.jar">java -jar bin/gateway.jar</a>
<a href="#java+-jar+bin/
 gateway.jar"><img src="markbook-section-link.png"/></a></h4><p>When
the gateway is run this way the diagnostic output is written directly to the console. If you
want to capture that output you will need to redirect the console output to a file using OS
specific techniques.</p>
+</table><h3><a id="Ambari+UI">Ambari UI</a> <a href="#Ambari+UI"><img
src="markbook-section-link.png"/></a></h3><p>Ambari UI has functionality
around provisioning and managing services in a hadoop cluster. This UI can now be used behind
the Knox gateway.</p><p>To enable this functionality, a topology file needs to
have the following configuration:</p>
+<pre><code>&lt;service&gt;
+    &lt;role&gt;AMBARIUI&lt;/role&gt;
+    &lt;url&gt;http://&lt;hostname&gt;:&lt;port&gt;&lt;/url&gt;
+&lt;/service&gt;
+</code></pre><p>The default Ambari http port is 8080. Also please note
that the UI service also requires the Ambari REST API service  to be enabled to function properly.
An example of a more complete topology is given below.</p><h4><a id="Ambari+UI+URL+Mapping">Ambari
UI URL Mapping</a> <a href="#Ambari+UI+URL+Mapping"><img src="markbook-section-link.png"/></a></h4><p>For
Ambari UI URLs, the mapping of Knox Gateway accessible URLs to direct Ambari UI URLs is the
following.</p>
+<table>
+  <tbody>
+    <tr>
+      <td>Gateway </td>
+      <td><code>https://{gateway-host}:{gateway-port}/{gateway-path}/{cluster-name}/ambari/</code>
</td>
+    </tr>
+    <tr>
+      <td>Cluster </td>
+      <td><code>http://{ambari-host}:{ambari-port}/}</code> </td>
+    </tr>
+  </tbody>
+</table><h4><a id="Example+Topology">Example Topology</a> <a href="#Example+Topology"><img
src="markbook-section-link.png"/></a></h4><p>The Ambari UI service may
require a separate topology file due to its requirements around authentication. Knox passes
through authentication challenge and credentials to the service in this case.</p>
+<pre><code>&lt;topology&gt;
+    &lt;gateway&gt;
+        &lt;provider&gt;
+            &lt;role&gt;authentication&lt;/role&gt;
+            &lt;name&gt;Anonymous&lt;/name&gt;
+            &lt;enabled&gt;true&lt;/enabled&gt;
+        &lt;/provider&gt;
+        &lt;provider&gt;
+            &lt;role&gt;identity-assertion&lt;/role&gt;
+            &lt;name&gt;Default&lt;/name&gt;
+            &lt;enabled&gt;false&lt;/enabled&gt;
+        &lt;/provider&gt;
+    &lt;/gateway&gt;
+    &lt;service&gt;
+        &lt;role&gt;AMBARI&lt;/role&gt;
+        &lt;url&gt;http://localhost:8080&lt;/url&gt;
+    &lt;/service&gt;
+
+    &lt;service&gt;
+        &lt;role&gt;AMBARIUI&lt;/role&gt;
+        &lt;url&gt;http://localhost:8080&lt;/url&gt;
+    &lt;/service&gt;
+&lt;/topology&gt;
+</code></pre><p>Please look at JIRA issue [KNOX-705] for a known issue
with this release.</p><h3><a id="Ranger+Admin+Console">Ranger Admin Console</a>
<a href="#Ranger+Admin+Console"><img src="markbook-section-link.png"/></a></h3><p>The
Ranger Admin console can now be used behind the Knox gateway.</p><p>To enable
this functionality, a topology file needs to have the following configuration:</p>
+<pre><code>&lt;service&gt;
+    &lt;role&gt;RANGERUI&lt;/role&gt;
+    &lt;url&gt;http://&lt;hostname&gt;:&lt;port&gt;&lt;/url&gt;
+&lt;/service&gt;
+</code></pre><p>The default Ranger http port is 8060. Also please note
that the UI service also requires the Ranger REST API service  to be enabled to function properly.
An example of a more complete topology is given below.</p><h4><a id="Ranger+Admin+Console+URL+Mapping">Ranger
Admin Console URL Mapping</a> <a href="#Ranger+Admin+Console+URL+Mapping"><img
src="markbook-section-link.png"/></a></h4><p>For Ranger Admin console
URLs, the mapping of Knox Gateway accessible URLs to direct Ranger Admin console URLs is the
following.</p>
+<table>
+  <tbody>
+    <tr>
+      <td>Gateway </td>
+      <td><code>https://{gateway-host}:{gateway-port}/{gateway-path}/{cluster-name}/ranger/</code>
</td>
+    </tr>
+    <tr>
+      <td>Cluster </td>
+      <td><code>http://{ranger-host}:{ranger-port}/}</code> </td>
+    </tr>
+  </tbody>
+</table><h4><a id="Example+Topology">Example Topology</a> <a href="#Example+Topology"><img
src="markbook-section-link.png"/></a></h4><p>The Ranger UI service may
require a separate topology file due to its requirements around authentication. Knox passes
through authentication challenge and credentials to the service in this case.</p>
+<pre><code>&lt;topology&gt;
+    &lt;gateway&gt;
+        &lt;provider&gt;
+            &lt;role&gt;authentication&lt;/role&gt;
+            &lt;name&gt;Anonymous&lt;/name&gt;
+            &lt;enabled&gt;true&lt;/enabled&gt;
+        &lt;/provider&gt;
+        &lt;provider&gt;
+            &lt;role&gt;identity-assertion&lt;/role&gt;
+            &lt;name&gt;Default&lt;/name&gt;
+            &lt;enabled&gt;false&lt;/enabled&gt;
+        &lt;/provider&gt;
+    &lt;/gateway&gt;
+    &lt;service&gt;
+        &lt;role&gt;RANGER&lt;/role&gt;
+        &lt;url&gt;http://localhost:8060&lt;/url&gt;
+    &lt;/service&gt;
+
+    &lt;service&gt;
+        &lt;role&gt;RANGERUI&lt;/role&gt;
+        &lt;url&gt;http://localhost:8060&lt;/url&gt;
+    &lt;/service&gt;
+&lt;/topology&gt;
+</code></pre><h2><a id="Limitations">Limitations</a> <a
href="#Limitations"><img src="markbook-section-link.png"/></a></h2><h3><a
id="Secure+Oozie+POST/PUT+Request+Payload+Size+Restriction">Secure Oozie POST/PUT Request
Payload Size Restriction</a> <a href="#Secure+Oozie+POST/PUT+Request+Payload+Size+Restriction"><img
src="markbook-section-link.png"/></a></h3><p>With one exception there
are no known size limits for requests or responses payloads that pass through the gateway.
The exception involves POST or PUT request payload sizes for Oozie in a Kerberos secured Hadoop
cluster. In this one case there is currently a 4Kb payload size limit for the first request
made to the Hadoop cluster. This is a result of how the gateway negotiates a trust relationship
between itself and the cluster via SPNego. There is an undocumented configuration setting
to modify this limit&rsquo;s value if required. In the future this will be made more easily
configurable and at that time it will be documente
 d.</p><h3><a id="Group+Membership+Propagation">Group Membership Propagation</a>
<a href="#Group+Membership+Propagation"><img src="markbook-section-link.png"/></a></h3><p>Groups
that are acquired via Shiro Group Lookup and/or Identity Assertion Group Principal Mapping
are not propagated to the Hadoop services. Therefore, groups used for Service Level Authorization
policy may not match those acquired within the cluster via GroupMappingServiceProvider plugins.</p><h2><a
id="Troubleshooting">Troubleshooting</a> <a href="#Troubleshooting"><img
src="markbook-section-link.png"/></a></h2><h3><a id="Finding+Logs">Finding
Logs</a> <a href="#Finding+Logs"><img src="markbook-section-link.png"/></a></h3><p>When
things aren&rsquo;t working the first thing you need to do is examine the diagnostic logs.
Depending upon how you are running the gateway these diagnostic logs will be output to different
locations.</p><h4><a id="java+-jar+bin/gateway.jar">java -jar bin/gateway.jar</a>
<a href="#java+-jar
 +bin/gateway.jar"><img src="markbook-section-link.png"/></a></h4><p>When
the gateway is run this way the diagnostic output is written directly to the console. If you
want to capture that output you will need to redirect the console output to a file using OS
specific techniques.</p>
 <pre><code>java -jar bin/gateway.jar &gt; gateway.log
 </code></pre><h4><a id="bin/gateway.sh+start">bin/gateway.sh start</a>
<a href="#bin/gateway.sh+start"><img src="markbook-section-link.png"/></a></h4><p>When
the gateway is run this way the diagnostic output is written to <code>{GATEWAY_HOME}/log/knox.out</code>
and <code>{GATEWAY_HOME}/log/knox.err</code>. Typically only knox.out will have
content.</p><h3><a id="Increasing+Logging">Increasing Logging</a>
<a href="#Increasing+Logging"><img src="markbook-section-link.png"/></a></h3><p>The
<code>log4j.properties</code> files <code>{GATEWAY_HOME}/conf</code>
can be used to change the granularity of the logging done by Knox. The Knox server must be
restarted in order for these changes to take effect. There are various useful loggers pre-populated
but commented out.</p>
 <pre><code>log4j.logger.org.apache.hadoop.gateway=DEBUG # Use this logger to
increase the debugging of Apache Knox itself.

Modified: knox/trunk/books/0.9.0/book_ui_service_details.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.9.0/book_ui_service_details.md?rev=1738573&r1=1738572&r2=1738573&view=diff
==============================================================================
--- knox/trunk/books/0.9.0/book_ui_service_details.md (original)
+++ knox/trunk/books/0.9.0/book_ui_service_details.md Mon Apr 11 12:01:46 2016
@@ -29,6 +29,8 @@ These are the current Hadoop services wi
 * #[HBase UI]
 * #[Yarn UI]
 * #[Spark UI]
+* #[Ambari UI]
+* #[Ranger Admin Console]
 
 ### Assumptions
 
@@ -221,3 +223,116 @@ UI URLs is:
 | ------- | -----------------------------------------------------------------------------
|
 | Gateway | `https://{gateway-host}:{gateway-port}/{gateway-path}/{cluster-name}/sparkhistory`
   |
 | Cluster | `http://{spark-history-host}:18080`                                         
         |
+
+
+### Ambari UI ###
+
+Ambari UI has functionality around provisioning and managing services in a hadoop cluster.
This UI can now be used 
+behind the Knox gateway.
+
+
+To enable this functionality, a topology file needs to have the following configuration:
+
+    <service>
+        <role>AMBARIUI</role>
+        <url>http://<hostname>:<port></url>
+    </service>
+
+The default Ambari http port is 8080. Also please note that the UI service also requires
the Ambari REST API service
+ to be enabled to function properly. An example of a more complete topology is given below.
+ 
+
+#### Ambari UI URL Mapping ####
+
+For Ambari UI URLs, the mapping of Knox Gateway accessible URLs to direct Ambari UI URLs
is the following.
+
+| ------- | -------------------------------------------------------------------------------------
|
+| Gateway | `https://{gateway-host}:{gateway-port}/{gateway-path}/{cluster-name}/ambari/`
        |
+| Cluster | `http://{ambari-host}:{ambari-port}/}`                                      
         |
+
+#### Example Topology ####
+ 
+The Ambari UI service may require a separate topology file due to its requirements around
authentication. Knox passes
+through authentication challenge and credentials to the service in this case.
+
+
+    <topology>
+        <gateway>
+            <provider>
+                <role>authentication</role>
+                <name>Anonymous</name>
+                <enabled>true</enabled>
+            </provider>
+            <provider>
+                <role>identity-assertion</role>
+                <name>Default</name>
+                <enabled>false</enabled>
+            </provider>
+        </gateway>
+        <service>
+            <role>AMBARI</role>
+            <url>http://localhost:8080</url>
+        </service>
+    
+        <service>
+            <role>AMBARIUI</role>
+            <url>http://localhost:8080</url>
+        </service>
+    </topology>
+    
+Please look at JIRA issue [KNOX-705] for a known issue with this release.
+
+### Ranger Admin Console ###
+
+The Ranger Admin console can now be used behind the Knox gateway.
+
+To enable this functionality, a topology file needs to have the following configuration:
+
+    <service>
+        <role>RANGERUI</role>
+        <url>http://<hostname>:<port></url>
+    </service>
+
+The default Ranger http port is 8060. Also please note that the UI service also requires
the Ranger REST API service
+ to be enabled to function properly. An example of a more complete topology is given below.
+ 
+
+#### Ranger Admin Console URL Mapping ####
+
+For Ranger Admin console URLs, the mapping of Knox Gateway accessible URLs to direct Ranger
Admin console URLs is the following.
+
+| ------- | -------------------------------------------------------------------------------------
|
+| Gateway | `https://{gateway-host}:{gateway-port}/{gateway-path}/{cluster-name}/ranger/`
        |
+| Cluster | `http://{ranger-host}:{ranger-port}/}`                                      
         |
+
+#### Example Topology ####
+ 
+The Ranger UI service may require a separate topology file due to its requirements around
authentication. Knox passes
+through authentication challenge and credentials to the service in this case.
+
+
+    <topology>
+        <gateway>
+            <provider>
+                <role>authentication</role>
+                <name>Anonymous</name>
+                <enabled>true</enabled>
+            </provider>
+            <provider>
+                <role>identity-assertion</role>
+                <name>Default</name>
+                <enabled>false</enabled>
+            </provider>
+        </gateway>
+        <service>
+            <role>RANGER</role>
+            <url>http://localhost:8060</url>
+        </service>
+    
+        <service>
+            <role>RANGERUI</role>
+            <url>http://localhost:8060</url>
+        </service>
+    </topology>
+    
+    
\ No newline at end of file



Mime
View raw message