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

wip

Browse Source
This commit is contained in:
Alberto Ricart
2019-05-15 14:12:30 -05:00
parent ec0cd3dcab
commit 28dfe4b752
88 changed files with 17563 additions and 609 deletions
Download Patch File Download Diff File Expand all files Collapse all files

111
nats_server/authentication.md Normal file
View File

@@ -0,0 +1,111 @@
## NATS Server Authentication
You can enable authentication on the NATS server so that a client must authenticate its identity when connecting. The NATS server supports single user authentication via the command line or using a configuration file, and multi-user authentication via a configuration file. Single user authentication is truly single user. The server will accept one set of credentials and no other.
## Command Line Options
You can start the NATS server with single-user authentication enabled by passing in the required credentials on the command line. The following server authentication options are supported on the command line:
--user user User required for connections
--pass password Password required for connections
--auth token Authorization token required for connections
Token is mutually exclusive from user and password, so only use one of those.
For example:
```sh
nats-server -DV --user foo --pass bar
```
will allow the user `foo` to log in with the password `bar`, but no other users to access the server.
Using the command line with an authorization token:
```sh
nats-server -DV -auth 'S3Cr3T0k3n!'
```
will allow clients with that token to connect, and no others.
## Single User Configuration Options
Single-user authentication can be configured in the configuration file:
```ascii
authorization {
user: derek
password: T0pS3cr3t
timeout: 1
}
```
If the server is part of a cluster, you can set up single-user authentication for route connections as well:
```ascii
cluster {
authorization {
user: route_user
password: T0pS3cr3tT00!
timeout: 0.5
}
}
```
Both of these configurations set a user and password as well as a connect timeout. The `auth` option can also be set to use tokens *instead of* user/password.
## Multi-User Authentication
Multi-user Authentication can only be set up in the configuration file. Users are defined in a list with user/password pairs.
For example, to define two users `alice` and `bob`:
```ascii
authorization {
users = [
{user: alice, password: foo}
{user: bob, password: bar}
]
}
```
You can also use [variables](/documentation/managing_the_server/configuration) to set user and password values. For example, here a password is declared as a variable named PASS and assigned to Joe.
```ascii
authorization {
PASS: abcdefghijklmnopqrstuvwxyz0123456789
users = [
{user: alice, password: foo}
{user: bob, password: bar}
{user: joe, password: $PASS}
]
}
```
The nats-server source code includes a tool that can be used to bcrypt passwords for the config file:
```sh
> go run mkpasswd.go -p
> password: password
> bcrypt hash: $2a$11$1oJy/wZYNTxr9jNwMNwS3eUGhBpHT3On8CL9o7ey89mpgo88VG6ba
```
This allows you to store hashed passwords instead of plain text ones.
## Client connection string
To connect to the server as an authenticated client, you can pass in the credentials in the connection string.
For example, user 'foo' with password 'bar':
```sh
nats://foo:bar@localhost:4222
```
Using token 'S3Cr3T0k3n!'
```sh
nats://S3Cr3T0k3n!@localhost:4222
```
The server also supports TLS mutual authentication documented in the [Security/Encryption section](/documentation/managing_the_server/security). Other methods are also discussed in the [developer doc](/documentation/writing_applications/secure_connection).

58
nats_server/authorization.md Normal file
View File

@@ -0,0 +1,58 @@
## Authorization
The NATS server supports authorization using subject-level permissions on a per-user basis. Permission-based authorization is available with [multi-user authentication](/documentation/managing_the_server/authentication/).
Each permission grant is an object with two fields: what subject(s) the authenticated user can publish to, and what subject(s) the authenticated user can subscribe to. The parser is generous at understanding what the intent is, so both arrays and singletons are processed. Subjects themselves can contain wildcards. Permissions can make use of [variables](/documentation/managing_the_server/configuration).
You set permissions by creating an entry inside of the `authorization` configuration block that conforms to the following syntax:
```ascii
authorization {
PERMISSION_NAME = {
publish = "singleton" or ["array", ...]
subscribe = "singleton" or ["array", ...]
}
}
```
**Important Note** NATS Authorizations are whitelist only, meaning in order to not break request/reply patterns you need to add rules as above with Alice and Bob for the `_INBOX.>` pattern. If an unauthorized client publishes or attempts to subscribe to a subject that has not been whitelisted, the action fails and is logged at the server, and an error message is returned to the client.
### Example
Here is an example authorization configuration that defines four users, three of whom are assigned explicit permissions.
```ascii
authorization {
ADMIN = {
publish = ">"
subscribe = ">"
}
REQUESTOR = {
publish = ["req.foo", "req.bar"]
subscribe = "_INBOX.>"
}
RESPONDER = {
subscribe = ["req.foo", "req.bar"]
publish = "_INBOX.>"
}
DEFAULT_PERMISSIONS = {
publish = "SANDBOX.*"
subscribe = ["PUBLIC.>", "_INBOX.>"]
}
PASS: abcdefghijklmnopqrstuvwxwz0123456789
users = [
{user: joe, password: foo, permissions: $ADMIN}
{user: alice, password: bar, permissions: $REQUESTOR}
{user: bob, password: $PASS, permissions: $RESPONDER}
{user: charlie, password: bar}
]
}
```
Since Joe is an ADMIN he can publish/subscribe on any subject. We use the wildcard `>` to match any subject.
Alice is a REQUESTOR and can publish requests on subjects `req.foo` or `req.bar`, and subscribe to anything that is a response (`_INBOX.>`).
Charlie has no permissions granted and therefore inherits the default permission set. You set the inherited default permissions by assigning them to the default_permissions entry inside of the authorization configuration block.
Bob is a RESPONDER to any of Alice's requests, so Bob needs to be able to subscribe to the request subjects and respond to Alice's reply subject which will be an `_INBOX.>`.

2
nats_server/clients.md
View File

@@ -13,7 +13,7 @@ If you have a client library installed you can try using a bundled client. Other
### Or download a zip file
You can pre-built binaries from the [go-nats-examples repo](https://github.com/nats-io/go-nats-examples/releases/tag/0.0.50)
You can install pre-built binaries from the [go-nats-examples repo](https://github.com/nats-io/go-nats-examples/releases/tag/0.0.50)
### Testing your setup

190
nats_server/clustering.md Normal file
View File

@@ -0,0 +1,190 @@
## NATS Server Clustering
NATS supports running each server in clustered mode. You can cluster servers together for high volume messaging systems and resiliency and high availability. Clients are cluster-aware.
Note that NATS clustered servers have a forwarding limit of one hop. This means that each `nats-server` instance will **only** forward messages that it has received **from a client** to the immediately adjacent `nats-server` instances to which it has routes. Messages received **from** a route will only be distributed to local clients. Therefore a full mesh cluster, or complete graph, is recommended for NATS to function as intended and as described throughout the documentation.
## Cluster URLs
In addition to a port for listening for clients, `nats-server` can listen on a "cluster" URL (the `-cluster` option). Additional `nats-server` servers can then add that URL to their `-routes` argument to join the cluster. These options can also be specified in a config file, but only the command-line version is shown in this overview for simplicity.
### Running with No Cluster
```sh
nats-server -p 4222
```
----
### Running a Simple Cluster
```sh
# Server A on 10.10.0.1
nats-server -p 4222 -cluster nats://10.10.0.1:5222
# Server B on 10.10.0.2
nats-server -p 4222 -cluster nats://10.10.0.2:5222 -routes nats://10.10.0.1:5222
```
----
```sh
# Server A on 10.10.0.1
nats-server -p 4222 -cluster nats://10.10.0.1:5222 -routes nats://10.10.0.2:5222
# Server B on 10.10.0.2
nats-server -p 4222 -cluster nats://10.10.0.2:5222 -routes nats://10.10.0.1:5222
```
Clients connecting to any server in the cluster will remain connected to the cluster even if the server it originally connected to is taken down, as long as at least a single server remains.
## Command Line Options
The following cluster options are supported:
--routes [rurl-1, rurl-2] Routes to solicit and connect
--cluster nats://host:port Cluster URL for solicited routes
When a NATS server routes to a specified URL, it will advertise its own cluster URL to all other servers in the route route effectively creating a routing mesh to all other servers.
**Note:** when using the `-routes` option, you must also specify a `-cluster` option.
Clustering can also be configured using the server [config file](/documentation/managing_the_server/configuration).
## Three Server Cluster Example
The following example demonstrates how to run a cluster of 3 servers on the same host. We will start with the seed server and use the `-D` command line parameter to produce debug information.
```sh
nats-server -p 4222 -cluster nats://localhost:4248 -D
```
Alternatively, you could use a configuration file, let's call it `seed.conf`, with a content similar to this:
```ascii
# Cluster Seed Node
listen: 127.0.0.1:4222
http: 8222
cluster {
listen: 127.0.0.1:4248
}
```
And start the server like this:
```sh
nats-server -config ./seed.conf -D
```
This will produce an output similar to:
```sh
[75653] 2016/04/26 15:14:47.339321 [INF] Listening for route connections on 127.0.0.1:4248
[75653] 2016/04/26 15:14:47.340787 [INF] Listening for client connections on 127.0.0.1:4222
[75653] 2016/04/26 15:14:47.340822 [DBG] server id is xZfu3u7usAPWkuThomoGzM
[75653] 2016/04/26 15:14:47.340825 [INF] server is ready
```
It is also possible to specify the hostname and port independently. At least the port is required. If you leave the hostname off it will bind to all the interfaces ('0.0.0.0').
```ascii
cluster {
host: 127.0.0.1
port: 4248
}
```
Now let's start two more servers, each one connecting to the seed server.
```sh
nats-server -p 5222 -cluster nats://localhost:5248 -routes nats://localhost:4248 -D
```
When running on the same host, we need to pick different ports for the client connections `-p`, and for the port used to accept other routes `-cluster`. Note that `-routes` points to the `-cluster` address of the seed server (`localhost:4248`).
Here is the log produced. See how it connects and registers a route to the seed server (`...GzM`).
```sh
[75665] 2016/04/26 15:14:59.970014 [INF] Listening for route connections on localhost:5248
[75665] 2016/04/26 15:14:59.971150 [INF] Listening for client connections on 0.0.0.0:5222
[75665] 2016/04/26 15:14:59.971176 [DBG] server id is 53Yi78q96t52QdyyWLKIyE
[75665] 2016/04/26 15:14:59.971179 [INF] server is ready
[75665] 2016/04/26 15:14:59.971199 [DBG] Trying to connect to route on localhost:4248
[75665] 2016/04/26 15:14:59.971551 [DBG] 127.0.0.1:4248 - rid:1 - Route connection created
[75665] 2016/04/26 15:14:59.971559 [DBG] 127.0.0.1:4248 - rid:1 - Route connect msg sent
[75665] 2016/04/26 15:14:59.971720 [DBG] 127.0.0.1:4248 - rid:1 - Registering remote route "xZfu3u7usAPWkuThomoGzM"
[75665] 2016/04/26 15:14:59.971731 [DBG] 127.0.0.1:4248 - rid:1 - Route sent local subscriptions
```
From the seed's server log, we see that the route is indeed accepted:
```sh
[75653] 2016/04/26 15:14:59.971602 [DBG] 127.0.0.1:52679 - rid:1 - Route connection created
[75653] 2016/04/26 15:14:59.971733 [DBG] 127.0.0.1:52679 - rid:1 - Registering remote route "53Yi78q96t52QdyyWLKIyE"
[75653] 2016/04/26 15:14:59.971739 [DBG] 127.0.0.1:52679 - rid:1 - Route sent local subscriptions
```
Finally, let's start the third server:
```sh
nats-server -p 6222 -cluster nats://localhost:6248 -routes nats://localhost:4248 -D
```
Again, notice that we use a different client port and cluster address, but still point to the same seed server at the address `nats://localhost:4248`:
```sh
[75764] 2016/04/26 15:19:11.528185 [INF] Listening for route connections on localhost:6248
[75764] 2016/04/26 15:19:11.529787 [INF] Listening for client connections on 0.0.0.0:6222
[75764] 2016/04/26 15:19:11.529829 [DBG] server id is IRepas80TBwJByULX1ulAp
[75764] 2016/04/26 15:19:11.529842 [INF] server is ready
[75764] 2016/04/26 15:19:11.529872 [DBG] Trying to connect to route on localhost:4248
[75764] 2016/04/26 15:19:11.530272 [DBG] 127.0.0.1:4248 - rid:1 - Route connection created
[75764] 2016/04/26 15:19:11.530281 [DBG] 127.0.0.1:4248 - rid:1 - Route connect msg sent
[75764] 2016/04/26 15:19:11.530408 [DBG] 127.0.0.1:4248 - rid:1 - Registering remote route "xZfu3u7usAPWkuThomoGzM"
[75764] 2016/04/26 15:19:11.530414 [DBG] 127.0.0.1:4248 - rid:1 - Route sent local subscriptions
[75764] 2016/04/26 15:19:11.530595 [DBG] 127.0.0.1:52727 - rid:2 - Route connection created
[75764] 2016/04/26 15:19:11.530659 [DBG] 127.0.0.1:52727 - rid:2 - Registering remote route "53Yi78q96t52QdyyWLKIyE"
[75764] 2016/04/26 15:19:11.530664 [DBG] 127.0.0.1:52727 - rid:2 - Route sent local subscriptions
```
First a route is created to the seed server (`...GzM`) and after that, a route from `...IyE` - which is the ID of the second server - is accepted.
The log from the seed server shows that it accepted the route from the third server:
```sh
[75653] 2016/04/26 15:19:11.530308 [DBG] 127.0.0.1:52726 - rid:2 - Route connection created
[75653] 2016/04/26 15:19:11.530384 [DBG] 127.0.0.1:52726 - rid:2 - Registering remote route "IRepas80TBwJByULX1ulAp"
[75653] 2016/04/26 15:19:11.530389 [DBG] 127.0.0.1:52726 - rid:2 - Route sent local subscriptions
```
And the log from the second server shows that it connected to the third.
```sh
[75665] 2016/04/26 15:19:11.530469 [DBG] Trying to connect to route on 127.0.0.1:6248
[75665] 2016/04/26 15:19:11.530565 [DBG] 127.0.0.1:6248 - rid:2 - Route connection created
[75665] 2016/04/26 15:19:11.530570 [DBG] 127.0.0.1:6248 - rid:2 - Route connect msg sent
[75665] 2016/04/26 15:19:11.530644 [DBG] 127.0.0.1:6248 - rid:2 - Registering remote route "IRepas80TBwJByULX1ulAp"
[75665] 2016/04/26 15:19:11.530650 [DBG] 127.0.0.1:6248 - rid:2 - Route sent local subscriptions
```
At this point, there is a full mesh cluster of NATS servers.
### Testing the Cluster
Now, the following should work: make a subscription to Node A then publish to Node C. You should be able to to receive the message without problems.
```sh
nats-sub -s "nats://192.168.59.103:7222" hello &
nats-pub -s "nats://192.168.59.105:7222" hello world
[#1] Received on [hello] : 'world'
# GNATSD on Node C logs:
[1] 2015/06/23 05:20:31.100032 [TRC] 192.168.59.103:7244 - rid:2 - <<- [MSG hello RSID:8:2 5]
# GNATSD on Node A logs:
[1] 2015/06/23 05:20:31.100600 [TRC] 10.0.2.2:51007 - cid:8 - <<- [MSG hello 2 5]
```

7
nats_server/configuration.md
View File

@@ -4,8 +4,8 @@ The NATS server products provide a flexible configuration format that combines t
The config file supports the following syntax:
- Lines or options can be commented with `#` and `//`
- Value assignment can use:
- Lines can be commented with `#` and `//`
- Values can be assigned to properties with:
- Equals sign: `foo = 2`
- Colon: `foo: 2`
- Whitespace: `foo 2`
@@ -21,7 +21,7 @@ Server configurations can specify variables. Variables allow you to reference a
Variables:
- Are block scoped
- Are referenced with a `$` prefix.
- Can be resolved from the environment
- Can be resolved from the environment variables having the same name
> If the environment variable value begins with a number you may have trouble resolving it depending on the server version you are running.
@@ -39,6 +39,7 @@ authorization {
A similar configuration, but this time, the value is in the environment:
```
# TOKEN should be defined in the environment
authorization {
token: $TOKEN
}

33
nats_server/flags.md
View File

@@ -17,7 +17,7 @@ The configuration flags revolve around:
| Flag | Description |
| :-------------------- | :-------- |
| `-a`, `--addr` | Host address to bind to (default: 0.0.0.0) - all interfaces. |
| `-a`, `--addr` | Host address to bind to (default: `0.0.0.0` - all interfaces). |
| `-p`, `--port` | NATS client port (default: 4222). |
| `-P`, `--pid` | File to store the process ID (PID). |
| `-m`, `--http_port` | HTTP port for monitoring dashboard (exclusive of `--https_port`). |
@@ -29,7 +29,23 @@ The configuration flags revolve around:
### Authentication Options
The following options control very simple authentication:
| Flag | Description |
| :-------------------- | :-------- |
| `--user` | Required _username_ for connections. |
| `--pass` | Required _password_ for connections. |
| `--auth` | Required _authorization token_ for connections. |
You can read more about [autentication configuration here](authentication.md).
### Logging Options
The following flags are available on the server to configure logging:
| Flag | Description |
| :-------------------- | :-------- |
| `-l`, `--log` | File to redirect log output |
@@ -40,14 +56,7 @@ The configuration flags revolve around:
| `-V`, `--trace` | Enable protocol trace log messages |
| `-DV` | Enable both debug and protocol trace messages |
### Authorization Options
| Flag | Description |
| :-------------------- | :-------- |
| `--user` | Required _username_ for connections. |
| `--pass` | Required _password_ for connections. |
| `--auth` | Required _authorization token_ for connections. |
You can read more about [logging configuration here](logging.md).
### TLS Options
@@ -63,6 +72,9 @@ The configuration flags revolve around:
### Cluster Options
The following flags are available on the server to configure clustering:
| Flag | Description |
| :-------------------- | :-------- |
| `--routes` | Comma separated list of cluster URLs to solicit and connect |
@@ -71,6 +83,9 @@ The configuration flags revolve around:
| `--cluster_advertise` | Cluster URL to advertise to other servers |
| `--connect_retries` | For implicit routes, number of connect retries |
You can read more about [clustering configuration here](clustering.md).
### Common Options
| Flag | Description |

6
nats_server/installation.md
View File

@@ -19,7 +19,7 @@ Via Docker:
> docker pull nats-server:latest
```
### Installing directly Release Build
### Installing A Release Build
You can find the latest release of nats-server [here](https://github.com/nats-io/nats-server/releases/latest).
@@ -41,13 +41,13 @@ Archive: nats-server.zip
### Installing from the source
If you have go installed, installing the binary is very easy:
If you have go installed, installing the binary is easy:
```
> go get github.com/nats-io/nats-server
```
This mechanism will always install the latest build on [master](https://github.com/nats-io/nats-server), which almost certainly will not be a released version. If you are a developer and want to play with the the latest, this is the easiest way of obtaining it.
This mechanism will install a build of [master](https://github.com/nats-io/nats-server), which almost certainly will not be a released version. If you are a developer and want to play with the the latest, this is the easiest way of obtaining it.
## Testing Your Installation

96
nats_server/logging.md Normal file
View File

@@ -0,0 +1,96 @@
## Configuring Logging
The NATS server provides various logging options that you can set via the command line or the configuration file.
### Command Line Options
The following logging operations are supported:
-l, --log FILE File to redirect log output.
-T, --logtime Timestamp log entries (default is true).
-s, --syslog Enable syslog as log method.
-r, --remote_syslog Syslog server address.
-D, --debug Enable debugging output.
-V, --trace Trace the raw protocol.
-DV Debug and Trace.
#### Debug and trace
The `-DV` flag enables trace and debug for the server.
```sh
nats-server -DV -m 8222 -user foo -pass bar
```
#### Log file redirect
```sh
nats-server -DV -m 8222 -l nats.log
```
#### Timestamp
If `-T false` then log entries are not timestamped. Default is true.
#### Syslog
You can configure syslog with `UDP`:
```sh
nats-server -s udp://localhost:514
```
or `syslog:`
```sh
nats-server -r syslog://<hostname>:<port>
```
For example:
```sh
syslog://logs.papertrailapp.com:26900
```
### Using the Configuration File
All of these settings are available in the configuration file as well.
```ascii
debug: false
trace: true
logtime: false
log_file: "/tmp/nats-server.log"
```
## Log Rotation with logrotate
NATS server does not provide tools to manage log files, but it does include mechanisms that make log rotation simple. We can use this mechanism with [logrotate](https://github.com/logrotate/logrotate); a simple standard Linux utility to rotate logs available on most distributions like Debian, Ubuntu, RedHat (CentOS), etc.
For example, you could configure `logrotate` with:
```ascii
/path/to/nats-server.log {
daily
rotate 30
compress
missingok
notifempty
postrotate
kill -SIGUSR1 `cat /var/run/nats-server.pid`
endscript
}
```
The first line specifies the location that the subsequent lines will apply to.
The rest of the file specifies that the logs will rotate daily ("daily" option) and that 30 older copies will be preserved ("rotate" option). Other options are described in [logrorate documentation](https://linux.die.net/man/8/logrotate).
The "postrotate" section tells NATS server to reload the log files once the rotation is complete. The command ```kill -SIGUSR1 `cat /var/run/nats-server.pid` ``` does not kill the NATS server process, but instead sends it a signal causing it to reload its log files. This will cause new requests to be logged to the refreshed log file.
The `/var/run/nats-server.pid` file is where NATS server stores the master process's pid.
## Some Logging Notes
- The NATS Server, in verbose mode, will log the receipt of `UNSUB` messages, but this does not indicate the subscription is gone, only that the message was received. The `DELSUB` message in the log can be used to determine when the actual subscription removal has taken place.

182
nats_server/monitoring.md Normal file
View File

@@ -0,0 +1,182 @@
## Monitoring
To monitor the NATS messaging system, `gnatsd` provides a lightweight HTTP server on a dedicated monitoring port. The monitoring server provides several endpoints, including [varz](#/varz), [connz](#/connz), [routez](#/routez), and [subsz](#/subz). All endpoints return a JSON object.
The NATS monitoring endpoints support JSONP and CORS, making it easy to create single page monitoring web applications.
## Enabling monitoring
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](/documentation/managing_the_server/configuration).
-m, --http_port PORT HTTP PORT for monitoring
-ms,--https_port PORT Use HTTPS PORT for monitoring
Example:
```sh
$ gnatsd -m 8222
[4528] 2015/08/19 20:09:58.572939 [INF] Starting gnatsd version 0.8.0
[4528] 2015/08/19 20:09:58.573007 [INF] Starting http monitor on port 8222
[4528] 2015/08/19 20:09:58.573071 [INF] Listening for client connections on 0.0.0.0:4222
[4528] 2015/08/19 20:09:58.573090 [INF] gnatsd is ready</td>
```
To test, run `gnatsd -m 8222`, then go to <a href="http://localhost:8222/" target="_blank">http://localhost:8222/</a>
## Monitoring endpoints
The following sections describe each supported monitoring endpoint: `varz`, `connz`, `routez`, and `subsz`.
### /varz
The endpoint <a href="http://localhost:8222/varz" target="_blank">http://localhost:8222/varz</a> reports various general statistics.
```json
{
"server_id": "ec933edcd2bd86bcf71d555fc8b4fb2c",
"version": "0.6.6",
"go": "go1.5.0",
"host": "0.0.0.0",
"port": 4222,
"auth_required": false,
"ssl_required": false,
"max_payload": 1048576,
"max_connections": 65536,
"ping_interval": 120000000000,
"ping_max": 2,
"http_port": 8222,
"ssl_timeout": 0.5,
"max_control_line": 1024,
"start": "2015-07-14T13:29:26.426805508-07:00",
"now": "2015-07-14T13:30:59.349179963-07:00",
"uptime": "1m33s",
"mem": 8445952,
"cores": 4,
"cpu": 0,
"connections": 39,
"routes": 0,
"remotes": 0,
"in_msgs": 100000,
"out_msgs": 100000,
"in_bytes": 1600000,
"out_bytes": 1600000,
"slow_consumers": 0
}
```
### /connz
The endpoint <a href="http://localhost:8222/connz" target="_blank">http://localhost:8222/connz</a> reports more detailed information on current connections. It uses a paging mechanism which defaults to 1024 connections.
You can control these via URL arguments (limit and offset). For example: <a href="http://localhost:8222/connz?limit=1&offset=1" target="_blank">http://localhost:8222/connz?limit=1&offset=1</a>.
You can also report detailed subscription information on a per connection basis using subs=1. For example: <a href="http://localhost:8222/connz?limit=1&offset=1&subs=1" target="_blank">http://localhost:8222/connz?limit=1&offset=1&subs=1</a>.
```json
{
"now": "2015-07-14T13:30:59.349179963-07:00",
"num_connections": 2,
"offset": 0,
"limit": 1024,
"connections": [
{
"cid": 571,
"ip": "127.0.0.1",
"port": 61572,
"pending_size": 0,
"in_msgs": 0,
"out_msgs": 0,
"in_bytes": 0,
"out_bytes": 0,
"subscriptions": 1,
"lang": "go",
"version": "1.0.9",
"subscriptions_list": [
"hello.world"
]
},
{
"cid": 574,
"ip": "127.0.0.1",
"port": 61577,
"pending_size": 0,
"in_msgs": 0,
"out_msgs": 0,
"in_bytes": 0,
"out_bytes": 0,
"subscriptions": 1,
"lang": "ruby",
"version": "0.5.0",
"subscriptions_list": [
"hello.world"
]
}
]
}
```
### /routez
The endpoint <a href="http://localhost:8222/routez" target="_blank">http://localhost:8222/routez</a> reports information on active routes for a cluster. Routes are expected to be low, so there is no paging mechanism with this endpoint.
The `routez` endpoint does support the `subs` argument from the `/connz` endpoint. For example: <a href="http://localhost:8222/routez?subs=1" target="_blank">http://localhost:8222/routez?subs=1</a>
```json
{
"now": "2015-07-14T13:30:59.349179963-07:00",
"num_routes": 1,
"routes": [
{
"rid": 1,
"remote_id": "de475c0041418afc799bccf0fdd61b47",
"did_solicit": true,
"ip": "127.0.0.1",
"port": 61791,
"pending_size": 0,
"in_msgs": 0,
"out_msgs": 0,
"in_bytes": 0,
"out_bytes": 0,
"subscriptions": 0
}
]
}
```
### /subsz
The endpoint <a href="http://localhost:8222/subz" target="_blank">http://localhost:8222/subz</a> reports detailed information about the current subscriptions and the routing data structure.
```json
{
"num_subscriptions": 3,
"num_cache": 0,
"num_inserts": 572,
"num_removes": 569,
"num_matches": 200000,
"cache_hit_rate": 0.99999,
"max_fanout": 0,
"avg_fanout": 0,
"stats_time": "2015-07-14T12:55:25.564818051-07:00"
}
```
## Creating monitoring applications
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). You can easily create single page web applications for monitoring. To do this you simply pass the `callback` query parameter to any endpoint.
For example:
```sh
http://localhost:8222/connz?callback=cb
```
Here is a JQuery example implementation:
```javascript
$.getJSON('http://localhost:8222/connz?callback=?', function(data) {
console.log(data);
});
```

137
nats_server/nats_top_tutorial.md Normal file
View File

@@ -0,0 +1,137 @@
## NATS TOP Tutorial
You can use [nats-top](natstop.md) to monitor in realtime NATS server connections and message statistics.
#### Prerequisites
- [Set up your Go environment](/documentation/additional_documentation/go-install/)
- [Installed the NATS server](/documentation/managing_the_server/installing/)
#### 1. Install nats-top
```sh
% go get github.com/nats-io/nats-top
```
You may need to run the following instead:
```sh
% sudo -E go get github.com/nats-io/nats-top
```
#### 2. Start the NATS server with monitoring enabled
```sh
% nats-server -m 8222
```
#### 3. Start nats-top
```sh
% nats-top
```
Result:
```sh
nats-server version 0.6.6 (uptime: 2m2s)
Server:
Load: CPU: 0.0% Memory: 6.3M Slow Consumers: 0
In: Msgs: 0 Bytes: 0 Msgs/Sec: 0.0 Bytes/Sec: 0
Out: Msgs: 0 Bytes: 0 Msgs/Sec: 0.0 Bytes/Sec: 0
Connections: 0
HOST CID SUBS PENDING MSGS_TO MSGS_FROM BYTES_TO BYTES_FROM LANG VERSION
```
#### 4. Run NATS client programs
Run some NATS client programs and exchange messages.
For the best experience, you will want to run multiple subscribers, at least 2 or 3. Refer to the [example pub-sub clients](/documentation/additional_documentation/nats-pub-sub).
#### 5. Check nats-top for statistics
```sh
nats-server version 0.6.6 (uptime: 30m51s)
Server:
Load: CPU: 0.0% Memory: 10.3M Slow Consumers: 0
In: Msgs: 56 Bytes: 302 Msgs/Sec: 0.0 Bytes/Sec: 0
Out: Msgs: 98 Bytes: 512 Msgs/Sec: 0.0 Bytes/Sec: 0
Connections: 3
HOST CID SUBS PENDING MSGS_TO MSGS_FROM BYTES_TO BYTES_FROM LANG VERSION
::1:58651 6 1 0 52 0 260 0 go 1.1.0
::1:58922 38 1 0 21 0 105 0 go 1.1.0
::1:58953 39 1 0 21 0 105 0 go 1.1.0
```
#### 6. Sort nats-top statistics
In nats-top, enter the command `o` followed by the option, such as `bytes_to`. You see that nats-top sorts the BYTES_TO column in ascending order.
```sh
nats-server version 0.6.6 (uptime: 45m40s)
Server:
Load: CPU: 0.0% Memory: 10.4M Slow Consumers: 0
In: Msgs: 81 Bytes: 427 Msgs/Sec: 0.0 Bytes/Sec: 0
Out: Msgs: 154 Bytes: 792 Msgs/Sec: 0.0 Bytes/Sec: 0
sort by [bytes_to]:
Connections: 3
HOST CID SUBS PENDING MSGS_TO MSGS_FROM BYTES_TO BYTES_FROM LANG VERSION
::1:59259 83 1 0 4 0 20 0 go 1.1.0
::1:59349 91 1 0 2 0 10 0 go 1.1.0
::1:59342 90 1 0 0 0 0 0 go 1.1.0
```
#### 7. Use different sort options
Use some different sort options to explore nats-top, such as:
`cid`, `subs`, `pending`, `msgs_to`, `msgs_from`, `bytes_to`, `bytes_from`, `lang`, `version`
You can also set the sort option on the command line using the `-sort` flag. For example: `nats-top -sort bytes_to`.
#### 8. Display the registered subscriptions.
In nats-top, enter the command `s` to toggle displaying connection subscriptions. When enabled, you see the subscription subject in nats-top table:
```sh
nats-server version 0.6.6 (uptime: 1h2m23s)
Server:
Load: CPU: 0.0% Memory: 10.4M Slow Consumers: 0
In: Msgs: 108 Bytes: 643 Msgs/Sec: 0.0 Bytes/Sec: 0
Out: Msgs: 185 Bytes: 1.0K Msgs/Sec: 0.0 Bytes/Sec: 0
Connections: 3
HOST CID SUBS PENDING MSGS_TO MSGS_FROM BYTES_TO BYTES_FROM LANG VERSION SUBSCRIPTIONS
::1:59708 115 1 0 6 0 48 0 go 1.1.0 foo.bar
::1:59758 122 1 0 1 0 8 0 go 1.1.0 foo
::1:59817 124 1 0 0 0 0 0 go 1.1.0 foo
```
#### 9. Quit nats-top
Use the `q` command to quit nats-top.
#### 10. Restart nats-top with a specified query
For example, to query for the connection with largest number of subscriptions:
```sh
% nats-top -n 1 -sort subs
```
Result: nats-top displays only the client connection with the largest number of subscriptions:
```sh
nats-server version 0.6.6 (uptime: 1h7m0s)
Server:
Load: CPU: 0.0% Memory: 10.4M Slow Consumers: 0
In: Msgs: 109 Bytes: 651 Msgs/Sec: 0.0 Bytes/Sec: 0
Out: Msgs: 187 Bytes: 1.0K Msgs/Sec: 0.0 Bytes/Sec: 0
Connections: 3
HOST CID SUBS PENDING MSGS_TO MSGS_FROM BYTES_TO BYTES_FROM LANG VERSION
::1:59708 115 1 0 6 0 48 0 go 1.1.0
```

81
nats_server/natstop.md Normal file
View File

@@ -0,0 +1,81 @@
## Statistics
[nats-top](https://github.com/nats-io/nats-top) is a [top](http://man7.org/linux/man-pages/man1/top.1.html)-like tool for monitoring nats-server servers.
The nats-top tool provides a dynamic real-time view of a NATS server. nats-top can display a variety of system summary information about the NATS server, such as subscription, pending bytes, number of messages, and more, in real time. For example:
```sh
nats-top
nats-server version 0.6.4 (uptime: 31m42s)
Server:
Load: CPU: 0.8% Memory: 5.9M Slow Consumers: 0
In: Msgs: 34.2K Bytes: 3.0M Msgs/Sec: 37.9 Bytes/Sec: 3389.7
Out: Msgs: 68.3K Bytes: 6.0M Msgs/Sec: 75.8 Bytes/Sec: 6779.4
Connections: 4
HOST CID SUBS PENDING MSGS_TO MSGS_FROM BYTES_TO BYTES_FROM LANG VERSION SUBSCRIPTIONS
127.0.0.1:56134 2 5 0 11.6K 11.6K 1.1M 905.1K go 1.1.0 foo, hello
127.0.1.1:56138 3 1 0 34.2K 0 3.0M 0 go 1.1.0 _INBOX.a96f3f6853616154d23d1b5072
127.0.0.1:56144 4 5 0 11.2K 11.1K 873.5K 1.1M go 1.1.0 foo, hello
127.0.0.1:56151 5 8 0 11.4K 11.5K 1014.6K 1.0M go 1.1.0 foo, hello
```
## Installation
nats-top can be installed using `go get`. For example:
```sh
go get github.com/nats-io/nats-top
```
NOTE: You may have to run the above command as user `sudo` depending on your setup. If you receive an error that you cannot install nats-top because your $GOPATH is not set, when in fact it is set, use command `sudo -E go get github.com/nats-io/nats-top` to install nats-top. The `-E` flag tells sudo to preserve the current user's environment.
## Usage
Once installed, nats-top can be run with the command `nats-top` and optional arguments.
```sh
nats-top [-s server] [-m monitor] [-n num_connections] [-d delay_in_secs] [-sort by]
```
## Options
Optional arguments inclde the following:
| Option | Description |
|-----------------------|-----------------------------------------------|
| `-m monitor` | Monitoring http port from nats-server. |
| `-n num_connections` | Limit the connections requested to the server (default 1024). |
| `-d delay_in_secs` | Screen refresh interval (default 1 second). |
| `-sort by` | Field to use for sorting the connections (see below). |
## Commands
While in nats-top view, you can use the following commands.
### option
Use the `o<option>` command to set the primary sort key to the `<option>` value. The option value can be one of the following: `cid`, `subs`, `pending`, `msgs_to`, `msgs_from`, `bytes_to`, `bytes_from`, `lang`, `version`.
You can also set the sort option on the command line using the `-sort` flag. For example: `nats-top -sort bytes_to`.
### limit
Use the `n<limit>` command to set the sample size of connections to request from the server.
You can also set this on the command line using the `-n num_connections` flag. For example: `nats-top -n 1`.
Note that if `n<limit>` is used in conjunction with `-sort`, the server will respect both options allowing queries such as the following: Query for the connection with largest number of subscriptions: `nats-top -n 1 -sort subs`.
### s, ? and q Commands
Use the `s` command to toggle displaying connection subscriptions.
Use the `?` command to show help message with options.
Use the `q` command to quit nats-top.
### Tutorial
For a walkthrough with `nats-top` check out the [tutorial](/documentation/additional_documentation/nats-top).

227
nats_server/tls.md Normal file
View File

@@ -0,0 +1,227 @@
## TLS Security
As of Release 0.7.0, the server can use modern TLS semantics for client connections, route connections, and the HTTPS monitoring port. To enable TLS on the client port add the TLS configuration section as follows:
```ascii
# Simple TLS config file
listen: 127.0.0.1:4443
tls {
cert_file: "./configs/certs/server-cert.pem"
key_file: "./configs/certs/server-key.pem"
timeout: 2
}
authorization {
user: derek
password: $2a$11$W2zko751KUvVy59mUTWmpOdWjpEm5qhcCZRd05GjI/sSOT.xtiHyG
timeout: 1
}
```
Note: This TLS configuration is also used for the monitor port if enabled with the `https_port` option.
The server **requires** a certificate and private key. Generating self signed certs and intermediary certificate authorities is beyond the scope here, but this document can be helpful in addition to Google Search:
<a href="https://docs.docker.com/engine/articles/https/" target="_blank">https://docs.docker.com/engine/articles/https/</a>
The server can be run using command line arguments to enable TLS functionality.
```
--tls Enable TLS, do not verify clients (default: false)
--tlscert FILE Server certificate file
--tlskey FILE Private key for server certificate
--tlsverify Enable TLS, verify client certificates
--tlscacert FILE Client certificate CA for verification
```
Examples using the test certificates which are self signed for localhost and 127.0.0.1.
```sh
> ./nats-server --tls --tlscert=./test/configs/certs/server-cert.pem --tlskey=./test/configs/certs/server-key.pem
[2935] 2016/04/26 13:34:30.685413 [INF] Starting nats-server version 0.8.0.beta
[2935] 2016/04/26 13:34:30.685509 [INF] Listening for client connections on 0.0.0.0:4222
[2935] 2016/04/26 13:34:30.685656 [INF] TLS required for client connections
[2935] 2016/04/26 13:34:30.685660 [INF] Server is ready
```
Notice that the log indicates that the client connections will be required to use TLS. If you run the server in Debug mode with -D or -DV, the logs will show the cipher suite selection for each connected client.
```sh
[15146] 2015/12/03 12:38:37.733139 [DBG] ::1:63330 - cid:1 - Starting TLS client connection handshake
[15146] 2015/12/03 12:38:37.751948 [DBG] ::1:63330 - cid:1 - TLS handshake complete
[15146] 2015/12/03 12:38:37.751959 [DBG] ::1:63330 - cid:1 - TLS version 1.2, cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
```
### TLS Ciphers
The server requires TLS version 1.2, and sets preferences for modern cipher suites that avoid those known with vulnerabilities. The
server's default preferences when building with Go1.5 are as follows.
```go
func defaultCipherSuites() []uint16 {
return []uint16{
// The SHA384 versions are only in Go1.5+
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
}
}
```
Optionally if your organization requires a specific cipher or list of ciphers, you can configure them with the `cipher_suites` option as follows:
```ascii
tls {
cert_file: "./configs/certs/server.pem"
key_file: "./configs/certs/key.pem"
timeout: 2
cipher_suites: [
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
]
}
```
A list of supported cipher suites is [located here in the cipherMap variable](https://github.com/nats-io/nats-server/blob/master/server/ciphersuites.go#L21).
### Client TLS Mutual Authentication
Optionally the server can require that clients need to present certificates, and the server can be configured with a CA authority to verify the client certificates. Simply add the option `verify` the TLS configuration section as follows:
```ascii
tls {
cert_file: "./configs/certs/server-cert.pem"
key_file: "./configs/certs/server-key.pem"
ca_file: "./configs/certs/ca.pem"
verify: true
}
```
If you want the server to enforce and require client certificates as well via the command line, utilize this example.
```sh
> ./nats-server --tlsverify --tlscert=./test/configs/certs/server-cert.pem --tlskey=./test/configs/certs/server-key.pem --tlscacert=./test/configs/certs/ca.pem
```
This option simply verifies the client's certificate has been signed by the CA specified in the `ca_file` option. However, it does not map any attribute of the client's certificate to the user's identity.
To have TLS Mutual Authentication map certificate attributes to the users identity, replace the option `verify` with `verify_and_map` as shown as follows:
```ascii
tls {
cert_file: "./configs/certs/server-cert.pem"
key_file: "./configs/certs/server-key.pem"
ca_file: "./configs/certs/ca.pem"
# Require a client certificate and map user id from certificate
verify_and_map: true
}
```
There are two options for certificate attributes that can be mapped to user names. The first is the email address in the Subject Alternative Name (SAN) field of the certificate. While generating a certificate with this attribute is outside the scope of this document, we will view this with OpenSSL:
```ascii
$ openssl x509 -noout -text -in test/configs/certs/client-id-auth-cert.pem
Certificate:
-------------<truncated>-------------
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:127.0.0.1, email:derek@nats.io
X509v3 Extended Key Usage:
TLS Web Client Authentication
-------------<truncated>-------------
```
The configuration to authorize this user would be as follows:
```ascii
authorization {
users = [
{user: "derek@nats.io", permissions: { publish: "foo" }}
]
}
```
Note: This configuration only works for the first email address if there are multiple emails in the SAN field.
The second option is to use the RFC 2253 Distinguished Names syntax from the certificate subject as follows:
```ascii
$ openssl x509 -noout -text -in test/configs/certs/tlsauth/client2.pem
Certificate:
Data:
-------------<truncated>-------------
Subject: OU=CNCF, CN=example.com
-------------<truncated>-------------
```
The configuration to authorize this user would be as follows:
```ascii
authorization {
users = [
{user: "CN=example.com,OU=CNCF", permissions: { publish: "foo" }}
]
}
```
### Cluster TLS Mutual 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. Certificates can be configured only for the server's cluster identity, keeping client and server certificates separate from cluster formation.
```ascii
cluster {
listen: 127.0.0.1:4244
tls {
# Route cert
cert_file: "./configs/certs/srva-cert.pem"
# Private key
key_file: "./configs/certs/srva-key.pem"
# Optional certificate authority verifying connected routes
# Required when we have self-signed CA, etc.
ca_file: "./configs/certs/ca.pem"
}
# Routes are actively solicited and connected to from this server.
# Other servers can connect to us if they supply the correct credentials
# in their routes definitions from above.
routes = [
nats-route://127.0.0.1:4246
]
}
```
### Using bcrypt to Protect Passwords
In addition to TLS functionality, the server now also supports hashing of passwords and authentication tokens using `bcrypt`. To take advantage of this, simply replace the plaintext password in the configuration with its `bcrypt` hash, and the server will automatically utilize `bcrypt` as needed.
A utility for creating `bcrypt` hashes is included with the nats-server distribution (`util/mkpasswd.go`). Running it with no arguments will generate a new secure password along with the associated hash. This can be used for a password or a token in the configuration.
```
~/go/src/github.com/nats-io/nats-server/util> go get golang.org/x/crypto/ssh/terminal
~/go/src/github.com/nats-io/nats-server/util> go build mkpasswd.go
~/go/src/github.com/nats-io/nats-server/util> ./mkpasswd
pass: #IclkRPHUpsTmACWzmIGXr
bcrypt hash: $2a$11$3kIDaCxw.Glsl1.u5nKa6eUnNDLV5HV9tIuUp7EHhMt6Nm9myW1aS
```
If you already have a password selected, you can supply the `-p` flag on the command line, enter your desired password, and a `bcrypt` hash will be generated for it:
```
~/go/src/github.com/nats-io/nats-server/util> ./mkpasswd -p
Enter Password: *******
Reenter Password: ******
bcrypt hash: $2a$11$3kIDaCxw.Glsl1.u5nKa6eUnNDLV5HV9tIuUp7EHhMt6Nm9myW1aS
```
Add the hash into the server configuration file's authorization section.
```
authorization {
user: derek
password: $2a$11$3kIDaCxw.Glsl1.u5nKa6eUnNDLV5HV9tIuUp7EHhMt6Nm9myW1aS
}
```

86
nats_server/upgrading.md Normal file
View File

@@ -0,0 +1,86 @@
## Cluster Upgrading
The basic strategy for upgrading a cluster revolves around the server's ability to gossip cluster configuration to clients and other servers. When cluster configuration changes, clients become aware of new servers automatically. In case of a disconnect, a client has a list of servers that joined the cluster in addition to the ones it knew about from its connection settings.
Note that since each server stores it's own permission and authentication configuration, new servers added to a cluster should provide the same users and authorization to prevent clients from getting rejected or gaining unexpected privileges.
For purposes of describing the scenario, let's get some fingers on keyboards, and go through the motions. Let's consider a cluster of two servers: 'A' and 'B.', and yes - clusters should be *three* to *five* servers, but for purposes of describing the behavior and cluster upgrade process, a cluster of two servers will suffice.
Let's build this cluster:
```bash
nats-server -D -p 4222 -cluster nats://localhost:6222 -routes nats://localhost:6222,nats://localhost:6333
```
The command above is starting nats-server with debug output enabled, listening for clients on port 4222, and accepting cluster connections on port 6222. The `-routes` option specifies a list of nats URLs where the server will attempt to connect
to other servers. These URLs define the cluster ports enabled on the cluster peers.
Keen readers will notice a self-route. Gnatsd will ignore the self-route, but it makes for a single consistent configuration for all servers.
You will see the server started, we notice it emits some warnings because it cannot connect to 'localhost:6333'. The message more accurately reads:
```ascii
Error trying to connect to route: dial tcp localhost:6333: connect: connection refused
```
Let's fix that, by starting the second server:
```bash
nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6222,nats://localhost:6333
```
The second server was started on port 4333 with its cluster port on 6333. Otherwise the same as 'A.'
Let's get one client, so we can observe it moving between servers as servers get removed:
```bash
nats-sub -s nats://localhost:4222 ">"
```
Nats-sub is a subscriber sample included with all NATS clients. Nats-sub subscribes to a subject and prints out any messages received. You can find the source code to the go version of nats-sub [here)(https://github.com/nats-io/go-nats/tree/master/examples). After starting the subscriber you should see a message on 'A' that a new client connected.
We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A,' let's introduce a new server 'T.' Server 'T' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go besides 'A.' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about ["Avoiding the Thundering Herd"](https://www.nats.io/documentation/writing_applications/connecting/).
Suffice it to say that clients redistribute themselves about evenly between all servers in the cluster. In our case 1/2 of the clients on 'A' will jump over to 'B' and the remaining half to 'T.'
Let's start our temporary server:
```bash
nats-server -D -p 4444 -cluster nats://localhost:6444 -routes nats://localhost:6222,nats://localhost:6333
```
After an instant or so, clients on 'A' learn of the new cluster member that joined. On our hands-on tutorial, `nats-sub` is now aware of 3 possible servers, 'A' (specified when we started the tool) and 'B' and 'T' learned from the cluster gossip.
We invoke our admin powers and turn off 'A' by issuing a `CTRL+C` to the terminal on 'A,' and observe that either 'B' or 'T' reports that a new client connected. That is our `nats-sub` client.
We perform the upgrade process, update the binary for 'A', and restart 'A':
```bash
nats-server -D -p 4222 -cluster nats://localhost:6222 -routes nats://localhost:6222,nats://localhost:6333
```
We move on to upgrade 'B'. Notice that clients from 'B' reconnect to 'A' and 'T'. We upgrade and restart 'B':
```bash
nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6222,nats://localhost:6333
```
If we had more servers, we would continue the stop, update, restart rotation as we did for 'A' and 'B.' After restarting the last server, we can go ahead and turn off 'T.' Any clients on 'T' will redistribute to our permanent cluster members.
### Seed Servers
In the examples above we started nats-server specifying two clustering routes. It is possible to allow the server gossip protocol drive it and reduce the amount of configuration. You could for example start A, B and C as follows:
#### A - Seed Server
```bash
nats-server -D -p 4222 -cluster nats://localhost:6222
```
#### B
```bash
nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6222
```
#### C
```bash
nats-server -D -p 4444 -cluster nats://localhost:6444 -routes nats://localhost:6222
```
Once they connect to the 'seed server', the will learn about all the other servers and connect to each other forming the full mesh.