gitlab-com-seaweedfs/seaweedfs
1
0
Fork 0
mirror of https://github.com/seaweedfs/seaweedfs.git synced 2024-01-19 02:48:24 +00:00
Code Issues Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/chrislusf/seaweedfs.wiki

chrislu 2021-12-25 01:26:59 -08:00
parent 8d3a39c5c5 28f7038b31
commit 4e9e959fce
3 changed files with 40 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
FUSE-Mount.md

@ -170,28 +170,28 @@ Threads started!
File operations: File operations:
reads/s: 1133.17 reads/s: 958.24
writes/s: 755.46 writes/s: 638.84
fsyncs/s: 2418.95 fsyncs/s: 2045.67
Throughput: Throughput:
read, MiB/s: 1133.17 read, MiB/s: 958.24
written, MiB/s: 755.46 written, MiB/s: 638.84
General statistics: General statistics:
total time: 60.0049s total time: 60.0045s
total number of events: 258353 total number of events: 218458
Latency (ms): Latency (ms):
min: 0.02 min: 0.02
avg: 0.23 avg: 0.27
max: 192.95 max: 166.61
95th percentile: 0.92 95th percentile: 1.01
sum: 59746.68 sum: 59775.56
Threads fairness: Threads fairness:
events (avg/stddev): 258353.0000/0.00 events (avg/stddev): 218458.0000/0.00
execution time (avg/stddev): 59.7467/0.00 execution time (avg/stddev): 59.7756/0.00
``` ```
The above is single-threaded. The following uses 16 threads. The above is single-threaded. The following uses 16 threads.
@ -223,28 +223,28 @@ Threads started!
File operations: File operations:
reads/s: 2219.10 reads/s: 2152.89
writes/s: 1479.62 writes/s: 1435.49
fsyncs/s: 4766.67 fsyncs/s: 4625.57
Throughput: Throughput:
read, MiB/s: 2219.10 read, MiB/s: 2152.89
written, MiB/s: 1479.62 written, MiB/s: 1435.49
General statistics: General statistics:
total time: 60.0423s total time: 60.0198s
total number of events: 506245 total number of events: 490963
Latency (ms): Latency (ms):
min: 0.03 min: 0.03
avg: 1.89 avg: 1.95
max: 272.82 max: 215.50
95th percentile: 7.98 95th percentile: 9.22
sum: 958926.66 sum: 958761.77
Threads fairness: Threads fairness:
events (avg/stddev): 31640.3125/259.62 events (avg/stddev): 30685.1875/161.07
execution time (avg/stddev): 59.9329/0.01 execution time (avg/stddev): 59.9226/0.00
``` ```

7
Security-Configuration.md

@ -17,6 +17,13 @@ $ weed scaffold -config=security
key = "" key = ""
expires_after_seconds = 10 # seconds expires_after_seconds = 10 # seconds
# by default, if the signing key above is set, the Volume UI over HTTP is disabled.
# by setting ui.access to true, you can re-enable the Volume UI. Despite
# some information leakage (as the UI is unauthenticted), this should not
# pose a security risk.
[access]
ui = false
# jwt for read is only supported with master+volume setup. Filer does not support this mode. # jwt for read is only supported with master+volume setup. Filer does not support this mode.
[jwt.signing.read] [jwt.signing.read]
key = "" key = ""

8
Security-Overview.md

@ -41,9 +41,15 @@ Besides gRPC mentioned above, volume servers can only be changed by file upload,
## JWT-based access control ## JWT-based access control
To enable JWT-based access control, To enable JWT-based access control,
1. generate `security.toml` file by `weed scaffold -config=security` 1. generate `security.toml` file by `weed scaffold -config=security`
1. set `jwt.signing.key` to a secrete string 1. set `jwt.signing.key` to a secret string
1. copy the same `security.toml` file to the masters and all volume servers. 1. copy the same `security.toml` file to the masters and all volume servers.
> **Re-enabling Volume UI**
>
> By default, if the `jwt.signing.key` is set, the web UI on the volume servers is disabled. You can re-enable the web UI by
> setting `access.ui=true` in `security.toml`. Despite some information leakage (as the UI is unauthenticted), this should not
> pose a security risk, as the UI is purely read-only.
## How JWT-based access control works ## How JWT-based access control works
* To upload a new file, when requesting a new fileId via `http://<master>:<port>/dir/assign`, the master will use the `jwt.signing.key` to generate and sign a JWT, and set it to response header `Authorization`. The JWT is valid for 10 seconds. * To upload a new file, when requesting a new fileId via `http://<master>:<port>/dir/assign`, the master will use the `jwt.signing.key` to generate and sign a JWT, and set it to response header `Authorization`. The JWT is valid for 10 seconds.
* To update or delete a file by fileId, the JWT can be read from the response header `Authorization` of `http://<master>:<port>/dir/lookup?fileId=xxxxx`. * To update or delete a file by fileId, the JWT can be read from the response header `Authorization` of `http://<master>:<port>/dir/lookup?fileId=xxxxx`.