mirror of https://github.com/minio/minio.git
remove all stale old docs about 2018 releases
This commit is contained in:
Harshavardhana
parent
71bab74148
commit
a2230868e0
|
|
@ -2,23 +2,13 @@
|
|||
|
||||
## Configuration Directory
|
||||
|
||||
Till MinIO release `RELEASE.2018-08-02T23-11-36Z`, MinIO server configuration file (`config.json`) was stored in the configuration directory specified by `--config-dir` or defaulted to `${HOME}/.minio`. However from releases after `RELEASE.2018-08-18T03-49-57Z`, the configuration file (only), has been migrated to the storage backend (storage backend is the directory passed to MinIO server while starting the server).
|
||||
|
||||
You can specify the location of your existing config using `--config-dir`, MinIO will migrate the `config.json` to your backend storage. Your current `config.json` will be renamed upon successful migration as `config.json.deprecated` in your current `--config-dir`. All your existing configurations are honored after this migration.
|
||||
|
||||
Additionally `--config-dir` is now a legacy option which will is scheduled for removal in future, so please update your local startup, ansible scripts accordingly.
|
||||
|
||||
```sh
|
||||
minio server /data
|
||||
```
|
||||
|
||||
MinIO also encrypts all the config, IAM and policies content if KMS is configured. Please refer to how to encrypt your config and IAM credentials [here](https://github.com/minio/minio/blob/master/docs/kms/IAM.md)
|
||||
MinIO stores all its config as part of the server deployment, config is erasure coded on MinIO. On a fresh deployment MinIO automatically generates a new `config` and this config is available to be configured via `mc admin config` command. MinIO also encrypts all the config, IAM and policies content if KMS is configured. Please refer to how to encrypt your config and IAM credentials [here](https://github.com/minio/minio/blob/master/docs/kms/IAM.md)
|
||||
|
||||
### Certificate Directory
|
||||
|
||||
TLS certificates by default are stored under ``${HOME}/.minio/certs`` directory. You need to place certificates here to enable `HTTPS` based access. Read more about [How to secure access to MinIO server with TLS](https://docs.min.io/docs/how-to-secure-access-to-minio-server-with-tls).
|
||||
TLS certificates by default are expected to be stored under ``${HOME}/.minio/certs`` directory. You need to place certificates here to enable `HTTPS` based access. Read more about [How to secure access to MinIO server with TLS](https://docs.min.io/docs/how-to-secure-access-to-minio-server-with-tls).
|
||||
|
||||
Following is the directory structure for MinIO server with TLS certificates.
|
||||
Following is a sample directory structure for MinIO server with TLS certificates.
|
||||
|
||||
```sh
|
||||
$ mc tree --files ~/.minio
|
||||
|
|
@ -32,7 +22,7 @@ $ mc tree --files ~/.minio
|
|||
You can provide a custom certs directory using `--certs-dir` command line option.
|
||||
|
||||
#### Credentials
|
||||
On MinIO admin credentials or root credentials are only allowed to be changed using ENVs namely `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD`. Using the combination of these two values MinIO encrypts the config stored at the backend.
|
||||
On MinIO admin credentials or root credentials are only allowed to be changed using ENVs namely `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD`.
|
||||
|
||||
```sh
|
||||
export MINIO_ROOT_USER=minio
|
||||
|
|
@ -125,7 +115,7 @@ MINIO_CACHE_COMMENT (sentence) optionally add a comment to this setting
|
|||
```
|
||||
|
||||
#### Etcd
|
||||
MinIO supports storing encrypted IAM assets and bucket DNS records on etcd.
|
||||
MinIO supports storing encrypted IAM assets in etcd, if KMS is configured. Please refer to how to encrypt your config and IAM credentials [here](https://github.com/minio/minio/blob/master/docs/kms/IAM.md)
|
||||
|
||||
> NOTE: if *path_prefix* is set then MinIO will not federate your buckets, namespaced IAM assets are assumed as isolated tenants, only buckets are considered globally unique but performing a lookup with a *bucket* which belongs to a different tenant will fail unlike federated setups where MinIO would port-forward and route the request to relevant cluster accordingly. This is a special feature, federated deployments should not need to set *path_prefix*.
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,6 @@ The default value for the `STANDARD` storage class depends on the number of volu
|
|||
| 6-7 | EC:3 |
|
||||
| 8 or more | EC:4 |
|
||||
|
||||
Prior to the ``RELEASE.2021-01-30T00-20-58Z`` MinIO release, the default `STANDARD` value was `EC(N/2)` where `N` was the number of erasure set drives.
|
||||
For more complete documentation on Erasure Set sizing, see the [MinIO Documentation on Erasure Sets](https://docs.min.io/minio/baremetal/concepts/erasure-coding.html#erasure-sets).
|
||||
|
||||
### Allowed values for REDUCED_REDUNDANCY storage class
|
||||
|
|
|
|||
|
|
@ -75,17 +75,7 @@ NOTE: `mybucket` only exists on one cluster either `cluster1` or `cluster2` this
|
|||
is decided by how `domain.com` gets resolved, if there is a round-robin DNS on `domain.com` then
|
||||
it is randomized which cluster might provision the bucket.
|
||||
|
||||
### 3. Upgrading to `etcdv3` API
|
||||
|
||||
Users running MinIO federation from release `RELEASE.2018-06-09T03-43-35Z` to `RELEASE.2018-07-10T01-42-11Z`, should migrate the existing bucket data on etcd server to `etcdv3` API, and update CoreDNS version to `1.2.0` before updating their MinIO server to the latest version.
|
||||
|
||||
Here is some background on why this is needed - MinIO server release `RELEASE.2018-06-09T03-43-35Z` to `RELEASE.2018-07-10T01-42-11Z` used etcdv2 API to store bucket data to etcd server. This was due to `etcdv3` support not available for CoreDNS server. So, even if MinIO used `etcdv3` API to store bucket data, CoreDNS wouldn't be able to read and serve it as DNS records.
|
||||
|
||||
Now that CoreDNS [supports etcdv3](https://coredns.io/2018/07/11/coredns-1.2.0-release/), MinIO server uses `etcdv3` API to store bucket data to etcd server. As `etcdv2` and `etcdv3` APIs are not compatible, data stored using `etcdv2` API is not visible to the `etcdv3` API. So, bucket data stored by previous MinIO version will not be visible to current MinIO version, until a migration is done.
|
||||
|
||||
CoreOS team has documented the steps required to migrate existing data from `etcdv2` to `etcdv3` in [this blog post](https://coreos.com/blog/migrating-applications-etcd-v3.html). Please refer the post and migrate etcd data to `etcdv3` API.
|
||||
|
||||
### 4. Test your setup
|
||||
### 3. Test your setup
|
||||
|
||||
To test this setup, access the MinIO server via browser or [`mc`](https://docs.min.io/docs/minio-client-quickstart-guide). You’ll see the uploaded files are accessible from the all the MinIO endpoints.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,6 @@
|
|||
# KMS IAM/Config Encryption
|
||||
|
||||
MinIO will soon release a change that re-works the encryption of IAM and
|
||||
configuration data. Currently, MinIO encrypts IAM data (user/temp. credentials,
|
||||
policies and other configuration data) with the cluster root credentials before
|
||||
storing it on the backend disks. After release `RELEASE.2021-04-22T15-44-28Z`
|
||||
onwards, MinIO will use the KMS provided keys to encrypt the IAM data instead
|
||||
of the cluster root credentials. If the KMS is not enabled, MinIO will store
|
||||
the IAM data as plain text in its backend.
|
||||
MinIO supports encrypting config, IAM assets with KMS provided keys. If the KMS is not enabled, MinIO will store the config, IAM data as plain text erasure coded in its backend.
|
||||
|
||||
### MinIO KMS Quick Start
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue