Feng Ruohang
6613c2a3cb
The test and verification scripts invoked ./minio and pulled their tooling from upstream infrastructure with no integrity check. Every `curl | tar` of a client or an old server binary was an unverified execution path in a script that regularly runs as a privileged user, and several fetched a floating "latest". Two installers replace all of it: - install-mcli.sh resolves a pinned pgsty/mc release, downloads the archive and its checksum manifest, requires exactly one valid manifest entry for the asset, verifies it, and installs. MCLI_BIN with a mandatory MCLI_SHA256 lets an offline or air-gapped run supply its own binary, still checksum-checked. - install-verified-fixture.sh takes source, expected SHA-256 and target, and refuses anything that does not match. Sources may be a URL or a local file. Every script that previously downloaded mc now calls install-mcli.sh. The three places that genuinely need an upstream artifact - the old MinIO server binary for the LDAP IAM upgrade-import test, the 2021 mc for the three-site replication test, and the functional-tests.sh fixture - go through install-verified-fixture.sh with the digest recorded inline. Those dl.min.io URLs remain on purpose: they are historical upstream artifacts needed to prove upgrade compatibility, and they are now pinned and verified rather than trusted. The scripts otherwise switch to ./silo, silo.service, the silo container and compose service names, and SILO_CONFIG_DIR. run-multi-site-minio-idp.sh is renamed to run-multi-site-silo-idp.sh with the Makefile target following. buildscripts/minio-upgrade.sh keeps its name and its `minio server` argv - it exists to test the MinIO-to-Silo upgrade, so the old side must stay old - but it is now pinned to an image digest rather than a tag, and its `docker system prune` and `docker volume prune` calls are removed. Those ran unfiltered against the developer's whole Docker installation; the resiliency tests had the same problem and lose their prune and `docker ps -q` sweeps too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Federation Quickstart Guide 
Federation feature is deprecated and should be avoided for future deployments
This document explains how to configure MinIO with Bucket lookup from DNS style federation.
Get started
1. Prerequisites
Install MinIO - MinIO Quickstart Guide.
2. Run MinIO in federated mode
Bucket lookup from DNS federation requires two dependencies
- etcd (for bucket DNS service records)
- CoreDNS (for DNS management based on populated bucket DNS service records, optional)
Architecture
Environment variables
MINIO_ETCD_ENDPOINTS
This is comma separated list of etcd servers that you want to use as the MinIO federation back-end. This should be same across the federated deployment, i.e. all the MinIO instances within a federated deployment should use same etcd back-end.
MINIO_DOMAIN
This is the top level domain name used for the federated setup. This domain name should ideally resolve to a load-balancer
running in front of all the federated MinIO instances. The domain name is used to create sub domain entries to etcd. For
example, if the domain is set to domain.com, the buckets bucket1, bucket2 will be accessible as bucket1.domain.com
and bucket2.domain.com.
MINIO_PUBLIC_IPS
This is comma separated list of IP addresses to which buckets created on this MinIO instance will resolve to. For example,
a bucket bucket1 created on current MinIO instance will be accessible as bucket1.domain.com, and the DNS entry for
bucket1.domain.com will point to IP address set in MINIO_PUBLIC_IPS.
- This field is mandatory for standalone and erasure code MinIO server deployments, to enable federated mode.
- This field is optional for distributed deployments. If you don't set this field in a federated setup, we use the IP addresses of hosts passed to the MinIO server startup and use them for DNS entries.
Run Multiple Clusters
cluster1
export MINIO_ETCD_ENDPOINTS="http://remote-etcd1:2379,http://remote-etcd2:4001"
export MINIO_DOMAIN=domain.com
export MINIO_PUBLIC_IPS=44.35.2.1,44.35.2.2,44.35.2.3,44.35.2.4
minio server http://rack{1...4}.host{1...4}.domain.com/mnt/export{1...32}
cluster2
export MINIO_ETCD_ENDPOINTS="http://remote-etcd1:2379,http://remote-etcd2:4001"
export MINIO_DOMAIN=domain.com
export MINIO_PUBLIC_IPS=44.35.1.1,44.35.1.2,44.35.1.3,44.35.1.4
minio server http://rack{5...8}.host{5...8}.domain.com/mnt/export{1...32}
In this configuration you can see MINIO_ETCD_ENDPOINTS points to the etcd backend which manages MinIO's
config.json and bucket DNS SRV records. MINIO_DOMAIN indicates the domain suffix for the bucket which
will be used to resolve bucket through DNS. For example if you have a bucket such as mybucket, the
client can use now mybucket.domain.com to directly resolve itself to the right cluster. MINIO_PUBLIC_IPS
points to the public IP address where each cluster might be accessible, this is unique for each cluster.
NOTE: mybucket only exists on one cluster either cluster1 or cluster2 this is random and
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. Test your setup
To test this setup, access the MinIO server via browser or mc. You’ll see the uploaded files are accessible from the all the MinIO endpoints.