mirror of
https://github.com/taigrr/nats.docs
synced 2025-01-18 04:03:23 -08:00
wip
This commit is contained in:
parent
033cfb44fe
commit
e02ebdf16e
26
SUMMARY.md
26
SUMMARY.md
@ -3,19 +3,20 @@
|
||||
* [Introduction](README.md)
|
||||
|
||||
## NATS Server
|
||||
* [Basics](nats_server/README.md)
|
||||
* [Installing](nats_server/installation.md)
|
||||
* [Running](nats_server/running.md)
|
||||
* [Window Service](nats_server/windows_srv.md)
|
||||
* [Clients](nats_server/clients.md)
|
||||
* [Flags](nats_server/flags.md)
|
||||
* [Configuration](nats_server/configuration.md)
|
||||
* [Authentication](nats_server/authentication.md)
|
||||
* [Authorization](nats_server/authorization.md)
|
||||
* [Clustering](nats_server/clustering.md)
|
||||
* [Installing](nats_server/installation.md)
|
||||
* [Running](nats_server/running.md)
|
||||
* [Window Service](nats_server/windows_srv.md)
|
||||
* [Clients](nats_server/clients.md)
|
||||
* [Flags](nats_server/flags.md)
|
||||
* [Configuration](nats_server/configuration.md)
|
||||
* [Securing NATS](nats_server/securing_nats.md)
|
||||
* [TLS Security](nats_server/tls.md)
|
||||
* [Logging](nats_server/logging.md)
|
||||
* [Monitoring](nats_server/monitoring.md)
|
||||
* [Authentication](nats_server/authentication.md)
|
||||
* [TLS Authentication](nats_server/tls_auth.md)
|
||||
* [Authorization](nats_server/authorization.md)
|
||||
* [Clustering](nats_server/clustering.md)
|
||||
* [Logging](nats_server/logging.md)
|
||||
* [Monitoring](nats_server/monitoring.md)
|
||||
|
||||
### Managing A NATS Server
|
||||
* [Upgrading a Cluster](nats_admin/upgrading_cluster.md)
|
||||
@ -23,6 +24,7 @@
|
||||
* [Signals](nats_admin/signals.md)
|
||||
|
||||
### NATS Tools
|
||||
* [mkpasswd](nats_tools/mkpasswd.md)
|
||||
* [NATS Top](nats_tools/nats_top/README.md)
|
||||
* [Tutorial](nats_tools/nats_top/tutorial.md)
|
||||
* [Benchmarking](nats_tools/natsbench.md)
|
||||
|
@ -4,39 +4,39 @@ On Unix systems, the NATS server responds to the following signals:
|
||||
|
||||
| Signal | Result |
|
||||
| :--- | :--- |
|
||||
| SIGKILL | Kills the process immediately |
|
||||
| SIGINT | Stops the server gracefully |
|
||||
| SIGUSR1 | Reopens the log file for log rotation |
|
||||
| SIGHUP | Reloads server configuration file |
|
||||
| SIGUSR2 | Stops the server after evicting all clients (lame duck mode) |
|
||||
| `SIGKILL` | Kills the process immediately |
|
||||
| `SIGINT` | Stops the server gracefully |
|
||||
| `SIGUSR1` | Reopens the log file for log rotation |
|
||||
| `SIGHUP` | Reloads server configuration file |
|
||||
| `SIGUSR2` | Stops the server after evicting all clients (lame duck mode) |
|
||||
|
||||
The `nats-server` binary can be used to send these signals to running NATS servers using the `-sl` flag:
|
||||
|
||||
```sh
|
||||
# Quit the server
|
||||
nats-server -sl quit
|
||||
nats-server --signal quit
|
||||
|
||||
# Stop the server
|
||||
nats-server -sl stop
|
||||
nats-server --signal stop
|
||||
|
||||
# Reopen log file for log rotation
|
||||
nats-server -sl reopen
|
||||
nats-server --signal reopen
|
||||
|
||||
# Reload server configuration
|
||||
nats-server -sl reload
|
||||
nats-server --signal reload
|
||||
|
||||
# Lame duck mode server configuration
|
||||
nats-server -sl ldm
|
||||
nats-server --signal ldm
|
||||
```
|
||||
|
||||
If there are multiple `nats-server` processes running, or if `pgrep` isn't available, you must either specify a PID or the absolute path to a PID file:
|
||||
|
||||
```sh
|
||||
nats-server -sl stop=<pid>
|
||||
nats-server --signal stop=<pid>
|
||||
```
|
||||
|
||||
```sh
|
||||
nats-server -sl stop=/path/to/pidfile
|
||||
nats-server --signal stop=/path/to/pidfile
|
||||
```
|
||||
|
||||
See the [Windows Service](windows_srv.md) section for information on signaling the NATS server on Windows.
|
@ -1,11 +0,0 @@
|
||||
# NATS Server
|
||||
|
||||
The NATS server is an extremely lightweight, high-performance messaging server written in Go. Emphasys is on _simplicity_.
|
||||
|
||||
|
||||
|
||||
- [Installation](installation.md)
|
||||
|
||||
|
||||
|
||||
|
@ -18,22 +18,67 @@ You can install pre-built binaries from the [go-nats-examples repo](https://gith
|
||||
|
||||
### Testing your setup
|
||||
|
||||
First [start a nats-server](running.md). Then you can on two different terminal windows:
|
||||
Open a terminal and [start a nats-server](running.md):
|
||||
```
|
||||
> nats-server
|
||||
[29670] 2019/05/16 08:45:59.836809 [INF] Starting nats-server version 2.0.0
|
||||
[29670] 2019/05/16 08:45:59.836889 [INF] Git commit [not set]
|
||||
[29670] 2019/05/16 08:45:59.837161 [INF] Listening for client connections on 0.0.0.0:4222
|
||||
[29670] 2019/05/16 08:45:59.837168 [INF] Server id is NAYH35Q7ROQHLQ3K565JR4OPTJGO5EK4FJX6KX5IHHEPLQBRSYVWI2NO
|
||||
[29670] 2019/05/16 08:45:59.837170 [INF] Server is ready
|
||||
```
|
||||
|
||||
Start a subscriber:
|
||||
|
||||
On another terminal start session start a subscriber:
|
||||
```
|
||||
> nats-sub ">"
|
||||
Listening on [>]
|
||||
```
|
||||
|
||||
Publish your first message:
|
||||
Note that when the client connected, the server didn't log anything interesting because server output is fairly quiet unless something interesting happens.
|
||||
|
||||
To make the server output more lively, you can specify the `-V` flag to enable logging of server protocol tracing messages. Go ahead and `<ctrl>+c` the process running the server, and restart the server with the `-V` flag:
|
||||
|
||||
```
|
||||
> nats-server -V
|
||||
[29785] 2019/05/16 08:46:12.731278 [INF] Starting nats-server version 2.0.0
|
||||
[29785] 2019/05/16 08:46:12.731347 [INF] Git commit [not set]
|
||||
[29785] 2019/05/16 08:46:12.731488 [INF] Listening for client connections on 0.0.0.0:4222
|
||||
[29785] 2019/05/16 08:46:12.731493 [INF] Server id is NCEOJJ5SBJKUTMZEDNU3NBPJSLJPCMQJUIQIWKFHWE5DPETJKHX2CO2Y
|
||||
[29785] 2019/05/16 08:46:12.731495 [INF] Server is ready
|
||||
[29785] 2019/05/16 08:46:13.467099 [TRC] 127.0.0.1:49805 - cid:1 - <<- [CONNECT {"verbose":false,"pedantic":false,"tls_required":false,"name":"NATS Sample Subscriber","lang":"go","version":"1.7.0","protocol":1,"echo":true}]
|
||||
[29785] 2019/05/16 08:46:13.467200 [TRC] 127.0.0.1:49805 - cid:1 - <<- [PING]
|
||||
[29785] 2019/05/16 08:46:13.467206 [TRC] 127.0.0.1:49805 - cid:1 - ->> [PONG]
|
||||
```
|
||||
|
||||
If you had created a subscriber, you should notice output on the subscriber telling you that it diesconnected, and reconnected. The server output above is more interesting. You can see the subscriber send a `CONNECT` protocol message, and a `PING` which was responded to by the server with a `PONG`.
|
||||
|
||||
> You can learn more about the [NATS protocol here](/nats_protocol/nats-protocol.md), but more intersting than the protocol description is [an interactive demo](/nats_protocol/nats-protocol-demo.md).
|
||||
|
||||
On a third terminal, publish your first message:
|
||||
```
|
||||
> nats-pub hello world
|
||||
Published [hello] : 'world'
|
||||
```
|
||||
|
||||
On the subscriber window you should see:
|
||||
|
||||
```
|
||||
[#1] Received on [hello]: 'world'
|
||||
```
|
||||
|
||||
|
||||
### Testing Against a Remote Server
|
||||
|
||||
If the NATS server was running in a different machine or a different port, you'll have to specify that to the client by specifying a _NATS URL_. NATS urls take the form of: `nats://<server>:<port>` and `tls://<server>:<port>`. URLs with a `tls` protocol sport a secured TLS connection.
|
||||
|
||||
```
|
||||
> nats-sub -s nats://server:port ">"
|
||||
```
|
||||
|
||||
If you want to try on a remote server, the NATS team maintains a demo server you can reach at `demo.nats.io`.
|
||||
|
||||
```
|
||||
> nats-sub -s nats://demo.nats.io ">"
|
||||
```
|
||||
|
||||
|
||||
|
@ -1,8 +1,8 @@
|
||||
## Configuration File Format
|
||||
|
||||
The NATS server products provide a flexible configuration format that combines the best of traditional formats and newer styles such as JSON and YAML.
|
||||
While the NATS server has many flags that allow for simple testing of features, the NATS server products provide a flexible configuration format that combines the best of traditional formats and newer styles such as JSON and YAML.
|
||||
|
||||
The config file supports the following syntax:
|
||||
The NATS configuration file supports the following syntax:
|
||||
|
||||
- Lines can be commented with `#` and `//`
|
||||
- Values can be assigned to properties with:
|
||||
@ -14,6 +14,31 @@ The config file supports the following syntax:
|
||||
- Maps can be assigned with no key separator
|
||||
- Semicolons can be used as terminators
|
||||
|
||||
### Strings and Numbers
|
||||
|
||||
The configuration parser is very forgiving, as you have seen:
|
||||
- values can be a primitive, or a list, or a map
|
||||
- strings and numbers typically do the right thing
|
||||
|
||||
String values that start with a number _can_ create issues. To force such values as strings, simply quote them.
|
||||
|
||||
*BAD Config*:
|
||||
```
|
||||
listen: 127.0.0.1:4222
|
||||
authorization: {
|
||||
# BAD!
|
||||
token: 3secret
|
||||
}
|
||||
```
|
||||
|
||||
Fixed Config:
|
||||
```
|
||||
listen: 127.0.0.1:4222
|
||||
authorization: {
|
||||
token: "3secret"
|
||||
}
|
||||
```
|
||||
|
||||
### Variables
|
||||
|
||||
Server configurations can specify variables. Variables allow you to reference a value from one or more sections in the configuration.
|
||||
@ -46,3 +71,41 @@ authorization {
|
||||
```
|
||||
|
||||
export TOKEN="hello"; nats-server -c /config/file
|
||||
|
||||
### Include Directive
|
||||
|
||||
The `include` directive allows you to split a server configuration into several files. This is useful for separating configuration into chunks that you can easily reuse between different servers.
|
||||
|
||||
Includes *must* use relative paths, and are relative to the main configuration (the one specified via the `-c` option):
|
||||
|
||||
server.conf:
|
||||
```
|
||||
listen: 127.0.0.1:4222
|
||||
include ./auth.conf
|
||||
```
|
||||
|
||||
> Note that `include` is not followed by `=` or `:`, as it is a _directive_.
|
||||
|
||||
auth.conf:
|
||||
```
|
||||
authorization: {
|
||||
token: "f0oBar"
|
||||
}
|
||||
```
|
||||
|
||||
```
|
||||
> nats-server -c server.conf
|
||||
```
|
||||
|
||||
|
||||
### Configuration Reloading
|
||||
|
||||
A server can reload most configuration changes without requiring a server restart or clients to disconnect by sending the nats-server a [signal](/nats_admin/signals.md):
|
||||
|
||||
```
|
||||
> nats-server --signal reload
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -52,7 +52,7 @@ This mechanism will install a build of [master](https://github.com/nats-io/nats-
|
||||
|
||||
## Testing Your Installation
|
||||
|
||||
To test your installation (provided the install locations are visible by your shell):
|
||||
To test your installation (provided the executable is visible to your shell):
|
||||
|
||||
```
|
||||
> nats-server
|
||||
|
35
nats_server/securing_nats.md
Normal file
35
nats_server/securing_nats.md
Normal file
@ -0,0 +1,35 @@
|
||||
# Securing NATS
|
||||
|
||||
The nats-server provides several forms of security:
|
||||
|
||||
- Connections can be _encrypted_ with TLS
|
||||
- Client connections can require _authentication_
|
||||
- Clients can require _authorization_ for subjects the publish or subscribe to
|
||||
|
||||
|
||||
|
||||
## Server TLS Configuration
|
||||
|
||||
TLS server configuration revolves around two options:
|
||||
|
||||
- `cert_file` - the server's certificate
|
||||
- `key_file` - the server's key file
|
||||
|
||||
|
||||
You can configure tls on the configuration file:
|
||||
```
|
||||
tls: {
|
||||
cert_file: "./server-cert.pem"
|
||||
key_file: "./server-key.pem"
|
||||
}
|
||||
```
|
||||
|
||||
Or by using [server options](./flags.md#tls-options):
|
||||
```
|
||||
> nats-server --tls --tlscert=./server-cert.pem --tlskey=./server-key.pem
|
||||
```
|
||||
|
||||
More advanced configurations require additional options:
|
||||
|
||||
- `ca_file` - a certificate file providing the trust chain for the certificate authority (CA). Used to validate client certificates.
|
||||
- `verify` - set to `true` if you want to verify client certs against the `ca_file` certificate.
|
@ -195,33 +195,3 @@ cluster {
|
||||
}
|
||||
```
|
||||
|
||||
### 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
|
||||
}
|
||||
```
|
||||
|
119
nats_server/tls_auth.md
Normal file
119
nats_server/tls_auth.md
Normal file
@ -0,0 +1,119 @@
|
||||
## TLS Authentication
|
||||
|
||||
TLS authentication allows a client to authenticate by presenting a TLS certificate. TLS Certificate authentication checks the client certificate’s `Subject Alternative Name` for an email address. Alternatively, you can map fields found in the client certificate’s `Subject`. If the mapped value is matched to the client's certificate, authentication succeeds.
|
||||
|
||||
### Enabling TLS Certificate Authentication
|
||||
|
||||
To enable TLS Certificate authentication, set the `verify_and_map` configuration option on the server's `tls` configuration:
|
||||
|
||||
```yaml
|
||||
tls {
|
||||
cert_file: "./server_cert.pem"
|
||||
key_file: "./server_key.pem"
|
||||
ca_file: "./ca.pem"
|
||||
|
||||
# Require a client certificate and map user ids
|
||||
verify_and_map: true
|
||||
}
|
||||
```
|
||||
|
||||
### Inspecting Certificate Contents
|
||||
|
||||
You can easily inspect a TLS certificate using `openssl`:
|
||||
|
||||
```text
|
||||
> openssl x509 -in client-id-auth-cert.pem -text
|
||||
Certificate:
|
||||
Data:
|
||||
Version: 3 (0x2)
|
||||
Serial Number: 17268173637974047931 (0xefa4e06edb353cbb)
|
||||
Signature Algorithm: sha1WithRSAEncryption
|
||||
Issuer: C=US, ST=CA, L=San Francisco, O=Apcera Inc, OU=nats.io, CN=localhost/emailAddress=derek@nats.io
|
||||
Validity
|
||||
Not Before: Jan 25 04:40:50 2019 GMT
|
||||
Not After : Jan 24 04:40:50 2023 GMT
|
||||
Subject: C=US, ST=CA, L=Los Angeles, O=Synadia Communications Inc., OU=NATS.io, CN=localhost/emailAddress=derek@nats.io
|
||||
Subject Public Key Info:
|
||||
Public Key Algorithm: rsaEncryption
|
||||
Public-Key: (2048 bit)
|
||||
Modulus:
|
||||
00:9c:ec:a1:c8:51:5e:0c:85:da:a4:2c
|
||||
…
|
||||
Exponent: 65537 (0x10001)
|
||||
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
|
||||
Signature Algorithm: sha1WithRSAEncryption
|
||||
…
|
||||
```
|
||||
|
||||
Here's one more example, this time showing a certificate that has multiple Subject Alternative Name (SAN):
|
||||
|
||||
```text
|
||||
openssl x509 -in /tmp/client.pem -text
|
||||
Certificate:
|
||||
Data:
|
||||
Version: 3 (0x2)
|
||||
Serial Number:
|
||||
2e:9c:da:46:3a:31:05:d9:fa:1a:7c:fd:28:15:06:8d:9b:9c:76:89
|
||||
Signature Algorithm: sha256WithRSAEncryption
|
||||
Issuer: OU=NATS.io, CN=www.nats.io
|
||||
Validity
|
||||
Not Before: Apr 19 04:38:00 2019 GMT
|
||||
Not After : Apr 17 04:38:00 2024 GMT
|
||||
Subject: CN=www.nats.io
|
||||
Subject Public Key Info:
|
||||
Public Key Algorithm: rsaEncryption
|
||||
Public-Key: (2048 bit)
|
||||
Modulus:
|
||||
00:db:64:6b:38:85:ae:e1:9b:e9:69:1d:56:91:a2:
|
||||
...
|
||||
45:3d:56:6b:01:52:02:0f:32:89:cd:8f:50:97:83:
|
||||
fc:e3
|
||||
Exponent: 65537 (0x10001)
|
||||
X509v3 extensions:
|
||||
X509v3 Key Usage: critical
|
||||
Digital Signature, Key Encipherment
|
||||
X509v3 Extended Key Usage:
|
||||
TLS Web Client Authentication
|
||||
X509v3 Basic Constraints: critical
|
||||
CA:FALSE
|
||||
X509v3 Subject Key Identifier:
|
||||
0C:75:6D:8B:34:34:D4:65:04:65:69:E3:7D:77:52:B8:FD:32:53:00
|
||||
X509v3 Authority Key Identifier:
|
||||
keyid:0C:1B:A8:58:3A:01:C9:7F:49:43:E1:D5:0F:FF:1C:DA:BC:80:E7:B7
|
||||
|
||||
X509v3 Subject Alternative Name:
|
||||
DNS:app.nats.dev, DNS:*.app.nats.dev
|
||||
Signature Algorithm: sha256WithRSAEncryption
|
||||
23:31:20:fb:db:9f:c8:e1:da:4c:81:0e:52:cf:50:b3:05:e1:
|
||||
...
|
||||
47:d0:94:60:18:f3:d7:59:5a:ab:9d:62:8e:f9:bb:ff:6e:b3:
|
||||
3f:32:c0:21
|
||||
...
|
||||
```
|
||||
|
||||
### NATS Server Configuration
|
||||
|
||||
The `authorization` section of the nats-server config can specify an email (when matching values in the `Subject Alternative Name` or specific fields in the `Subject` respectively:
|
||||
|
||||
```yaml
|
||||
authorization {
|
||||
users = [
|
||||
{user: “derek@nats.io”},
|
||||
{user: “OU=nats.io”},
|
||||
{user: “*.example.nats.io”}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
TLS certificate authentication is available for clients as well as for cluster configurations.
|
||||
|
||||
### Client TLS Configuration
|
||||
|
||||
Client TLS configuration using the various client libraries are documented in [Encrypting Connections with TLS](https://nats.io/documentation/writing_applications/secure_connection).
|
||||
|
||||
Keen eyes will notice that there is no new configuration. The burden of configuration is all in the server to expose one or more details about the client's TLS certificate. Client simply needs to provide a client-side certificate.
|
||||
|
@ -7,23 +7,23 @@ sc.exe create nats-server binPath= "%NATS_PATH%\nats-server.exe [nats-server fla
|
||||
sc.exe start nats-server
|
||||
```
|
||||
|
||||
The above will create and start a `nats-server` service. Note that the nats-server flags should be passed in when creating the service. This allows for running multiple NATS server configurations on a single Windows server by using a 1:1 service instance per installed NATS server service. Once the service is running, it can be controlled using `sc.exe` or `nats-server.exe -sl`:
|
||||
The above will create and start a `nats-server` service. Note that the nats-server flags should be passed in when creating the service. This allows for running multiple NATS server configurations on a single Windows server by using a 1:1 service instance per installed NATS server service. Once the service is running, it can be controlled using `sc.exe` or `nats-server.exe --signal`:
|
||||
|
||||
```batch
|
||||
REM Reload server configuration
|
||||
nats-server.exe -sl reload
|
||||
nats-server.exe --signal reload
|
||||
|
||||
REM Reopen log file for log rotation
|
||||
nats-server.exe -sl reopen
|
||||
nats-server.exe --signal reopen
|
||||
|
||||
REM Stop the server
|
||||
nats-server.exe -sl stop
|
||||
nats-server.exe --signal stop
|
||||
```
|
||||
|
||||
The above commands will default to controlling the `nats-server` service. If the service is another name, it can be specified:
|
||||
|
||||
```batch
|
||||
nats-server.exe -sl stop=<service name>
|
||||
nats-server.exe --signal stop=<service name>
|
||||
```
|
||||
|
||||
For a complete list of signals, see [process signaling](/nats_admin/signals.md).
|
41
nats_tools/mkpasswd.md
Normal file
41
nats_tools/mkpasswd.md
Normal file
@ -0,0 +1,41 @@
|
||||
### `mkpasswd`: Protect Passwords with bcrypt
|
||||
|
||||
The server 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.
|
||||
|
||||
## Installing `mkpasswd`
|
||||
|
||||
If you have [go installed](https://golang.org/doc/install), you can easily install the `mkpasswd` tool by doing:
|
||||
|
||||
```
|
||||
> go get github.com/nats-server/util/mkpasswd
|
||||
```
|
||||
|
||||
Alternatively, you can
|
||||
|
||||
```
|
||||
> git clone git@github.com:nats-io/nats-server
|
||||
> cd nats-server/util/mkpasswd
|
||||
> go build mkpasswd.go
|
||||
> ./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:
|
||||
```
|
||||
> ./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
|
||||
}
|
||||
```
|
Loading…
x
Reference in New Issue
Block a user