GitBook: [master] 6 pages modified

SUMMARY.md

@@ -146,7 +146,7 @@
 * [nats](nats-tools/natscli.md)
 * [nk](nats-tools/nk.md)
 * [nsc](nats-tools/nsc/README.md)
-  * [Basics](nats-tools/nsc/nsc.md)
+  * [Basics](nats-tools/nsc/basics.md)
   * [Streams](nats-tools/nsc/streams.md)
   * [Services](nats-tools/nsc/services.md)
   * [Signing Keys](nats-tools/nsc/signing_keys.md)

jetstream/disaster_recovery.md

@@ -1,4 +1,4 @@
-# Disaster Recovery
+# Disaser Recovery
 
 Disaster Recovery of the JetStream system is a topic we are still exploring and fleshing out and that will be impacted by the clustering work. For example replication will extend the options available to you.
 

nats-server/configuration/securing_nats/jwt/README.md

@@ -56,11 +56,11 @@ Lastly, all NATS JWTs \(Operators, Accounts, Users and others\) are expected to
 
 Configuration is broken up into separate steps. Depending on organizational needs these are performed by the same or different entities.
 
-JWT configuration is done using the [`nsc` tool](../../../../nats-tools/nsc/). It can be set up to issue [NKeys](../auth_intro/nkey_auth.md) and corresponding JWTs for all [nkey roles](./#nkey-roles): Operator/Account/User \([Example usage](../../../../nats-tools/nsc/nsc.md#creating-an-operator-account-and-user)\). Despite Account and User creation not happening in server configuration, this model is a centralized authentication and authorization setup.
+JWT configuration is done using the [`nsc` tool](../../../../nats-tools/nsc/). It can be set up to issue [NKeys](../auth_intro/nkey_auth.md) and corresponding JWTs for all [nkey roles](./#nkey-roles): Operator/Account/User \([Example usage](../../../../nats-tools/nsc/basics.md#creating-an-operator-account-and-user)\). Despite Account and User creation not happening in server configuration, this model is a centralized authentication and authorization setup.
 
 Provided institutional trust, it is also possible to use nsc to import account or user public [NKeys](../auth_intro/nkey_auth.md) and issue corresponding JWTs. This way an operator can issue account JWTs and a separate entity can issue JWTs for user associated with it's account. Neither entity has to be aware of the other's private Nkey. This not only allows users to be configured some place other than servers, but also by different organizations altogether. Say administrators of a NATS installation controlling operators, issuing account JWTs to individual prod/dev teams managing their own user. This is a fully decentralized authorization setup!
 
-With an Operator JWT in place, the server needs to be configured to trust it by specifying `operator`. Furthermore the server needs a way to obtain account JWTs. This done by either defaulting to the resolver specified in the operator jwt or by manually specifying the [resolver](resolver.md). Depending on your configuration an [account server](../../../../nats-tools/nsc/nsc.md#account-server-configuration) needs to be in place
+With an Operator JWT in place, the server needs to be configured to trust it by specifying `operator`. Furthermore the server needs a way to obtain account JWTs. This done by either defaulting to the resolver specified in the operator jwt or by manually specifying the [resolver](resolver.md). Depending on your configuration an [account server](../../../../nats-tools/nsc/basics.md#account-server-configuration) needs to be in place
 
 > It is possible to [mix](jwt_nkey_auth.md) JWT and [NKEY](../auth_intro/nkey_auth.md)/[Account](../accounts.md) based Authentication/Authorization.
 

nats-tools/nsc/README.md

@@ -44,7 +44,7 @@ nsc/
 
 You can find various task-oriented tutorials to working with the tool here:
 
-* [Basic Usage](nsc.md)
+* [Basic Usage](basics.md)
 * [Configuring Streams](streams.md)
 * [Configuring Services](services.md)
 * [Signing Keys](signing_keys.md)