knox-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lmc...@apache.org
Subject svn commit: r1588708 - in /knox: site/books/knox-0-4-0/knox-0-4-0-new.html site/books/knox-0-4-0/knox-0-4-0.html trunk/books/0.4.0/knox_cli.md
Date Sat, 19 Apr 2014 21:24:44 GMT
Author: lmccay
Date: Sat Apr 19 21:24:44 2014
New Revision: 1588708

URL: http://svn.apache.org/r1588708
Log:
KNOX-329 update the Knox CLI docs

Modified:
    knox/site/books/knox-0-4-0/knox-0-4-0-new.html
    knox/site/books/knox-0-4-0/knox-0-4-0.html
    knox/trunk/books/0.4.0/knox_cli.md

Modified: knox/site/books/knox-0-4-0/knox-0-4-0-new.html
URL: http://svn.apache.org/viewvc/knox/site/books/knox-0-4-0/knox-0-4-0-new.html?rev=1588708&r1=1588707&r2=1588708&view=diff
==============================================================================
--- knox/site/books/knox-0-4-0/knox-0-4-0-new.html (original)
+++ knox/site/books/knox-0-4-0/knox-0-4-0-new.html Sat Apr 19 21:24:44 2014
@@ -427,7 +427,7 @@ ip-10-39-107-209.ec2.internal
   <li>All security related artifacts are protected with the master secret</li>
   <li>Secrets used by the gateway itself are stored within the gateway credential store
and are the same across all gateway instances in the cluster of gateways</li>
   <li>Secrets used by providers within cluster topologies are stored in topology specific
credential stores and are the same for the same topology across the cluster of gateway instances.
 However, they are specific to the topology - so secrets for one hadoop cluster are different
from those of another.  This allows for fail-over from one gateway instance to another even
when encryption is being used while not allowing the compromise of one encryption key to expose
the data for all clusters.</li>
-</ol><p>NOTE: the SSL certificate will need special consideration depending on
the type of certificate. Wildcard certs may be able to be shared across all gateway instances
in a cluster. When certs are dedicated to specific machines the gateway identity store will
not be able to be blindly replicated as host name verification problems will ensue. Obviously,
trust-stores will need to be taken into account as well.</p></div><div id="Knox+CLI"><h3><a
id="Knox+CLI"></a>Knox CLI</h3><p>The Knox CLI is a command line utility
for management of various aspects of the Knox deployment. It is primarily concerned with the
management of the security artifacts for the gateway instance and each of the deployed topologies
or hadoop clusters that are gated by the Knox Gateway instance.</p><p>The various
security artifacts are also generated and populated automatically by the Knox Gateway runtime
when they are not found at startup. The assumptions made in those cases are appropriate for
a test or dev
 elopment gateway instance and assume &lsquo;localhost&rsquo; for hostname specific
activities. For production deployments the use of the CLI may aid in managing some production
deployments.</p><p>The knoxcli.sh script is located in the {GATEWAY_HOME}/bin
directory.</p><h4><a id="Help"></a>Help</h4><h5><a
id="knoxcli.sh+[--help]"></a>knoxcli.sh [&ndash;help]</h5><p>prints
help for all commands</p><h4><a id="Master+secret+persistence"></a>Master
secret persistence</h4><h5><a id="knoxcli.sh+create-master+[--help]"></a>knoxcli.sh
create-master [&ndash;help]</h5><p>Creates and persists an encrypted master
secret in a file within {GATEWAY_HOME}/data/security/master. </p><p>NOTE: This
command fails when there is an existing master file in the expected location.</p><h4><a
id="Alias+creation"></a>Alias creation</h4><h5><a id="knoxcli.sh+create-alias+n+[--cluster+c]+[--value+v]+[--generate]+[--help]"></a>knoxcli.sh
create-alias n [&ndash;cluster c] [&ndash;value v] [&ndash;generate] [&ndash;h
 elp]</h5><p>Creates a password alias and stores it in a credential store within
the {GATEWAY_HOME}/data/security/keystores dir. </p>
+</ol><p>NOTE: the SSL certificate will need special consideration depending on
the type of certificate. Wildcard certs may be able to be shared across all gateway instances
in a cluster. When certs are dedicated to specific machines the gateway identity store will
not be able to be blindly replicated as host name verification problems will ensue. Obviously,
trust-stores will need to be taken into account as well.</p></div><div id="Knox+CLI"><h3><a
id="Knox+CLI"></a>Knox CLI</h3><p>The Knox CLI is a command line utility
for management of various aspects of the Knox deployment. It is primarily concerned with the
management of the security artifacts for the gateway instance and each of the deployed topologies
or hadoop clusters that are gated by the Knox Gateway instance.</p><p>The various
security artifacts are also generated and populated automatically by the Knox Gateway runtime
when they are not found at startup. The assumptions made in those cases are appropriate for
a test or dev
 elopment gateway instance and assume &lsquo;localhost&rsquo; for hostname specific
activities. For production deployments the use of the CLI may aid in managing some production
deployments.</p><p>The knoxcli.sh script is located in the {GATEWAY_HOME}/bin
directory.</p><h4><a id="Help"></a>Help</h4><h5><a
id="knoxcli.sh+[--help]"></a>knoxcli.sh [&ndash;help]</h5><p>prints
help for all commands</p><h4><a id="Knox+Verison+Info"></a>Knox Verison
Info</h4><h5><a id="knoxcli.sh+version+[--help]"></a>knoxcli.sh version
[&ndash;help]</h5><p>Displays Knox version information.</p><h4><a
id="Master+secret+persistence"></a>Master secret persistence</h4><h5><a
id="knoxcli.sh+create-master+[--force][--help]"></a>knoxcli.sh create-master [&ndash;force][&ndash;help]</h5><p>Creates
and persists an encrypted master secret in a file within {GATEWAY_HOME}/data/security/master.
</p><p>NOTE: This command fails when there is an existing master file in the expected
location. You may force it to overwrite t
 he master file with the &ndash;force switch. NOTE: this will require you to change passwords
protecting the keystores for the gateway identity keystores and all credential stores.</p><h4><a
id="Alias+creation"></a>Alias creation</h4><h5><a id="knoxcli.sh+create-alias+n+[--cluster+c]+[--value+v]+[--generate]+[--help]"></a>knoxcli.sh
create-alias n [&ndash;cluster c] [&ndash;value v] [&ndash;generate] [&ndash;help]</h5><p>Creates
a password alias and stores it in a credential store within the {GATEWAY_HOME}/data/security/keystores
dir. </p>
 <table>
   <thead>
     <tr>
@@ -499,7 +499,7 @@ ip-10-39-107-209.ec2.internal
       <td>name of the host to be used in the self-signed certificate. This allows multi-host
deployments to specify the proper hostnames for hostname verification to succeed on the client
side of the SSL connection. The default is “localhost”.</td>
     </tr>
   </tbody>
-</table></div><div id="Authentication"><h3><a id="Authentication"></a>Authentication</h3><p>There
are two types of providers supported in Knox for establishing a user&rsquo;s identity:</p>
+</table><h4><a id="Topology+Redeploy"></a>Topology Redeploy</h4><h4><a
id="redeploy+[--cluster+c]"></a>redeploy [&ndash;cluster c]</h4><p>Redeploys
one or all of the gateway&rsquo;s clusters (a.k.a topologies).</p></div><div
id="Authentication"><h3><a id="Authentication"></a>Authentication</h3><p>There
are two types of providers supported in Knox for establishing a user&rsquo;s identity:</p>
 <ol>
   <li>Authentication Providers</li>
   <li>Federation Providers</li>

Modified: knox/site/books/knox-0-4-0/knox-0-4-0.html
URL: http://svn.apache.org/viewvc/knox/site/books/knox-0-4-0/knox-0-4-0.html?rev=1588708&r1=1588707&r2=1588708&view=diff
==============================================================================
--- knox/site/books/knox-0-4-0/knox-0-4-0.html (original)
+++ knox/site/books/knox-0-4-0/knox-0-4-0.html Sat Apr 19 21:24:44 2014
@@ -427,7 +427,7 @@ ip-10-39-107-209.ec2.internal
   <li>All security related artifacts are protected with the master secret</li>
   <li>Secrets used by the gateway itself are stored within the gateway credential store
and are the same across all gateway instances in the cluster of gateways</li>
   <li>Secrets used by providers within cluster topologies are stored in topology specific
credential stores and are the same for the same topology across the cluster of gateway instances.
 However, they are specific to the topology - so secrets for one hadoop cluster are different
from those of another.  This allows for fail-over from one gateway instance to another even
when encryption is being used while not allowing the compromise of one encryption key to expose
the data for all clusters.</li>
-</ol><p>NOTE: the SSL certificate will need special consideration depending on
the type of certificate. Wildcard certs may be able to be shared across all gateway instances
in a cluster. When certs are dedicated to specific machines the gateway identity store will
not be able to be blindly replicated as host name verification problems will ensue. Obviously,
trust-stores will need to be taken into account as well.</p><h3><a id="Knox+CLI"></a>Knox
CLI</h3><p>The Knox CLI is a command line utility for management of various aspects
of the Knox deployment. It is primarily concerned with the management of the security artifacts
for the gateway instance and each of the deployed topologies or hadoop clusters that are gated
by the Knox Gateway instance.</p><p>The various security artifacts are also generated
and populated automatically by the Knox Gateway runtime when they are not found at startup.
The assumptions made in those cases are appropriate for a test or development gateway instance
  and assume &lsquo;localhost&rsquo; for hostname specific activities. For production
deployments the use of the CLI may aid in managing some production deployments.</p><p>The
knoxcli.sh script is located in the {GATEWAY_HOME}/bin directory.</p><h4><a
id="Help"></a>Help</h4><h5><a id="knoxcli.sh+[--help]"></a>knoxcli.sh
[&ndash;help]</h5><p>prints help for all commands</p><h4><a
id="Master+secret+persistence"></a>Master secret persistence</h4><h5><a
id="knoxcli.sh+create-master+[--help]"></a>knoxcli.sh create-master [&ndash;help]</h5><p>Creates
and persists an encrypted master secret in a file within {GATEWAY_HOME}/data/security/master.
</p><p>NOTE: This command fails when there is an existing master file in the expected
location.</p><h4><a id="Alias+creation"></a>Alias creation</h4><h5><a
id="knoxcli.sh+create-alias+n+[--cluster+c]+[--value+v]+[--generate]+[--help]"></a>knoxcli.sh
create-alias n [&ndash;cluster c] [&ndash;value v] [&ndash;generate] [&ndash;help]</h5><p>Creates
a pas
 sword alias and stores it in a credential store within the {GATEWAY_HOME}/data/security/keystores
dir. </p>
+</ol><p>NOTE: the SSL certificate will need special consideration depending on
the type of certificate. Wildcard certs may be able to be shared across all gateway instances
in a cluster. When certs are dedicated to specific machines the gateway identity store will
not be able to be blindly replicated as host name verification problems will ensue. Obviously,
trust-stores will need to be taken into account as well.</p><h3><a id="Knox+CLI"></a>Knox
CLI</h3><p>The Knox CLI is a command line utility for management of various aspects
of the Knox deployment. It is primarily concerned with the management of the security artifacts
for the gateway instance and each of the deployed topologies or hadoop clusters that are gated
by the Knox Gateway instance.</p><p>The various security artifacts are also generated
and populated automatically by the Knox Gateway runtime when they are not found at startup.
The assumptions made in those cases are appropriate for a test or development gateway instance
  and assume &lsquo;localhost&rsquo; for hostname specific activities. For production
deployments the use of the CLI may aid in managing some production deployments.</p><p>The
knoxcli.sh script is located in the {GATEWAY_HOME}/bin directory.</p><h4><a
id="Help"></a>Help</h4><h5><a id="knoxcli.sh+[--help]"></a>knoxcli.sh
[&ndash;help]</h5><p>prints help for all commands</p><h4><a
id="Knox+Verison+Info"></a>Knox Verison Info</h4><h5><a id="knoxcli.sh+version+[--help]"></a>knoxcli.sh
version [&ndash;help]</h5><p>Displays Knox version information.</p><h4><a
id="Master+secret+persistence"></a>Master secret persistence</h4><h5><a
id="knoxcli.sh+create-master+[--force][--help]"></a>knoxcli.sh create-master [&ndash;force][&ndash;help]</h5><p>Creates
and persists an encrypted master secret in a file within {GATEWAY_HOME}/data/security/master.
</p><p>NOTE: This command fails when there is an existing master file in the expected
location. You may force it to overwrite the master file with the &
 ndash;force switch. NOTE: this will require you to change passwords protecting the keystores
for the gateway identity keystores and all credential stores.</p><h4><a id="Alias+creation"></a>Alias
creation</h4><h5><a id="knoxcli.sh+create-alias+n+[--cluster+c]+[--value+v]+[--generate]+[--help]"></a>knoxcli.sh
create-alias n [&ndash;cluster c] [&ndash;value v] [&ndash;generate] [&ndash;help]</h5><p>Creates
a password alias and stores it in a credential store within the {GATEWAY_HOME}/data/security/keystores
dir. </p>
 <table>
   <thead>
     <tr>
@@ -499,7 +499,7 @@ ip-10-39-107-209.ec2.internal
       <td>name of the host to be used in the self-signed certificate. This allows multi-host
deployments to specify the proper hostnames for hostname verification to succeed on the client
side of the SSL connection. The default is “localhost”.</td>
     </tr>
   </tbody>
-</table><h3><a id="Authentication"></a>Authentication</h3><p>There
are two types of providers supported in Knox for establishing a user&rsquo;s identity:</p>
+</table><h4><a id="Topology+Redeploy"></a>Topology Redeploy</h4><h4><a
id="redeploy+[--cluster+c]"></a>redeploy [&ndash;cluster c]</h4><p>Redeploys
one or all of the gateway&rsquo;s clusters (a.k.a topologies).</p><h3><a
id="Authentication"></a>Authentication</h3><p>There are two types of
providers supported in Knox for establishing a user&rsquo;s identity:</p>
 <ol>
   <li>Authentication Providers</li>
   <li>Federation Providers</li>

Modified: knox/trunk/books/0.4.0/knox_cli.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.4.0/knox_cli.md?rev=1588708&r1=1588707&r2=1588708&view=diff
==============================================================================
--- knox/trunk/books/0.4.0/knox_cli.md (original)
+++ knox/trunk/books/0.4.0/knox_cli.md Sat Apr 19 21:24:44 2014
@@ -26,11 +26,15 @@ The knoxcli.sh script is located in the 
 ##### knoxcli.sh [--help] #####
 prints help for all commands
 
+#### Knox Verison Info ####
+##### knoxcli.sh version [--help] #####
+Displays Knox version information.
+
 #### Master secret persistence ####
-##### knoxcli.sh create-master [--help] #####
+##### knoxcli.sh create-master [--force][--help] #####
 Creates and persists an encrypted master secret in a file within {GATEWAY_HOME}/data/security/master.

 
-NOTE: This command fails when there is an existing master file in the expected location.
+NOTE: This command fails when there is an existing master file in the expected location.
You may force it to overwrite the master file with the --force switch. NOTE: this will require
you to change passwords protecting the keystores for the gateway identity keystores and all
credential stores.
 
 #### Alias creation ####
 ##### knoxcli.sh create-alias n [--cluster c] [--value v] [--generate] [--help] #####
@@ -68,3 +72,7 @@ argument | description
 :--------|-----------
 --hostname	|	name of the host to be used in the self-signed certificate. This allows multi-host
deployments to specify the proper hostnames for hostname verification to succeed on the client
side of the SSL connection. The default is “localhost”.
 
+#### Topology Redeploy ####
+#### redeploy [--cluster c] ####
+Redeploys one or all of the gateway's clusters (a.k.a topologies).
+



Mime
View raw message