mirror of
https://github.com/taigrr/nats.docs
synced 2025-01-18 04:03:23 -08:00
Merge branch 'master' into full-doc-review-mh
This commit is contained in:
commit
97911d0fdb
@ -64,12 +64,15 @@ All of these settings are available in the configuration file as well.
|
||||
debug: false
|
||||
trace: true
|
||||
logtime: false
|
||||
logfile_size_limit: 1GB
|
||||
log_file: "/tmp/nats-server.log"
|
||||
```
|
||||
|
||||
### Log Rotation with logrotate
|
||||
### Log Rotation
|
||||
|
||||
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.
|
||||
Introduced in NATS Server v2.1.4, NATS allows for auto-rotation of log files when the size is greater than the configured limit set in `logfile_size_limit`. The backup files will have the same name as the original log file with the suffix .yyyy.mm.dd.hh.mm.ss.micros.
|
||||
|
||||
You can also use NATS-included mechanisms 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., to make log rotation simple.
|
||||
|
||||
For example, you could configure `logrotate` with:
|
||||
|
||||
|
@ -14,6 +14,8 @@ The `permissions` map specify subjects that can be subscribed to or published by
|
||||
| :--- | :--- |
|
||||
| `publish` | subject, list of subjects, or permission map the client can publish |
|
||||
| `subscribe` | subject, list of subjects, or permission map the client can subscribe |
|
||||
| `allow_responses` | boolean or object |
|
||||
|
||||
|
||||
## Permission Map
|
||||
|
||||
@ -26,6 +28,20 @@ The `permission` map provides additional properties for configuring a `permissio
|
||||
|
||||
**Important Note** NATS Authorizations can be _allow lists_, _deny lists_, or both. It is important to not break request/reply patterns. In some cases \(as shown below\) 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 _allow listed_, the action fails and is logged at the server, and an error message is returned to the client.
|
||||
|
||||
## Allow Responses Map
|
||||
|
||||
The `allow_responses` option dynamically allows publishing to reply subjects and works well for service responders.
|
||||
When set to `true`, only one response is allowed, meaning the permission to publish to the reply subject defaults to only once. The `allow_responses` map allows you to configure a maximum number of responses and how long the permission is valid.
|
||||
|
||||
| Property | Description |
|
||||
| :--- | :--- |
|
||||
| `max` | The maximum number of response messages that can be published. |
|
||||
| `expires` | The amount of time the permission is valid. Values such as `1s`, `1m`, `1h` (1 second, minute, hour) etc can be specified. Default doesn't have a time limit. |
|
||||
|
||||
When `allow_responses` is set to `true`, it defaults to the equivalent of `{ max: 1 }` and no time limit.
|
||||
|
||||
**Important Note** When using `nsc` to configure your users, you can specify the `--allow-pub-response` and `--response-ttl` to control these settings.
|
||||
|
||||
## Example
|
||||
|
||||
Here is an example authorization configuration that uses _variables_ which defines four users, three of whom are assigned explicit permissions.
|
||||
@ -95,6 +111,20 @@ authorization: {
|
||||
}
|
||||
```
|
||||
|
||||
Here's an example with `allow_responses`:
|
||||
|
||||
```text
|
||||
authorization: {
|
||||
users: [
|
||||
{ user: a, password: a },
|
||||
{ user: b, password: b, permissions: {subscribe: "q", allow_responses: true } },
|
||||
{ user: c, password: c, permissions: {subscribe: "q", allow_responses: { max: 5, expires: "1m" } } }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
User `a` has no restrictions. User `b` can listen on `q` for requests and can only publish once to reply subjects. All other subjects will be denied. User `c` can also listen on `q` for requests, but is able to return at most 5 reply messages, and the reply subject can be published at most for `1` minute.
|
||||
|
||||
## Queue Permissions
|
||||
|
||||
Added in NATS Server v2.1.2, Queue Permissions allow you to express authorization for queue groups. As queue groups are integral to implementing horizontally scalable microservices, control of who is allowed to join a specific queue group is important to the overall security model.
|
||||
@ -127,5 +157,3 @@ users = [
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
|
||||
|
@ -2,6 +2,14 @@
|
||||
|
||||
The NATS.io team is always working to bring you features to improve your NATS experience. Below you will find feature summaries for new implementations to NATS. Check back often for release highlights and updates.
|
||||
|
||||
## Server release v2.1.4
|
||||
### Log Rotation
|
||||
|
||||
NATS introduces `logfile_size_limit` allowing auto-rotation of log files when the size is greater than the configured limit set in `logfile_size_limit` as a number of bytes. You can provide the size with units, such as MB, GB, etc. The backup files will have the same name as the original log file with the suffix .yyyy.mm.dd.hh.mm.ss.micros. For more information see Configuring Logging in the [NATS Server Configuration section](nats-server/configuration/logging.md#using-the-configuration-file).
|
||||
|
||||
* Release notes [2.1.4](https://github.com/nats-io/nats-server/releases/tag/v2.1.4)
|
||||
* Full list of Changes [2.1.2...2.1.4](https://github.com/nats-io/nats-server/compare/v2.1.2...v2.1.4)
|
||||
|
||||
## Server release v2.1.2
|
||||
### Queue Permissions
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user