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

Fixing links (all lower chase anchors and removing github links)

Browse Source 
Signed-off-by: Matthias Hanel <mh@synadia.com>
This commit is contained in:
Matthias Hanel 2020-04-13 16:22:10 -04:00
parent ceace00a26
commit 9443b0ced5
17 changed files with 38 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
developing-with-nats/security/tls.md
View File

@ -6,7 +6,7 @@ While authentication limits which clients can connect, TLS can be used to encryp
Using TLS to connect to a server that verifies the client's identity is straightforward. The client has to provide a certificate and private key. The NATS client will use these to prove it's identity to the server. For the client to verify the server's identity, the CA certificate is provided as well.
Use example certificates created in [self signed certificates for testing](../../nats-server/configuration/securing_nats/tls.md#Creating-Self-Signed-Certificates-for-Testing).
Use example certificates created in [self signed certificates for testing](../../nats-server/configuration/securing_nats/tls.md#creating-self-signed-certificates-for-festing).
```bash
> nats-server --tls --tlscert=server-cert.pem --tlskey=server-key.pem --tlscacert rootCA.pem --tlsverify

2
nats-protocol/nats-protocol/nats-client-dev.md
View File

@ -62,7 +62,7 @@ NATS implements auto-pruning. When a client connects to the server, the server e
## Parsing the protocol
NATS provides a text-based message format. The text-based [protocol](https://github.com/nats-io/nats.docs/tree/51fc56e3090645f7cedb242415e2d5361e1807e7/documentation/internals/nats-protocol/README.md) makes it easy to implement NATS clients. The key consideration is deciding on a parsing strategy.
NATS provides a text-based message format. The text-based [protocol](README.md) makes it easy to implement NATS clients. The key consideration is deciding on a parsing strategy.
The NATS server implements a [zero allocation byte parser](https://youtu.be/ylRKac5kSOk?t=10m46s) that is fast and efficient. Off the wire, a NATS message is simply a slice of bytes. Across the wire the message is transported as an immutable string over a TCP connection. It is up to the client to implement logic to parse the message.

12
nats-server/configuration/README.md
View File

@ -115,7 +115,7 @@ authorization: {
| `client_advertise` | Alternative client listen specification `<host>:<port>` or just `<host>` to advertise to clients and other server. Useful in [cluster](clustering/cluster_config.md) setups with NAT. | Advertise what `host` and `port` specify. |
| [`tls`](securing_nats/tls.md) | Configuration map for tls for client and http monitoring. | |
| [`cluster`](clustering/cluster_config.md) | Configuration map for [cluster](clustering/). | |
| [`gateway`](gateways/gateway.md#Gateway-Configuration-Block) | Configuration map for [gateway](gateways/). | |
| [`gateway`](gateways/gateway.md#gateway-configuration-block) | Configuration map for [gateway](gateways/). | |
| [`leafnode`](leafnodes/leafnode_conf.md) | Configuration map for a [leafnode](leafnodes/). | |
### Connection Timeouts
@ -131,8 +131,8 @@ authorization: {
| Property | Description | Default |
| :--- | :--- | :--- |
| `max_connections` | Maximum number of active client connections. | `64K` |
| `max_control_line` | Maximum length of a protocol line \(including combined length of subject and queue group\). Increasing this value may require [client changes](https://github.com/nats-io/nats.docs/tree/542bb62cfd07aef621e53479ed9946f26e514ce6/developing-with-nats/connecting/protocol.md#Set-the-Maximum-Control-Line-Size) to be used. Applies to all traffic. | `4Kb` |
| `max_payload` | Maximum number of bytes in a message payload. Reducing this size may force you to implement [chunking](https://github.com/nats-io/nats.docs/tree/542bb62cfd07aef621e53479ed9946f26e514ce6/developing-with-nats/connecting/protocol.md#Get-the-Maximum-Payload-Siz) in your clients. Applies to client and leafnode payloads. | `1Mb` |
| `max_control_line` | Maximum length of a protocol line \(including combined length of subject and queue group\). Increasing this value may require [client changes](../../developing-with-nats/connecting/misc.md#set-the-maximum-control-line-size) to be used. Applies to all traffic. | `4Kb` |
| `max_payload` | Maximum number of bytes in a message payload. Reducing this size may force you to implement [chunking](../../developing-with-nats/connecting/misc.md#get-the-maximum-payload-size) in your clients. Applies to client and leafnode payloads. | `1Mb` |
| `max_pending` | Maximum number of bytes buffered for a connection Applies to client connections. | `64Mb` |
| `max_subscriptions` | Maximum numbers of subscriptions per client and leafnode accounts connection. | `0`, unlimited |
@ -151,8 +151,8 @@ The Configuration options here refer to [JWT](securing_nats/jwt/) based authenti
| Property | Description |
| :--- | :--- |
| [`operator`](securing_nats/jwt/#Decentralized-Authentication-and-Authorization-Configuration) | Path to an operator JWT. |
| [`resolver`](securing_nats/jwt/#Decentralized-Authentication-and-Authorization-Configuration) | Resolver type [`MEMORY`](securing_nats/jwt/resolver.md#memory) or [`URL(<url>)`](securing_nats/jwt/resolver.md#url-resolver) for account JWTs. \(When the operator JWT contains an account URL, it will be used as default. In this case `resolver` is only needed to overwrite the default.\) |
| [`operator`](securing_nats/jwt/README.md#decentralized-authentication-and-authorization-configuration) | Path to an operator JWT. |
| [`resolver`](securing_nats/jwt/README.md#decentralized-authentication-and-authorization-configuration) | Resolver type [`MEMORY`](securing_nats/jwt/resolver.md#memory) or [`URL(<url>)`](securing_nats/jwt/resolver.md#url-resolver) for account JWTs. \(When the operator JWT contains an account URL, it will be used as default. In this case `resolver` is only needed to overwrite the default.\) |
| [`resolver_tls`](securing_nats/jwt/resolver.md#url-resolver) | [`tls` configuration map](securing_nats/tls.md) for tls connections to the resolver. \(This is for an outgoing connection and therefore does not use `timeout`, `verify` and `map_and_verify`\) |
| [`resolver_preload`](securing_nats/jwt/resolver.md#memory) | [Map](securing_nats/jwt/resolver.md#memory) to preload account public keys and their corresponding JWT. Keys consist of `<account public nkey>`, value is the `<corresponding jwt>`. Only used when `resolver=MEMORY`. |
@ -181,7 +181,7 @@ The Configuration options here refer to [JWT](securing_nats/jwt/) based authenti
| [`http`](monitoring.md) | Listen specification `<host>:<port>`for server monitoring. | |
| [`https_port`](monitoring.md) | https port for server monitoring. This is influenced by the tls property. | |
| [`https`](monitoring.md) | Listen specification `<host>:<port>`for TLS server monitoring. | |
| `system_account` | Name of the system account. Users of this account can subscribe to system events. See [System Accounts](https://github.com/nats-io/nats.docs/tree/542bb62cfd07aef621e53479ed9946f26e514ce6/nats-server/configuration/monitoring/README.md) for more details. | |
| `system_account` | Name of the system account. Users of this account can subscribe to system events. See [System Accounts](sys_accounts/README.md) for more details. | |
| `pid_file` | File containing PID, relative to ... This can serve as input to [nats-server --signal](../nats_admin/signals.md) | |
| `port_file_dir` | Directory to write a file containing the servers open ports to, relative to ... | |
| `connect_error_reports` | Number of attempts at which a repeated failed route, gateway or leaf node connection is reported. Connect attempts are made once every second. | `3600`, approx every hour |

4
nats-server/configuration/clustering/cluster_config.md
View File

@ -7,12 +7,12 @@ The `cluster` configuration map has the following configuration options:
| `host` | Interface where the gateway will listen for incoming route connections. |
| `port` | Port where the gateway will listen for incoming route connections. |
| `listen` | Combines `host` and `port` as `<host>:<port>`. |
| `tls` | A [`tls` configuration map](../securing_nats/tls.md) for securing the clustering connection. `verify` is always enabled and `cert_file` is used for client and server. [See](../securing_nats/tls.md#Wrong-Key-Usage) for certificate pitfalls. |
| `tls` | A [`tls` configuration map](../securing_nats/tls.md) for securing the clustering connection. `verify` is always enabled and `cert_file` is used for client and server. [See](../securing_nats/tls.md#wrong-key-usage) for certificate pitfalls. |
| `advertise` | Hostport `<host>:<port>` to advertise how this server can be contacted by other cluster members. This is useful in setups with NAT. |
| `no_advertise` | When set to `true`, do not advertise this server to clients. |
| `routes` | A list of other servers \(URLs\) to cluster with. Self-routes are ignored. Should authentication via `token` or `username`/`password` be required, specify them as part of the URL. |
| `connect_retries` | After how many failed connect attempts to give up establishing a connection to a discovered route. Default is `0`, do not retry. When enabled, attempts will be made once a second. This, does not apply to explicitly configured routes. |
| `authorization` | [Authorization](../securing_nats/auth_intro/#Authorization-Map) map for configuring cluster routes. When `token` or a single `username`/`password` are used, they define the authentication mechanism this server expects. What authentication values other server have to provide when connecting. They also specify how this server will authenticate itself when establishing a connection to a discovered route. This will not be used for routes explicitly listed in `routes` and therefore have to be provided as part of the URL. If you use token or password based authentication, either use the same credentials throughout the system or list every route explicitly on every server. If the `tls` configuration map specifies `verify_and_map` only provide the expected `username`. Here different certificates can be used, but they do have to map to the same `username`. The authorization map also allows for `timeout` which is honored but `users` and `permissions` are ignored. |
| `authorization` | [Authorization](../securing_nats/auth_intro/README.md#authorization-map) map for configuring cluster routes. When `token` or a single `username`/`password` are used, they define the authentication mechanism this server expects. What authentication values other server have to provide when connecting. They also specify how this server will authenticate itself when establishing a connection to a discovered route. This will not be used for routes explicitly listed in `routes` and therefore have to be provided as part of the URL. If you use token or password based authentication, either use the same credentials throughout the system or list every route explicitly on every server. If the `tls` configuration map specifies `verify_and_map` only provide the expected `username`. Here different certificates can be used, but they do have to map to the same `username`. The authorization map also allows for `timeout` which is honored but `users` and `permissions` are ignored. |
```text
cluster {

2
nats-server/configuration/clustering/cluster_tls.md
View File

@ -1,6 +1,6 @@
# TLS Authentication
When setting up clusters, all servers in the cluster, if using TLS, will both verify the connecting endpoints and the server responses. So certificates are checked in [both directions](../securing_nats/tls.md#Wrong-Key-Usage). Certificates can be configured only for the server's cluster identity, keeping client and server certificates separate from cluster formation.
When setting up clusters, all servers in the cluster, if using TLS, will both verify the connecting endpoints and the server responses. So certificates are checked in [both directions](../securing_nats/tls.md#wrong-key-usage). Certificates can be configured only for the server's cluster identity, keeping client and server certificates separate from cluster formation.
TLS Mutual Authentication _is the only way_ of securing routes.

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

@ -64,14 +64,14 @@ Published [foo] : 'bar'
| :--- | :--- |
| `name` | Name for this cluster, all gateways belonging to the same cluster, should specify the same name. |
| `reject_unknown` | If `true`, gateway will reject connections from gateways that are not configured in `gateways`. |
| `gateways` | List of Gateway [entries](gateway.md#Gateway-Entry) - see below. |
| `gateways` | List of Gateway [entries](#gateway-entry) - see below. |
| `host` | Interface where the gateway will listen for incoming gateway connections. |
| `port` | Port where the gateway will listen for incoming gateway connections. |
| `listen` | Combines `host` and `port` as `<host>:<port>` |
| `tls` | A [`tls` configuration map](../securing_nats/tls.md) for securing gateway connections. `verify` is always enabled. Unless otherwise specified in a [`gateway`](gateway.md#Gateway-Entry), `cert_file` will be the default client certificate. [See](../securing_nats/tls.md#Wrong-Key-Usage) for certificate pitfalls. |
| `tls` | A [`tls` configuration map](../securing_nats/tls.md) for securing gateway connections. `verify` is always enabled. Unless otherwise specified in a [`gateway`](#gateway-entry), `cert_file` will be the default client certificate. [See](../securing_nats/tls.md#wrong-key-usage) for certificate pitfalls. |
| `advertise` | Hostport `<host>:<port>` to advertise how this server can be contacted by other gateway members. This is useful in setups with NAT. |
| `connect_retries` | After how many failed connect attempts to give up establishing a connection to a discovered gateway. Default is `0`, do not retry. When enabled, attempts will be made once a second. This, does not apply to explicitly configured gateways. |
| `authorization` | [Authorization](../securing_nats/auth_intro/#Authorization-Map) map for gateways. When `token` or a single `username`/`password` are used, they define the authentication mechanism this server expects. What authentication values other server have to provide when connecting. They also specify how this server will authenticate itself when establishing a connection to a discovered gateway. This will not be used for gateways explicitly listed in [`gateways`](gateway.md#Gateway-Entry) and therefore have to be provided as part of the URL. If you use token or password based authentication, either use the same credentials throughout the system or list every gateway explicitly on every server. If the `tls` configuration map specifies `verify_and_map` only provide the expected `username`. Here different certificates can be used, but they do have to map to the same `username`. The authorization map also allows for `timeout` which is honored but `users` and `permissions` are ignored. |
| `authorization` | [Authorization](../securing_nats/auth_intro/README.md#authorization-map) map for gateways. When `token` or a single `username`/`password` are used, they define the authentication mechanism this server expects. What authentication values other server have to provide when connecting. They also specify how this server will authenticate itself when establishing a connection to a discovered gateway. This will not be used for gateways explicitly listed in [`gateways`](#gateway-entry) and therefore have to be provided as part of the URL. If you use token or password based authentication, either use the same credentials throughout the system or list every gateway explicitly on every server. If the `tls` configuration map specifies `verify_and_map` only provide the expected `username`. Here different certificates can be used, but they do have to map to the same `username`. The authorization map also allows for `timeout` which is honored but `users` and `permissions` are ignored. |
### `Gateway` Entry

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

@ -13,7 +13,7 @@ To monitor the NATS messaging system, `nats-server` provides a lightweight HTTP
All endpoints return a JSON object.
The NATS monitoring endpoints support [JSONP](https://en.wikipedia.org/wiki/JSONP) and [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#How_CORS_works), making it easy to create single page monitoring web applications. Part of the NATS ecosystem is a tool called [nats-top](../../nats-tools/nats_top/) that visualizes data from these endpoints on the command line.
The NATS monitoring endpoints support [JSONP](https://en.wikipedia.org/wiki/JSONP) and [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#How_CORS_works), making it easy to create single page monitoring web applications. Part of the NATS ecosystem is a tool called [nats-top](../../nats-tools/nats_top/README.md) that visualizes data from these endpoints on the command line.
> Warning: `nats-server` does not have authentication/authorization for the monitoring endpoint. When you plan to open your `nats-server` to the internet make sure to not expose the monitoring port as well. By default monitoring binds to every interface `0.0.0.0` so consider setting monitoring to `localhost` or have appropriate firewall rules.
>
@ -21,7 +21,7 @@ The NATS monitoring endpoints support [JSONP](https://en.wikipedia.org/wiki/JSON
### Enabling monitoring from the command line
To enable the monitoring server, start the NATS server with the monitoring flag `-m` and the monitoring port, or turn it on in the [configuration file](monitoring.md#Enable-monitoring-from-the-configuration-file).
To enable the monitoring server, start the NATS server with the monitoring flag `-m` and the monitoring port, or turn it on in the [configuration file](#enable-monitoring-from-the-configuration-file).
```text
-m, --http_port PORT HTTP PORT for monitoring

6
nats-server/configuration/securing_nats/accounts.md
View File

@ -1,6 +1,6 @@
# Multi Tenancy using Accounts
In modern microservice architecture it is common to share infrastructure - such as NATS - between services. [Accounts](accounts.md#Accounts) are securely isolated communication contexts that allow multi-tenancy in a NATS deployment. They allow users to bifurcate technology from business driven use cases, where data silos are created by design, not software limitations. Furthermore, they facilitate the [controlled exchange](accounts.md#Exporting-and-Importing) of information between those data silos/Tenants/Accounts.
In modern microservice architecture it is common to share infrastructure - such as NATS - between services. [Accounts](accounts.md#accounts) are securely isolated communication contexts that allow multi-tenancy in a NATS deployment. They allow users to bifurcate technology from business driven use cases, where data silos are created by design, not software limitations. Furthermore, they facilitate the [controlled exchange](accounts.md#exporting-and-importing) of information between those data silos/Tenants/Accounts.
## Accounts
@ -13,8 +13,8 @@ Accounts configuration is done in `accounts` map. The contents of an account ent
| Property | Description |
| :--- | :--- |
| `users` | a list of [user configuration maps](auth_intro/#user-configuration-map) |
| `exports` | a list of [export maps](accounts.md#Export-Configuration-Map) |
| `imports` | a list of [import maps](accounts.md#Import-Configuration-Map) |
| `exports` | a list of [export maps](accounts.md#export-configuration-map) |
| `imports` | a list of [import maps](accounts.md#import-configuration-map) |
The `accounts` list is a map, where the keys on the map are an account name.

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

@ -7,7 +7,7 @@ The server can require TLS certificates from a client. When needed, you can use
> Note: To simplify the common scenario of maintainers looking at the monitoring endpoint, `verify` and `verify_and_map` do not apply to the monitoring port.
The examples in the following sections make use of the certificates you [generated](../tls.md#Self-Signed-Certificates-for-Testing) locally.
The examples in the following sections make use of the certificates you [generated](../tls.md#self-signed-certificates-for-testing) locally.
## Validating a Client Certificate

6
nats-server/configuration/securing_nats/jwt/resolver.md
View File

@ -1,6 +1,6 @@
# Account lookup using Resolver
The `resolver` configuration option is used in conjunction with [NATS JWT Authentication](./) and [nsc](https://github.com/nats-io/nats.docs/tree/aecb86faf9be946a413d1c6200fc0ff5d1b0baef/nats-server/configuration/nats-tools/nsc/nsc/README.md). The `resolver` option specifies a URL where the nats-server can retrieve an account JWT. There are two built-in resolver implementations:
The `resolver` configuration option is used in conjunction with [NATS JWT Authentication](README.md) and [nsc](../../../../nats-tools/nsc/README.md). The `resolver` option specifies a URL where the nats-server can retrieve an account JWT. There are two built-in resolver implementations:
* `URL`
* `MEMORY`
@ -9,7 +9,7 @@ The `resolver` configuration option is used in conjunction with [NATS JWT Authen
## URL Resolver
The `URL` resolver specifies a URL where the server can append an account public key to retrieve that account's JWT. Convention for [NATS Account JWT Servers](https://github.com/nats-io/nats.docs/tree/aecb86faf9be946a413d1c6200fc0ff5d1b0baef/nats-server/configuration/nats-tools/nas/README.md) is to serve JWTs at: `http://localhost:9090/jwt/v1/accounts/`. For such a configuration you would specify the resolver as follows:
The `URL` resolver specifies a URL where the server can append an account public key to retrieve that account's JWT. Convention for [NATS Account JWT Servers](../../../../nats-tools/nas/README.md) is to serve JWTs at: `http://localhost:9090/jwt/v1/accounts/`. For such a configuration you would specify the resolver as follows:
```yaml
resolver: URL(http://localhost:9090/jwt/v1/accounts/)
@ -17,7 +17,7 @@ resolver: URL(http://localhost:9090/jwt/v1/accounts/)
> Note that if you are not using a nats-account-server, the URL can be anything as long as by appending the public key for an account, the requested JWT is returned.
If the server used requires client authentication, or you want to specify which CA is trusted for the lookup of account information, specify `resolver_tls`. This [`tls` configuration map](https://github.com/nats-io/nats.docs/tree/aecb86faf9be946a413d1c6200fc0ff5d1b0baef/nats-server/configuration/securing_nats/jwt/securing_nats/tls.md) lets you further restrict TLS to the resolver.
If the server used requires client authentication, or you want to specify which CA is trusted for the lookup of account information, specify `resolver_tls`. This [`tls` configuration map](../tls.md) lets you further restrict TLS to the resolver.
## MEMORY

8
nats-server/configuration/securing_nats/tls.md
View File

@ -10,9 +10,9 @@ The NATS server uses modern TLS semantics to encrypt client, route, and monitori
| `cipher_suites` | When set, only the specified TLS cipher suites will be allowed. Values must match the golang version used to build the server. |
| `curve_preferences` | List of TLS cipher curves to use in order. |
| `insecure` | Skip certificate verification. **NOT Recommended** |
| `timeout` | TLS handshake [timeout](tls.md#TLS-Timeout) in fractional seconds. Default set to `0.5` seconds. |
| `verify` | If `true`, require and [verify](auth_intro/tls_mutual_auth.md#Validating-a-Client-Certificate) client certificates. To support use by Browser, this option does not apply to monitoring. |
| `verify_and_map` | If `true`, require and verify client certificates and [map](auth_intro/tls_mutual_auth.md#Mapping-Client-Certificates-To-A-User) certificate values for authentication purposes. Does not apply to monitoring either. |
| `timeout` | TLS handshake [timeout](#tls-timeout) in fractional seconds. Default set to `0.5` seconds. |
| `verify` | If `true`, require and [verify](auth_intro/tls_mutual_auth.md#validating-a-client-certificate) client certificates. To support use by Browser, this option does not apply to monitoring. |
| `verify_and_map` | If `true`, require and verify client certificates and [map](auth_intro/tls_mutual_auth.md#mapping-client-certificates-to-a-user) certificate values for authentication purposes. Does not apply to monitoring either. |
The simplest configuration:
@ -116,7 +116,7 @@ nats-server --tls --tlscert=server-cert.pem --tlskey=server-key.pem -ms 8222
```
Now you should be able to access the monitoring endpoint `https://localhost:8222` with your browser.
`https://127.0.0.1:8222` however should result in an error as `127.0.0.1` is not listed as SAN. You will not be able to establish a connection from another computer either. For that to work you have to provide appropriate DNS and/or IP [SAN\(s\)](tls.md#Missing-Subject-Alternative-Name)
`https://127.0.0.1:8222` however should result in an error as `127.0.0.1` is not listed as SAN. You will not be able to establish a connection from another computer either. For that to work you have to provide appropriate DNS and/or IP [SAN\(s\)](#missing-subject-alternative-name)
To generate certificates that work with `verify` provide the `-client` option. This will cause it to add an appropriate key usage for client authentication. Please note that client refers to connecting process, not necessarily a NATS client. Also add a SAN email for usage as user name in `verify_and_map`.

8
nats-server/configuration/sys_accounts/README.md
View File

@ -9,12 +9,12 @@ NATS servers leverage [Accounts](../securing_nats/accounts.md) support and gener
In addition the server supports a limited number of requests that can be used to query for account connections, server stat summaries, and pinging servers in the cluster.
These events are enabled by configuring `system_account` and [subscribing/requesting](./#Available-Events-and-Services) using a _system account_ user.
These events are enabled by configuring `system_account` and [subscribing/requesting](#available-events-and-services) using a _system account_ user.
[Accounts](../securing_nats/accounts.md) are used so that subscriptions from your applications, say `>`, do not receive system events and vice versa. Using accounts requires either:
* [Configuring authentication locally](./#Local-Configuration) and listing one of the accounts in `system_account`
* Or by using decentralized authentication and authorization via [jwt](../securing_nats/jwt/) as shown in this [Tutorial](https://github.com/nats-io/nats.docs/tree/aecb86faf9be946a413d1c6200fc0ff5d1b0baef/nats-server/configuration/sys_accounts/sys_accounts.md). In this case `system_account` contains the account public key.
* [Configuring authentication locally](#local-configuration) and listing one of the accounts in `system_account`
* Or by using decentralized authentication and authorization via [jwt](../securing_nats/jwt/README.md) as shown in this [Tutorial](sys_accounts.md). In this case `system_account` contains the account public key.
## Available Events and Services
@ -30,7 +30,7 @@ Server initiated events:
* `$SYS.ACCOUNT.<id>.LEAFNODE.DISCONNECT` \(leaf node disconnects\)
* `$SYS.SERVER.<id>.STATSZ` \(stats summary\)
In addition other tools with system account privileges, can initiate requests \(Examples can be found [here](https://github.com/nats-io/nats.docs/tree/aecb86faf9be946a413d1c6200fc0ff5d1b0baef/nats-server/configuration/sys_accounts/sys_accounts.md#System-Services)\):
In addition other tools with system account privileges, can initiate requests \(Examples can be found [here](sys_accounts.md#system-services)\):
* `$SYS.REQ.SERVER.<id>.STATSZ` \(request server stat summary\)
* `$SYS.REQ.SERVER.PING` \(discover servers - will return multiple messages\)

4
nats-server/nats_admin/README.md
View File

@ -6,6 +6,6 @@ Managing a NATS server is simple, typical lifecycle operations include:
* [Upgrading](upgrading_cluster.md) a server \(or cluster\)
* Understanding [slow consumers](slow_consumers.md)
* Monitoring the server via:
* The monitoring [endpoint](../configuration/monitoring.md) and tools like [nats-top](../../nats-tools/nats_top/)
* By subscribing to [system events](https://github.com/nats-io/nats.docs/tree/e59525da15403e4a01839339b24d7804d4a26db9/nats-server/configuration/sys_accounts/sys_accounts.md)
* The monitoring [endpoint](../configuration/monitoring.md) and tools like [nats-top](../../nats-tools/nats_top/README.md)
* By subscribing to [system events](../configuration/sys_accounts/README.md)

2
nats-streaming-server/configuring/persistence/file_store.md
View File

@ -24,7 +24,7 @@ Finally, the number of stored messages for a given channel can also be limited w
## Options
As described in the [Configuring](https://github.com/nats-io/nats.docs/tree/51fc56e3090645f7cedb242415e2d5361e1807e7/nats_streaming/configuring/cfgfile.html#configuration-file) section, there are several options that you can use to configure a file store.
As described in the [Configuring](../cfgfile.md#configuration-file) section, there are several options that you can use to configure a file store.
Regardless of channel limits, you can configure message logs to be split in individual files \(called file slices\). You can configure those slices by number of messages it can contain \(`--file_slice_max_msgs`\), the size of the file - including the corresponding index file \(`--file_slice_max_bytes`\), or the period of time that a file slice should cover - starting at the time the first message is stored in that slice \(`--file_slice_max_age`\). The default file store options are defined such that only the slice size is configured to 64MB.

2
nats-tools/nas/README.md
View File

@ -13,5 +13,5 @@ The server supports replica mode, which allows load balancing, fault tolerance a
The account server can host activation tokens as well as account JWTs. These tokens are used when one account needs to give permission to another account to access a private export. Tokens can be configured as full tokens, or URLs. By hosting them in the account server you can avoid the copy/paste process of embedding tokens. They can also be updated more easily on expiration. The account serer furthermore allows for jwt inspection.
All account server configuration options can be found [here](nas_conf.md#Configuration-File). It futhermore allows [inspection](inspecting_jwts.md) of JWT.
All account server configuration options can be found [here](nas_conf.md#configuration-file). It futhermore allows [inspection](inspecting_jwts.md) of JWT.

4
nats-tools/nas/nas_conf.md
View File

@ -117,9 +117,9 @@ Let's take a look at the configuration options:
| Option | Description |
| :--- | :--- |
| `dir` | Configures a directory as a store. |
| `nsc` | Configures an nsc read-only store. The value should be the path to an operator _directory_. Option is mutually exlusive with `dir`. |
| `nsc` | Configures an nsc read-only store. The value should be the path to an operator _directory_. Option is mutually exclusive with `dir`. |
| `readonly` | If `true`, the store will not accept POST requests. Note that to receive requests, the store must also have `operatorjwtpath` specified as a root option. |
| `shard` | If `true`, JWTs are sharded in the store directory. |
| `shard` | If `true`, JWTs are shared in the store directory. |
## `logging` Options

2
nats-tools/nas/notifications.md
View File

@ -2,7 +2,7 @@
The `nats-account-server` can notify a nats-server about [JWT](../../nats-server/configuration/securing_nats/jwt/) updates, enabling the NATS server to update itself to the newly updated JWT.
To push notifications, the nats-account-server makes use of [system accounts](https://github.com/nats-io/nats.docs/tree/aecb86faf9be946a413d1c6200fc0ff5d1b0baef/nats-server/configuration/sys_accounts/sys_accounts.md).
To push notifications, the nats-account-server makes use of [system accounts](../../nats-server/configuration/sys_accounts/README.md).
Here's a nats-account-server configuration with updates enabled: