taigrr/nats.docs
1
0
Fork 0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Code Issues Projects Releases Wiki Activity

Multiple typo and bug fixes

Browse Source 
* Typos in prose
* Typo fix in copy/paste (dropped a letter)
* markup fix: keep list within quoted text
* Auto-corrupt cleanup: Jason to JSON
* gateway: multiple typos and language nits
* monitoring: add missing leafz, fix subsz spelling
This commit is contained in:
Phil Pennock 2019-12-18 12:37:02 -05:00 committed by Phil Pennock
parent 1adc0271aa
commit 28f7c2f1b4
6 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
nats-server/configuration/gateways/gateway.md
View File

@ -19,7 +19,7 @@ gateway {
}
```
One difference is that instead of `routes` you specify `gateways`. As expected _self-gateway_ connections are ignored, so you can share gateway configurations with minimal fuzz.
One difference is that instead of `routes` you specify `gateways`. As expected _self-gateway_ connections are ignored, so you can share gateway configurations with minimal fuss.
Starting a server:
@ -60,15 +60,15 @@ Listening on [>]
| Property | Description |
| :--- | :--- |
| `advertise` | Hostport `<host>:<port>` to advertise to other gateways. |
| `authorization` | Authorization block \(same as other nats-server `authorization` configuration\). |
| `authorization` | Authorization block \(same as other nats-server `authorization` configurations\). |
| `connect_retries` | Number of times the server will try to connect to a discovered gateway. |
| `gateways` | List of Gateway entries - see below. |
| `host` | Interface where the gateway will listen for incomming gateway connections. |
| `host` | Interface where the gateway will listen for incoming gateway connections. |
| `listen` | Combines `host` and `port` as `<host>:<port>` |
| `name` | Name for this cluster, all gateways belonging to the same cluster, should specify the same name. |
| `port` | Port where the gateway will listen for incomming gateway connections. |
| `port` | Port where the gateway will listen for incoming gateway connections. |
| `reject_unknown` | If `true`, gateway will reject connections from gateways that are not configured in `gateways`. |
| `tls` | TLS configuration block \(same as other [nats-server `tls` configuration](../securing_nats/tls.md#tls-configuration)\). |
| `tls` | TLS configuration block \(same as other [nats-server `tls` configurations](../securing_nats/tls.md#tls-configuration)\). |
### `Gateway` Entry
@ -78,7 +78,7 @@ The `gateways` configuration block is a list of gateway entries with the followi
| :--- | :--- |
| `name` | Gateway name. |
| `url` | Hostport `<host>:<port>` describing where the remote gateway can be reached. If multiple IPs are returned, one is randomly selected. |
| `urls` | A list of `url` |
| `urls` | A list of `url` strings. |
By using `urls` and an array, you can specify a list of endpoints that form part of a cluster as below. A NATS Server will pick one of those addresses randomly and only establish a single outbound gateway connection to one of the members from another cluster:

7
nats-server/configuration/monitoring.md
View File

@ -48,7 +48,8 @@ For example, to monitor this server locally, the endpoint would be [http://demo.
## Monitoring endpoints
The following sections describe each supported monitoring endpoint: `varz`, `connz`, `routez`, `subsz`, and `gatewayz`. There are not any required arguments, however use of arguments can let you tailor monitoring to your environment and tooling.
The following sections describe each supported monitoring endpoint: `varz`, `connz`, `routez`, `subsz`, `gatewayz`, and `leafz`.
There are not any required arguments, however use of arguments can let you tailor monitoring to your environment and tooling.
### General Information
@ -472,9 +473,9 @@ As noted above, the `leafz` endpoint does support the `subs` argument from the `
### Subscription Routing Information
The `/subz` endpoint reports detailed information about the current subscriptions and the routing data structure. It is not normally used.
The `/subsz` endpoint reports detailed information about the current subscriptions and the routing data structure. It is not normally used.
**Endpoint:** `http://server:port/subz`
**Endpoint:** `http://server:port/subsz`
| Result | Return Code |
| :--- | :--- |

3
nats-server/configuration/securing_nats/README.md
View File

@ -4,5 +4,4 @@ The NATS server provides several forms of security:
* Connections can be [_encrypted_ with TLS](tls.md)
* Client connections can require [_authentication_](auth_intro/)
* Clients can require [_authorization_](authorization.md) for subjects the publish or subscribe to
* Clients can require [_authorization_](authorization.md) for subjects they publish or subscribe to

10
nats-server/configuration/securing_nats/auth_intro/accounts.md
View File

@ -36,11 +36,11 @@ accounts: {
> These two accounts are isolated from each other. Messages published by users in `A` are not visible to users in `B`.
>
> The user configuration map is the same as any other NATS [user configuration map](./#user-configuration-map). You can use:
* username/password
* nkeys
* and add permissions
>
> * username/password
> * nkeys
> * and add permissions
>
> While the name _account_ implies one or more users, it is much simpler and enlightening to think of one account as a messaging container for one application. Users in the account are simply the minimum number of services that must work together to provide some functionality. In simpler terms, more accounts with few \(even one\) clients is a better design topology than a large account with many users with complex authorization configuration.
### Exporting and Importing

2
nats-server/configuration/securing_nats/auth_intro/username_password.md
View File

@ -34,7 +34,7 @@ Username/password also supports bcrypted passwords using the [`mkpasswd`](../../
```text
> mkpasswd
ass: (Uffs#rG42PAu#Oxi^BNng
pass: (Uffs#rG42PAu#Oxi^BNng
bcrypt hash: $2a$11$V1qrpBt8/SLfEBr4NJq4T.2mg8chx8.MTblUiTBOLV3MKDeAy.f7u
```

2
nats-tools/nsc/nsc.md
View File

@ -2,7 +2,7 @@
NSC allows you to manage identities. Identities take the form of _nkeys_. Nkeys are a public-key signature system based on Ed25519 for the NATS ecosystem.
The nkey identities are associated with NATS configuration in the form of a Jason Web Token \(JWT\). The JWT is digitally signed by the private key of an issuer forming a chain of trust. The `nsc` tool creates and manages these identities and allows you to deploy them to a JWT account server, which in turn makes the configurations available to nats-servers.
The nkey identities are associated with NATS configuration in the form of a JSON Web Token \(JWT\). The JWT is digitally signed by the private key of an issuer forming a chain of trust. The `nsc` tool creates and manages these identities and allows you to deploy them to a JWT account server, which in turn makes the configurations available to nats-servers.
There’s a logical hierarchy to the entities: