chore: cut over to pgsty/silo and main

The transitional references land in one commit, because they are only correct
together: the repository is pgsty/silo, its default branch is main, and nothing
in the tree should point a user at the old names.

Changed:

- Workflow branch filters. go.yml and vulncheck.yml gated on `branches: master`
  for both push and pull_request, so renaming the default branch would have
  taken automatic CI offline with no error and no signal - the workflows would
  simply never trigger again. They now name main.
- Release target. goreleaser's `release.github.name` becomes silo, which is
  what actually decides where a tagged build publishes. sign-release-rpms.sh's
  GH_REPO default follows.
- The OCI `image.source` label, the Helm chart `sources` entry, the security
  advisory link in the issue-template config, and the go.mod comment citing the
  LDAP TLS fix.
- 115 occurrences across README, README_ZH, SECURITY, CONTRIBUTING and 30 docs
  pages, including 72 links that also carried the master branch in their path.
  Those matter most: GitHub redirects clone, fetch, push and web URLs after a
  rename, but raw.githubusercontent.com does not, and neither follows a branch
  rename - every one of those links would 404 twice over.
- Three error strings in cmd/erasure-sets.go, cmd/storage-errors.go and
  internal/config/errors.go that print an issue URL to operators. These are Go
  string literals inside rebrand-guard's brand allowlist, so the baseline is
  regenerated. The regeneration removes exactly those three entries and adds
  none; all twelve other protected sets, including the 9014 exported symbols,
  are byte-identical.
- The transitional-naming disclaimers in README, README_ZH, SECURITY and
  CONTRIBUTING are dropped, since they no longer describe anything.

Deliberately unchanged, all three because they exist to reject or freeze the old
name rather than to point at it:

- buildscripts/minio-upgrade.sh pins pgsty/minio@sha256:b6bfe72... - the frozen
  pre-rebrand image is the control group for the MinIO-to-Silo upgrade test.
- helm-migration-guard rejects any rendered container still pulling pgsty/minio.
- verify-rebrand.sh rejects the same in the delivery surfaces.

Also unchanged: docs/config/README.md links to pgsty/mc/blob/master, and that
repository's default branch really is still master. It moves when mc does.

verify-rebrand.sh gains three assertions so this cannot silently regress: no
source reference may name pgsty/minio outside the three allowlisted guards, no
link may target pgsty/silo's master branch, and go.yml and vulncheck.yml must
filter on main. Both new rejections were negative-tested - reintroducing a
master branch filter and adding a pgsty/minio URL each fail the gate with the
specific message.

This commit assumes the rename actually happens. Until the GitHub branch and
repository renames are executed, the links it introduces do not resolve.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Feng Ruohang
2026-08-06 09:28:06 +08:00
parent fd2ca1c6d2
commit c46b16ec62
48 changed files with 146 additions and 127 deletions
+1 -1
View File
@@ -4,5 +4,5 @@ contact_links:
url: https://silo.pgsty.com/docs/ url: https://silo.pgsty.com/docs/
about: Installation, configuration, operations, and compatibility guidance about: Installation, configuration, operations, and compatibility guidance
- name: Private Security Report - name: Private Security Report
url: https://github.com/pgsty/minio/security/advisories/new url: https://github.com/pgsty/silo/security/advisories/new
about: Privately report a suspected vulnerability in Silo about: Privately report a suspected vulnerability in Silo
+1 -2
View File
@@ -66,8 +66,7 @@ signs:
release: release:
github: github:
owner: pgsty owner: pgsty
# Transitional until the irreversible GitHub repository rename. name: silo
name: minio
draft: true draft: true
prerelease: false prerelease: false
mode: append mode: append
+3 -3
View File
@@ -3,13 +3,13 @@ name: Go CI
on: on:
pull_request: pull_request:
branches: branches:
- master - main
push: push:
branches: branches:
- master - main
workflow_dispatch: workflow_dispatch:
# Cancel superseded runs for the same PR; never cancel master push runs. # Cancel superseded runs for the same PR; never cancel main push runs.
# Keyed on PR number (not head_ref) so fork PRs sharing a branch name # Keyed on PR number (not head_ref) so fork PRs sharing a branch name
# do not collide. # do not collide.
concurrency: concurrency:
+2 -2
View File
@@ -3,10 +3,10 @@ name: VulnCheck
on: on:
pull_request: pull_request:
branches: branches:
- master - main
push: push:
branches: branches:
- master - main
workflow_dispatch: workflow_dispatch:
permissions: permissions:
+2 -5
View File
@@ -14,15 +14,12 @@ before implementation.
### Set up a checkout ### Set up a checkout
```sh ```sh
git clone https://github.com/pgsty/minio git clone https://github.com/pgsty/silo
cd minio cd silo
go build -o silo . go build -o silo .
./silo --version ./silo --version
``` ```
The `pgsty/minio` source-repository name is transitional. Follow repository
redirects after the coordinated `pgsty/silo` cutover.
### Keep the lineage remote separate ### Keep the lineage remote separate
```sh ```sh
+1 -1
View File
@@ -72,7 +72,7 @@ FROM registry.access.redhat.com/ubi9/ubi-micro:latest
LABEL org.opencontainers.image.title="Silo" \ LABEL org.opencontainers.image.title="Silo" \
org.opencontainers.image.description="S3-Interface Libre Object Storage" \ org.opencontainers.image.description="S3-Interface Libre Object Storage" \
org.opencontainers.image.url="https://silo.pgsty.com" \ org.opencontainers.image.url="https://silo.pgsty.com" \
org.opencontainers.image.source="https://github.com/pgsty/minio" \ org.opencontainers.image.source="https://github.com/pgsty/silo" \
org.opencontainers.image.licenses="AGPL-3.0-or-later" \ org.opencontainers.image.licenses="AGPL-3.0-or-later" \
maintainer="PGSTY <https://silo.pgsty.com>" maintainer="PGSTY <https://silo.pgsty.com>"
+12 -12
View File
@@ -13,20 +13,20 @@
<a href="https://silo.pgsty.com/docs/">Documentation</a> · <a href="https://silo.pgsty.com/docs/">Documentation</a> ·
<a href="https://silo.pgsty.com/download/">Download</a> · <a href="https://silo.pgsty.com/download/">Download</a> ·
<a href="https://silo.pgsty.com/blog/">Blog</a> · <a href="https://silo.pgsty.com/blog/">Blog</a> ·
<a href="https://github.com/pgsty/minio/releases">Releases</a> · <a href="https://github.com/pgsty/silo/releases">Releases</a> ·
<a href="SECURITY.md">Security</a> · <a href="SECURITY.md">Security</a> ·
<a href="README_ZH.md">中文</a> <a href="README_ZH.md">中文</a>
</p> </p>
<p align="center"> <p align="center">
<a href="https://github.com/pgsty/minio/releases"><img alt="GitHub Release" src="https://img.shields.io/github/v/release/pgsty/minio?include_prereleases&label=release&logo=github"></a> <a href="https://github.com/pgsty/silo/releases"><img alt="GitHub Release" src="https://img.shields.io/github/v/release/pgsty/silo?include_prereleases&label=release&logo=github"></a>
<a href="https://hub.docker.com/r/pgsty/silo"><img alt="Docker Pulls" src="https://img.shields.io/docker/pulls/pgsty/silo?logo=docker"></a> <a href="https://hub.docker.com/r/pgsty/silo"><img alt="Docker Pulls" src="https://img.shields.io/docker/pulls/pgsty/silo?logo=docker"></a>
<a href="go.mod"><img alt="Go Version" src="https://img.shields.io/github/go-mod/go-version/pgsty/minio?logo=go"></a> <a href="go.mod"><img alt="Go Version" src="https://img.shields.io/github/go-mod/go-version/pgsty/silo?logo=go"></a>
<a href="LICENSE"><img alt="License" src="https://img.shields.io/badge/license-AGPLv3-blue"></a> <a href="LICENSE"><img alt="License" src="https://img.shields.io/badge/license-AGPLv3-blue"></a>
</p> </p>
> [!IMPORTANT] > [!IMPORTANT]
> Silo is an independent, community-maintained fork of the open-source MinIO server, published by [Pigsty](https://pigsty.io) from [`pgsty/minio`](https://github.com/pgsty/minio). It is not affiliated with, endorsed by, or sponsored by MinIO, Inc. “MinIO” is used only to identify the upstream project and compatibility lineage. > Silo is an independent, community-maintained fork of the open-source MinIO server, published by [Pigsty](https://pigsty.io) from [`pgsty/silo`](https://github.com/pgsty/silo). It is not affiliated with, endorsed by, or sponsored by MinIO, Inc. “MinIO” is used only to identify the upstream project and compatibility lineage.
## Overview ## Overview
@@ -42,8 +42,8 @@ The official project portal is [silo.pgsty.com](https://silo.pgsty.com/). It bri
| Installation methods and downloads | [Download & Install](https://silo.pgsty.com/download/) ([中文](https://silo.pgsty.com/zh/download/)) | | Installation methods and downloads | [Download & Install](https://silo.pgsty.com/download/) ([中文](https://silo.pgsty.com/zh/download/)) |
| Operations, administration, development, and reference | [Documentation](https://silo.pgsty.com/docs/) ([中文](https://silo.pgsty.com/zh/docs/)) | | Operations, administration, development, and reference | [Documentation](https://silo.pgsty.com/docs/) ([中文](https://silo.pgsty.com/zh/docs/)) |
| Project news, release notes, and security notes | [Blog](https://silo.pgsty.com/blog/), including [releases](https://silo.pgsty.com/blog/release/) and [security](https://silo.pgsty.com/blog/security/) | | Project news, release notes, and security notes | [Blog](https://silo.pgsty.com/blog/), including [releases](https://silo.pgsty.com/blog/release/) and [security](https://silo.pgsty.com/blog/security/) |
| Versioned binaries, checksums, and source archives | [GitHub Releases](https://github.com/pgsty/minio/releases) | | Versioned binaries, checksums, and source archives | [GitHub Releases](https://github.com/pgsty/silo/releases) |
| Bug reports and feature discussions | [GitHub Issues](https://github.com/pgsty/minio/issues) | | Bug reports and feature discussions | [GitHub Issues](https://github.com/pgsty/silo/issues) |
| License, attribution, and trademark information | [License](https://silo.pgsty.com/about/license/), [Attribution](https://silo.pgsty.com/about/attribution/), and [Trademark](https://silo.pgsty.com/about/trademark/) | | License, attribution, and trademark information | [License](https://silo.pgsty.com/about/license/), [Attribution](https://silo.pgsty.com/about/attribution/), and [Trademark](https://silo.pgsty.com/about/trademark/) |
## Maintenance Policy ## Maintenance Policy
@@ -84,9 +84,9 @@ Use [Download & Install](https://silo.pgsty.com/download/) to choose an installa
| Artifact | Location | | Artifact | Location |
| :-- | :-- | | :-- | :-- |
| Source | [`github.com/pgsty/minio`](https://github.com/pgsty/minio) | | Source | [`github.com/pgsty/silo`](https://github.com/pgsty/silo) |
| Container image | [`pgsty/silo`](https://hub.docker.com/r/pgsty/silo), multi-arch for `linux/amd64` and `linux/arm64` | | Container image | [`pgsty/silo`](https://hub.docker.com/r/pgsty/silo), multi-arch for `linux/amd64` and `linux/arm64` |
| Server binaries and checksums | [GitHub Releases](https://github.com/pgsty/minio/releases) for Linux, macOS, and Windows on `amd64` and `arm64` | | Server binaries and checksums | [GitHub Releases](https://github.com/pgsty/silo/releases) for Linux, macOS, and Windows on `amd64` and `arm64` |
| Linux packages | RPM, DEB, and APK artifacts, also distributed through the [Pigsty repository](https://pigsty.io/docs/repo/) | | Linux packages | RPM, DEB, and APK artifacts, also distributed through the [Pigsty repository](https://pigsty.io/docs/repo/) |
| Client | [`pgsty/mc`](https://github.com/pgsty/mc), bundled in the container as `mcli` with an `mc` compatibility alias | | Client | [`pgsty/mc`](https://github.com/pgsty/mc), bundled in the container as `mcli` with an `mc` compatibility alias |
| Console | [`pgsty/silo-console`](https://github.com/pgsty/silo-console), embedded through the compatibility import path `github.com/minio/console` | | Console | [`pgsty/silo-console`](https://github.com/pgsty/silo-console), embedded through the compatibility import path `github.com/minio/console` |
@@ -116,7 +116,7 @@ cosign verify-blob \
# Signed build provenance (online verification against this repository). # Signed build provenance (online verification against this repository).
gh attestation verify silo_<version>_linux_amd64.tar.gz \ gh attestation verify silo_<version>_linux_amd64.tar.gz \
--repo pgsty/minio --repo pgsty/silo
``` ```
For packages, use `silo_<version>_packages_checksums.txt` and its adjacent For packages, use `silo_<version>_packages_checksums.txt` and its adjacent
@@ -127,7 +127,7 @@ multi-architecture container provenance by digest:
```bash ```bash
gh attestation verify \ gh attestation verify \
oci://index.docker.io/pgsty/silo@sha256:<manifest-digest> \ oci://index.docker.io/pgsty/silo@sha256:<manifest-digest> \
--repo pgsty/minio --repo pgsty/silo
``` ```
The platform SBOM attestations are attached to the `amd64` and `arm64` image The platform SBOM attestations are attached to the `amd64` and `arm64` image
@@ -136,7 +136,7 @@ digests rather than the multi-architecture manifest. Verify each one explicitly:
```bash ```bash
gh attestation verify \ gh attestation verify \
oci://index.docker.io/pgsty/silo@sha256:<platform-digest> \ oci://index.docker.io/pgsty/silo@sha256:<platform-digest> \
--repo pgsty/minio \ --repo pgsty/silo \
--predicate-type https://spdx.dev/Document/v2.3 --predicate-type https://spdx.dev/Document/v2.3
``` ```
@@ -232,4 +232,4 @@ This project was created in response to changes in the upstream community distri
## License and Trademark ## License and Trademark
The server remains licensed under the [GNU Affero General Public License v3.0](LICENSE). See [`CREDITS`](CREDITS) and [`NOTICE`](NOTICE) for upstream authorship and attribution. MinIO is a trademark of MinIO, Inc. Silo is an independent community project and is not affiliated with or endorsed by MinIO, Inc. The source repository retains the transitional `pgsty/minio` name until the coordinated repository cutover. The server remains licensed under the [GNU Affero General Public License v3.0](LICENSE). See [`CREDITS`](CREDITS) and [`NOTICE`](NOTICE) for upstream authorship and attribution. MinIO is a trademark of MinIO, Inc. Silo is an independent community project and is not affiliated with or endorsed by MinIO, Inc.
+12 -12
View File
@@ -13,20 +13,20 @@
<a href="https://silo.pgsty.com/zh/docs/">文档</a> · <a href="https://silo.pgsty.com/zh/docs/">文档</a> ·
<a href="https://silo.pgsty.com/zh/download/">下载</a> · <a href="https://silo.pgsty.com/zh/download/">下载</a> ·
<a href="https://silo.pgsty.com/zh/blog/">博客</a> · <a href="https://silo.pgsty.com/zh/blog/">博客</a> ·
<a href="https://github.com/pgsty/minio/releases">版本发布</a> · <a href="https://github.com/pgsty/silo/releases">版本发布</a> ·
<a href="SECURITY.md">安全策略</a> · <a href="SECURITY.md">安全策略</a> ·
<a href="README.md">English</a> <a href="README.md">English</a>
</p> </p>
<p align="center"> <p align="center">
<a href="https://github.com/pgsty/minio/releases"><img alt="GitHub Release" src="https://img.shields.io/github/v/release/pgsty/minio?include_prereleases&label=release&logo=github"></a> <a href="https://github.com/pgsty/silo/releases"><img alt="GitHub Release" src="https://img.shields.io/github/v/release/pgsty/silo?include_prereleases&label=release&logo=github"></a>
<a href="https://hub.docker.com/r/pgsty/silo"><img alt="Docker Pulls" src="https://img.shields.io/docker/pulls/pgsty/silo?logo=docker"></a> <a href="https://hub.docker.com/r/pgsty/silo"><img alt="Docker Pulls" src="https://img.shields.io/docker/pulls/pgsty/silo?logo=docker"></a>
<a href="go.mod"><img alt="Go Version" src="https://img.shields.io/github/go-mod/go-version/pgsty/minio?logo=go"></a> <a href="go.mod"><img alt="Go Version" src="https://img.shields.io/github/go-mod/go-version/pgsty/silo?logo=go"></a>
<a href="LICENSE"><img alt="License" src="https://img.shields.io/badge/license-AGPLv3-blue"></a> <a href="LICENSE"><img alt="License" src="https://img.shields.io/badge/license-AGPLv3-blue"></a>
</p> </p>
> [!IMPORTANT] > [!IMPORTANT]
> Silo 是由 [Pigsty](https://pigsty.cc) 独立维护、从 [`pgsty/minio`](https://github.com/pgsty/minio) 发布的开源 MinIO 社区分支。本项目与 MinIO, Inc. 不存在隶属、背书或赞助关系;文中使用 “MinIO” 仅用于说明上游项目及兼容谱系。 > Silo 是由 [Pigsty](https://pigsty.cc) 独立维护、从 [`pgsty/silo`](https://github.com/pgsty/silo) 发布的开源 MinIO 社区分支。本项目与 MinIO, Inc. 不存在隶属、背书或赞助关系;文中使用 “MinIO” 仅用于说明上游项目及兼容谱系。
## 概述 ## 概述
@@ -44,8 +44,8 @@ Pigsty 使用本分支提供对象存储,包括 PostgreSQL 备份存储。
| 安装方式与软件下载 | [下载与安装](https://silo.pgsty.com/zh/download/)[English](https://silo.pgsty.com/download/) | | 安装方式与软件下载 | [下载与安装](https://silo.pgsty.com/zh/download/)[English](https://silo.pgsty.com/download/) |
| 运维、管理、开发与参考指南 | [中文文档](https://silo.pgsty.com/zh/docs/)[English](https://silo.pgsty.com/docs/) | | 运维、管理、开发与参考指南 | [中文文档](https://silo.pgsty.com/zh/docs/)[English](https://silo.pgsty.com/docs/) |
| 项目动态、版本说明与安全通告 | [博客](https://silo.pgsty.com/zh/blog/),包括[版本发布](https://silo.pgsty.com/zh/blog/release/)与[安全通告](https://silo.pgsty.com/zh/blog/security/) | | 项目动态、版本说明与安全通告 | [博客](https://silo.pgsty.com/zh/blog/),包括[版本发布](https://silo.pgsty.com/zh/blog/release/)与[安全通告](https://silo.pgsty.com/zh/blog/security/) |
| 带版本的二进制、校验和与源码归档 | [GitHub Releases](https://github.com/pgsty/minio/releases) | | 带版本的二进制、校验和与源码归档 | [GitHub Releases](https://github.com/pgsty/silo/releases) |
| 缺陷报告与功能讨论 | [GitHub Issues](https://github.com/pgsty/minio/issues) | | 缺陷报告与功能讨论 | [GitHub Issues](https://github.com/pgsty/silo/issues) |
| 私密漏洞报告 | [`SECURITY.md`](SECURITY.md) 与 [`VULNERABILITY_REPORT.md`](VULNERABILITY_REPORT.md) | | 私密漏洞报告 | [`SECURITY.md`](SECURITY.md) 与 [`VULNERABILITY_REPORT.md`](VULNERABILITY_REPORT.md) |
| 许可证、署名与商标信息 | [许可证](https://silo.pgsty.com/zh/about/license/)、[署名归属](https://silo.pgsty.com/zh/about/attribution/)与[商标政策](https://silo.pgsty.com/zh/about/trademark/) | | 许可证、署名与商标信息 | [许可证](https://silo.pgsty.com/zh/about/license/)、[署名归属](https://silo.pgsty.com/zh/about/attribution/)与[商标政策](https://silo.pgsty.com/zh/about/trademark/) |
@@ -87,9 +87,9 @@ Silo 自有交付面统一使用 `silo` 可执行文件、软件包、服务、H
| 产物 | 位置 | | 产物 | 位置 |
| :-- | :-- | | :-- | :-- |
| 源码 | [`github.com/pgsty/minio`](https://github.com/pgsty/minio) | | 源码 | [`github.com/pgsty/silo`](https://github.com/pgsty/silo) |
| 容器镜像 | [`pgsty/silo`](https://hub.docker.com/r/pgsty/silo),支持 `linux/amd64``linux/arm64` 多架构清单 | | 容器镜像 | [`pgsty/silo`](https://hub.docker.com/r/pgsty/silo),支持 `linux/amd64``linux/arm64` 多架构清单 |
| 服务端二进制与校验和 | [GitHub Releases](https://github.com/pgsty/minio/releases),覆盖 Linux、macOS、Windows 的 `amd64``arm64` | | 服务端二进制与校验和 | [GitHub Releases](https://github.com/pgsty/silo/releases),覆盖 Linux、macOS、Windows 的 `amd64``arm64` |
| Linux 软件包 | RPM、DEB、APK,并通过 [Pigsty 软件仓库](https://pigsty.cc/docs/repo/) 分发 | | Linux 软件包 | RPM、DEB、APK,并通过 [Pigsty 软件仓库](https://pigsty.cc/docs/repo/) 分发 |
| 客户端 | [`pgsty/mc`](https://github.com/pgsty/mc),容器内以 `mcli` 提供,并保留 `mc` 兼容别名 | | 客户端 | [`pgsty/mc`](https://github.com/pgsty/mc),容器内以 `mcli` 提供,并保留 `mc` 兼容别名 |
| 管理控制台 | [`pgsty/silo-console`](https://github.com/pgsty/silo-console),通过兼容导入路径 `github.com/minio/console` 嵌入服务端构建 | | 管理控制台 | [`pgsty/silo-console`](https://github.com/pgsty/silo-console),通过兼容导入路径 `github.com/minio/console` 嵌入服务端构建 |
@@ -118,7 +118,7 @@ cosign verify-blob \
# 在线验证本仓库签发的构建来源。 # 在线验证本仓库签发的构建来源。
gh attestation verify silo_<version>_linux_amd64.tar.gz \ gh attestation verify silo_<version>_linux_amd64.tar.gz \
--repo pgsty/minio --repo pgsty/silo
``` ```
软件包使用 `silo_<version>_packages_checksums.txt` 及其相邻的 Sigstore 软件包使用 `silo_<version>_packages_checksums.txt` 及其相邻的 Sigstore
@@ -128,7 +128,7 @@ SPDX JSON SBOM。按 digest 验证多架构容器清单的构建来源:
```bash ```bash
gh attestation verify \ gh attestation verify \
oci://index.docker.io/pgsty/silo@sha256:<manifest-digest> \ oci://index.docker.io/pgsty/silo@sha256:<manifest-digest> \
--repo pgsty/minio --repo pgsty/silo
``` ```
分架构 SBOM 证明附在 `amd64``arm64` 平台镜像的 digest 上,而非多架构 分架构 SBOM 证明附在 `amd64``arm64` 平台镜像的 digest 上,而非多架构
@@ -137,7 +137,7 @@ gh attestation verify \
```bash ```bash
gh attestation verify \ gh attestation verify \
oci://index.docker.io/pgsty/silo@sha256:<platform-digest> \ oci://index.docker.io/pgsty/silo@sha256:<platform-digest> \
--repo pgsty/minio \ --repo pgsty/silo \
--predicate-type https://spdx.dev/Document/v2.3 --predicate-type https://spdx.dev/Document/v2.3
``` ```
@@ -233,4 +233,4 @@ Issue 与 Pull Request 应说明受影响版本、复现步骤、影响、预期
服务端继续采用 [GNU Affero General Public License v3.0](LICENSE) 发布。上游作者与署名信息见 [`CREDITS`](CREDITS) 与 [`NOTICE`](NOTICE)。 服务端继续采用 [GNU Affero General Public License v3.0](LICENSE) 发布。上游作者与署名信息见 [`CREDITS`](CREDITS) 与 [`NOTICE`](NOTICE)。
MinIO 是 MinIO, Inc. 的商标。Silo 是独立社区项目,与 MinIO, Inc. 不存在隶属或背书关系;源码仓库在协调切换完成前暂时保留过渡名称 `pgsty/minio` MinIO 是 MinIO, Inc. 的商标。Silo 是独立社区项目,与 MinIO, Inc. 不存在隶属或背书关系。
+3 -4
View File
@@ -1,9 +1,8 @@
# Security Policy # Security Policy
Silo is an independent, community-maintained object-storage server derived from Silo is an independent, community-maintained object-storage server derived from
the open-source MinIO server. The source repository retains the transitional the open-source MinIO server. Upstream MinIO security contacts do not handle
name `pgsty/minio` until the coordinated repository cutover. Upstream MinIO Silo-specific fixes or release notes.
security contacts do not handle Silo-specific fixes or release notes.
## Supported Versions ## Supported Versions
@@ -16,7 +15,7 @@ Silo release line is supported unless an advisory says otherwise.
For vulnerabilities in this fork: For vulnerabilities in this fork:
1. Follow the fork-specific expectations in [VULNERABILITY_REPORT.md](VULNERABILITY_REPORT.md). 1. Follow the fork-specific expectations in [VULNERABILITY_REPORT.md](VULNERABILITY_REPORT.md).
2. Prefer this repository's [private GitHub security advisory](https://github.com/pgsty/minio/security/advisories/new) workflow. 2. Prefer this repository's [private GitHub security advisory](https://github.com/pgsty/silo/security/advisories/new) workflow.
3. If private reporting is unavailable, contact the maintainers through the 3. If private reporting is unavailable, contact the maintainers through the
repository without publishing exploit details until a private channel is repository without publishing exploit details until a private channel is
established. established.
@@ -10146,7 +10146,6 @@
"cmd/data-scanner.go=\"x-minio-versions-count\"", "cmd/data-scanner.go=\"x-minio-versions-count\"",
"cmd/data-scanner.go=\"x-minio-versions-size\"", "cmd/data-scanner.go=\"x-minio-versions-size\"",
"cmd/erasure-metadata.go=\"x-minio-internal-erasure-upgraded\"", "cmd/erasure-metadata.go=\"x-minio-internal-erasure-upgraded\"",
"cmd/erasure-sets.go=\"Unable to heal the newly replaced drives due to format.json inconsistencies; please report this to Silo maintainers at https://github.com/pgsty/minio/issues: %w\"",
"cmd/event-notification.go=\"minio:s3\"", "cmd/event-notification.go=\"minio:s3\"",
"cmd/event-notification.go=\"x-minio-deployment-id\"", "cmd/event-notification.go=\"x-minio-deployment-id\"",
"cmd/event-notification.go=\"x-minio-origin-endpoint\"", "cmd/event-notification.go=\"x-minio-origin-endpoint\"",
@@ -10218,7 +10217,6 @@
"cmd/object-multipart-handlers.go=\"X-Minio-Replication-Server-Side-Encryption-Sealed-Key\"", "cmd/object-multipart-handlers.go=\"X-Minio-Replication-Server-Side-Encryption-Sealed-Key\"",
"cmd/s3-zip-handlers.go=\"x-minio-extract\"", "cmd/s3-zip-handlers.go=\"x-minio-extract\"",
"cmd/server-startup-msg.go=\"https://silo.pgsty.com/reference/minio-mc/#quickstart\"", "cmd/server-startup-msg.go=\"https://silo.pgsty.com/reference/minio-mc/#quickstart\"",
"cmd/storage-errors.go=\"unexpected error, please report this issue at https://github.com/pgsty/minio/issues\"",
"cmd/storage-rest-server.go=\"X-Minio-Time\"", "cmd/storage-rest-server.go=\"X-Minio-Time\"",
"cmd/tier.go=\"X-MinIO-TierCfg-RefreshedAt\"", "cmd/tier.go=\"X-MinIO-TierCfg-RefreshedAt\"",
"cmd/update.go=\"minio\"", "cmd/update.go=\"minio\"",
@@ -10232,7 +10230,6 @@
"cmd/xl-storage-format-v2.go=\"\\xbcX-Minio-Internal-compression\\xc4\\x15klauspost/compress/s2\"", "cmd/xl-storage-format-v2.go=\"\\xbcX-Minio-Internal-compression\\xc4\\x15klauspost/compress/s2\"",
"internal/arn/arn.go=\"minio\"", "internal/arn/arn.go=\"minio\"",
"internal/bucket/replication/destination.go=\"arn:minio:replication:\"", "internal/bucket/replication/destination.go=\"arn:minio:replication:\"",
"internal/config/errors.go=\"Please report this Silo error at https://github.com/pgsty/minio/issues\"",
"internal/config/errors.go=\"Please set the correct default KMS key value or the correct root credentials for older MinIO versions.\"", "internal/config/errors.go=\"Please set the correct default KMS key value or the correct root credentials for older MinIO versions.\"",
"internal/config/errors.go=\"Revert MINIO_KMS_KES_KEY_NAME or MINIO_ROOT_USER/MINIO_ROOT_PASSWORD (for older MinIO versions) to be able to decrypt the internal data again.\"", "internal/config/errors.go=\"Revert MINIO_KMS_KES_KEY_NAME or MINIO_ROOT_USER/MINIO_ROOT_PASSWORD (for older MinIO versions) to be able to decrypt the internal data again.\"",
"internal/config/lambda/event/arn.go=\"arn:minio:s3-object-lambda:\"", "internal/config/lambda/event/arn.go=\"arn:minio:s3-object-lambda:\"",
+1 -2
View File
@@ -18,8 +18,7 @@ expected_payload="/etc/default/silo
/usr/bin/silo /usr/bin/silo
/usr/lib/systemd/system/silo.service /usr/lib/systemd/system/silo.service
/usr/lib/sysusers.d/silo.conf" /usr/lib/sysusers.d/silo.conf"
# Transitional until the irreversible GitHub repository rename. repository="${GH_REPO:-pgsty/silo}"
repository="${GH_REPO:-pgsty/minio}"
container="${DNFUPDATE_CONTAINER:-dnfupdate}" container="${DNFUPDATE_CONTAINER:-dnfupdate}"
upload=false upload=false
release_tag="" release_tag=""
+28
View File
@@ -135,6 +135,34 @@ if rg -n 'pgsty/minio:' .github/workflows Dockerfile.goreleaser helm/silo; then
fail "an active delivery surface still publishes the frozen pgsty/minio image" fail "an active delivery surface still publishes the frozen pgsty/minio image"
fi fi
# The repository and its default branch are pgsty/silo and main. Only three
# places may still name the old repository, and each one exists to reject or
# freeze it rather than to point users at it: the pinned pre-rebrand image
# digest in the upgrade test, and the two guards that refuse a legacy image.
repo_guard_allowlist='^(buildscripts/minio-upgrade\.sh|buildscripts/verify-rebrand\.sh|buildscripts/helm-migration-guard/main\.go):'
stale_repo="$(rg -n 'pgsty/minio' --glob '!.git/**' --glob '!dist/**' \
--glob '!SILO_REBRANDING_MIGRATION.md' \
--glob '!buildscripts/rebrand-guard/compat-baseline.json' . |
sed 's#^\./##' | grep -Ev "${repo_guard_allowlist}" || true)"
if [ -n "${stale_repo}" ]; then
printf '%s\n' "${stale_repo}" >&2
fail "a source reference still names the pre-rename pgsty/minio repository"
fi
stale_branch="$(rg -n 'pgsty/silo/(blob/|tree/|raw/)?master' \
--glob '!.git/**' --glob '!dist/**' . || true)"
if [ -n "${stale_branch}" ]; then
printf '%s\n' "${stale_branch}" >&2
fail "a link still targets the retired master branch; raw and Actions URLs do not follow a branch rename"
fi
for workflow in .github/workflows/go.yml .github/workflows/vulncheck.yml; do
if rg -q '^\s+- master$' "${workflow}"; then
fail "${workflow} still filters on master and would go silently dormant on main"
fi
require_text "${workflow}" " - main"
done
network_hits="$(rg -n --glob '*.go' --glob '!**/*_test.go' \ network_hits="$(rg -n --glob '*.go' --glob '!**/*_test.go' \
'https?://[^"`[:space:]]*(dl\.min\.io|subnet\.min\.io|api\.min\.io|slack\.min\.io|play\.min\.io)' \ 'https?://[^"`[:space:]]*(dl\.min\.io|subnet\.min\.io|api\.min\.io|slack\.min\.io|play\.min\.io)' \
cmd internal || true)" cmd internal || true)"
+1 -1
View File
@@ -148,7 +148,7 @@ func apiErrorCode(t *testing.T, rec *httptest.ResponseRecorder) string {
return e.Code return e.Code
} }
// TestAPICompleteMultipartFullObjectChecksum covers pgsty/minio#31. // TestAPICompleteMultipartFullObjectChecksum covers pgsty/silo#31.
// //
// A multipart upload created with a full object checksum type must be // A multipart upload created with a full object checksum type must be
// completable by sending only PartNumber and ETag per part, plus the object // completable by sending only PartNumber and ETag per part, plus the object
+1 -1
View File
@@ -1051,7 +1051,7 @@ func (s *erasureSets) HealFormat(ctx context.Context, dryRun bool) (res madmin.H
if !reflect.DeepEqual(s.format, refFormat) { if !reflect.DeepEqual(s.format, refFormat) {
// Format is corrupted and unrecognized by the running instance. // Format is corrupted and unrecognized by the running instance.
healingLogIf(ctx, fmt.Errorf("Unable to heal the newly replaced drives due to format.json inconsistencies; please report this to Silo maintainers at https://github.com/pgsty/minio/issues: %w", healingLogIf(ctx, fmt.Errorf("Unable to heal the newly replaced drives due to format.json inconsistencies; please report this to Silo maintainers at https://github.com/pgsty/silo/issues: %w",
errCorruptedFormat)) errCorruptedFormat))
return res, errCorruptedFormat return res, errCorruptedFormat
} }
+1 -1
View File
@@ -26,7 +26,7 @@ import (
var errMaxVersionsExceeded = StorageErr("maximum versions exceeded, please delete few versions to proceed") var errMaxVersionsExceeded = StorageErr("maximum versions exceeded, please delete few versions to proceed")
// errUnexpected - unexpected error, requires manual intervention. // errUnexpected - unexpected error, requires manual intervention.
var errUnexpected = StorageErr("unexpected error, please report this issue at https://github.com/pgsty/minio/issues") var errUnexpected = StorageErr("unexpected error, please report this issue at https://github.com/pgsty/silo/issues")
// errCorruptedFormat - corrupted format. // errCorruptedFormat - corrupted format.
var errCorruptedFormat = StorageErr("corrupted format") var errCorruptedFormat = StorageErr("corrupted format")
+12 -12
View File
@@ -2,7 +2,7 @@
## **1. Cloud-native Architecture** ## **1. Cloud-native Architecture**
![cloud-native](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image1.png?raw=true "cloud native architecture") ![cloud-native](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image1.png?raw=true "cloud native architecture")
Kubernetes manages stateless Spark and Hive containers elastically on the compute nodes. Spark has native scheduler integration with Kubernetes. Hive, for legacy reasons, uses YARN scheduler on top of Kubernetes. Kubernetes manages stateless Spark and Hive containers elastically on the compute nodes. Spark has native scheduler integration with Kubernetes. Hive, for legacy reasons, uses YARN scheduler on top of Kubernetes.
@@ -23,17 +23,17 @@ Silo also supports multi-cluster, multi-site federation similar to AWS regions a
After successful installation navigate to the Ambari UI `http://<ambari-server>:8080/` and login using the default credentials: [**_username: admin, password: admin_**] After successful installation navigate to the Ambari UI `http://<ambari-server>:8080/` and login using the default credentials: [**_username: admin, password: admin_**]
![ambari-login](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image3.png?raw=true "ambari login") ![ambari-login](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image3.png?raw=true "ambari login")
### **3.1 Configure Hadoop** ### **3.1 Configure Hadoop**
Navigate to **Services** -> **HDFS** -> **CONFIGS** -> **ADVANCED** as shown below Navigate to **Services** -> **HDFS** -> **CONFIGS** -> **ADVANCED** as shown below
![hdfs-configs](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image2.png?raw=true "hdfs advanced configs") ![hdfs-configs](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image2.png?raw=true "hdfs advanced configs")
Navigate to **Custom core-site** to configure Silo parameters for `_s3a_` connector Navigate to **Custom core-site** to configure Silo parameters for `_s3a_` connector
![s3a-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image5.png?raw=true "custom core-site") ![s3a-config](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image5.png?raw=true "custom core-site")
``` ```
sudo pip install yq sudo pip install yq
@@ -100,17 +100,17 @@ The rest of the other optimization options are discussed in the links below
Once the config changes are applied, proceed to restart **Hadoop** services. Once the config changes are applied, proceed to restart **Hadoop** services.
![hdfs-services](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image7.png?raw=true "hdfs restart services") ![hdfs-services](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image7.png?raw=true "hdfs restart services")
### **3.2 Configure Spark2** ### **3.2 Configure Spark2**
Navigate to **Services** -> **Spark2** -> **CONFIGS** as shown below Navigate to **Services** -> **Spark2** -> **CONFIGS** as shown below
![spark-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image6.png?raw=true "spark config") ![spark-config](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image6.png?raw=true "spark config")
Navigate to “**Custom spark-defaults**” to configure Silo parameters for `_s3a_` connector Navigate to “**Custom spark-defaults**” to configure Silo parameters for `_s3a_` connector
![spark-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image9.png?raw=true "spark defaults") ![spark-config](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image9.png?raw=true "spark defaults")
Add the following optimal entries for _spark-defaults.conf_ to configure Spark with **Silo**. Add the following optimal entries for _spark-defaults.conf_ to configure Spark with **Silo**.
@@ -146,17 +146,17 @@ spark.hadoop.fs.s3a.threads.max 2048 # maximum number of threads for S3A
Once the config changes are applied, proceed to restart **Spark** services. Once the config changes are applied, proceed to restart **Spark** services.
![spark-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image12.png?raw=true "spark restart services") ![spark-config](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image12.png?raw=true "spark restart services")
### **3.3 Configure Hive** ### **3.3 Configure Hive**
Navigate to **Services** -> **Hive** -> **CONFIGS**-> **ADVANCED** as shown below Navigate to **Services** -> **Hive** -> **CONFIGS**-> **ADVANCED** as shown below
![hive-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image10.png?raw=true "hive advanced config") ![hive-config](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image10.png?raw=true "hive advanced config")
Navigate to “**Custom hive-site**” to configure Silo parameters for `_s3a_` connector Navigate to “**Custom hive-site**” to configure Silo parameters for `_s3a_` connector
![hive-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image11.png?raw=true "hive advanced config") ![hive-config](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image11.png?raw=true "hive advanced config")
Add the following optimal entries for `hive-site.xml` to configure Hive with **Silo**. Add the following optimal entries for `hive-site.xml` to configure Hive with **Silo**.
@@ -171,11 +171,11 @@ mapreduce.input.fileinputformat.list-status.num-threads=50
For more information about these options please visit [https://www.cloudera.com/documentation/enterprise/5-11-x/topics/admin_hive_on_s3_tuning.html](https://www.cloudera.com/documentation/enterprise/5-11-x/topics/admin_hive_on_s3_tuning.html) For more information about these options please visit [https://www.cloudera.com/documentation/enterprise/5-11-x/topics/admin_hive_on_s3_tuning.html](https://www.cloudera.com/documentation/enterprise/5-11-x/topics/admin_hive_on_s3_tuning.html)
![hive-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image13.png?raw=true "hive advanced custom config") ![hive-config](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image13.png?raw=true "hive advanced custom config")
Once the config changes are applied, proceed to restart all Hive services. Once the config changes are applied, proceed to restart all Hive services.
![hive-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image14.png?raw=true "restart hive services") ![hive-config](https://github.com/pgsty/silo/blob/main/docs/bigdata/images/image14.png?raw=true "restart hive services")
## **4. Run Sample Applications** ## **4. Run Sample Applications**
+1 -1
View File
@@ -1,6 +1,6 @@
# ILM Tiering Design [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/) # ILM Tiering Design [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
Lifecycle transition functionality provided in [bucket lifecycle guide](https://github.com/pgsty/minio/blob/master/docs/bucket/lifecycle/README.md) allows tiering of content from Silo object store to public clouds or other Silo clusters. Lifecycle transition functionality provided in [bucket lifecycle guide](https://github.com/pgsty/silo/blob/main/docs/bucket/lifecycle/README.md) allows tiering of content from Silo object store to public clouds or other Silo clusters.
Transition tiers can be added to Silo using `mc admin tier add` command to associate a `gcs`, `s3` or `azure` bucket or prefix path on a bucket to the tier name. Transition tiers can be added to Silo using `mc admin tier add` command to associate a `gcs`, `s3` or `azure` bucket or prefix path on a bucket to the tier name.
Lifecycle transition rules can be applied to buckets (both versioned and un-versioned) by specifying the tier name defined above as the transition storage class for the lifecycle rule. Lifecycle transition rules can be applied to buckets (both versioned and un-versioned) by specifying the tier name defined above as the transition storage class for the lifecycle rule.
+1 -1
View File
@@ -1,6 +1,6 @@
# Bucket Quota Configuration Quickstart Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/) # Bucket Quota Configuration Quickstart Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
![quota](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/quota/bucketquota.png) ![quota](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/quota/bucketquota.png)
Buckets can be configured to have `Hard` quota - it disallows writes to the bucket after configured quota limit is reached. Buckets can be configured to have `Hard` quota - it disallows writes to the bucket after configured quota limit is reached.
+2 -2
View File
@@ -1,6 +1,6 @@
# Bucket Replication Design [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/) # Bucket Replication Design [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
This document explains the design approach of server side bucket replication. If you're looking to get started with replication, we suggest you go through the [Bucket replication guide](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/README.md) first. This document explains the design approach of server side bucket replication. If you're looking to get started with replication, we suggest you go through the [Bucket replication guide](https://github.com/pgsty/silo/blob/main/docs/bucket/replication/README.md) first.
## Overview ## Overview
@@ -59,7 +59,7 @@ If 3 or more targets are participating in active-active replication, the replica
### Internal metadata for replication ### Internal metadata for replication
`xl.meta` that is in use for [versioning](https://github.com/pgsty/minio/blob/master/docs/bucket/versioning/DESIGN.md) has additional metadata for replication of objects,delete markers and versioned deletes. `xl.meta` that is in use for [versioning](https://github.com/pgsty/silo/blob/main/docs/bucket/versioning/DESIGN.md) has additional metadata for replication of objects,delete markers and versioned deletes.
### Metadata for object replication - on source ### Metadata for object replication - on source
+6 -6
View File
@@ -94,7 +94,7 @@ The access key provided for the replication *target* cluster should have these m
} }
``` ```
Please note that the permissions required by the admin user on the target cluster can be more fine grained to exclude permissions like "s3:ReplicateDelete", "s3:GetBucketObjectLockConfiguration" etc depending on whether delete replication rules are set up or if object locking is disabled on `destbucket`. The above policies assume that replication of objects, tags and delete marker replication are all enabled on object lock enabled buckets. A sample script to setup replication is provided [here](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/setup_replication.sh) Please note that the permissions required by the admin user on the target cluster can be more fine grained to exclude permissions like "s3:ReplicateDelete", "s3:GetBucketObjectLockConfiguration" etc depending on whether delete replication rules are set up or if object locking is disabled on `destbucket`. The above policies assume that replication of objects, tags and delete marker replication are all enabled on object lock enabled buckets. A sample script to setup replication is provided [here](https://github.com/pgsty/silo/blob/main/docs/bucket/replication/setup_replication.sh)
To set up replication from `srcbucket` on the `mysilo` cluster to `destbucket` To set up replication from `srcbucket` on the `mysilo` cluster to `destbucket`
on a target Silo cluster at `https://replica-endpoint:9000`, use: on a target Silo cluster at `https://replica-endpoint:9000`, use:
@@ -162,9 +162,9 @@ Replication status can be seen in the metadata on the source and destination obj
To perform bi-directional replication, repeat the above process on the target site - this time setting the source bucket as the replication target. It is recommended that replication be run in a system with at least two CPU's available to the process, so that replication can run in its own thread. To perform bi-directional replication, repeat the above process on the target site - this time setting the source bucket as the replication target. It is recommended that replication be run in a system with at least two CPU's available to the process, so that replication can run in its own thread.
![put](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/replication/PUT_bucket_replication.png) ![put](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/replication/PUT_bucket_replication.png)
![head](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/replication/HEAD_bucket_replication.png) ![head](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/replication/HEAD_bucket_replication.png)
## Replica Modification sync ## Replica Modification sync
@@ -211,11 +211,11 @@ Also note that `mc` version `RELEASE.2021-09-02T09-21-27Z` or older supports onl
Status of delete marker replication can be viewed by doing a GET/HEAD on the object version - it will return a `X-Minio-Replication-DeleteMarker-Status` header and http response code of `405`. In the case of permanent deletes, if the delete replication is pending or failed to propagate to the target cluster, GET/HEAD will return additional `X-Minio-Replication-Delete-Status` header and a http response code of `405`. Status of delete marker replication can be viewed by doing a GET/HEAD on the object version - it will return a `X-Minio-Replication-DeleteMarker-Status` header and http response code of `405`. In the case of permanent deletes, if the delete replication is pending or failed to propagate to the target cluster, GET/HEAD will return additional `X-Minio-Replication-Delete-Status` header and a http response code of `405`.
![delete](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/replication/DELETE_bucket_replication.png) ![delete](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/replication/DELETE_bucket_replication.png)
The status of replication can be monitored by configuring event notifications on the source and target buckets using `mc event add`.On the source side, the `s3:PutObject`, `s3:Replication:OperationCompletedReplication` and `s3:Replication:OperationFailedReplication` events show the status of replication in the `X-Amz-Replication-Status` metadata. The status of replication can be monitored by configuring event notifications on the source and target buckets using `mc event add`.On the source side, the `s3:PutObject`, `s3:Replication:OperationCompletedReplication` and `s3:Replication:OperationFailedReplication` events show the status of replication in the `X-Amz-Replication-Status` metadata.
On the target bucket, `s3:PutObject` event shows `X-Amz-Replication-Status` status of `REPLICA` in the metadata. Additional metrics to monitor backlog state for the purpose of bandwidth management and resource allocation are exposed via Prometheus - see <https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/list.md> for more details. On the target bucket, `s3:PutObject` event shows `X-Amz-Replication-Status` status of `REPLICA` in the metadata. Additional metrics to monitor backlog state for the purpose of bandwidth management and resource allocation are exposed via Prometheus - see <https://github.com/pgsty/silo/blob/main/docs/metrics/prometheus/list.md> for more details.
### Sync/Async Replication ### Sync/Async Replication
@@ -277,6 +277,6 @@ Silo does not support SSE-C encrypted objects on replicated buckets, any applica
## Explore Further ## Explore Further
- [Silo Bucket Replication Design](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/DESIGN.md) - [Silo Bucket Replication Design](https://github.com/pgsty/silo/blob/main/docs/bucket/replication/DESIGN.md)
- [Silo Bucket Versioning Implementation](https://silo.pgsty.com/administration/object-management/object-retention/) - [Silo Bucket Versioning Implementation](https://silo.pgsty.com/administration/object-management/object-retention/)
- [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart) - [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
+1 -1
View File
@@ -42,7 +42,7 @@ Therefore, the metadata is wrapped as a binary array for easy skipping.
- LegacyObjectType (preserves existing deployments and older xl.json format) - LegacyObjectType (preserves existing deployments and older xl.json format)
- DeleteMarker (a versionId to capture the DELETE sequences implemented primarily for AWS spec compatibility) - DeleteMarker (a versionId to capture the DELETE sequences implemented primarily for AWS spec compatibility)
A sample msgpack-JSON `xl.meta`, you can debug the content inside `xl.meta` using [xl-meta.go](https://github.com/pgsty/minio/tree/master/docs/debugging#decoding-metadata) program. A sample msgpack-JSON `xl.meta`, you can debug the content inside `xl.meta` using [xl-meta.go](https://github.com/pgsty/silo/tree/main/docs/debugging#decoding-metadata) program.
```json ```json
{ {
+6 -6
View File
@@ -2,7 +2,7 @@
Silo versioning is designed to keep multiple versions of an object in one bucket. For example, you could store `spark.csv` (version `ede336f2`) and `spark.csv` (version `fae684da`) in a single bucket. Versioning protects you from unintended overwrites, deletions, protect objects with retention policies. Silo versioning is designed to keep multiple versions of an object in one bucket. For example, you could store `spark.csv` (version `ede336f2`) and `spark.csv` (version `fae684da`) in a single bucket. Versioning protects you from unintended overwrites, deletions, protect objects with retention policies.
To control data retention and storage usage, use object versioning with [object lifecycle management](https://github.com/pgsty/minio/blob/master/docs/bucket/lifecycle/README.md). If you have an object expiration lifecycle policy in your non-versioned bucket and you want to maintain the same permanent delete behavior when on versioning-enabled bucket, you must add a noncurrent expiration policy. The noncurrent expiration lifecycle policy will manage the deletes of the noncurrent object versions in the versioning-enabled bucket. (A version-enabled bucket maintains one current and zero or more noncurrent object versions.) To control data retention and storage usage, use object versioning with [object lifecycle management](https://github.com/pgsty/silo/blob/main/docs/bucket/lifecycle/README.md). If you have an object expiration lifecycle policy in your non-versioned bucket and you want to maintain the same permanent delete behavior when on versioning-enabled bucket, you must add a noncurrent expiration policy. The noncurrent expiration lifecycle policy will manage the deletes of the noncurrent object versions in the versioning-enabled bucket. (A version-enabled bucket maintains one current and zero or more noncurrent object versions.)
Versioning must be explicitly enabled on a bucket, versioning is not enabled by default. Object locking enabled buckets have versioning enabled automatically. Enabling and suspending versioning is done at the bucket level. Versioning must be explicitly enabled on a bucket, versioning is not enabled by default. Object locking enabled buckets have versioning enabled automatically. Enabling and suspending versioning is done at the bucket level.
@@ -10,25 +10,25 @@ Only Silo generates version IDs, and they can't be edited. Version IDs are simpl
When you PUT an object in a versioning-enabled bucket, the noncurrent version is not overwritten. The following figure shows that when a new version of `spark.csv` is PUT into a bucket that already contains an object with the same name, the original object (ID = `ede336f2`) remains in the bucket, Silo generates a new version (ID = `fae684da`), and adds the newer version to the bucket. When you PUT an object in a versioning-enabled bucket, the noncurrent version is not overwritten. The following figure shows that when a new version of `spark.csv` is PUT into a bucket that already contains an object with the same name, the original object (ID = `ede336f2`) remains in the bucket, Silo generates a new version (ID = `fae684da`), and adds the newer version to the bucket.
![put](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/versioning/versioning_PUT_versionEnabled.png) ![put](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/versioning/versioning_PUT_versionEnabled.png)
This protects against accidental overwrites or deletes of objects, allows previous versions to be retrieved. This protects against accidental overwrites or deletes of objects, allows previous versions to be retrieved.
When you DELETE an object, all versions remain in the bucket and Silo adds a delete marker, as shown below: When you DELETE an object, all versions remain in the bucket and Silo adds a delete marker, as shown below:
![delete](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/versioning/versioning_DELETE_versionEnabled.png) ![delete](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/versioning/versioning_DELETE_versionEnabled.png)
Now the delete marker becomes the current version of the object. GET requests by default always retrieve the latest stored version. So performing a simple GET object request when the current version is a delete marker would return `404` `The specified key does not exist` as shown below: Now the delete marker becomes the current version of the object. GET requests by default always retrieve the latest stored version. So performing a simple GET object request when the current version is a delete marker would return `404` `The specified key does not exist` as shown below:
![get](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/versioning/versioning_GET_versionEnabled.png) ![get](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/versioning/versioning_GET_versionEnabled.png)
GET requests by specifying a version ID as shown below, you can retrieve the specific object version `fae684da`. GET requests by specifying a version ID as shown below, you can retrieve the specific object version `fae684da`.
![get_version_id](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/versioning/versioning_GET_versionEnabled_id.png) ![get_version_id](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/versioning/versioning_GET_versionEnabled_id.png)
To permanently delete an object you need to specify the version you want to delete, only the user with appropriate permissions can permanently delete a version. As shown below DELETE request called with a specific version id permanently deletes an object from a bucket. Delete marker is not added for DELETE requests with version id. To permanently delete an object you need to specify the version you want to delete, only the user with appropriate permissions can permanently delete a version. As shown below DELETE request called with a specific version id permanently deletes an object from a bucket. Delete marker is not added for DELETE requests with version id.
![delete_version_id](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/versioning/versioning_DELETE_versionEnabled_id.png) ![delete_version_id](https://raw.githubusercontent.com/pgsty/silo/main/docs/bucket/versioning/versioning_DELETE_versionEnabled_id.png)
## Concepts ## Concepts
+4 -4
View File
@@ -2,7 +2,7 @@
## Configuration Directory ## Configuration Directory
Silo stores all its config as part of the server deployment, config is erasure coded on Silo. On a fresh deployment Silo automatically generates a new `config` and this config is available to be configured via `mc admin config` command. Silo 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/pgsty/minio/blob/master/docs/kms/IAM.md). Silo stores all its config as part of the server deployment, config is erasure coded on Silo. On a fresh deployment Silo automatically generates a new `config` and this config is available to be configured via `mc admin config` command. Silo 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/pgsty/silo/blob/main/docs/kms/IAM.md).
### Certificate Directory ### Certificate Directory
@@ -65,7 +65,7 @@ silo server /data
### Storage Class ### Storage Class
By default, parity for objects with standard storage class is set to `N/2`, and parity for objects with reduced redundancy storage class objects is set to `2`. Read more about storage class support in Silo server [here](https://github.com/pgsty/minio/blob/master/docs/erasure/storage-class/README.md). By default, parity for objects with standard storage class is set to `N/2`, and parity for objects with reduced redundancy storage class objects is set to `2`. Read more about storage class support in Silo server [here](https://github.com/pgsty/silo/blob/main/docs/erasure/storage-class/README.md).
``` ```
KEY: KEY:
@@ -91,7 +91,7 @@ MINIO_STORAGE_CLASS_COMMENT (sentence) optionally add a comment to this setti
#### Etcd #### Etcd
Silo 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/pgsty/minio/blob/master/docs/kms/IAM.md). Silo 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/pgsty/silo/blob/main/docs/kms/IAM.md).
> NOTE: if *path_prefix* is set then Silo 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 Silo 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*. > NOTE: if *path_prefix* is set then Silo 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 Silo 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*.
@@ -125,7 +125,7 @@ MINIO_ETCD_COMMENT (sentence) optionally add a comment to this setting
### API ### API
By default, there is no limitation on the number of concurrent requests that a server/cluster processes at the same time. However, it is possible to impose such limitation using the API subsystem. Read more about throttling limitation in Silo server [here](https://github.com/pgsty/minio/blob/master/docs/throttle/README.md). By default, there is no limitation on the number of concurrent requests that a server/cluster processes at the same time. However, it is possible to impose such limitation using the API subsystem. Read more about throttling limitation in Silo server [here](https://github.com/pgsty/silo/blob/main/docs/throttle/README.md).
``` ```
KEY: KEY:
+1 -1
View File
@@ -115,7 +115,7 @@ In above example there are two server pools
> Notice the requirement of common SLA here original cluster had 1024 drives with 16 drives per erasure set with default parity of '4', second pool is expected to have a minimum of 8 drives per erasure set to match the original cluster SLA (parity count) of '4'. '12' drives stripe per erasure set in the second pool satisfies the original pool's parity count. > Notice the requirement of common SLA here original cluster had 1024 drives with 16 drives per erasure set with default parity of '4', second pool is expected to have a minimum of 8 drives per erasure set to match the original cluster SLA (parity count) of '4'. '12' drives stripe per erasure set in the second pool satisfies the original pool's parity count.
Refer to the sizing guide with details on the default parity count chosen for different erasure stripe sizes [here](https://github.com/pgsty/minio/blob/master/docs/distributed/SIZING.md) Refer to the sizing guide with details on the default parity count chosen for different erasure stripe sizes [here](https://github.com/pgsty/silo/blob/main/docs/distributed/SIZING.md)
Silo places new objects in server pools based on proportionate free space, per pool. Following pseudo code demonstrates this behavior. Silo places new objects in server pools based on proportionate free space, per pool. Following pseudo code demonstrates this behavior.
+2 -2
View File
@@ -8,7 +8,7 @@ Silo in distributed mode can help you setup a highly-available storage system wi
### Data protection ### Data protection
Distributed Silo provides protection against multiple node/drive failures and [bit rot](https://github.com/pgsty/minio/blob/master/docs/erasure/README.md#what-is-bit-rot-protection) using [erasure code](https://silo.pgsty.com/operations/concepts/erasure-coding/). As the minimum drives required for distributed Silo is 2 (same as minimum drives required for erasure coding), erasure code automatically kicks in as you launch distributed Silo. Distributed Silo provides protection against multiple node/drive failures and [bit rot](https://github.com/pgsty/silo/blob/main/docs/erasure/README.md#what-is-bit-rot-protection) using [erasure code](https://silo.pgsty.com/operations/concepts/erasure-coding/). As the minimum drives required for distributed Silo is 2 (same as minimum drives required for erasure coding), erasure code automatically kicks in as you launch distributed Silo.
If one or more drives are offline at the start of a PutObject or NewMultipartUpload operation the object will have additional data protection bits added automatically to provide additional safety for these objects. If one or more drives are offline at the start of a PutObject or NewMultipartUpload operation the object will have additional data protection bits added automatically to provide additional safety for these objects.
@@ -18,7 +18,7 @@ A stand-alone Silo server would go down if the server hosting the drives goes of
For example, an 16-server distributed setup with 200 drives per node would continue serving files, up to 4 servers can be offline in default configuration i.e around 800 drives down Silo would continue to read and write objects. For example, an 16-server distributed setup with 200 drives per node would continue serving files, up to 4 servers can be offline in default configuration i.e around 800 drives down Silo would continue to read and write objects.
Refer to sizing guide for more understanding on default values chosen depending on your erasure stripe size [here](https://github.com/pgsty/minio/blob/master/docs/distributed/SIZING.md). Parity settings can be changed using [storage classes](https://github.com/pgsty/minio/tree/master/docs/erasure/storage-class). Refer to sizing guide for more understanding on default values chosen depending on your erasure stripe size [here](https://github.com/pgsty/silo/blob/main/docs/distributed/SIZING.md). Parity settings can be changed using [storage classes](https://github.com/pgsty/silo/tree/main/docs/erasure/storage-class).
### Consistency Guarantees ### Consistency Guarantees
+1 -1
View File
@@ -3,7 +3,7 @@
See the [Silo documentation](https://silo.pgsty.com/docs/) for production See the [Silo documentation](https://silo.pgsty.com/docs/) for production
deployment and operations guidance. deployment and operations guidance.
For images built from this `pgsty/minio` fork, the container also bundles `mcli` and a compatibility `mc` symlink from `pgsty/mc`. For images built from this `pgsty/silo` fork, the container also bundles `mcli` and a compatibility `mc` symlink from `pgsty/mc`.
## Prerequisites ## Prerequisites
+2 -2
View File
@@ -6,7 +6,7 @@ Silo protects data against hardware failures and silent data corruption using er
Erasure code is a mathematical algorithm to reconstruct missing or corrupted data. Silo uses Reed-Solomon code to shard objects into variable data and parity blocks. For example, in a 12 drive setup, an object can be sharded to a variable number of data and parity blocks across all the drives - ranging from six data and six parity blocks to ten data and two parity blocks. Erasure code is a mathematical algorithm to reconstruct missing or corrupted data. Silo uses Reed-Solomon code to shard objects into variable data and parity blocks. For example, in a 12 drive setup, an object can be sharded to a variable number of data and parity blocks across all the drives - ranging from six data and six parity blocks to ten data and two parity blocks.
By default, Silo shards the objects across N/2 data and N/2 parity drives. Though, you can use [storage classes](https://github.com/pgsty/minio/tree/master/docs/erasure/storage-class) to use a custom configuration. We recommend N/2 data and parity blocks, as it ensures the best protection from drive failures. By default, Silo shards the objects across N/2 data and N/2 parity drives. Though, you can use [storage classes](https://github.com/pgsty/silo/tree/main/docs/erasure/storage-class) to use a custom configuration. We recommend N/2 data and parity blocks, as it ensures the best protection from drive failures.
In 12 drive example above, with Silo server running in the default configuration, you can lose any of the six drives and still reconstruct the data reliably from the remaining drives. In 12 drive example above, with Silo server running in the default configuration, you can lose any of the six drives and still reconstruct the data reliably from the remaining drives.
@@ -14,7 +14,7 @@ In 12 drive example above, with Silo server running in the default configuration
Erasure code protects data from multiple drives failure, unlike RAID or replication. For example, RAID6 can protect against two drive failure whereas in Silo erasure code you can lose as many as half of drives and still the data remains safe. Further, Silo's erasure code is at the object level and can heal one object at a time. For RAID, healing can be done only at the volume level which translates into high downtime. As Silo encodes each object individually, it can heal objects incrementally. Storage servers once deployed should not require drive replacement or healing for the lifetime of the server. Silo's erasure coded backend is designed for operational efficiency and takes full advantage of hardware acceleration whenever available. Erasure code protects data from multiple drives failure, unlike RAID or replication. For example, RAID6 can protect against two drive failure whereas in Silo erasure code you can lose as many as half of drives and still the data remains safe. Further, Silo's erasure code is at the object level and can heal one object at a time. For RAID, healing can be done only at the volume level which translates into high downtime. As Silo encodes each object individually, it can heal objects incrementally. Storage servers once deployed should not require drive replacement or healing for the lifetime of the server. Silo's erasure coded backend is designed for operational efficiency and takes full advantage of hardware acceleration whenever available.
![Erasure](https://github.com/pgsty/minio/blob/master/docs/screenshots/erasure-code.jpg?raw=true) ![Erasure](https://github.com/pgsty/silo/blob/main/docs/screenshots/erasure-code.jpg?raw=true)
## What is Bit Rot protection? ## What is Bit Rot protection?
+1 -1
View File
@@ -80,7 +80,7 @@ export MINIO_STORAGE_CLASS_STANDARD=EC:3
export MINIO_STORAGE_CLASS_RRS=EC:2 export MINIO_STORAGE_CLASS_RRS=EC:2
``` ```
Storage class can also be set via `mc admin config` get/set commands to update the configuration. Refer [storage class](https://github.com/pgsty/minio/tree/master/docs/config#storage-class) for Storage class can also be set via `mc admin config` get/set commands to update the configuration. Refer [storage class](https://github.com/pgsty/silo/tree/main/docs/config#storage-class) for
more details. more details.
#### Note #### Note
+3 -3
View File
@@ -23,9 +23,9 @@ All properties except the file size are tied to the zip file. This means that mo
## Code Examples ## Code Examples
[Using minio-go library](https://github.com/pgsty/minio/blob/master/docs/extensions/s3zip/examples/minio-go/main.go) [Using minio-go library](https://github.com/pgsty/silo/blob/main/docs/extensions/s3zip/examples/minio-go/main.go)
[Using AWS JS SDK v2](https://github.com/pgsty/minio/blob/master/docs/extensions/s3zip/examples/aws-js/main.js) [Using AWS JS SDK v2](https://github.com/pgsty/silo/blob/main/docs/extensions/s3zip/examples/aws-js/main.js)
[Using boto3](https://github.com/pgsty/minio/blob/master/docs/extensions/s3zip/examples/boto3/main.py) [Using boto3](https://github.com/pgsty/silo/blob/main/docs/extensions/s3zip/examples/boto3/main.py)
## Requirements and limits ## Requirements and limits
+4 -4
View File
@@ -34,7 +34,7 @@ Follow the steps from the Veeam documentation for adding Silo as an object store
For Veeam Backup with Immutability, choose the amount of days you want to make backups immutable for For Veeam Backup with Immutability, choose the amount of days you want to make backups immutable for
![Choose Immutability Days for Object Store](https://raw.githubusercontent.com/pgsty/minio/master/docs/integrations/veeam/screenshots/object_store_immutable_days.png) ![Choose Immutability Days for Object Store](https://raw.githubusercontent.com/pgsty/silo/main/docs/integrations/veeam/screenshots/object_store_immutable_days.png)
### Creating the Scale-out Backup Repository ### Creating the Scale-out Backup Repository
@@ -58,7 +58,7 @@ For Veeam Backup with Immutability, choose the amount of days you want to make b
- For Veeam Backup with Immutability, you can choose a number of restore points or days to make backups immutable. - For Veeam Backup with Immutability, you can choose a number of restore points or days to make backups immutable.
![Choose Immutability Options for Backups](https://raw.githubusercontent.com/pgsty/minio/master/docs/integrations/veeam/screenshots/backup_job_immutable_days.png) ![Choose Immutability Options for Backups](https://raw.githubusercontent.com/pgsty/silo/main/docs/integrations/veeam/screenshots/backup_job_immutable_days.png)
#### Backup Office 365 with VBO #### Backup Office 365 with VBO
@@ -70,7 +70,7 @@ mc mb -l mysilo/vbo
- Under Backup Infrastructure, right click on Object Storage Repositories and choose "Add object storage" - Under Backup Infrastructure, right click on Object Storage Repositories and choose "Add object storage"
![Adding Object Storage to VBO Step 1](https://raw.githubusercontent.com/pgsty/minio/master/docs/integrations/veeam/screenshots/1_add_object_store.png) ![Adding Object Storage to VBO Step 1](https://raw.githubusercontent.com/pgsty/silo/main/docs/integrations/veeam/screenshots/1_add_object_store.png)
- Follow through the wizard as above for Veeam Backup and Replication as the steps are the same between both products - Follow through the wizard as above for Veeam Backup and Replication as the steps are the same between both products
@@ -78,7 +78,7 @@ mc mb -l mysilo/vbo
- Follow the wizard. Under the "Object Storage Backup Repository" section, choose the Silo object storage you created above - Follow the wizard. Under the "Object Storage Backup Repository" section, choose the Silo object storage you created above
![Adding Object Storage to VBO Backup Repository](https://raw.githubusercontent.com/pgsty/minio/master/docs/integrations/veeam/screenshots/6_add_sobr_with_object_store.png) ![Adding Object Storage to VBO Backup Repository](https://raw.githubusercontent.com/pgsty/silo/main/docs/integrations/veeam/screenshots/6_add_sobr_with_object_store.png)
- When you create your backup job, choose the backup repository you created above. - When you create your backup job, choose the backup repository you created above.
+2 -2
View File
@@ -7,7 +7,7 @@ Silo supports encrypting config, IAM assets with KMS provided keys. If the KMS i
Silo supports two ways of encrypting IAM and configuration data. Silo supports two ways of encrypting IAM and configuration data.
You can either use KES - together with an external KMS - or, much simpler, You can either use KES - together with an external KMS - or, much simpler,
set the env. variable `MINIO_KMS_SECRET_KEY` and start/restart the Silo server. For more details about KES and how set the env. variable `MINIO_KMS_SECRET_KEY` and start/restart the Silo server. For more details about KES and how
to set it up refer to our [KMS Guide](https://github.com/pgsty/minio/blob/master/docs/kms/README.md). to set it up refer to our [KMS Guide](https://github.com/pgsty/silo/blob/main/docs/kms/README.md).
Instead of configuring an external KMS you can start with a single key by Instead of configuring an external KMS you can start with a single key by
setting the env. variable `MINIO_KMS_SECRET_KEY`. It expects the following setting the env. variable `MINIO_KMS_SECRET_KEY`. It expects the following
@@ -45,7 +45,7 @@ kes key create my-minio-key OSMM+vkKUTCvQs9YL/CVMIMt43HFhkUpqJxTmGl6rYw=
- For instructions on setting up KES, see the [KES Getting Started guide](https://github.com/minio/kes/wiki/Getting-Started) - For instructions on setting up KES, see the [KES Getting Started guide](https://github.com/minio/kes/wiki/Getting-Started)
- For instructions on using KES for encrypting the Silo backend, follow the [KMS Quick Start](https://github.com/pgsty/minio/tree/master/docs/kms). The SSE-S3 configuration setup also supports Silo KMS backend encryption. - For instructions on using KES for encrypting the Silo backend, follow the [KMS Quick Start](https://github.com/pgsty/silo/tree/main/docs/kms). The SSE-S3 configuration setup also supports Silo KMS backend encryption.
## FAQ ## FAQ
+2 -2
View File
@@ -9,7 +9,7 @@ Silo server has two healthcheck related un-authenticated endpoints, a liveness p
- Liveness probe available at `/minio/health/live` - Liveness probe available at `/minio/health/live`
- Cluster probe available at `/minio/health/cluster` - Cluster probe available at `/minio/health/cluster`
Read more on how to use these endpoints in [Silo healthcheck guide](https://github.com/pgsty/minio/blob/master/docs/metrics/healthcheck/README.md). Read more on how to use these endpoints in [Silo healthcheck guide](https://github.com/pgsty/silo/blob/main/docs/metrics/healthcheck/README.md).
## Prometheus Probe ## Prometheus Probe
@@ -25,7 +25,7 @@ The additional bucket specific metrics which include additional go metrics or pr
The additional resource specific metrics which include additional go metrics or process metrics are exposed at The additional resource specific metrics which include additional go metrics or process metrics are exposed at
`<Address for Silo Node>/minio/v2/metrics/resource`. `<Address for Silo Node>/minio/v2/metrics/resource`.
To use this endpoint, setup Prometheus to scrape data from this endpoint. Read more on how to configure and use Prometheus to monitor Silo server in [How to monitor Silo server with Prometheus](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/README.md). To use this endpoint, setup Prometheus to scrape data from this endpoint. Read more on how to configure and use Prometheus to monitor Silo server in [How to monitor Silo server with Prometheus](https://github.com/pgsty/silo/blob/main/docs/metrics/prometheus/README.md).
### **Deprecated metrics monitoring** ### **Deprecated metrics monitoring**
+3 -3
View File
@@ -171,7 +171,7 @@ Prometheus sets the `Host` header to `domain:port` as part of HTTP operations ag
### 6. Configure Grafana ### 6. Configure Grafana
After Prometheus is configured, you can use Grafana to visualize Silo metrics. Refer the [document here to setup Grafana with Silo prometheus metrics](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/grafana/README.md). After Prometheus is configured, you can use Grafana to visualize Silo metrics. Refer the [document here to setup Grafana with Silo prometheus metrics](https://github.com/pgsty/silo/blob/main/docs/metrics/prometheus/grafana/README.md).
## List of metrics exposed by Silo ## List of metrics exposed by Silo
@@ -189,8 +189,8 @@ curl http://127.0.0.1:9000/minio/v2/metrics/cluster
### List of metrics reported Cluster and Bucket level ### List of metrics reported Cluster and Bucket level
[The list of metrics reported can be here](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/list.md) [The list of metrics reported can be here](https://github.com/pgsty/silo/blob/main/docs/metrics/prometheus/list.md)
### Configure Alerts for Prometheus ### Configure Alerts for Prometheus
[The Prometheus AlertManager and alerts can be configured following this](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/alerts.md) [The Prometheus AlertManager and alerts can be configured following this](https://github.com/pgsty/silo/blob/main/docs/metrics/prometheus/alerts.md)
+1 -1
View File
@@ -117,4 +117,4 @@ To verify the above sample alert follow below steps
} }
``` ```
![Prometheus](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/minio-es-tolerance-alert.png) ![Prometheus](https://raw.githubusercontent.com/pgsty/silo/main/docs/metrics/prometheus/minio-es-tolerance-alert.png)
+1 -1
View File
@@ -4,7 +4,7 @@
## Prerequisites ## Prerequisites
- Prometheus and Silo configured as explained in [document here](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/README.md). - Prometheus and Silo configured as explained in [document here](https://github.com/pgsty/silo/blob/main/docs/metrics/prometheus/README.md).
- Grafana installed as explained [here](https://grafana.com/grafana/download). - Grafana installed as explained [here](https://grafana.com/grafana/download).
## Silo Grafana dashboards ## Silo Grafana dashboards
+1 -1
View File
@@ -41,7 +41,7 @@ For optimal production setup Silo recommends Linux kernel version 4.x and later.
## List of Amazon S3 APIs not supported on Silo ## List of Amazon S3 APIs not supported on Silo
We found the following APIs to be redundant or less useful outside of AWS S3. If you have a different view on any of the APIs we missed, please consider opening a [GitHub issue](https://github.com/pgsty/minio/issues) with relevant details on why Silo must implement them. We found the following APIs to be redundant or less useful outside of AWS S3. If you have a different view on any of the APIs we missed, please consider opening a [GitHub issue](https://github.com/pgsty/silo/issues) with relevant details on why Silo must implement them.
### List of Amazon S3 Bucket APIs not supported on Silo ### List of Amazon S3 Bucket APIs not supported on Silo
+1 -1
View File
@@ -10,7 +10,7 @@ In this document we will explain in detail on how to configure multiple users.
- Install mc - [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart) - Install mc - [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
- Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/) - Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
- Configure etcd - [Etcd V3 Quickstart Guide](https://github.com/pgsty/minio/blob/master/docs/sts/etcd.md) - Configure etcd - [Etcd V3 Quickstart Guide](https://github.com/pgsty/silo/blob/main/docs/sts/etcd.md)
### 2. Create a new user with canned policy ### 2. Create a new user with canned policy
+8 -8
View File
@@ -15,17 +15,17 @@ Following are advantages for using temporary credentials:
| AuthN | Description | | AuthN | Description |
| :---------------------- | ------------------------------------------ | | :---------------------- | ------------------------------------------ |
| [**WebIdentity**](https://github.com/pgsty/minio/blob/master/docs/sts/web-identity.md) | Let users request temporary credentials using any OpenID(OIDC) compatible web identity providers such as KeyCloak, Dex, Facebook, Google etc. | | [**WebIdentity**](https://github.com/pgsty/silo/blob/main/docs/sts/web-identity.md) | Let users request temporary credentials using any OpenID(OIDC) compatible web identity providers such as KeyCloak, Dex, Facebook, Google etc. |
| [**AD/LDAP**](https://github.com/pgsty/minio/blob/master/docs/sts/ldap.md) | Let AD/LDAP users request temporary credentials using AD/LDAP username and password. | | [**AD/LDAP**](https://github.com/pgsty/silo/blob/main/docs/sts/ldap.md) | Let AD/LDAP users request temporary credentials using AD/LDAP username and password. |
| [**AssumeRole**](https://github.com/pgsty/minio/blob/master/docs/sts/assume-role.md) | Let Silo users request temporary credentials using user access and secret keys. | | [**AssumeRole**](https://github.com/pgsty/silo/blob/main/docs/sts/assume-role.md) | Let Silo users request temporary credentials using user access and secret keys. |
### Understanding JWT Claims ### Understanding JWT Claims
> NOTE: JWT claims are only meant for WebIdentity and ClientGrants. > NOTE: JWT claims are only meant for WebIdentity and ClientGrants.
> AssumeRole or LDAP users can skip the entire portion and directly visit one of the links below. > AssumeRole or LDAP users can skip the entire portion and directly visit one of the links below.
> >
> - [**AssumeRole**](https://github.com/pgsty/minio/blob/master/docs/sts/assume-role.md) > - [**AssumeRole**](https://github.com/pgsty/silo/blob/main/docs/sts/assume-role.md)
> - [**AD/LDAP**](https://github.com/pgsty/minio/blob/master/docs/sts/ldap.md) > - [**AD/LDAP**](https://github.com/pgsty/silo/blob/main/docs/sts/ldap.md)
The id_token received is a signed JSON Web Token (JWT). Use a JWT decoder to decode the id_token to access the payload of the token that includes following JWT claims, `policy` claim is mandatory and should be present as part of your JWT claim. Without this claim the generated credentials will not have access to any resources on the server, using these credentials application would receive 'Access Denied' errors. The id_token received is a signed JSON Web Token (JWT). Use a JWT decoder to decode the id_token to access the payload of the token that includes following JWT claims, `policy` claim is mandatory and should be present as part of your JWT claim. Without this claim the generated credentials will not have access to any resources on the server, using these credentials application would receive 'Access Denied' errors.
@@ -37,12 +37,12 @@ The id_token received is a signed JSON Web Token (JWT). Use a JWT decoder to dec
In this document we will explain in detail on how to configure all the prerequisites. In this document we will explain in detail on how to configure all the prerequisites.
> NOTE: If you are interested in AssumeRole API only, skip to [here](https://github.com/pgsty/minio/blob/master/docs/sts/assume-role.md) > NOTE: If you are interested in AssumeRole API only, skip to [here](https://github.com/pgsty/silo/blob/main/docs/sts/assume-role.md)
### Prerequisites ### Prerequisites
- [Configuring keycloak](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md) or [Configuring Casdoor](https://github.com/pgsty/minio/blob/master/docs/sts/casdoor.md) - [Configuring keycloak](https://github.com/pgsty/silo/blob/main/docs/sts/keycloak.md) or [Configuring Casdoor](https://github.com/pgsty/silo/blob/main/docs/sts/casdoor.md)
- [Configuring etcd](https://github.com/pgsty/minio/blob/master/docs/sts/etcd.md) - [Configuring etcd](https://github.com/pgsty/silo/blob/main/docs/sts/etcd.md)
### Setup Silo with Identity Provider ### Setup Silo with Identity Provider
+1 -1
View File
@@ -97,7 +97,7 @@ silo server /mnt/export
``` ```
Testing with an example Testing with an example
> Obtaining client ID and secrets follow [Keycloak configuring documentation](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md) > Obtaining client ID and secrets follow [Keycloak configuring documentation](https://github.com/pgsty/silo/blob/main/docs/sts/keycloak.md)
``` ```
$ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga $ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga
+2 -2
View File
@@ -50,7 +50,7 @@ NOTE: If `etcd` is configured with `Client-to-server authentication with HTTPS c
Once etcd is configured, **any STS configuration** will work including Client Grants, Web Identity or AD/LDAP. Once etcd is configured, **any STS configuration** will work including Client Grants, Web Identity or AD/LDAP.
For example, you can configure STS with Client Grants (KeyCloak) using the guides at [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) and [KeyCloak Configuration Guide](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md). Once this is done, STS credentials can be generated: For example, you can configure STS with Client Grants (KeyCloak) using the guides at [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) and [KeyCloak Configuration Guide](https://github.com/pgsty/silo/blob/main/docs/sts/keycloak.md). Once this is done, STS credentials can be generated:
``` ```
go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga
@@ -64,7 +64,7 @@ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrO
} }
``` ```
These credentials can now be used to perform Silo API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md). These credentials can now be used to perform Silo API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/silo/blob/main/docs/sts/client-grants.md).
## Explore Further ## Explore Further
+1 -1
View File
@@ -351,7 +351,7 @@ export MINIO_IDENTITY_LDAP_GROUP_SEARCH_FILTER='(&(objectclass=groupOfNames)(mem
silo server ~/test silo server ~/test
``` ```
You can make sure it works appropriately using our [example program](https://raw.githubusercontent.com/pgsty/minio/master/docs/sts/ldap.go): You can make sure it works appropriately using our [example program](https://raw.githubusercontent.com/pgsty/silo/main/docs/sts/ldap.go):
``` ```
$ go run ldap.go -u foouser -p foopassword $ go run ldap.go -u foouser -p foopassword
+1 -1
View File
@@ -101,7 +101,7 @@ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrO
} }
``` ```
These credentials can now be used to perform Silo API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md). These credentials can now be used to perform Silo API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/silo/blob/main/docs/sts/client-grants.md).
## Explore Further ## Explore Further
+1 -1
View File
@@ -237,7 +237,7 @@ Silo can connect to other servers, including Silo nodes or other server types su
## Explore Further ## Explore Further
* [TLS Configuration for Silo server on Kubernetes](https://github.com/pgsty/minio/tree/master/docs/tls/kubernetes) * [TLS Configuration for Silo server on Kubernetes](https://github.com/pgsty/silo/tree/main/docs/tls/kubernetes)
* [Silo Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/) * [Silo Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
* [Silo Network Encryption Overview](https://silo.pgsty.com/operations/network-encryption/) * [Silo Network Encryption Overview](https://silo.pgsty.com/operations/network-encryption/)
* [Generate Let's Encrypt Certificate](https://silo.pgsty.com/integrations/generate-lets-encrypt-certificate-using-certbot-for-minio/) * [Generate Let's Encrypt Certificate](https://silo.pgsty.com/integrations/generate-lets-encrypt-certificate-using-certbot-for-minio/)
+1 -1
View File
@@ -12,7 +12,7 @@ This document explains how to configure Silo server with TLS certificates on Kub
For a [distributed Silo setup](https://silo.pgsty.com/operations/deployments/kubernetes/), where there are multiple pods with different domain names expected to run, you will either need wildcard certificates valid for all the domains or have specific certificates for each domain. If you are going to use specific certificates, make sure to create Kubernetes secrets accordingly. For a [distributed Silo setup](https://silo.pgsty.com/operations/deployments/kubernetes/), where there are multiple pods with different domain names expected to run, you will either need wildcard certificates valid for all the domains or have specific certificates for each domain. If you are going to use specific certificates, make sure to create Kubernetes secrets accordingly.
For testing purposes, here is [how to create self-signed certificates](https://github.com/pgsty/minio/tree/master/docs/tls#3-generate-self-signed-certificates). For testing purposes, here is [how to create self-signed certificates](https://github.com/pgsty/silo/tree/main/docs/tls#3-generate-self-signed-certificates).
## 2. Create Kubernetes secret ## 2. Create Kubernetes secret
+1 -1
View File
@@ -11,7 +11,7 @@ Please make sure the following packages are already installed via `dnf` or `apt`
#### Step 1 - download `tuned.conf` from the referenced link #### Step 1 - download `tuned.conf` from the referenced link
``` ```
wget https://raw.githubusercontent.com/pgsty/minio/master/docs/tuning/tuned.conf wget https://raw.githubusercontent.com/pgsty/silo/main/docs/tuning/tuned.conf
``` ```
#### Step 2 - install tuned.conf as supported performance profile on all nodes #### Step 2 - install tuned.conf as supported performance profile on all nodes
+1 -1
View File
@@ -10,7 +10,7 @@ replace github.com/minio/console => github.com/pgsty/silo-console v0.0.0-2026080
replace github.com/minio/mc => github.com/pgsty/mc v0.0.0-20260801042411-ad10a2a10b76 replace github.com/minio/mc => github.com/pgsty/mc v0.0.0-20260801042411-ad10a2a10b76
// Use Pigsty's maintained SILO package fork while preserving upstream import paths. // Use Pigsty's maintained SILO package fork while preserving upstream import paths.
// This retains the LDAP TLS fix tracked in https://github.com/pgsty/minio/issues/15. // This retains the LDAP TLS fix tracked in https://github.com/pgsty/silo/issues/15.
// v3.11.0 follows upstream minio/pkg's 3.11 line and carries the // v3.11.0 follows upstream minio/pkg's 3.11 line and carries the
// minio/minio#20449 bucket-write boundary hardening. // minio/minio#20449 bucket-write boundary hardening.
replace github.com/minio/pkg/v3 => github.com/pgsty/silo-pkg/v3 v3.11.0 replace github.com/minio/pkg/v3 => github.com/pgsty/silo-pkg/v3 v3.11.0
+1 -1
View File
@@ -12,7 +12,7 @@ keywords:
home: https://silo.pgsty.com/ home: https://silo.pgsty.com/
icon: https://silo.pgsty.com/img/silo.svg icon: https://silo.pgsty.com/img/silo.svg
sources: sources:
- https://github.com/pgsty/minio - https://github.com/pgsty/silo
maintainers: maintainers:
- name: Pigsty - name: Pigsty
url: https://pigsty.io url: https://pigsty.io
+1 -1
View File
@@ -209,7 +209,7 @@ Examples:
ErrUnexpectedError = newErrFn( ErrUnexpectedError = newErrFn(
"Unexpected error", "Unexpected error",
"Please report this Silo error at https://github.com/pgsty/minio/issues", "Please report this Silo error at https://github.com/pgsty/silo/issues",
"", "",
) )