SOW 文档

• 1: 上手
  • 1.1: 安装
  • 1.2: 快速上手
  • 1.3: 第一个工作区
  • 1.4: 核心概念
• 2: 教程
  • 2.1: 搭建 YUM 仓库
  • 2.2: 迁移已有 YUM 仓库
  • 2.3: 搭建 APT 仓库
  • 2.4: 仓库签名
  • 2.5: 服务与发布仓库
  • 2.6: 演练构建 pigsty-infra 仓库
• 3: 功能
  • 3.1: Plain 平面仓库
  • 3.2: Managed 工作区
  • 3.3: 包池与元数据视图
  • 3.4: 成员策略
  • 3.5: 签名模型
  • 3.6: 事务与恢复
  • 3.7: 可观测与审计
• 4: 参考
  • 4.1: sow.yml 配置参考
  • 4.2: 包引用
  • 4.3: 仓库布局
  • 4.4: 退出码
  • 4.5: JSON 输出
  • 4.6: 平台与集成
• 5: 命令
  • 5.1: sow create
  • 5.2: sow init
  • 5.3: sow config
  • 5.4: sow repo
  • 5.5: sow dist
  • 5.6: sow add
  • 5.7: sow rm
  • 5.8: sow ls
  • 5.9: sow show
  • 5.10: sow where
  • 5.11: sow status
  • 5.12: sow build
  • 5.13: sow check
  • 5.14: sow changes
  • 5.15: sow publish
  • 5.16: sow retain
  • 5.17: sow gc
  • 5.18: sow export
  • 5.19: sow log

1 - 上手

SOW 生成 RPM/YUM 与 DEB/APT 静态仓库，本身不是 HTTP 守护进程。先选择一条相互隔离的 运行路径：

• Plain： sow create 在普通目录中为现有软件包重建索引。

• Managed： 工作区持续记录成员关系、Dist、架构视图、策略、签名、Generation、 审计历史与发布目标。

• 安装 — 选择 Release 归档、RPM/DEB 安装包或源码构建，并校验二进制。

• 快速上手 — 从一个软件包目录创建平面仓库，并通过 HTTP 提供服务。

• 第一个工作区 — 初始化 Managed 模式，创建 RPM/DEB Dist，添加软件包，然后构建并校验。

• 核心概念 — Workspace、Repository、Dist、Package Object、Desired Membership 与 Built Generation。

Managed 工作区需要具备建议锁、fsync 与原子 rename 语义的本地 POSIX 文件系统。元数据 在进程内生成；可选的 RPM 包签名需要 rpm，agent:// 元数据密钥需要 gpg 与 gpg-agent。

1.1 - 安装

SOW 只有一个可执行文件，不需要启用服务，也不依赖语言运行时。Release 构建目标是 Linux 与 macOS 的 amd64、arm64；Linux 另外提供 RPM 与 DEB 安装包。不支持 Windows。

在下载页选择匹配操作系统与架构的归档或 Linux 安装包。页面同时提供每个 已发布制品、对应源码 Tag 与 SHA256SUMS 的链接。

安装归档

下载一个归档与 SHA256SUMS，解压前只校验对应条目：

# Linux amd64
grep '  sow_0.5.0_linux_amd64.tar.gz$' SHA256SUMS | sha256sum -c -
tar -xzf sow_0.5.0_linux_amd64.tar.gz
sudo install -m 0755 sow /usr/local/bin/sow

macOS 选择 darwin_amd64 或 darwin_arm64，并把 sha256sum -c - 换成 shasum -a 256 -c -。没有 root 时，把二进制装到已经加入 PATH 的目录，例如 ~/.local/bin。

安装 Linux 软件包

Linux 软件包使用 1PGSTY Release 后缀：

sudo rpm -Uvh ./sow-0.5.0-1PGSTY.x86_64.rpm
sudo apt install ./sow_0.5.0-1PGSTY_amd64.deb

只执行符合本机发行版与架构的那条命令。RPM 把 License 安装到 /usr/share/licenses/sow/LICENSE；DEB 把版权/协议文件安装到 /usr/share/doc/sow/。

从源码构建

Go Module 声明使用 Go 1.27.1，元数据生成不需要 C 工具链。使用与固定版本下载一致的 v0.5.0 源码 Tag：

git clone https://github.com/pgsty/sow.git
cd sow
set -euo pipefail
SOW_TAG=v0.5.0
git checkout "$SOW_TAG"
SOW_VERSION="${SOW_TAG#v}"
CGO_ENABLED=0 go build -trimpath \
  -ldflags="-s -w -X github.com/pgsty/sow/internal/v2cli.Version=${SOW_VERSION}" \
  -o sow ./cmd/sow
sudo install -m 0755 sow /usr/local/bin/sow

这组命令使用 Release 构建参数，并把所选 Tag 的产品版本写入二进制。

校验

sow version
sow help

sow version 输出产品版本、目标 OS/架构与构建 Go 工具链；sow help 列出命令树。 归档中还包含 README.md、CHANGELOG.md、Apache-2.0 LICENSE 与 THIRD_PARTY_NOTICES。

从 0.4 升级到 0.5

通过下载页安装 SOW 0.5.0，本次变更见 0.5.0 发布注记。

SOW 0.5 使用数据库 Schema v13，新增候选包池路径的查询索引，sow/v3 配置与公共布局保持 不变。先停止写入并备份整个工作区，再在普通使用前逐个迁移 Repository：

sow repo migrate REPOSITORY -C /srv/sow
sow build -r REPOSITORY -C /srv/sow
sow check -r REPOSITORY -C /srv/sow

更新后的 RPM 认证与 APT 元数据契约需要对受影响的 Dist 重建一次。之后，未变化且具有匹配 Built 证据的 RPM 不必反复读取包体验签。迁移会增加私有数据库索引，发布历史较大时需要时间 和磁盘空间；迁移后不要再使用旧版本二进制打开数据库。sow repo migrate 会报告变化，例如 schema=12->13；重复执行显示 schema=13->13。Repository 迁移之前，其写命令以 5 退出并提示 repository schema v12 predates this binary (v13); back up the workspace, then run `sow repo migrate NAME`。

备份工具必须保留硬链接，因为 DEB 的 by-hash 条目是硬链接：Linux 上可用 GNU cp -a、 rsync -aH 或 tar；macOS 的 cp -a 不保留硬链接。

Plain 仓库新增 create --metadata-timestamp，请检查实际二进制的 create --help 是否包含 该参数。默认值仍为 0，因此仅升级二进制不会修复已发布 YUM 仓库的时间戳。替换已有维护 流程前，请按 YUM 迁移指南操作。

升级 0.3 Managed Workspace

SOW 0.4 引入了内部数据库 Schema v11 与 v12，0.5 升级到 v13。公共布局和 schema: sow/v3 配置标识均不改变， 但每个既有 v0.3 Repository 都必须在普通读写前显式迁移。备份前先停止 Workspace 全部写入：

cp -a /srv/sow /srv/sow.backup-before-upgrade   # GNU cp；其他平台请用 rsync -aH 或 tar
sow repo migrate REPOSITORY -C /srv/sow
sow build -r REPOSITORY -C /srv/sow
sow check -r REPOSITORY -C /srv/sow

对 sow.yml 中的每个 Repository 重复最后三条命令。数据库 Transition 是单向的；迁移完成后 不要再用旧版本二进制打开 Workspace。状态、Signer 与 Publication Evidence 的修复范围见 sow repo migrate。

权限与可选工具

执行用户需要读取输入软件包，并能写入 Plain 目标目录或 Managed 工作区。Managed 工作区 应放在本地 POSIX 文件系统上；锁、fsync、安全路径与原子 rename 都属于正确性契约。

软件包解析与元数据渲染都在进程内完成。只有两条可选路径需要主机工具：

• RPM 包签名 需要 rpm 与可用的 GPG 环境；
• agent:// 元数据密钥需要 gpg 与 gpg-agent。

接下来可用快速上手进入 Plain 模式，或用 第一个工作区进入 Managed 模式。

1.2 - 快速上手

Plain 模式在一个目录内生成平面仓库。它不读取 sow.yml，不创建工作区，也不维护数据库。

mkdir -p /srv/repo
cp /path/to/packages/*.rpm /path/to/packages/*.deb /srv/repo/

sow create /srv/repo

created /srv/repo: rpm=1 deb=1 signed=0 removed=0 marker=false noop=false recovered=false

/srv/repo/
├── package.rpm
├── package.deb
├── repodata/       # RPM: repomd.xml、primary、filelists、other
├── Packages        # DEB 平面索引
└── Packages.gz

cd /srv/repo
python3 -m http.server --bind 127.0.0.1 8080

curl --fail http://127.0.0.1:8080/repodata/repomd.xml >/dev/null
curl --fail http://127.0.0.1:8080/Packages.gz >/dev/null

# /etc/yum.repos.d/sow-quickstart.repo
[sow-quickstart]
name=SOW Quick Start
baseurl=http://REPO_HOST:8080/
enabled=1
gpgcheck=0
repo_gpgcheck=0

# /etc/apt/sources.list.d/sow-quickstart.list
deb [trusted=yes] http://REPO_HOST:8080/ ./

sudo dnf makecache
sudo dnf install PACKAGE_NAME

sudo apt update
sudo apt install PACKAGE_NAME

sow create /srv/repo

sow create /srv/repo --json

何时使用 Managed 模式

如果目录已经恰好包含要发布的全部内容，使用 Plain。需要具名 Dist、架构视图、成员策略、 已签名元数据、Generation、审计或发布目标时，使用 Managed 工作区。

另见 sow create 与 Plain 平面仓库。

1.3 - 第一个工作区

Managed 模式会持久保存配置、成员关系、Generation 与审计状态。下面从空目录开始。

sow init /srv/sow
cd /srv/sow

/srv/sow/
├── sow.yml   # 配置；schema: sow/v3
└── .sow/     # SQLite 状态、锁、staging、恢复与操作日志

sow repo new local
sow dist new el9 --format rpm
sow dist new bookworm --format deb

/srv/sow/local/
├── pool/
└── dists/
    ├── el9/
    │   ├── x86_64/repodata/
    │   └── aarch64/repodata/
    └── bookworm/
        ├── Release
        └── main/
            ├── binary-amd64/{Packages,Packages.gz,by-hash/}
            └── binary-arm64/{Packages,Packages.gz,by-hash/}

sow add /path/to/packages/*.rpm -d el9
sow add /path/to/packages/*.deb -d bookworm

sow add /path/to/more/*.rpm -d el9 --skip
sow build

sow status
sow ls -d el9
sow ls -d bookworm
sow check

sow config show --all

选择规则

• Workspace：给了 -C DIR 就从该目录向上找，否则从当前目录找；未找到工作区时再尝试 SOW_DIR。显式 -C 不会禁用这条回退。
• Repository：-r NAME、当前路径所属 Repository，或唯一已配置 Repository。
• Dist：-d NAME，可重复；只有命令能够唯一确定范围时才可省略。

-C 指定的是发现起点，不保证该目录本身就是最终 Workspace Root。用 sow config check -C DIR 查看解析后的工作区；必须固定操作对象的脚本应指定明确的物理工作区根及 -r NAME。 存在歧义时直接报错；SOW 不会随便挑选 Repository 或 Dist。

下一步

• 核心概念
• 搭建 YUM 仓库
• 搭建 APT 仓库
• sow.yml 参考

1.4 - 核心概念

Plain 还是 Managed

两条运行路径相互独立。

目录内容已经等于目标仓库时使用 Plain。需要由 SOW 管理成员、策略、Generation、签名、 审计或发布时使用 Managed。

Managed 层级

Workspace                    /srv/sow
├── sow.yml                  配置
├── .sow/                    私有状态；绝不对外服务
└── Repository               /srv/sow/local
    ├── pool/                规范包体
    └── dists/
        └── Dist             一个具名 RPM 或 DEB 成员集
            └── views        按架构渲染的元数据

• Workspace 是配置与发现边界。
• Repository 是隔离、Generation、发布和公共树边界。不同 Repository 之间不去重包体。
• Dist 是单一包格式的具名成员集合。
• 架构视图 是派生输出，不是第二套成员关系。noarch RPM 与 all DEB 会进入所有适用 视图，但包池字节不重复。

一条规范包体路径

Package Object 以确切字节的 SHA-256 标识；逻辑坐标来自 RPM header 或 DEB control， 不来自文件名。

每个已接受包体在 Repository pool/ 下只有一条规范路径。RPM 架构视图只含 repodata/， 包位置通过父级相对路径回到包池；APT Packages 直接指向同一包池。

普通包管理器与镜像工具是不同契约。默认 dnf reposync 会拒绝规范 RPM 视图中的父级跳转。 需要自包含 RPM 镜像 leaf 时，使用 sow export rpm-leaf 生成独立产物。

Desired 与 Built

Managed 模式分别追踪意图与公共字节：

add / rm -> Desired Membership (revision)
                    |
                  build
                    v
             Built Generation -> pool/ + dists/

add 与 rm 默认构建受影响的 Dist。--skip 只记录成员变更，Repository 会保持 dirty； 随后用 sow build 把 Desired 收敛为新的 Built Generation。

• sow status 低成本读取状态，并报告 ready_to_copy。
• sow check 执行完整只读交付证明。dirty 或 recovering 状态不可交付。
• sow changes [BASE_GENERATION] 描述某个已记录 Generation 到当前 Built Generation 的 物理差异。它是证据与计划输出，不能替代发布恢复或远端验证。
• sow publish TARGET 通过配置的 Provider 发布已校验 Generation，并记录 target 级恢复与 checkpoint 状态。

事务与失败状态

写操作由 Workspace 或 Repository 锁串行化，并在公共变更前记录意图。包体与不可变元数据 先准备，可变协议指针最后更新。下一条 writer 会先恢复被中断操作，再开始新工作。

用 status 诊断，用 check 做发布门禁。ready_to_copy=false 的 Repository 不应发布。

继续阅读

• Managed 工作区
• 包池与架构视图
• 事务与恢复
• 发布与恢复

2 - 教程

这里的教程涵盖新建 Managed 工作区与迁移已有 Plain 仓库。请按顺序执行命令，并按你的环境 替换大写占位符与包路径。

如果还没装 SOW，先看安装与快速上手。

先看哪篇

YUM 与 APT 两篇是彼此独立的全新 Workspace 路径。实际使用中，如果它们适合共用同一所有权 边界，一个 Workspace 的同一 Repository 可以同时容纳 RPM 与 DEB Dist。

本板块约定

Shell 代码块里的命令不带 $ 提示符，方便整块复制。输出单独成块放在命令下方，只有一行时用注释 标注。需要你自行替换的值一律写成 大写。

每篇教程都有验证步骤。Managed 模式通过 sow check 返回 0，确认所选 Repository 完整且 与记录的 Generation 一致。Plain 模式按迁移指南验证元数据、签名和真实客户端行为； sow check 不用于检查平面目录。

2.1 - 搭建 YUM 仓库

本教程从零创建一个 Managed RPM 仓库。你需要一个可写目录，以及一个或多个 RPM 文件。

1. 创建工作区

mkdir -p /srv/sow
cd /srv/sow
sow init .
sow repo new pigsty
sow dist new el9 --format rpm -r pigsty

Dist 名称由你定义。SOW 不会根据 el9 推断操作系统版本。

2. 配置成员策略

编辑生成的 sow.yml。下面的配置按包名与架构各保留一个版本，并排除调试包：

schema: sow/v3
architectures: [x86_64, aarch64]
repos:
  pigsty:
    dists:
      el9:
        format: rpm
        limit: 1
        exclude:
          - kind: [debuginfo, debugsource, llvmjit]
targets: {}

手工修改配置后，先校验再写仓库状态：

sow config check
sow config show --all

策略先执行 exclude，再执行 limit。noarch 包会投影到每个启用的架构视图，不能写进 architectures。

3. 添加 RPM

sow add /path/to/packages/*.rpm -r pigsty -d el9
sow status -r pigsty
sow check -r pigsty

add 解析包头，将每个接纳的包只保存一次，更新 Desired 成员关系并落成新 Generation。 被策略排除的输入会逐项报告，但不算命令失败。

公共树如下：

/srv/sow/pigsty/
├── pool/...
└── dists/el9/
    ├── x86_64/repodata/...
    └── aarch64/repodata/...

rpm-md 的 location href 通过相对路径访问根目录下的 pool/。不要只复制某个架构目录； 它不是独立仓库。

4. HTTP 预览

本地预览可以直接使用：

cd /srv/sow
python3 -m http.server --bind 127.0.0.1 8080

在另一个终端检查入口：

curl --fail http://127.0.0.1:8080/pigsty/dists/el9/x86_64/repodata/repomd.xml >/dev/null

长期服务应使用持续维护的 HTTP Server。它必须完整暴露 pigsty/ 树，确保客户端解析后落到 pigsty/pool/ 的软件包 URL 可访问。

5. 配置 dnf

将 REPO_HOST 替换为客户端可访问的地址：

# /etc/yum.repos.d/pigsty.repo
[pigsty-el9]
name=Pigsty EL9
baseurl=http://REPO_HOST:8080/pigsty/dists/el9/$basearch/
enabled=1
gpgcheck=0
repo_gpgcheck=0

刷新并查询仓库：

sudo dnf clean metadata
sudo dnf makecache --refresh
dnf --disablerepo='*' --enablerepo=pigsty-el9 list available

这里有意使用未签名配置。只有完成仓库签名后，才应打开客户端验签。

6. 发布或导出

交付前必须通过深度校验：

sow check -r pigsty

向已配置的 filesystem 或 R2 目标交付时，使用 sow publish。 只有先复制到离线 staging、再原子切换上线时，才适合整根复制；不要对在线仓库做无序原地同步。

默认 dnf reposync 等工具会拒绝指向根包池的父级相对路径。遇到这种消费者时，导出一份 自包含 RPM Leaf：

sow export rpm-leaf el9 x86_64 /srv/export/pigsty-el9-x86_64 -r pigsty

目标目录必须不存在或为空。默认会复制包体；--hardlink 只适用于同一文件系统、可信且只读的 显式优化场景。

更新仓库

sow add /path/to/new.rpm -r pigsty -d el9
sow rm PACKAGE_NAME -r pigsty -d el9
sow build -r pigsty
sow check -r pigsty

add 与 rm 修改 Desired 成员关系；策略或签名配置变化后用 build 收敛；发布门禁是 check，不能只看 status。

自动化客户端与平台覆盖见平台与集成。

2.2 - 迁移已有 YUM 仓库

本指南适用于 RPM 与 repodata/ 放在同一层目录的平面仓库，例如此前用 createrepo_c 维护的仓库。它使用 Plain sow create，不创建 Managed 工作区。发布时间参数是 SOW 0.5.0 新增功能，请使用该版本或更新版本。

1. 明确迁移范围

在候选副本上操作，并完整保留旧软件包与元数据备份。可能重签的 RPM 不要用硬链接复制。 先确认真正使用的二进制：

SOW=/path/to/sow
"$SOW" version
"$SOW" create --help

帮助中必须包含 --metadata-timestamp；正式版 0.4.0 不接受该参数。

在存在模块过滤的环境中，为普通 RPM 保留适当的 module_hotfixes=1 策略。这不会恢复 dnf module install 所需的模块流或 profile。

2. 保留发布时间历史

EL7 YUM 可能拒收 data 最大时间早于缓存的索引。检查当前 repomd.xml 与可信旧副本中的 <data><timestamp>，取客户端可能见过的最大值。如果在线索引此前已被写成零，只看这个 零值无法恢复历史。revision 和文件 mtime 不能替代该记录。

维护脚本应在同一个仓库锁内操作，并在上传目录外保存历史最大发布时间。下面的 +1 是区分新内容的 发布策略；EL7 本身也接受相等时间。真正产生新一代内容时，选择：

下一次时间 = max(当前 Unix 秒,
                 当前索引最大时间 + 1,
                 已保存的历史最大时间 + 1,
                 可信历史下限 + 1)

在切换公开索引之前持久保存该值。发布失败可以消耗一个时间值，跳号没有问题。恢复旧内容，或把 同一公开 URL 对应的本地目录移到新位置时，也必须保留这份时钟。

内容不变时，维护脚本可以在检查完整元数据内容身份、引用文件校验和以及签名后，复用旧索引与 分离签名。零时间或已经倒退的时间仍需修复。每次直接调用 create 都传入当前时间，会让索引 每次变化，从而失去空跑不写文件的效果。

3. 构建并签署候选

下面演示一次重建。先准备独立的 /srv/yum.candidate 副本，将 HISTORICAL_MAX 设为从当前 索引、持久时钟和可信历史中核实的最大值，将 SIGN_KEY 设为元数据签名密钥的完整指纹。 示例用 Python 3 选择严格递增的时间：

set -euo pipefail
: "${SOW:?Set the path to the tested SOW binary}"
: "${HISTORICAL_MAX:?Set the verified historical maximum Unix second}"
: "${SIGN_KEY:?Set the full metadata signing fingerprint}"
PUBLISH_TIME=$(python3 -c 'import sys,time; h=int(sys.argv[1]); assert 0 <= h < 253402300799; print(max(int(time.time()), h+1))' "$HISTORICAL_MAX")

"$SOW" create /srv/yum.candidate --metadata-timestamp "$PUBLISH_TIME"
gpg --batch --yes --armor --detach-sign --local-user "$SIGN_KEY" \
  --output /srv/yum.candidate/repodata/repomd.xml.asc \
  /srv/yum.candidate/repodata/repomd.xml
gpg --verify /srv/yum.candidate/repodata/repomd.xml.asc \
  /srv/yum.candidate/repodata/repomd.xml

这段命令只生成候选，不会保存持久时钟或发布目录。切换线上内容前，还要由维护系统持久记录 PUBLISH_TIME。验签应绑定预期公钥，不能只判断大信任库里是否存在某把可用公钥。

--sign-with KEY 只为未签名 RPM 补签；已经签名的包会保留原字节，包括其他供应商签署的包。 如果策略要求每个 RPM 都由自己的密钥签署，应逐包验证目标密钥，并只在候选中重签不满足要求的 包。--overwrite 是显式的批量替代方案：它重签所有保留 RPM，改变包字节，因此必须根据最终 包字节重建索引。最后一次 create 完成后，始终重新生成对应的索引分离签名。

4. 切换前验收

对候选与预期服务端点检查以下事项：

1. 三类 XML 与 RPM 集合对应，引用文件校验和正确。若只改变发布时间，RPM 与压缩 XML 应保持 逐字节一致。
2. 每个软件包与索引签名都满足预期客户端信任策略。
3. 包字节、选项和时间戳相同时，重复构建元数据应为空操作；此项检查不要强制重签包。维护脚本还应 保留旧的有效分离签名，避免重新签名。
4. 带旧缓存的客户端接受新索引，并实际下载、验证软件包。这个测试保留原 URL、repo ID 与缓存。
5. 第二次真实内容更新使用更晚的时间，同一客户端仍能接受。需要确认安装行为时，在可丢弃主机上 使用生产中的确切客户端补做安装测试。

对已有签名仓库，验收全程保留 gpgcheck=1 与 repo_gpgcheck=1。清缓存或关闭验签，会绕过 本来需要测试的行为。与旧 createrepo_c 比较时，应核对依赖含义，而非要求 XML 逐字节一致； 相关规则见平台与集成。

5. 发布与恢复资料保留

Plain 会替换多个文件，不提供整个目录的原子切换。发布层需要协调包文件、索引、分离签名以及 缓存的可见顺序。仍可能被缓存客户端请求的旧元数据文件应继续保留；直接运行 Plain 重建，可能 删除目录中不再引用的 SOW checksum 命名元数据。

保留原始备份与持久时钟。回滚软件包内容时，把它当成更晚的一次发布重新建库、签名。只恢复旧 repomd.xml、却搭配已经改变的 RPM，会重新引入校验和或时间戳问题。

Managed 的 sow check 不用于审计 Plain 目录。这里的验收依据是上述检查与真实 YUM/DNF 客户端。精确命令契约见 sow create，两层签名的区别见 仓库签名。

2.3 - 搭建 APT 仓库

本教程从零创建一个 Managed DEB 仓库。你需要一个可写目录，以及一个或多个 DEB 文件。

1. 创建工作区

mkdir -p /srv/sow
cd /srv/sow
sow init .
sow repo new pigsty
sow dist new trixie --format deb -r pigsty

Dist 名称会成为 APT Suite。它由你定义；SOW 不会根据 trixie 推断发行版语义。

2. 配置成员策略

如果需要过滤或限制版本，编辑生成的 sow.yml：

schema: sow/v3
architectures: [x86_64, aarch64]
repos:
  pigsty:
    dists:
      trixie:
        format: deb
        limit: 1
        exclude:
          - kind: [dbgsym, dbg]
targets: {}

然后校验：

sow config check
sow config show --all

配置中保存规范架构名，渲染时使用 Debian 生态名称：x86_64 对应 amd64，aarch64 对应 arm64；中立架构 all 包会进入两个视图。

3. 添加 DEB

sow add /path/to/packages/*.deb -r pigsty -d trixie
sow status -r pigsty
sow check -r pigsty

接纳的包体只保存一次。公共树如下：

/srv/sow/pigsty/
├── pool/...
└── dists/trixie/
    ├── Release
    └── main/
        ├── binary-amd64/
        │   ├── Packages
        │   ├── Packages.gz
        │   └── by-hash/SHA256/...
        └── binary-arm64/...

pool/ 下的路径按规范化源码包名分组；Packages 中的 Filename 相对 Archive Root； SOW 会写入 SHA-256 by-hash 副本，并在 Release 中声明。

4. HTTP 预览

本地预览可以直接使用：

cd /srv/sow
python3 -m http.server --bind 127.0.0.1 8080

检查协议入口：

curl --fail http://127.0.0.1:8080/pigsty/dists/trixie/Release >/dev/null
curl --fail http://127.0.0.1:8080/pigsty/dists/trixie/main/binary-amd64/Packages.gz >/dev/null

长期服务应使用持续维护的 HTTP Server，并完整暴露 pigsty/ 树。

5. 配置 APT

将 REPO_HOST 替换为客户端可访问的地址。未签名测试仓库可使用显式信任的 deb822 配置：

# /etc/apt/sources.list.d/pigsty.sources
Types: deb
URIs: http://REPO_HOST:8080/pigsty
Suites: trixie
Components: main
Architectures: amd64
Trusted: yes

刷新并查询：

sudo apt update
apt-cache policy

Trusted: yes 会关闭真实性校验，只适合受控测试。签名仓库应删除该行并配置 Keyring：

Types: deb
URIs: https://repo.example.com/pigsty
Suites: trixie
Components: main
Architectures: amd64
Signed-By: /usr/share/keyrings/pigsty-archive-keyring.gpg

打开 Signed-By 前，请先完成仓库签名。

6. 安全发布

交付前必须通过深度校验：

sow check -r pigsty

向已配置的 filesystem 或 R2 目标交付时，使用 sow publish。 如果使用其他传输方式，应把完整仓库复制到离线 staging，再原子切换上线。不要逐文件更新在线 dists/ 树，否则客户端可能同时看到不同 Generation 的元数据与包体。

更新仓库

sow add /path/to/new.deb -r pigsty -d trixie
sow rm PACKAGE_NAME -r pigsty -d trixie
sow build -r pigsty
sow check -r pigsty

策略或签名配置变化后用 build 收敛；发布门禁是 check，不能只看 status。

自动化客户端与平台覆盖见平台与集成。

2.4 - 仓库签名

SOW 提供两条互相独立的签名路径：

APT 通过签名的 Release 信任包哈希；SOW 不重签 DEB 包体。先配置元数据签名；只有当你负责 这些 RPM 字节的签名策略时，再启用包体签名。

1. 创建专用密钥

下面生成一把无口令的示例密钥。生产环境应使用受保护密钥并配置 passphrase 引用，详见 配置参考。

SIGNING_UID='SOW Repository <repo@example.com>'
gpg --batch --pinentry-mode loopback --passphrase '' \
  --quick-generate-key "$SIGNING_UID" rsa3072 sign 2y

FPR="$(gpg --batch --with-colons --list-secret-keys "$SIGNING_UID" \
  | awk -F: '$1 == "fpr" {print $10; exit}')"
test -n "$FPR"

sudo install -d -m 0700 /srv/sow-secrets
sudo chown "$(id -u):$(id -g)" /srv/sow-secrets
gpg --batch --pinentry-mode loopback --passphrase '' --armor \
  --export-secret-keys "$FPR" > /srv/sow-secrets/repo-signing.asc
gpg --armor --export "$FPR" > /srv/sow-secrets/repo-signing.pub
chmod 600 /srv/sow-secrets/repo-signing.asc

私钥必须放在 Workspace 公共 Repository 树与所有 Web Root 之外。若 SOW 由专用服务账户运行， 目录 owner 应是该账户，而不是交互用户。只向客户端分发 repo-signing.pub。

2. 配置元数据签名

在 /srv/sow/sow.yml 的 Repository 下添加所需配置；未使用的包生态可以省略：

repos:
  pigsty:
    signing:
      rpm:
        metadata:
          key: file:///srv/sow-secrets/repo-signing.asc
      deb:
        metadata:
          key: file:///srv/sow-secrets/repo-signing.asc
    dists:
      # 保留已有 Dist 定义

解析密钥引用、重建并执行发布门禁：

cd /srv/sow
sow config check
sow build -r pigsty
sow check -r pigsty

受口令保护的密钥可在 key 旁增加 passphrase: env://SOW_METADATA_PASSPHRASE，或使用 有界文件引用。SOW 不会把密钥或口令内容写入配置、SQLite、JSON 或日志。

3. 手工验证元数据

按实际 Dist 与架构调整路径：

gpg --verify \
  pigsty/dists/el9/x86_64/repodata/repomd.xml.asc \
  pigsty/dists/el9/x86_64/repodata/repomd.xml

gpg --verify pigsty/dists/trixie/InRelease
gpg --verify \
  pigsty/dists/trixie/Release.gpg \
  pigsty/dists/trixie/Release

sow check 会在深度一致性校验中检查配置的签名身份。建立客户端信任根时，仍应手工验证一次。

4. 可选：签署 RPM 包体

只有客户端要求内嵌包签名时，才添加 rpm.packages：

repos:
  pigsty:
    signing:
      rpm:
        packages:
          mode: fill
          key: agent://REPLACE_WITH_THE_FINGERPRINT
        metadata:
          key: file:///srv/sow-secrets/repo-signing.asc

将占位符替换为 $FPR 中的 40 位十六进制指纹。该操作要求：

• 安装 rpm 与 gpg；
• 匹配的私钥存在于 rpm 使用的环境 GPG Keyring 中；
• fill 保留已经由配置 key 或 trusted_keys 签好的包；
• always 重签所有未由配置身份签好的包；
• never 保持输入字节不变。

SOW 只会对私有 staged 副本调用 rpm --addsign 或 rpm --resign，不会修改输入文件。 这些规则适用于新导入的包；build 不会重签已有的不可变包对象。在启用 fill 或更换 key 前，确认 所有已有 RPM 都由配置 key 或受信任身份签署。只检查 signature_key 是否为空还不够：已有的第三方签名也可能不受新策略信任。若确实信任该签名身份，可将其 公钥加入 trusted_keys；否则先在仓库外准备正确签名的包，使用新的包版本与文件名导入，或从 原始包重建新仓库。准备完成前保留旧策略。策略拒绝会保留已有 Desired 状态。

确认已有包兼容后，再校验并构建：

sow config check
sow build -r pigsty
sow check -r pigsty

用 rpmkeys --checksig /path/to/package.rpm 检查结果。

5. 启用 dnf 验签

通过可信通道把公钥传到客户端：

sudo install -m 0644 /path/to/repo-signing.pub /etc/pki/rpm-gpg/RPM-GPG-KEY-pigsty
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-pigsty

再打开与你实际签名范围对应的检查：

[pigsty-el9]
name=Pigsty EL9
baseurl=https://repo.example.com/pigsty/dists/el9/$basearch/
enabled=1
repo_gpgcheck=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-pigsty

没有配置包体签名时，将 gpgcheck 设为 0；既然已经配置元数据签名，就不要关闭 repo_gpgcheck。

6. 启用 APT 验签

将公钥安装为独立 Keyring：

sudo gpg --dearmor --yes \
  --output /usr/share/keyrings/pigsty-archive-keyring.gpg /path/to/repo-signing.pub

在 deb822 配置中引用它，且不要设置 Trusted: yes：

Types: deb
URIs: https://repo.example.com/pigsty
Suites: trixie
Components: main
Architectures: amd64
Signed-By: /usr/share/keyrings/pigsty-archive-keyring.gpg

执行 apt update。任何签名错误都应视为部署失败，不能靠削弱客户端配置绕过。

Plain 模式 RPM 签名

Plain 模式可以签署 RPM 包体，但不会签署仓库元数据，也不会生成 APT Release：

sow create /srv/flat --sign-with 0123456789ABCDEF

key 去掉可选的 0x 或 0X 前缀后，必须是恰好 16、40 或 64 位十六进制字符；SOW 会去掉 前缀并规范化为大写。匹配私钥必须能被环境中的 rpm/GPG 使用。不带 --overwrite 时，已有签名的 RPM 保持字节不变；带上该参数则显式重签 所有 RPM。SOW 先签署私有 staged 副本，再替换包体与元数据。

已有签名并不等于由 --sign-with 指定的密钥签署。如果要求全部 RPM 都使用自己的密钥， 应逐包验证，在候选副本上选择性重签不匹配的包；也可以明确使用 --overwrite 重签全部包。

已有在线 YUM 仓库还应保留发布时间。SOW 0.5.0 新增 --metadata-timestamp；最后一次 create 完成后，发布前应单独签署并验证新的 repomd.xml。包签名与索引签名是两项独立 检查。完整顺序及带缓存客户端验收见 YUM 迁移指南。

更换密钥

在 Managed 模式中，改变 key 引用或解析出的指纹会让相关 Dist 变为 dirty。元数据 key 可以先分发新公钥，再重建、 校验并切换客户端。RPM 包 key 必须分阶段轮换：Package Object 不可变，build 遇到不满足新策略的 既有 RPM 会拒绝，而不是原地重签。旧软件包坐标尚未下架或由新 Release 替代前，应使用 fill 并把旧公钥保留在 trusted_keys。最后在目标环境做真实客户端验收。

最后应使用生产中的确切 dnf/APT 版本与信任策略验收签名仓库。自动化覆盖见 平台与集成。

2.5 - 服务与发布仓库

SOW 只生成静态文件，不是 HTTP 服务器。本指南把可写 Workspace 与 Nginx 服务路径分开。

公共与私有路径

第一个工作区里的源 Repository 是 /srv/sow/local。不要把 /srv/sow 设为 document root。

1. 校验源 Generation

cd /srv/sow
sow build -r local
sow check -r local

只有 check 返回 0 才继续。status 适合诊断；check 才是完整只读交付证明。

2. 配置 filesystem target

先创建 endpoint 目录。它必须是真实、规范目录，不能是 symlink；SOW 不会替你创建缺失 endpoint。

sudo install -d -m 0755 /srv/repo-public
sudo chown "$(id -u):$(id -g)" /srv/repo-public

第二条命令把写权限交给当前操作者；若 sow publish 由专用服务账户执行，应改为该账户。

在 /srv/sow/sow.yml 中增加 target：

targets:
  public:
    repository: local
    provider: filesystem
    endpoint: file:///srv/repo-public
    prefix: local
    public_endpoint: file:///srv/repo-public/local/
    max_cache_ttl: 0s
    authoritative_workspace: true
    single_writer: true
    exclusive_write_authority: true

三个布尔字段都是必填安全确认。endpoint 与 prefix 合并为 /srv/repo-public/local； SOW 会在预先存在的 endpoint 下创建并拥有该 prefix。

校验并发布：

sow config check
sow publish public

发布先复制不可变包体和元数据，再更新可变协议指针，随后校验结果并记录 target checkpoint。 同一 Generation 重复发布是幂等空操作。

不要让其他工具写入同一 target prefix。target 契约是单 writer、独占写入。

3. 用 Nginx 服务 target

server {
    listen 80;
    server_name repo.example.com;

    root /srv/repo-public;
    autoindex off;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ (^|/)\. {
        deny all;
    }
}

校验配置后 reload Nginx。客户端 URL 为：

DNF baseurl: http://repo.example.com/local/dists/el9/x86_64/
APT source:  deb http://repo.example.com/local bookworm main

如果元数据或包体已签名，请单独发布对应公钥并配置 gpgkey/Signed-By；私钥绝不能放在 document root 下。

4. 验证服务入口

curl --fail --head \
  http://repo.example.com/local/dists/el9/x86_64/repodata/repomd.xml

curl --fail --head \
  http://repo.example.com/local/dists/bookworm/Release

curl --fail --head \
  http://repo.example.com/local/dists/bookworm/main/binary-amd64/Packages.gz

随后从客户端主机运行真实包管理器。HTTP 可达不等于客户端已验证，两层都要检查。

完整 Repository prefix 必须使用同一访问策略。RPM 元数据可能通过 ../../../pool/... 解析包路径，APT Filename 也直接指向 pool/...。只保护 dists/ 而误放开或拦截 pool/ 都会破坏仓库。

手工与隔离交付

如果 sow publish 无法到达目标：

1. 在源端运行 sow check；
2. 把完整 Repository 复制到新的、非 live staging/release 目录；
3. 用 sow changes 0 或 archive manifest 校验传输哈希；
4. 原子切换操作者拥有的父级引用到新目录；
5. 保留上一版，直到客户端与缓存越过它。

不要直接对 live Repository root 执行无序 rsync --delete。它不保留 SOW 的指针顺序、 target checkpoint、缓存 grace 或恢复状态。sow changes 描述 Generation 差异，不代表可以 绕过这些控制直接修改 live target。

R2 target

provider: r2 使用 S3 兼容存储传输与只报告的 target GC。传输集成会针对固定的 PGSTY Silo fixture 验证 list、HEAD、GET 与单段条件 PUT；不覆盖条件式 Multipart 完成，也不能替代真实 R2 验收。启用生产目标前，请先在非生产 prefix 验证凭据、bucket policy、公共 endpoint、缓存行为、重放与恢复。详见平台与集成。

下一步

• sow publish 与 sow gc
• 发布设计
• 签名教程

2.6 - 演练构建 pigsty-infra 仓库

pgsty/infra-pkg 是 Pigsty Infra 软件包的上游构建源码。 本教程假设双架构 RPM 与 DEB 已经构建完成，只处理后半程：从一堆包开始，用 SOW 建成真正可消费、可维护的 infra 仓库。

1. 把包集中到 ~/repo

本教程固定使用 ~/repo，不再为每条路径定义环境变量。先把已有包复制进两个输入目录：

mkdir -p ~/repo/packages/rpm ~/repo/packages/deb
cp ~/pgsty/infra-pkg/dist/rpm/*.rpm ~/repo/packages/rpm/
cp ~/pgsty/infra-pkg/dist/deb/*.deb ~/repo/packages/deb/

先确认四个“格式 × 架构”象限都有真实包体：

find ~/repo/packages/rpm -maxdepth 1 -type f -name '*.x86_64.rpm' | wc -l
find ~/repo/packages/rpm -maxdepth 1 -type f -name '*.aarch64.rpm' | wc -l
find ~/repo/packages/deb -maxdepth 1 -type f -name '*_amd64.deb' | wc -l
find ~/repo/packages/deb -maxdepth 1 -type f -name '*_arm64.deb' | wc -l

四个结果都必须大于零。此时目录只有输入包池：

~/repo/
└── packages/
    ├── rpm/                         # x86_64 + aarch64 RPM
    └── deb/                         # amd64 + arm64 DEB

2. 创建 infra Repository 与两个 Dist

初始化 Workspace，并创建名为 infra 的 Repository：

sow init ~/repo
cd ~/repo
sow repo new infra
sow dist new rpm --format rpm -r infra
sow dist new deb --format deb -r infra

现在模型已经确定：

Repository: infra
├── Dist: rpm    format=rpm    policy=latest
└── Dist: deb    format=deb    policy=latest

打开 ~/repo/sow.yml，把配置整理为：

schema: sow/v3
architectures: [x86_64, aarch64]
repos:
  infra:
    dists:
      rpm:
        format: rpm
        limit: 1
      deb:
        format: deb
        limit: 1

limit: 1 按“包名 + 原生架构”只保留最新一个版本。因此 rpm 与 deb 就是两个滚动更新的 latest channel；它们仍会同时保留 x86-64 与 ARM64 两个架构。

sow config check
sow config show --all -r infra

3. 一次性导入并构建

先更新 Desired Membership，最后只构建一次：

cd ~/repo
sow add ~/repo/packages/rpm --recursive -r infra -d rpm --skip
sow add ~/repo/packages/deb --recursive -r infra -d deb --skip
sow build -r infra -d rpm -d deb
sow check -r infra

sow check 返回 0，才算初始化完成。再核对 SOW 从包头读出的真实格式与架构：

sow ls -r infra -d rpm -d deb --json |
  jq -r '.result.packages | group_by(.format + "/" + .canonical_arch)[] |
    "\(.[0].format)\t\(.[0].canonical_arch)\t\(length) packages"'

预期至少出现：

deb     aarch64   ... packages
deb     x86_64    ... packages
rpm     aarch64   ... packages
rpm     x86_64    ... packages

SOW 使用规范化架构名，因此 DEB 的 amd64/arm64 在这里显示为 x86_64/aarch64。

4. 看懂生成的目录

打印实际目录：

find ~/repo -maxdepth 6 -type d | LC_ALL=C sort

关键结构应当是：

~/repo/
├── sow.yml                            # 配置，不对外服务
├── .sow/                              # 数据库、锁、恢复状态，不对外服务
├── packages/                          # 原始输入包池，可自行归档
│   ├── rpm/
│   └── deb/
└── infra/                             # 完整的公开 Repository Root
    ├── pool/                          # RPM 与 DEB 共享的单副本包池
    └── dists/
        ├── rpm/
        │   ├── x86_64/repodata/
        │   └── aarch64/repodata/
        └── deb/
            ├── Release
            └── main/
                ├── binary-amd64/
                └── binary-arm64/

这里有一个容易混淆、但必须记住的路径规则：SOW 的 Dist 固定放在 dists/ 下。因此逻辑上的 infra/rpm 与 infra/deb，真实视图路径分别是 /infra/dists/rpm/ 和 /infra/dists/deb/； 包体则统一放在 /infra/pool/。发布或挂载时必须使用完整的 ~/repo/infra，不能只拿走某个 Dist。

5. 用 Nginx 只读服务仓库

使用官方 nginx:alpine 镜像，把 Repository Root 只读挂载到 /infra：

docker network create --internal infra-lab
docker run --detach \
  --name infra-nginx \
  --network infra-lab \
  --publish 8080:80 \
  --volume "$HOME/repo/infra:/usr/share/nginx/html/infra:ro" \
  nginx:alpine

直接检查两种索引入口：

curl -fsS http://127.0.0.1:8080/infra/dists/rpm/x86_64/repodata/repomd.xml | head
curl -fsS http://127.0.0.1:8080/infra/dists/deb/Release | head

Nginx 只看得到 ~/repo/infra，既看不到 sow.yml 与 .sow/，也无法修改仓库。

6. 在 EL9 中只用 infra 安装 RPM

下面的 Rocky Linux 9 容器位于 --internal 网络中。脚本先删除所有预置仓库，再只启用刚创建的 infra，因此成功安装不能依赖公网软件源。

docker run --rm --interactive --network infra-lab rockylinux:9 bash -s <<'ROCKY'
set -euxo pipefail

rm -f /etc/yum.repos.d/*.repo
cat >/etc/yum.repos.d/infra.repo <<'REPO'
[infra]
name=Pigsty Infra RPM
baseurl=http://infra-nginx/infra/dists/rpm/$basearch/
enabled=1
gpgcheck=0
repo_gpgcheck=0
REPO

dnf clean all
dnf --disablerepo='*' --enablerepo=infra makecache
dnf --disablerepo='*' --enablerepo=infra install -y pg-exporter
rpm -q --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n' pg-exporter
command -v pg_exporter
ROCKY

RPM 的 baseurl 必须落到具体架构视图。$basearch 会由 dnf 展开为 x86_64 或 aarch64。

7. 在 Ubuntu 24.04 中只用 infra 安装 DEB

APT 的 URI 指向 Repository Root，Suites 才是 Dist 名 deb：

docker run --rm --interactive --network infra-lab ubuntu:24.04 bash -s <<'UBUNTU'
set -euxo pipefail

rm -f /etc/apt/sources.list
rm -f /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources
cat >/etc/apt/sources.list.d/infra.sources <<'SOURCE'
Types: deb
URIs: http://infra-nginx/infra
Suites: deb
Components: main
Trusted: yes
SOURCE

apt-get clean
apt-get update
apt-get install -y --no-install-recommends pg-exporter
dpkg-query -W -f='${Package}\t${Version}\t${Architecture}\n' pg-exporter
command -v pg_exporter
UBUNTU

本教程使用隔离 HTTP 仓库，所以临时关闭了验签。正式服务应配置 RPM/APT 元数据签名，并移除 gpgcheck=0 与 Trusted: yes。

Docker 默认验证宿主机架构。若要完成四格运行矩阵，分别给两条 docker run 增加 --platform linux/amd64 与 --platform linux/arm64 后各跑一次；跨架构运行需要 Docker 的 binfmt/QEMU 支持。仓库清单检查与客户端安装检查是两个独立门禁。

8. 日常维护：添加一个新版本

更新仓库的正常动作是 add，不是先删除旧包。假设已经拿到新版 pg-exporter 的四个包体：

cp ~/pgsty/infra-pkg/dist/rpm/pg-exporter-*.rpm ~/repo/packages/rpm/
cp ~/pgsty/infra-pkg/dist/deb/pg-exporter_*.deb ~/repo/packages/deb/

cd ~/repo
sow add ~/repo/packages/rpm/pg-exporter-*.rpm -r infra -d rpm --skip
sow add ~/repo/packages/deb/pg-exporter_*.deb -r infra -d deb --skip
sow build -r infra -d rpm -d deb
sow check -r infra

因为 latest Dist 配了 limit: 1，新版本胜出后，旧版本会自动退出该 Dist 的 Desired Membership。 旧字节不会被立即删除，也不会因为以后放宽策略而自动回来。

可以重新运行第 6、7 节的客户端，先 makecache/update，再安装或升级，完成更新验收。

9. 两层保留策略：latest 与 stable

rpm、deb 的 limit: 1 适合持续滚动，但不能表达“保留所有正式发布历史”。为此再创建两个 Dist：

cd ~/repo
sow dist new rpm-stable --format rpm -r infra
sow dist new deb-stable --format deb -r infra
sow config show --all -r infra -d rpm-stable -d deb-stable

新 Dist 的默认 limit 是 0，表示保留所有版本。最终策略是：

注意：stable 不是把“包池里的所有历史”自动放回来，而是从现在开始，累积每次明确晋升的版本。

10. 把 latest 晋升到 stable

SOW 没有独立的 promote 命令。当前可靠做法是先冻结写入并导出源 Dist 的精确 Membership， 再把这些对象加入目标 Dist。输入直接取自 infra/pool；SOW 会校验并复用已有 Package Object， 不会重新打包，也不会在 pool 中复制第二份包体。

先确保源状态干净，并保存本次晋升清单：

cd ~/repo
sow check -r infra
mkdir -p ~/repo/manifests

sow ls -r infra -d rpm --json |
  jq -r '.result.packages[].pool_path' > ~/repo/manifests/rpm-latest-202608.list
sow ls -r infra -d deb --json |
  jq -r '.result.packages[].pool_path' > ~/repo/manifests/deb-latest-202608.list

在晋升结束前暂停对 rpm 与 deb 的写入，然后复用这些 pool 对象：

cd ~/repo
(
  set -e
  while IFS= read -r pool_path; do
    sow add "$HOME/repo/infra/$pool_path" -r infra -d rpm-stable --skip
  done < ~/repo/manifests/rpm-latest-202608.list

  while IFS= read -r pool_path; do
    sow add "$HOME/repo/infra/$pool_path" -r infra -d deb-stable --skip
  done < ~/repo/manifests/deb-latest-202608.list

  sow build -r infra -d rpm-stable -d deb-stable
  sow check -r infra
)

每次 add 应报告 reused。若中途失败，源 Dist 不受影响；修复问题后对同一清单重跑即可。 随着以后重复晋升，rpm/deb 仍只保留最新版本，而 rpm-stable/deb-stable 会逐次累积历史版本。

11. 从 stable 创建 2026-08 快照

客户端可见的月度快照也是两个新的 Dist：

cd ~/repo
sow dist new rpm-202608 --format rpm -r infra
sow dist new deb-202608 --format deb -r infra
sow config show --all -r infra -d rpm-202608 -d deb-202608

在快照窗口内暂停 stable 写入，先把其精确 Membership 固化为清单：

sow check -r infra
sow ls -r infra -d rpm-stable --json |
  jq -r '.result.packages[].pool_path' > ~/repo/manifests/rpm-stable-202608.list
sow ls -r infra -d deb-stable --json |
  jq -r '.result.packages[].pool_path' > ~/repo/manifests/deb-stable-202608.list

再把清单加入对应快照 Dist：

cd ~/repo
(
  set -e
  while IFS= read -r pool_path; do
    sow add "$HOME/repo/infra/$pool_path" -r infra -d rpm-202608 --skip
  done < ~/repo/manifests/rpm-stable-202608.list

  while IFS= read -r pool_path; do
    sow add "$HOME/repo/infra/$pool_path" -r infra -d deb-202608 --skip
  done < ~/repo/manifests/deb-stable-202608.list

  sow build -r infra -d rpm-202608 -d deb-202608
  sow check -r infra
)

把这次已验证的完整 Repository Generation 也加入保留集合，防止后续 GC 把它当作不可达历史处理：

sow retain add "$(sow status -r infra --json | jq -r '.result.built_generation')" -r infra
sow retain ls -r infra

retain 保留的是整个 Repository Generation，用于恢复与 GC 安全根；客户端可见的固定 URL 仍由 rpm-202608 与 deb-202608 两个 Dist 提供。SOW 尚不强制快照 Dist 只读，因而创建后不再对它们 执行 add 或 rm 是维护规约的一部分。

12. 客户端地址总表

同一个 Nginx 与同一份 infra/pool 支撑所有 channel：

最终验收：

cd ~/repo
sow dist ls -r infra
sow status -r infra
sow check -r infra

到这里，我们得到的不是一次性演示目录，而是一个可以继续收包、晋升与做月度快照的真实 Infra Repository：rpm/deb 负责快速更新，rpm-stable/deb-stable 负责积累正式历史，月度 Dist 提供固定入口， 所有视图复用同一份不可变包体。

实验结束后可停止临时服务：

docker rm --force infra-nginx
docker network rm infra-lab

3 - 功能

SOW 提供两条相互隔离的运行路径。Plain 模式无状态地重建一个目录；Managed 模式在工作区中 持续记录软件包成员关系与不可变仓库 Generation。两者都不会暗中接管对方的状态。

能力矩阵

SOW 在进程内解析软件包并渲染元数据，不调用 createrepo_c、dpkg-scanpackages、 reprepro 或 modifyrepo_c。RPM 包签名是例外：它会改写包体，因此需要主机上的 rpm 命令与 GPG 环境。

仓库格式

SOW 有意不生成 SQLite rpm-md、zchunk、modulemd、源码包索引与 MD5/SHA1 DEB manifest。 它负责构建仓库文件，不提供 HTTP 服务或 CDN。

按问题阅读

Release 目标、文件系统要求、客户端与 Provider 见平台与集成。

3.1 - Plain 平面仓库

sow create 接手一个已经放着 .rpm / .deb 的目录，在包旁边生成平面仓库索引。Plain 模式没有工作区、配置文件、数据库、期望状态，也没有操作 journal。包目录就是权威事实来源，所有索引都是当前目录内容的可丢弃投影。

这个边界是刻意的：Managed 仓库保存状态并恢复事务；Plain 仓库失败了就便宜地重建。一次运行失败或被中断后，重新执行同一条命令，覆盖派生元数据即可。

契约

Plain 模式由四条规则定义：

1. 包是权威事实。 默认 create 不修改包字节，只替换 repodata/、Packages 与 Packages.gz。--pigsty 和显式 RPM 签名是文档明确列出的例外。
2. 包内容只扫一遍。 默认未签名路径中，每个选中包只打开一次、完整计算一次 SHA-256，并在同一遍里解析。完整 RPM/DEB 元数据保留给渲染阶段；渲染与输出校验不会再次打开包体。
3. 收尾只做一次便宜校验。 发布前重新列出顶层包集合，把 stat 事实与扫描快照比较，不再计算第二遍包 SHA-256。
4. 失败就重建。 Plain 没有事务 journal、pre-image、前滚或回滚。失败可能留下部分已替换的派生元数据；下一次 sow create 丢弃自有临时残留，按当前包目录完整重建。

输入字节与参数（包括元数据时间戳）均不变时，输出仍然确定，重复运行报告 noop=true。

单遍流水线

--jobs 默认等于逻辑 CPU 数，控制唯一一次包内容扫描：

锁定目录
  -> 列出并排序顶层 RPM/DEB
  -> 并行打开 + SHA-256 + 解析（每包一次）
  -> 处理坐标冲突与 Pigsty 过滤
  -> 从保留的解析事实渲染 RPM/DEB 元数据
  -> 只校验生成的元数据
  -> 重新列目录并比较包 stat 快照
  -> 覆盖派生输出；--pigsty 最后写 repo_complete

worker 完成先后不会影响结果：解析事实始终按规范 basename / 索引顺序消费。RPM XML 直接使用 worker 保留下来的完整解析对象；DEB Packages 直接使用保留的 control 段落与该 worker 已经算出的 SHA-256。

输出自校验仍会读取生成的 XML、repomd.xml、Packages 与 Packages.gz。这些是很小的派生元数据，不会再次读取包体。

最终 stat 校验保证什么

收尾校验要求：

• 顶层普通 .rpm / .deb basename 的排序集合完全相同；
• 文件 identity / inode 相同；
• 文件类型与 mode 不变；
• size 与 mtime 不变。

任一事实不同，都在发布前以完整性退出码 5 拒绝。这能以一次列目录的成本发现正常的新增、删除、替换、截断与重写竞争。

它刻意不是密码学复验。若外部写者原地改字节，同时伪造保持 inode、size 与 mtime 不变，stat 无法发现。Plain 接受这个权衡，因为目标场景是本机单进程、协作写入、结果可重建。需要对抗并发篡改证据或持久恢复时，应使用 Managed 仓库。

扫描与输出规则

• 只考虑目录顶层普通文件；永不递归，也不跟随符号链接。
• 只选择 .rpm 与 .deb 后缀。
• 包身份与架构来自 RPM header 或 DEB control，绝不从文件名猜；RPM src / nosrc 被拒绝。
• 所有合法版本都进索引；同一逻辑坐标对应不同字节流时拒绝。
• 默认模式拒绝空目录；--pigsty 可以把一次中断清理后已经为空的权威包集合收敛完成。

有 RPM 就生成 repodata/，有 DEB 就生成 Packages 与 Packages.gz：

/srv/repo/
├── pev2-1.23.0-1.noarch.rpm
├── xray_26.2.6-1_amd64.deb
├── Packages
├── Packages.gz
└── repodata/
    ├── <sha256>-primary.xml.gz
    ├── <sha256>-filelists.xml.gz
    ├── <sha256>-other.xml.gz
    └── repomd.xml

平面位置全部是相对路径：RPM 使用裸 basename，DEB 使用 ./<basename>。公开目录固定 0755，生成文件与 repo_complete 固定 0644，不受 umask 影响。

某种包格式消失时，SOW 删除该格式已知的派生输出。重跑也会覆盖中断留下的半套输出，例如只有一个 Packages；新一代不再引用的 SOW checksum 形状 RPM 元数据会被移除，未知文件保持不动。

确定性与 no-op

repomd.xml 的 revision 固定为 0，data 时间戳默认为 0。从 0.5 开始，可以用 --metadata-timestamp SECONDS 显式指定 data 时间。gzip header 仍固定，排序仍规范化，因此 同一包集合与参数生成逐字节一致的元数据。发布前 SOW 会比较 stage 与 live 元数据；如果无需 清理/签名且所有输出已经相同，就只删私有 stage，不替换公开 inode，并返回 noop=true。

只改变时间戳时，变化仅在 repomd.xml，不影响 RPM 字节、压缩 XML、包时间或 DEB 输出。 调用者负责保存发布历史和签署索引。迁移已有在线 YUM 仓库时，请按 迁移指南处理，避免时间倒退导致带缓存的 EL7 客户端拒收； 已有正数时间戳的索引不适合直接替换成默认的 0。

Plain create 不做 journal 恢复，因此 JSON 字段 recovered 始终为 false。

发布与中断语义

开始发布前，全部元数据都已在目标目录内的私有 stage 生成并验证。单文件替换使用同文件系统 rename；RPM 先安装 checksum 命名元数据，最后替换 repomd.xml。

这不是多文件事务。进程在发布中被杀，可能留下新 RPM 元数据配旧 DEB 元数据、只剩一个 DEB 索引文件，或多余的旧 checksum RPM 元数据。这些状态不是需要调和的事务证据，只是可丢弃输出。下一次运行按当前包集合重新渲染完整投影，覆盖或删除残留。

实现不创建持久 journal 或 recovery trash。启动时会先丢弃 Plain 保留 staging 命名空间中 属于 SOW 的残留，再开始全新扫描。

--pigsty marker 门禁

--pigsty 还会删除命中兼容规则的解析包事实（DEB i386 与 Patroni 3.0.4），并把剩余包按 basename 排序写入 repo_complete，格式为 <sha256><两个空格><basename>。RPM 不会仅因为架构是 i386/i486/i586/i686 而被删除。

发布顺序为：

stage + 校验
  -> 最终 stat 校验
  -> 撤下旧 repo_complete
  -> 安装显式请求签名后的 RPM（如有）
  -> 安装 RPM 与 DEB 元数据
  -> 删除命中清理规则的包
  -> 最后写 repo_complete

marker 缺失就表示“尚未完成”，消费方不得使用该目录。若运行在撤 marker 后停止，重新执行 sow create --pigsty：它扫描现在仍存在的包，覆盖元数据、完成清理，最后写新 marker，无需动作日志。

默认模式看到已有 repo_complete 会拒绝运行，避免未受门禁控制的命令留下过期就绪声明。

显式 RPM 签名

--sign-with 是修改包体的显式授权，也是独立慢路径。SOW 在私有 stage 副本上签名，验证嵌入签名与 signature-neutral digest，重新解析结果，再先于元数据安装签后字节。这些必要的复制、签名与签后验证读取不属于默认未签名的一遍保证。签名中断后同样按当前包目录重跑，不从 journal 重放签名事务。

锁与适用范围

sow create 在一次运行期间锁定目标目录及其稳定父目录；--timeout / --no-wait 控制协作锁等待。锁能阻止另一个协作 SOW 进程同时写入，但不会把任意外部包修改变成受支持负载。

本地单进程创建一个可随时重建的平面仓库，用 Plain。需要期望状态、审计历史、原子 generation 切换或证据驱动崩溃恢复，用 Managed 工作区。

继续阅读

• sow create 参考 —— 参数、输出与失败契约
• 事务与恢复 —— Managed 的耐久边界
• 快速上手 —— 五分钟建一个仓库

3.2 - Managed 工作区

当同一个仓库要维护好几个月 —— 包成批到达、由策略决定谁留下、事后还得说清楚什么时候变了什么 —— 你需要的是 Managed 模式。本页讲三层模型、它产出的布局,以及命令怎么判断你说的是哪个仓库、哪个 Dist。

三个层级

Workspace 工作区                    发现与配置边界
└── Repository 仓库                 所有权边界:pool、dists、SQLite、锁、Generation
    └── Dist 发行版                 单一格式的具名成员集合
        └── Architecture View 架构视图   渲染投影 —— 不是成员关系

每层只做一件事,边界很硬:

工作区(Workspace) 只拥有两样东西:根级 sow.yml 和 .sow/ 状态目录。工作区根下其他任何东西都不属于 SOW。它是发现的单位 —— 命令从某个起始目录向上找到工作区 —— 也是架构许可表所在的地方。

仓库(Repository) 固定在 <workspace>/<name>。你不能把它指到别处,没有 path 选项。一个 Repository 拥有自己的 pool/、dists/、SQLite、锁、恢复状态、Generation、保留代根、发布 checkpoint 与 GC 证据。两个 Repository 之间永不去重 —— 同一个包 add 进两个仓库就存两份,这是刻意的:这样删掉一个仓库永远不可能伤到另一个。

Dist 是一个单一格式(rpm 或 deb)的普通具名成员集合。名字对 SOW 是不透明字符串。el9、trixie、el9-beta、customer-acme —— 它们都不产生状态机、晋升流程或快照。想要一个 beta 频道,就建一个叫 el9-beta 的 Dist;含义存在于你的脑子和 .repo 文件里,不在 SOW 里。

架构视图(Architecture View) 是 build 渲染出来的东西,不产生第二份成员关系。一个 noarch RPM 只有一个包对象、一条成员记录,构建时投影进每个适用视图。参见包池与元数据视图。

一个 Repository 可以同时拥有 RPM Dist 与 DEB Dist,共用同一个 pool/。

磁盘布局

Managed 路径从不由用户输入拼装,而是由解析后的真实工作区根、已校验的名称和固定相对片段推导出来 —— 这就是为什么符号链接替换和路径逃逸没有可攻击的面。

<workspace>/
├── sow.yml                       # 唯一的配置文件
├── .sow/                         # 私有状态;绝不要对外服务
│   ├── workspace.lock
│   ├── workspace-ops/            # 工作区生命周期 journal
│   ├── repo-locks/<repo>.lock
│   ├── <repo>.db                 # 每个仓库一个 SQLite
│   └── <repo>/
│       ├── stage/                # 同文件系统的 staging 区
│       ├── recovery/             # 删除动作的原子移入目标
│       ├── pending/              # --skip 的耐久 payload
│       ├── retained/             # 保留代的私有根
│       └── transitions/          # 布局迁移的恢复状态
└── <repo>/                       # 可对外服务的树
    ├── pool/                     # 不可变包字节
    └── dists/
        └── <dist>/               # 架构视图渲染在这里

执行过两次 dist new 与两次 add 之后的真实工作区:

$ find .sow | sort
.sow
.sow/pigsty
.sow/pigsty.db
.sow/pigsty.db-shm
.sow/pigsty.db-wal
.sow/pigsty/pending
.sow/pigsty/recovery
.sow/pigsty/retained
.sow/pigsty/stage
.sow/pigsty/transitions
.sow/repo-locks
.sow/repo-locks/pigsty.lock
.sow/workspace-ops
.sow/workspace.lock

<repo>/ 下是公共交付树：可以直接服务、由 SOW 发布，或整根复制到离线 staging 后原子切换。 .sow/ 下全部是私有状态，绝不能暴露；详见对外服务。

名称必须匹配 [a-z0-9][a-z0-9._-]*；.、..、.sow、pool、dists 以及工作区保留名一律拒绝。

状态数据库与软件包事实

私有 SQLite 数据库按 package_sha256 索引 Desired/Built Membership，因此查询与构建可以 一次批量展开完整成员投影，而不是为每个软件包单独查询。数据库还保存以不可变包体 SHA-256 为键、可重建的软件包事实缓存。Ingest 从已认证快照解析一次软件包事实；快照安装到 pending、 再提升到 Pool 时，为保证恢复正确性，各阶段仍独立验证内容，整个 add 并不是只读一遍包体。生产构建只按本次 选中的 Digest，以有界、确定性批次读取 Facts Row，遇到缺失或损坏记录时再从已认证包体惰性 重建。无关或超大的 Facts Row 不会被读取。

对于未改变的 Pool 文件，暖构建使用设备号、inode、size、mtime 与 ctime 指纹避免重新读取 包体。指纹漂移与 Facts 缺失共享一次权威 SHA-256 校验并自动修复； sow check 仍是显式的完整密码学审计，并且无论指纹是否匹配，都会 对每个唯一物理包体哈希一次。

缓存与指纹只属于私有实现状态，不改变公共 pool/ + dists/ 布局。不要手工编辑数据库或 PRAGMA user_version。v0.3 或 v0.4 Repository 必须先备份，再通过 sow repo migrate 显式升级，之后才能执行普通 0.5 读写。Schema v13 为包池路径归属增加索引，使 add 只查询候选路径，不再扫描无关发布历史。 首次构建刷新受影响的 RPM 认证与 APT 元数据契约，之后未变化的包可复用匹配的 Built 认证证据。 其他维护只在 SOW 诊断明确指出时执行。

sow.yml 驱动一切

只有一个配置文件，用严格 decoder 解析。未知字段不会被忽略——它会失败。重复的规范化架构、非法名称或 format、Dist 架构不是工作区许可表的子集、非法 glob 或分类、不完整的 signing 块，同样失败。

schema: sow/v3
architectures:
  - x86_64
  - aarch64
repos:
  pigsty:
    signing:
      rpm:
        packages:
          mode: never
    dists:
      el9:
        format: rpm
      trixie:
        format: deb
targets:
  local:
    repository: pigsty
    provider: filesystem
    endpoint: file:///srv/mirror
    prefix: pigsty
    public_endpoint: file:///srv/mirror/pigsty/
    max_cache_ttl: 0s
    authoritative_workspace: true
    single_writer: true
    exclusive_write_authority: true

config show --all 展开全部默认值与规范化别名,让你看到 SOW 实际的决定:

$ sow config show --all
schema: sow/v3
architectures:
  - x86_64
  - aarch64
repos:
  pigsty:
    protected: false
    signing:
      rpm:
        packages:
          mode: never
    dists:
      el9:
        format: rpm
        architectures:
          - x86_64
          - aarch64
        limit: 0
        exclude: []
      trixie:
        format: deb
        architectures:
          - x86_64
          - aarch64
        limit: 0
        exclude: []

架构别名只在解析边界规范化一次:amd64 → x86_64,arm64 → aarch64。输出永远是 canonical family。生态名只在渲染出来的 DEB 视图目录名里出现(binary-amd64、binary-arm64)。

config check 不是 YAML lint。它会打开每个已初始化 Repository 的 SQLite,把候选配置与实际的 Dist、架构、成员集、Built 状态和签名可用性逐项比对。移除仍被成员或 Built 状态引用的架构族是预期拒绝(退出码 6);数据库或协议证据损坏是完整性错误(退出码 5)。每个写命令在写 journal 之前都跑同一套预检,所以 config check 能提前告诉你下一条 add 会不会被拒。

$ sow config check
configuration valid: /data/ws repositories=1 dists=2

完整 schema(包括 filesystem 与 r2 发布目标)见 sow.yml 配置参考。

发现:哪个工作区?

Managed 命令按以下顺序寻找最近祖先中的 sow.yml:

1. 给了 -C/--workdir DIR：从 DIR 向上找，并跳过当前目录候选。
2. 否则从当前目录向上找。
3. 仍未找到：从 $SOW_DIR 向上找；显式 -C 查找失败后也保留这条回退。
4. 还是没有:失败,并提示 sow init、--workdir 与 SOW_DIR。

找到第一个 sow.yml 就停,不会越过它继续往上找"更好的那个"。 查找沿传入路径的字面祖先进行，找到后再解析并绑定真实工作区根。符号链接起点可以使用， 但其字面祖先未必等于目标的物理祖先；别名引起选择歧义时，直接指定物理根。 sow config check 报告解析后的工作区，而不只是发现起点。

--workdir 不是 chdir。它只改变发现的起点。sow add 里的相对 PATH 仍然相对你真实的当前目录解析 —— 这正是 sow add ./build/*.rpm -C /srv/ws 应有的行为。

sow create 不参与上述任何一步。

选择:哪个仓库、哪个 Dist?

Repository 选择,按序:

1. 显式 -r/--repo NAME。
2. 命令起始目录位于 <workspace>/<repo>/ 内。
3. 工作区只有一个 Repository。
4. 否则失败并列出候选。

Dist 选择,按序:

1. 一个或多个显式 -d/--dist NAME(可重复)。
2. 起始目录位于 <workspace>/<repo>/dists/<dist>/ 内。
3. 选定 Repository 只有一个 Dist。
4. 否则失败并列出候选。

关键的不对称在这里:没给 -d 时,build、check、status 默认作用于选定 Repository 的 全部 Dist —— 对这几个命令而言,“没有过滤条件"解释成"全都要"是安全的。而 add、rm、ls 必须得到明确的 Dist 集合,因为猜一个包该落到哪里并不安全:

$ sow ls
workspace discovery error: managed: workspace discovery error: repository "pigsty" has multiple Dists (el9, trixie); select one or more with --dist

退出码 2。所有推断都在路径类型与符号链接校验之后才进行。

init 只做收敛,不做重置

sow init 的幂等性是设计出来的,它的规则是架构不变式而不是使用便利:

• 没有 sow.yml: 创建一个,写入 schema: sow/v3 与 architectures: [x86_64, aarch64],同时创建 .sow/。不自动创建任何 Repository。
• 已有合法配置: 按稳定名称顺序补齐尚未初始化的部分 —— 缺失的 Repository 外壳、缺失的 SQLite、整个缺失的 Dist。新建的 Dist 立刻生成其当前有效架构的全部空视图。
• 已有有效数据库状态或有效协议指针: 只校验。绝不覆盖、绝不清零 Generation、绝不重写字节。
• Dist 已初始化之后又往配置里加了架构: init 不渲染新视图、不推进 Generation。该 Dist 保持 dirty,等待显式 build。移除仍被成员或 Built 状态使用的架构族则失败。

$ sow init .
initialized /data/ws: config_created=false repositories_initialized=0 dists_initialized=0

第三、第四条规则的意义在于:init 必须能安全地在装着真实内容的仓库上执行。它朝声明的配置收敛,但绝不会拿"还没初始化"当借口去重建一个本来就好好的东西。

对象按稳定顺序处理。如果靠前的配置、Repository 或 Dist 已经耐久提交,而靠后的对象失败了,已提交的计数会被保留:人类输出先报告已提交的结果,--json 保留结构化 result,命令以 3(部分成功)退出。如果此时还没有任何东西提交过,则按原始错误类别退出。

空 Dist 也有合法协议发布面

dist new 建出来的 Dist,在 add 第一个包之前就已具备完整协议入口。RPM Dist 每个架构族 有一份合法的空 repodata;DEB Dist 有 Packages、Packages.gz、by-hash 条目和 Release。如果 Repository 配了元数据密钥,空 Dist 也一样签名。

因此从 Dist 里移除最后一个包之后,留下的是一份合法的空索引（配置签名时仍签名）， 而不是缺失或损坏的协议入口。真实包管理器验收仍是另一层兼容性门禁。

Protected 仓库

repos:
  pigsty:
    protected: true

protected: true 会拒绝 repo rm,即使加了 -f,返回退出码 6。它不限制别的:add、rm、build 和常规 Dist 维护照常。真要删这个 Repository,你必须先改 sow.yml、通过 config check,然后才能删 —— 这个摩擦正是该 flag 存在的意义。

继续阅读

• 包池与元数据视图 —— build 到底写了什么
• 发布模型 —— Generation 如何抵达目标
• 成员策略 —— exclude 与 limit 如何决定谁留下
• 第一个工作区 —— 本页的十分钟动手版
• sow.yml 配置参考 —— 完整 schema

3.3 - 包池与元数据视图

不变式

在一个 Repository 内，每个 live Package Object 在 pool/ 下只有一条正典 payload 路径。 Dist 与架构 view 拥有元数据，不拥有包体 alias：

<repo>/pool/...                              正典包体
<repo>/dists/<rpm-dist>/<arch>/repodata/... 纯 RPM 元数据
<repo>/dists/<deb-dist>/main/binary-*/...   纯 APT 元数据

相同 digest 出现在另一个 Repository 或发布 prefix 时，仍是另一个 owner 下的独立对象。 SOW 不会为了本地去重而制造共享的分布式所有权。

构建完成的 Repository

一个包含一份 x86_64 包与一份 noarch 包的 RPM Dist 形如：

demo/
├── pool/
│   ├── c/centos-release/centos-release-6-0.el6.centos.5.x86_64.rpm
│   └── e/epel-release/epel-release-7-5.noarch.rpm
└── dists/el9/
    ├── aarch64/repodata/
    │   ├── <sha256>-primary.xml.gz
    │   ├── <sha256>-filelists.xml.gz
    │   ├── <sha256>-other.xml.gz
    │   └── repomd.xml
    └── x86_64/repodata/
        ├── <sha256>-primary.xml.gz
        ├── <sha256>-filelists.xml.gz
        ├── <sha256>-other.xml.gz
        └── repomd.xml

不存在 dists/.../pool/ 子树。仍被保留的 live Generation 可以让多组内容寻址元数据并存； repomd.xml 指针决定当前生效的是哪一组。

RPM view 使用计算出的父级相对 href

rpm-md 相对架构 view 解析 <location href>。SOW 从实际 view 计算回到正典 Pool 的路径：

<location href="../../../pool/c/centos-release/centos-release-6-0.el6.centos.5.x86_64.rpm"/>
<location href="../../../pool/e/epel-release/epel-release-7-5.noarch.rpm"/>

深度从实际 view root 推导，不来自域名，也不写死部署路径。sow check 会解析、规范化每条 href，拒绝逃出 Repository 的路径，并证明它抵达预期 Pool 对象。

因此完整 Repository 根才是客户端与交付边界。DNF 指向 dists/el9/x86_64/，但对外服务或 复制时必须包含同级根 pool/ 的整个 Repository。

为什么 view 只含元数据

如果把软件包复制到每个架构 view，在没有 inode 身份的存储系统上就会产生额外 object key 与重复上传。SOW 因此把包体所有权集中在 Repository 包池，让索引负责投影成员关系。 完整复制、归档或发布都能保持这份契约，无需依赖 hardlink。

“只存一份”的边界是一个 Repository 或一个发布前缀，不是 Workspace、bucket、账号或整套 系统。相同软件包位于不同 Repository 或 target 时仍有各自独立的 owner。

中性包只被选入，不会复制

x86_64 view 选择 x86_64 + noarch；aarch64 view 选择 aarch64 + noarch。 中性包仍只有一份 Pool 对象，每个 view 只增加一条指回它的元数据记录。

DEB 在 archive root 层面同理：all 包进入每个适用的 Packages 索引，Filename: pool/... 始终指向唯一正典包体。

APT view

APT 原生把 Filename 定义成相对 archive root：

Filename: pool/p/postgresql-18/libpq5_18.3-1_amd64.deb

SOW 在 dists/<dist>/main/binary-<arch>/ 下渲染 Packages、Packages.gz 与 by-hash。 Release、InRelease、Release.gpg 是协议指针与签名。没有每 view 包体 alias，也没有 每架构 Release 存根。

普通客户端与 reposync 是两份契约

规范布局面向能消费完整 Repository 并正确处理协议相对路径的软件包客户端。默认 EL dnf reposync 是另一份契约：它的 safe-write 检查会 拒绝规范化后落到 per-repository 下载目录上方的软件包路径。这是明确不支持的组合；该工作流 应使用导出的 Leaf。

需要自包含 RPM leaf 时，在 Repository 与所有已配置 filesystem 发布根之外创建导出：

sow export rpm-leaf el9 x86_64 /srv/exports/el9-x86_64

导出拥有自己的包体树、repodata、manifest 与 .sow-export.json 完成标记。默认复制； --hardlink 是显式的同文件系统、可信只读优化。导出不会成为 Membership、Generation、 publish input 或 GC root。

复制与发布

正典正确性不依赖 inode 身份。优先使用已配置的 Publication Target。必须使用其他传输方式时， 用 rsync、cp 或 tar 把完整、稳定的 pool/ + dists/ 复制到离线 staging，复验后再原子 切换上线；不要逐文件更新在线树。只复制某个 RPM 架构 Leaf 不受支持，因为其中元数据有意 引用同级根 Pool。

sow changes 只在 pool/ 下列一次包体，随后是元数据与指针：

add  payload   pool/c/centos-release/centos-release-6-0.el6.centos.5.x86_64.rpm  ...
add  payload   pool/e/epel-release/epel-release-7-5.noarch.rpm                  ...
add  metadata  dists/el9/x86_64/repodata/<sha256>-primary.xml.gz               ...
add  pointer   dists/el9/x86_64/repodata/repomd.xml                            ...

dists/ 下不会出现 package payload 变更项。

继续阅读

• Managed 工作区——所有权与 Generation 状态
• 平台与集成——已验证与明确不支持的组合
• 对外服务——HTTP、复制与发布目标
• 仓库布局——准确的公有/私有路径

3.4 - 成员策略

策略回答的是这个问题:“我把整个构建目录倒进了这个 Dist,但我不想要 debuginfo 包,而且每个包只留最新版本。“两条规则完成这件事,它们按固定顺序执行,并且作用于 完整候选集,而不是你这次恰好 add 的那几个包。

两条规则与它们的顺序

候选集  →  exclude  →  limit  →  期望成员集(Desired Membership)

exclude 丢掉命中规则的包,limit 再按包名与架构限制存活的版本数。顺序固定且不可配置 —— 反过来的话,一个即将被排除的包会在离场路上白白占掉一个版本名额。

两条规则在每次 add、每次 rm 和每次 build 时都强制执行。最后这条很关键:在 sow.yml 里改 limit 或 exclude 会让受影响的 Dist 变 dirty,下一次 build 就把新策略重新施加到现有成员集上。想让收紧后的策略生效,你不需要重新 add 任何东西。

dists:
  el9:
    format: rpm
    limit: 1
    exclude:
      - kind: [debuginfo, debugsource, llvmjit]

exclude

exclude 是一个规则列表。同一条规则内,各字段之间是 AND;同一字段内,多个 pattern 之间是 OR;规则与规则之间是 OR —— 任一规则命中即排除。字段顺序和规则顺序都不影响结果。

exclude:
  - kind: [debuginfo, debugsource, dbgsym, dbg, llvmjit]
  - name: ["test-*", "*-experimental"]
    arch: [aarch64]

这段读作:不分架构地丢掉所有 debug 类包,并且 丢掉名字以 test- 开头或以 -experimental 结尾的 aarch64 包。

允许五个字段:

pattern 是区分大小写的精确字符串或 shell glob(*、?、[])。没有正则,没有版本比较,没有取反,也没有表达式语言。未知字段、空规则和非法 glob 会在 config check 时失败,而不是静默地什么都匹配不到。但取值不会按 kind 枚举校验:枚举之外的 kind(例如 debug)能通过校验,却什么都不匹配。

kind 由二进制包名推导,优先取最具体的后缀:

分类结果只来自包本身,不依赖文件所在目录,也不依赖当前主机,所以同一份输入永远分到同一类。sow show --json 会输出算出来的 kind。

被排除的包会被如实报告,不算解析失败,也不会被存下来:

$ sow add pkg/blackbox_exporter-0.28.0-1.x86_64.rpm pkg/pev2-1.23.0-1.noarch.rpm -r demo -d el9
add repository=demo operation=7877233225745514469 accepted=1 failed=0 memberships=+1/-0 revision=3 generation=3 dirty=false
item input="pkg/blackbox_exporter-0.28.0-1.x86_64.rpm" status=excluded format=rpm coordinate="blackbox_exporter-0:0.28.0-1.x86_64" sha256:5759c643… dists=el9:excluded
item input="pkg/pev2-1.23.0-1.noarch.rpm" status=accepted format=rpm coordinate="pev2-0:1.23.0-1.noarch" sha256:d06d7f23… dists=el9:accepted

命令退出码是 0。被排除的包本身没有任何问题,它只是不属于这个 Dist。如果一个包没有被任何 Dist 接受,就不会为它写下无主的 pool 对象。

limit

limit 按 (二进制包名, 原生架构) 分组,保留最新的 N 个:

• 0 —— 保留全部版本,这是默认值。
• 正整数 N —— 按原生版本序保留最新的 N 个。
• 负数 —— 配置错误。

有两个细节能回答现实中的绝大多数疑问。

分组键包含架构。 limit: 1 不是"这个 Dist 里这个包只留一个版本”,而是"每个包名 + 每个原生架构留一个版本”。所以 pg_sample-1.13(x86_64)与 pg_sample-1.17(noarch)可以同时存在于 limit: 1 的 Dist 里,因为它们属于不同分组。中性包(noarch/all)作为自己的原生架构只计一次,尽管它会渲染进多个视图。

排序用格式的原生规则。 RPM 用 EVR 比较 —— epoch、version、release,遵循标准 rpm 分段规则。DEB 用 Debian version 比较,版本串本身已经包含 epoch 与 revision。SOW 不发明版本方案,也不做字典序比较。

下面是 limit: 1 在同名同架构的两个 Debian 版本之间做决定:

$ sow add pkg/libpq5_18.4-1.bookworm_amd64.deb pkg/libpq5_18.4-1.trixie_amd64.deb -r demo -d trixielim
add repository=demo operation=2402398619981505515 accepted=1 failed=0 memberships=+1/-0 revision=4 generation=4 dirty=false
item input="pkg/libpq5_18.4-1.bookworm_amd64.deb" status=excluded format=deb coordinate="libpq5=3:18.4-1.bookworm:amd64" sha256:be8a2863… dists=trixielim:limited
item input="pkg/libpq5_18.4-1.trixie_amd64.deb" status=accepted format=deb coordinate="libpq5=3:18.4-1.trixie:amd64" sha256:0a7df397… dists=trixielim:accepted

注意这里有两级报告:条目的整体 status 是 excluded(它最终没在任何地方成为成员),而逐 Dist 的结果是 limited —— 告诉你它是输在版本上,不是被某条 exclude 规则命中。当你同时选中多个 Dist 时,每个 Dist 各报各的结果,所以一条命令里同一个包完全可能在一个 Dist 是 accepted、在另一个是 limited。

limit 移除旧成员、加入新成员发生在同一个 Operation 内,所以账本上看到的是一次原子决策,而不是一次删除加一次不相干的插入。

策略作用于完整候选集

一个常见误读是:add 只对命令行上的包施加策略。并非如此。把你的输入合并进目标成员集之后,SOW 会对每个选中 Dist 的 完整 成员集执行 exclude,再执行 limit。

现实后果是:往一个已经装着版本 1 和版本 2 的 limit: 2 Dist 里加版本 3,会在同一个操作里移除版本 1。你没法靠"分开单独 add"绕过版本上限,也不会因为"只拿增量与上限比"而落得 N+1 个成员。

放宽策略永远不会复活任何东西

这条语义最常被误以为是反过来的,所以值得直接演示。接着上面 limit: 1 的例子,把胜出的那个版本删掉:

$ sow rm 'deb:libpq5=3:18.4-1.trixie:amd64' -r demo -d trixielim
$ sow ls -d trixielim
repository=demo dists=trixielim dirty=false
SHA256	COORDINATE	DISTS	BUILT_DISTS	POOL_PATH

Dist 空了。bookworm 那个构建没有回来 —— 尽管它的字节还躺在 pool 里,尽管 limit: 1 此刻明明空出了一个名额。

原因在于 exclude 与 limit 移除的是 真实的期望成员。SOW 不维护一份"被策略压下、将来也许还能回来的候选"影子清单。Pool 字节是存储,不是候选集。因此提高 limit 或放宽 exclude 只是给未来的添加腾出空间;它不会回头翻历史,猜哪些你曾经拥有过的包该重新出现。

想让它回来,就再显式 add 一次:

$ sow add pkg/libpq5_18.4-1.bookworm_amd64.deb -r demo -d trixielim
add repository=demo operation=590501245267266669 accepted=1 failed=0 memberships=+1/-0 revision=6 generation=6 dirty=false
item input="pkg/libpq5_18.4-1.bookworm_amd64.deb" status=accepted format=deb coordinate="libpq5=3:18.4-1.bookworm:amd64" sha256:be8a2863… dists=trixielim:accepted

收敛是单向的,而且这是写进不变式的:收紧策略可以移除成员,放宽策略永远不会恢复成员。 正是这种不对称让 build 在任何时刻都能安全执行。假如它是对称的,那么编辑 sow.yml 就可能静默地重新发布一个你刻意下架的包 —— 而这恰恰是安全更新场景里最不能出的事故。

预览一次决策

sow rm -c 计算将要移除的成员、策略后果,以及此刻 build 会产生的文件变化,但什么都不写:

sow rm patroni -r pgsql -d el9 -c

-c/--check 不取写锁,并且与 --skip 互斥。同时给出 --timeout 或 --no-wait 属于用法错误 —— 免得有人误以为一次预览会去等待写事务。

继续阅读

• sow.yml 配置参考 —— 完整策略 schema
• sow add 参考 —— 逐条目状态与部分成功退出码
• 包池与架构视图 —— 存活下来的成员被渲染到哪里
• sow retain 与 sow gc —— 包体生命周期控制

3.5 - 签名模型

客户端会对一个仓库提两个不同的问题,SOW 用两套彼此独立的机制分别回答。把它们混为一谈,是"我明明签了名,dnf 还是报错"这类问题最常见的来源 —— 所以本页先把两者拆开。

两条独立的信任链

二者分别配置、可分别使用。通常正确的起点是只做元数据签名:它在一个地方为整份索引背书,而且完全不需要改动你从上游拿到的那些包。

Managed 的元数据签名完全由 sow.yml 控制。没有 CLI 覆盖开关,build 上没有 --sign 参数,也没有办法让这次构建和下次构建签得不一样。这是刻意的 —— 仓库的签名身份是仓库的属性,不是"碰巧更新了它的那条命令"的属性。

配置

repos:
  pigsty:
    signing:
      rpm:
        packages:
          mode: never              # never | fill | always
        metadata:
          key: "file:///secure/repo-signing.asc"
      deb:
        metadata:
          key: "file:///secure/repo-signing.asc"

RPM 与 DEB 的元数据密钥分开声明,所以你可以像上面这样两边共用同一把钥匙,也可以拆开用。每个 metadata 块除 key 外还接受可选的 passphrase 引用。

配了元数据密钥之后,每次构建都会产出签名文件 —— 空 Dist 也不例外:

• RPM,每个架构视图:repodata/repomd.xml 加一份 ASCII-armored 的 repodata/repomd.xml.asc
• DEB,每个 Dist:Release 加一份 clearsigned 的 InRelease 与一份分离式 armored 的 Release.gpg

InRelease 的 clearsign 正文与 Release 完全一致。没有配元数据密钥时,这两个签名文件根本不会生成 —— 你只会得到 repomd.xml 和 Release。

0.5.0 暂不支持 RPM v6 包格式的签名；包体签名与验签工作流请使用 RPM v4 格式包。 这是 RPM 容器格式的限制，不限制下面的元数据密钥引用形态。

四种密钥引用形态

密钥引用是一个 URI,scheme 决定由谁来签:

file:// 与 env:// 不需要装任何东西 —— SOW 自己签元数据,这也是为什么用 file:// 元数据密钥的仓库在 macOS 和最小化容器里能构建出一致的结果。agent:// 把签名委托给你的 GPG agent,适合私钥在智能卡上、或绝不能落盘的场景。agent:// 不能与 passphrase 引用同时使用,因为那次交互归 agent 管。

passphrase 引用接受相对 Workspace Root 的路径、file:// 或 env://，不接受 agent://。

任何秘密都不会被持久化。 配置、SQLite、日志、JSON 输出和错误文本里,只有引用字符串、fingerprint 和公钥验证证书。config show --all 打印引用与 fingerprint,绝不打印密钥材料。如果某个密钥引用无法解析或不可用于签名,config check 会在你执行 build 之前就告诉你。

Agent 元数据签名按身份与确定性发布时间探签一次小消息，检查 GPG 实际选中的子钥，再固定 完整指纹完成签名，因此支持一台机器只持有证书中部分签名子钥的部署。GPG 时钟被冻结， 同一操作的多个 Dist 复用选钥结果。新构建要求实际签名钥匙在发布时间和当前时间都有效； 历史验签及已冻结树的恢复继续使用留存证书与原字节。

新 APT 元数据使用 SHA-256 签名。创建新的发布尝试时，InRelease 与 Release.gpg 都必须使用 SHA-256、SHA-384 或 SHA-512。历史 SHA-1 签名仍可验证；升级后执行 sow build 刷新旧 APT 元数据，再开始新发布。已经冻结的发布尝试仍按原计划恢复。

RPM 包体签名

signing:
  rpm:
    packages:
      mode: fill
      key: agent://7F721C4AD40F4A9D8CA578BFAC7E4690B50CCF3B
      trusted_keys: [keys/pgdg.asc]

三种模式:

trusted_keys 自动包含配置 key 的公钥部分。没有 key 时只能用 never;有 key 时默认 fill。

信任环彼此独立验证

对于带签名 RPM，SOW 会分别评估每个 Retained 单 Key Ring、当前 Policy Ring 与组合 trusted_keys Ring。所有可识别 OpenPGP Signature Packet 必须在同一个候选 Ring 内验证通过， 且至少一条通过的路径必须认证 Payload。SOW 绝不会把一个 Key 接受的 Packet 与另一个单 Key Ring 接受的 Packet 拼在一起，虚构出 Retained Signer。

这条区别在有意双签过渡时尤其重要：组合 Trusted Ring 可以接受该包，但任一单独 Retained Key 都不能宣称自己独立证明了它。历史 CentOS OpenPGP v3/v4 签名继续受支持。所有候选 Ring 共享 同一遍 Signed-byte Stream，因此增加 Trusted Key 只改变授权结论，不会放大包体读取。

包体签名总是对私有 staged 副本调用环境中的 rpm --addsign 或 rpm --resign，不会就地 修改输入文件。签完后 SOW 会重新解析结果，要求嵌入签名存在、signature-neutral digest 与 NEVRA 不变，并且签名身份与配置完全一致。fill 与 always 必须有 rpm、gpg，且匹配私钥 必须存在于 rpm 使用的 GPG 环境中。key 引用用于标识并验证签名者，不会把私钥自动导入该环境。

由于签名里嵌入了时间戳，同一个未签名 RPM 签两次会得到不同字节。SOW 对不可变的 header 与 payload（排除签名头）计算 signature-neutral payload digest。逻辑坐标与该摘要相同， 且既有对象满足当前策略时，才复用最终字节。重复 add 只有在满足复用条件时才是空操作；策略 变化导致重签时，可能产生不同字节并触发包池路径冲突。此时应使用新的包版本和文件名，不能 覆盖已经发布的 URL。

同一命令内，渲染复用 RPM 签名预检结果；跨命令时，未变化的包字节与完全一致的签名策略可 复用已认证的 Built 证据。策略、证书、文件指纹变化或证据缺失时重新验证。认证契约升级后， 首次构建会建立一次证据；sow check 仍是显式全量审计。常规目录/stat 检查与元数据生成仍然 需要与所选仓库范围对应的工作量。

这种复用的口子刻意开得很窄。never 模式要求完整字节一致,因为该模式承诺保留输入字节。如果 payload digest 不同,或既有对象不满足当前签名策略,那就是硬冲突 —— add 不会悄悄地在既有坐标上就地重签一个包。这里没有 --replace;如果重签导致字节变化,请提高 release,或专门规划一次密钥轮换流程。

更换密钥会让 Dist 变 dirty

一个 Dist 的 Built 配置摘要覆盖它的 format、canonical 架构、limit、exclude,以及 已冻结的签名身份。改动密钥引用或 fingerprint 会改变这个摘要,于是所有受影响的 Dist 变 dirty:

$ sow status
repository=pigsty status=dirty ready_to_copy=false revision=5 generation=4 dirty_dists=el9,trixie pending=0/0 locked=false

更换 元数据 key 后，sow build 会用新身份签署索引并产生新 Generation。

RPM 包体是不可变 Package Object；build 不会在同一坐标下静默重签既有对象。如果当前 Desired RPM 不满足新的包签名策略，build 会拒绝。分阶段轮换通常使用 fill：将新 key 设为当前 key， 同时把旧公钥保留在 trusted_keys；旧 key 软件包保持字节不变，新加入的软件包使用新 key。 只有当旧坐标已下架或被新 Release 替代后，才移除旧信任。直接切到新 key 的 always，要求 每个 Desired RPM 已经由新 key 签名。

当前 Built 元数据的精确公钥证书身份按 Dist 记录,同一 primary fingerprint 的多个证书版本可以共存 —— 所以延长有效期或增加子钥,不会让已经发布出去的东西失效。

fill 或 always 模式下的包签名信任更严格。增加或轮换签名子钥不会影响已有包签名；但延长主钥 有效期并重新导出后会产生更新的自签名，SOW 0.5.0 随即拒绝在该自签名之前签署的包，而且 trusted_keys 不能同时容纳同一证书的两个版本。用于包签名时，建议主钥不设过期时间，改为轮换 签名子钥。

Plain 模式

sow create /srv/repo --sign-with 6D5C5A26C36B1F73
sow create /srv/repo --sign-with 6D5C5A26C36B1F73 --overwrite

Plain 模式只签 RPM 包体,没有元数据签名。KEY 去掉可选的 0x 或 0X 前缀后，必须是恰好 16、40 或 64 位十六进制 GPG key ID/fingerprint；去掉前缀并规范化为大写后作为 _gpg_name macro 传给 rpm。不带 --overwrite 时只签没有可解析嵌入签名的 RPM;带上则对全部保留的 RPM 重签。

--sign-with 要求 --pigsty 清理后至少保留一个顶层 RPM。纯 DEB 目录、缺少 rpm 可执行文件、密钥不可用,都在任何公开变更之前失败。签名是显式慢路径，必然包含复制、签名验证与最终 RPM 解析读取；中断后按当前包目录重跑，而不是重放 Plain journal。见 Plain 平面仓库。

客户端验证什么

[pigsty-el9]
name=Pigsty EL9
baseurl=https://repo.example.com/pigsty/dists/el9/$basearch/
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://repo.example.com/keys/repo-signing.asc

Types: deb
URIs: https://repo.example.com/pigsty
Suites: trixie
Components: main
Signed-By: /etc/apt/keyrings/repo-signing.asc

repo_gpgcheck=1 让 dnf 验证 repomd.xml.asc；gpgcheck=1 让它验证每个包的嵌入签名。 APT 侧的 Signed-By 让 apt 验证 InRelease。自动化检查会直接校验生成的签名；完整的签名 Managed dnf/APT 验收必须在目标环境中使用真实客户端执行。确切证据见 平台与集成。

sow check 在常规运行中就会校验全部已声明的签名与文件哈希,所以签名配置出错会在发货之前暴露,而不是在客户机器上暴露。

继续阅读

• 仓库签名 —— 生成专用密钥并把两条链都接起来
• sow.yml 配置参考 —— 完整签名 schema 与密钥引用文法
• 可观测与审计 —— check 如何证明这些签名

3.6 - 事务与恢复

本页说明 Managed 模式如何防止 live 指针指向缺失内容，以及如何协调 SQLite 状态与文件系统变更。

不变式

在受支持的本地 POSIX 文件系统上，沿 Managed 协议指针读取的客户端只会得到完整旧视图或 完整新视图，包括进程中断之后。

下面所有内容都是为了守住这条线:元数据在任何公开变更之前完整 stage 并校验,指针切换就是提交决策,每个操作都留下足够的持久证据,让下一条命令能把它做完或撤销,而不需要猜。

Plain sow create 刻意不属于这套事务模型。它以包目录为权威事实、把元数据视为可丢弃投影：一遍内容 扫描、一次最终 stat 校验，然后覆盖发布。中断后重新运行 sow create，而不是重放 journal。详见 Plain 平面仓库。

也要注意它 没有 声称什么。dirty 不是指索引写了一半；它表示 Desired 状态领先于 Built Generation，而旧的 Built View 仍然完整。SOW 也不承诺两个不同 Dist 在同一瞬间翻代； 它承诺每个协议视图始终自洽，且写命令返回时，本次 Operation 包含的每个 Dist 都处于记录的 Built Generation。

两类持久日志

Managed 仓库生命周期与变更使用两类持久化载体，各自作用域很窄：

这个划分不是随意的。工作区生命周期操作发生在目标仓库数据库尚不存在、或即将被删除的时候，因此不能用它；仓库变更有可用数据库，就用数据库。Plain 两者都没有，因为它的恢复单元是按包重新构建。

Workspace journal 保存操作类型、随机 64 位十六进制 id、仓库名,以及新旧 sow.yml 的原始字节与各自 SHA-256。工作区锁保证同时只有一条 active operation。sow.yml 的原子 rename 就是提交决策:如果当前 config 仍然哈希为旧值,就清理 planned journal 并回滚;如果哈希为新值,就幂等地补齐仓库外壳,或把自有对象移入 recovery。两边都不匹配则拒绝猜测。

Repository 操作日志 在任何公开文件副作用 之前 先向 SQLite 提交一条 planned Operation,随后记录每次状态迁移。它的 payload 绑定仓库、config SHA-256、精确的选中 Dist 集合、精确的 build_dists、--skip 决策,以及一个 manifest 哈希 —— 后者覆盖新对象事实、完整期望集、逐 Dist 策略结果、RPM 公钥证书快照与目标 Generation。

这不是 SQLite 的 WAL。WAL 负责 SQLite 自己的页面事务,它无法原子地协调 pool、staging 区与 dists/。跨数据库记录与 POSIX 文件动作的,是这套应用级操作日志。

操作生命周期

planned → staged → applied → built → done
                       └──────────────→ done_dirty
   任一非终态 → recovering → built / done / done_dirty / rolled_back / failed
   apply 前出错 → failed

sow log <OPERATION> 展示带时间戳的状态迁移:

"events":[
  {"sequence":0,"state":"planned","occurred_at":"2026-08-04T04:06:32.907704Z"},
  {"sequence":1,"state":"staged","occurred_at":"2026-08-04T04:06:33.067824Z"},
  {"sequence":2,"state":"applied","occurred_at":"2026-08-04T04:06:33.253073Z"},
  {"sequence":3,"state":"built","occurred_at":"2026-08-04T04:06:34.074916Z"},
  {"sequence":4,"state":"done","occurred_at":"2026-08-04T04:06:34.077441Z"}
]

--skip 使 Desired 领先于 Built 时以 done_dirty 收尾；若之后仓库仍是干净的（例如重复加入 已有成员），则以 done 收尾。恢复旧操作时还有一个有限出口：Desired 已提交、构建计划尚未冻结， 且原构建被以下之一阻止：可识别的签名策略拒绝、渲染开始后 sow.yml 的字节发生任何变化（哪怕 只改注释），或已知契约升级。SOW 校验已提交状态与包字节， 保留 Desired 和旧 Built 视图，并记录暂未构建的原因；必要时修正策略，再重跑 build。 普通 I/O、损坏或已冻结构建失败仍是恢复错误，不会被静默改为 done_dirty。

在 applied 之前失败的 Operation 会成为 failed。这里有一处契约上的微妙之处:add 必须在解析包之前先记录 planned Operation,所以一个架构不被许可的包确实会留下审计记录。但除了那条终态 failed 记录之外,什么都不会被写入 —— 没有包对象、没有成员关系、没有 pending 字节、没有公开树变化、没有 Generation。既留住了审计线索,又保证无效架构不会进入任何产品投影。

如果 Ctrl-C 在 applied 之前中断操作，SOW 先记录 failed，再在 5 秒预算内删除该操作的临时 包字节；剩余部分由下一条写命令（例如 sow build）删除，在此之前 sow check 报告 recovering。

锁模型

锁是本机的 POSIX advisory flock。产品契约是单机、单写、本地 POSIX、协作式锁 —— 网络文件系统既不检测也不支持。

两把都需要时,顺序固定:先工作区,后仓库,释放顺序相反。仓库锁的 inode 位于稳定路径,绝不随私有状态目录移动 —— 这样删除仓库时可以在别的进程还持有旧描述符的情况下撤下锁路径,而不会有第二个写者在新 inode 上形成。

sow create 同时锁住目标目录 和 它稳定的父目录。父目录锁的作用是:阻止另一个协作写者用 rename 把目录整个换掉,再对替身取得一把独立的锁。

只读命令从不取写锁,也不接受锁参数。其中需要组合读取配置、SQLite 与 live 元数据的那几个(config check、repo ls/show、dist ls/show)会在整个快照期间持有共享锁。status 刻意更轻:它只探测仓库锁,以便在写入进行中报告 recovering 或 locked,而不会被它阻塞。

两个参数控制等待行为,适用于所有取写锁的命令:

两条失败路径都以 4 退出。--no-wait 与非零 --timeout 同时出现是用法错误,退出码 2。

$ sow add ./build/*.rpm -r pgsql -d el9 -N
lock unavailable

在"宁可跳过这轮、也不要堆积"的 cron 作业里用 -N;在"排一小会儿队可以、但绝不能挂死"的 CI 里用 -T 30s。

提交顺序

每一代都按同样的四个阶段写入,而顺序正是不变式成立的原因:

payload  →  metadata  →  pointer  →  delete

1. payload —— 规范包字节写入 pool/。此时还没有任何东西引用它们。
2. metadata —— checksum 命名的 RPM 元数据、Packages、Packages.gz,以及 by-hash 索引副本。此时仍没有指针指向它们。
3. pointer —— 客户端入口:RPM 的 repomd.xml(配置了签名则连同 .asc);Managed APT 则在每个架构的 direct 与 by-hash 索引都就位之后,才发布 Release(连同 InRelease 与 Release.gpg)。这一步就是提交。
4. delete —— 清理已过保留窗口的旧代元数据。

Pending 包体在单写者下分批提升，每次 group commit 最多 512 个对象或 1 GiB。SOW 先持久化 Pool 目录项，再删除 pending 名称；恢复因此能把 pending-only、指向同一 inode 的双链接或 Pool-only 状态重新绑定到 Operation，而不会冒同时丢失两个名称的风险。

正着读:包一定先于引用它的索引存在,索引一定先于指向它的指针存在。反着读:在一个不再引用某文件的指针耐久落地之前,那个文件不会被删。不存在任何一个窗口,让客户端沿活的指针走到一个不存在的文件。

这一切都通过与目标同文件系统的 staging 区完成,初始化时通过比较 st_dev 校验。挂载点或设备不同是明确失败,绝不降级为复制。文件先写入、fsync、由 SOW 自己的解析器与闭包校验器验证,之后才用原子 rename 换入。公开文件不继承你的 umask:repodata/ 是 0755,索引文件与指针是 0644。

sow changes 用于审计与交付规划，描述 Generation Delta；它不能替代发布协议。请使用 sow publish，或把完整树复制到离线 staging 后再原子切换上线。见 可观测与审计。

崩溃恢复

每条 Managed 写命令都先恢复,再做自己的事。 没有单独的修复命令,也没有守护进程盯着陈旧状态;恢复是变更的前置条件。只要存在非终态 Operation,下一条 add、rm、build、dist new/rm 或 log prune 就先把它做完或回滚,然后才继续。

全局恢复顺序是固定的:先在工作区锁下恢复工作区生命周期;如果那不是一次仓库删除,再按仓库名顺序、在各自稳定的仓库锁下恢复仓库 Operation。已经越过"删除仓库"提交决策的工作区操作具有支配权,并禁止任何嵌套的仓库恢复 —— 在一个正被删除的仓库内部恢复状态毫无意义。

恢复由证据驱动,不做乐观假设。每个阶段都有明确规则:

这套规则的验收方式是在多个不同时机向 sow add 发送 SIGKILL。每一次,status 都报告 recovering,下一条写命令都先恢复该 Operation 再执行自身,最终 check 全部层通过,公开树从未撕裂。

$ sow status
repository=pigsty status=recovering ready_to_copy=false ...

sow build 是唯一的显式前滚恢复入口:它在收敛之前,会先尝试完成或回滚任何可判定的非终态 Operation。看到 recovering 时,执行 sow build 就是标准反应。

error 专留给 journal、数据库与文件证据互相矛盾、任何自动选择都不安全的情况。此时 build 拒绝覆盖,最后完成的视图继续服务,你应当从备份恢复,再跑 check 与 build。这里刻意没有 repair --force —— 一个可能猜错的修复,比一个拒绝执行的修复更糟。

fail-closed 的路径安全

Managed 路径从不由用户提供的字符串拼装。每次创建、rename 和删除都走同一套流程:

1. 把工作区根解析为绝对真实路径;
2. 用固定相对片段重新构造目标,并验证相对路径不含任何逃逸分量;
3. 对路径上每个已存在的受控组件执行 Lstat,拒绝符号链接和非预期文件类型;
4. 只删除已经先被原子移入 .sow/.../recovery 的对象;
5. 删除前再次证明该 recovery 目标确实位于对应的私有状态目录内。

名称必须匹配 [a-z0-9][a-z0-9._-]*,.、..、.sow、pool、dists 及工作区保留名一律拒绝。

对文件句柄也是同样的姿态。SQLite 以 O_NOFOLLOW 打开并绑定普通文件 inode,连接建立后再按路径复核一次;数据库、WAL、shm 或 rollback journal 中任何一个是符号链接、非普通文件、有多个硬链接,或在打开期间被换绑,都会被拒绝。log export 拒绝覆盖已存在的文件,也拒绝父目录是符号链接的目标 —— 这就是为什么在 macOS 上往 /tmp 导出会失败:那里的 /tmp 本身是个符号链接。

各类 journal 都有大小上限:工作区 32 MiB、仓库 Operation payload 16 MiB,外置的 mutation manifest 与 base manifest 各 64 MiB。超限既不截断也不降级,而是在提交窗口之外直接失败 —— 这样写者永远不会产出一条"自己写得进去、恢复读者却永远读不回来"的 Operation 记录。

以上没有一条声称能抵御以同一用户身份运行、拥有无限权限的恶意进程。它抵御的是现实中的失败模式:崩溃、协作进程之间的竞态,以及在检查与使用之间形态发生变化的路径。

继续阅读

• 可观测与审计 —— 如何读取这些机制维护的状态
• 退出码 —— 4、5、6 分别意味着什么、什么时候会看到
• build、status、check 与 changes

3.7 - 可观测与审计

每个读取表面回答不同问题。

status：低成本状态

sow status -r local

它报告 Desired revision、Built Generation、dirty Dist、pending 包体计数、锁状态与 ready_to_copy。它不哈希公共树，不恢复操作，也不构建。

用 status 诊断，不要把它当成 check 的替代品。

check：交付证明

sow check -r local

稳态下，checker 按顺序报告九层：

未完成布局迁移使用更短的诊断表面：依次报告 config、state、public-modes 与 layout-transition，随后停止，并在诊断指定的维护操作完成或在 commit 前安全中止前返回不可交付。

check 不写入也不修复。dirty 或 recovering Repository 不可交付，即使上一份已提交树仍可读取。 在发布流水线中执行 check，任何非零退出都应停止。

每次 Check 都会对每个唯一物理包体执行一次权威 SHA-256，不会因缓存指纹匹配而省略；随后在 Retained Record、Index、Signature、最终 Generation Manifest 与 changes 之间共享基于描述符 的证据。带签名 RPM 只额外使用一遍所有 Signature Packet 与 Trust Ring 共用的签名流，不会随 Dist、Key 或 Retained Generation 数量放大。

changes：Generation 差异

sow changes -r local
sow changes 0 -r local
sow changes 42 -r local --json

• 不给 base：比较当前 Built Generation 与前一代；
• base 0：描述完整当前公共树；
• base N：给出已记录 Generation N 到当前 Built 的净差异。

每行包含操作、phase、Repository 相对路径、大小与 SHA-256。phase 使用与本地构建相同的 payload、metadata、pointer、delete 词汇。

changes 是 manifest/差异表面。它不连接目标、不持久化远端 checkpoint、不执行 cache grace， 也不恢复中断传输。配置好的 live target 应使用 sow publish TARGET。离线复制应先 stage 完整树、复验，再原子切换上线。

Generation 保留与 GC

sow retain add 42 -r local
sow retain ls -r local
sow retain rm 42 -r local
sow gc -r local

retain add 校验并冻结 Generation 的元数据与引用集合，不复制另一棵包体树。保留记录是显式 GC root。retain rm 移除该 root，本身不删除包字节。

本地 sow gc 只删除已证明不被当前状态、显式 retention、active recovery/publication 状态及 其他记录根引用的包体。Target GC 是另一项操作：sow gc TARGET 使用该 Provider 的安全模型。

普通构建会携带紧邻前一代的 RPM 不可变元数据与 APT by-hash object，让已读取旧指针的客户端 完成下载。这个有界协议窗口与显式 retain 是两回事。

操作日志

sow log -r local
sow log OPERATION -r local
sow log export operations.jsonl -r local
sow log prune 2026-01-01 -r local

日志按操作记录 kind/state、时间、配置/manifest identity、包处置、成员变化，以及适用时的 物理 changeset。

log export 输出稳定 JSONL，拒绝覆盖既有文件，并校验输出路径。log prune 接受日期或 RFC 3339 时间，只移除符合条件的终态审计记录；不会删除当前状态、恢复证据或仍被需要的 Generation manifest。

操作模式

sow build -r local
sow check -r local
sow publish public

status 用于监控，check 用于门禁，publish 用于目标变更，log 用于事后证据。

延伸阅读

• sow build 与 sow check
• Log 命令
• sow publish 与 sow gc

4 - 参考

这一部分记录配置字段、包引用、路径、退出码、JSON、平台与集成等稳定契约。CLI 语法和状态变化 见命令，使用模型见上手。

输出示例只说明形态；标识符、路径、哈希、时间戳与计数会随工作区变化。二进制自带的 sow help 始终是精确语法权威。

约定

命令示例不带 $ 提示符，方便整块复制。输出块只代表结构，可变值与长结构会在标注处省略。 二进制自带的 sow help 始终是精确语法权威。

语法块中占位符用大写(NAME、DIR、PACKAGE),字面量用小写。方括号表示可选参数, ... 表示可重复,竖线分隔互斥项 —— 与 sow help 的写法一致。

4.1 - sow.yml 配置参考

sow.yml 是 Managed 托管工作区(Workspace)唯一的配置文件。它位于工作区根目录, 声明存在哪些仓库(Repository)与 Dist,并保存每次构建都要执行的成员策略与签名设置。 Plain 平面模式(sow create)完全不读它。

本页列出解析器接受的每一个字段。没有列在这里的字段一律拒绝 —— 不存在未公开的 键,也没有为将来预留的键。

文件是怎么读的

SOW 用严格 YAML 解析器读取 sow.yml。具体表现是:

• 未知字段是错误,不是警告。 把 repos: 写成 repositories: 会直接失败(退出码 2), 并指出出问题的行号。
• 只允许一个 YAML 文档。 用 --- 引入第二个文档会报错。
• 只接受普通文件。 sow.yml 是符号链接,或者大于 16 MiB,在解析前就被拒绝。
• 默认值在解析时补齐,不写回磁盘。 想看完全展开后的形态,用 sow config show --all。

文件的一部分是机器维护的:sow init、sow repo new、sow repo rm、sow dist new、 sow dist rm 会作为各自事务的一部分原子改写 sow.yml。成员策略与签名则由你手工编辑 —— 没有对应的命令行参数。

任何手工修改之后,跑一次 sow config check。它解析文件、与每个已初始化仓库的 SQLite 状态交叉核对、并解析每一个签名 key 引用,全程只读:

sow config check

configuration valid: /srv/repo repositories=1 dists=2

根级字段

schema: sow/v3
architectures: [x86_64, aarch64]
repos:
  <name>: <repository>
targets:
  <name>: <publication-target>

schema 配置值必须恰好是 sow/v3。

architectures

这是 上限,不是目标。它声明 SOW 最多可以接纳哪些架构;各 Dist 默认继承整张表, 除非自己再收窄。

目前只支持两个规范族(canonical family):x86_64 与 aarch64。DEB 生态名作为输入别名 被接受,并在解析边界规范化:

所以 architectures: [amd64, arm64] 与 architectures: [x86_64, aarch64] 是同一份配置。 把同一族的两个别名都写上 —— [amd64, x86_64] —— 属于重复,会失败:

configuration error: load config "/srv/repo/sow.yml": workspace architectures: duplicate architecture "x86_64" after normalization

noarch(RPM)与 all(DEB)不是 这里的架构。它们是中性(neutral)包,构建时投影进 每个适用视图,解析器拒绝把它们写进这个列表。不支持的值(如 riscv64)立即失败:

configuration error: load config "/srv/repo/sow.yml": workspace architectures: unsupported architecture "riscv64"; supported canonical families are x86_64 and aarch64

这个列表可以整体省略,但不能写成空列表。

Repository 仓库

repos:
  pigsty:
    protected: true
    signing: { ... }
    dists: { ... }

protected

protected: true 是防止误删整个仓库的闸门,它只拦一件事 —— 仓库删除:

operation rejected: managed: operation rejected: repository "pigsty" is protected

这是退出码 6。其余一切照常:add、rm、build、建/删 Dist 都不受影响。 要真的删掉一个 protected 仓库,先把 sow.yml 改成 protected: false, 用 sow config check 确认,再执行 sow repo rm。

名称约束

仓库名与 Dist 名共用一套文法:必须匹配 [a-z0-9][a-z0-9._-]* —— 小写字母、数字、 点、下划线、连字符,且以字母或数字开头。大写被拒绝,因为名称会变成目录名, 必须在大小写敏感的 Linux 与默认大小写不敏感的 macOS 文件系统上表现一致:

configuration error: load config "/srv/repo/sow.yml": repository name "Infra": name "Infra" must match [a-z0-9][a-z0-9._-]*

下列名称是保留名,一律拒绝:.、..、.sow、pool、dists、sow.yml、 workspace.lock、workspace-ops、repo-locks。两个会在状态目录里撞车的仓库名 (比如 db 与 db.db)也会被拒绝:

configuration error: load config "/srv/repo/sow.yml": repository names "db" and "db.db" collide at reserved state path "db.db"

原因见仓库布局。

Dist

    dists:
      el9:
        format: rpm
        architectures: [x86_64]
        limit: 1
        exclude:
          - kind: [debuginfo, debugsource, llvmjit]

format

format 是 sow dist new 唯一从命令行接受的业务参数,并且创建之后不可更改 —— RPM Dist 永远不会变成 DEB Dist。格式不匹配的包根本不会成为该 Dist 的候选:

configuration error: load config "/srv/repo/sow.yml": repository "a" dist "d1" format must be rpm or deb, got "apk"

architectures

省略这个字段,Dist 继承工作区列表 —— 绝大多数情况下这就是你要的。 只有需要 收窄 时才声明:比如双架构工作区里,某个 el9 Dist 只做 x86。

列表必须是工作区列表的子集,且不能为空:

configuration error: load config "/srv/repo/sow.yml": repository "a" dist "d1" architecture "aarch64" is not allowed by workspace

在这里新增一个架构族会让该 Dist 变为待构建(dirty),下一次 sow build 渲染新视图。 移除一个仍被现有成员关系或已构建代引用的族,config check 与所有写命令都会拒绝。

limit

limit 限定该 Dist 中同一个包保留几个版本。分组键是 (二进制包名, 原生架构), 所以同一个包的 x86_64 与 aarch64 构建各自计数,noarch/all 包自成一组。

• 0(默认)保留全部版本。
• N > 0 保留最新的 N 个,RPM 按 EVR 比较,DEB 按 Debian version 规则比较。
• 负数是配置错误:

configuration error: load config "/srv/repo/sow.yml": repository "a" dist "d1" policy: limit must be zero or positive, got -1

limit: 1 时,把旧版本和新版本一起加入,旧版本会被报告为 limited 且不建立成员关系:

item input=".../libpq5_18.2-1.pgdg12+1_amd64.deb" status=excluded format=deb coordinate="libpq5=18.2-1.pgdg12+1:amd64" sha256:310611d0... dists=trixie:limited
item input=".../libpq5_18.3-1.pgdg12+1_amd64.deb" status=accepted format=deb coordinate="libpq5=18.3-1.pgdg12+1:amd64" sha256:4b526223... dists=trixie:accepted

事后调大 limit 不会 复活曾被策略移出的版本。包体字节可能还留在包池里, 但成员关系已经没了;要拿回来就重新 add 一次。理由见成员策略。

exclude

exclude 是规则列表。每条规则是若干字段的集合:规则内字段之间是 AND, 同一字段的多个 pattern 之间是 OR,规则与规则之间是 OR。任一规则命中即排除。

exclude:
  - kind: [debuginfo, debugsource, dbgsym, dbg, llvmjit]
  - name: ["test-*", "*-experimental"]
    arch: [aarch64]

读作:丢掉所有 debug 类包;另外,丢掉名字以 test- 开头或以 -experimental 结尾的 aarch64 包。

允许五个字段:

kind 由二进制包名的后缀决定,取最具体的一个。配置中枚举之外的 kind 能通过校验,但什么都不匹配:

pattern 区分大小写,只有两种形态:精确字符串,或使用 *、?、[...] 的 shell glob。 不支持正则、版本比较、否定,也没有表达式语法。空规则、空或带首尾空白的 pattern、 同一字段内重复的 pattern、非法 glob,都是配置错误:

configuration error: load config "/srv/repo/sow.yml": repository "a" dist "d1" policy: exclude rule 0 is empty
configuration error: load config "/srv/repo/sow.yml": repository "a" dist "d1" policy: exclude rule 0 field name has invalid glob "[bad": syntax error in pattern

策略顺序固定:先 exclude,后 limit。被排除的包逐条报告,不算失败:

item input=".../blackbox_exporter-0.28.0-1.x86_64.rpm" status=excluded format=rpm coordinate="blackbox_exporter-0:0.28.0-1.x86_64" sha256:5759c643... dists=el9:excluded

签名

签名配置挂在仓库级(不是 Dist 级),覆盖两条互相独立的信任链:软件包本身, 以及客户端在信任其他一切之前先验证的仓库元数据。

    signing:
      rpm:
        packages:
          mode: fill
          key: env://SOW_RPM_PACKAGE_KEY
          trusted_keys: [keys/pgdg.asc]
        metadata:
          key: keys/repo-signing.asc
          passphrase: env://SOW_METADATA_PASSPHRASE
      deb:
        metadata:
          key: keys/repo-signing.asc
          passphrase: env://SOW_METADATA_PASSPHRASE

树形是固定的:signing.rpm 下有 packages 与 metadata;signing.deb 下 只有 metadata —— DEB 包体永远不会被重签,因为 APT 通过 Release 验证整个仓库, 而不是逐包签名。

rpm.packages

三种模式:

• never —— 原样保存输入字节。包进来时带什么签名(或没有签名),客户端拿到的就是什么。
• fill —— 对没有签名、或签名无法被 key 及 trusted_keys 验证的包补签; 已经能验证通过的包保持字节不变。
• always —— 最终每个包都必须由 key 有效签名。已经由该 key 签好的保持字节, 其余一律重签。

有 key 时默认是 fill,因为它是唯一保留上游签名的模式。设成 fill 或 always 却不给 key 是错误:

configuration error: load config "/srv/repo/sow.yml": repository "a" signing: rpm packages mode "fill" requires key

trusted_keys 列出哪些公钥的签名被 fill 视为"已经合格"。key 的公钥部分自动受信, 不需要重复列出。同一个引用写两次是错误:

configuration error: load config "/srv/repo/sow.yml": repository "a" signing: duplicate rpm trusted key reference "keys/x.asc"

RPM 包签名是唯一会调用外部程序的操作:SOW 对 私有 stage 副本 调用环境里的 rpm --addsign / rpm --resign,永远不碰你的输入文件。私钥必须已经存在于 rpm 使用的 GPG 环境中。

rpm.metadata 与 deb.metadata

配置 rpm.metadata.key,每个 RPM 架构视图会额外发布分离签名 repodata/repomd.xml.asc;配置 deb.metadata.key,每个 DEB Dist 会额外发布 clearsign 的 InRelease 与分离的 Release.gpg。没配 key 就不生成这些文件 —— repomd.xml 与 Release 则始终会写。

file:// 与 env:// 引用由 SOW 在 进程内 完成签名,不需要 gpg 可执行文件。 只有 agent:// 需要环境里有 gpg。

改变 key 引用或它背后的 fingerprint 会让相关 Dist 变 dirty —— 签名身份是每个 Dist 已构建配置摘要的一部分。下一次 sow build 重新签名并推进新的代。

key 引用文法

key 引用是下列四种写法之一:

其他 scheme 一律拒绝:

configuration error: load config "/srv/repo/sow.yml": repository "a" signing: deb metadata key: unsupported key reference scheme in "https://example.com/key.asc"

引用分两阶段校验。文法 在解析时检查,失败退出码 2;引用 能否解析出真实密钥 由 sow config check 和每条写命令检查,失败退出码 6:

operation rejected: ... deb metadata key: key reference does not resolve to a bounded regular file
operation rejected: ... deb metadata key: environment key reference SOW_METADATA_KEY is unset
operation rejected: ... deb metadata key: gpg public-key export returned no bounded key material

私钥与口令不会输出。sow config show 不带 --all 也可解析并显示 key_fingerprint。 启用 RPM 包签名时，还会显示公钥证书快照摘要和规范化的受信任 key 身份；指纹数组与摘要 数组独立排序、去重，不能按下标配对。元数据签名条目示例如下：

    signing:
      deb:
        metadata:
          key: file:///srv/repo/keys/repo-signing.asc
          key_fingerprint: 7F721C4AD40F4A9D8CA578BFAC7E4690B50CCF3B

私钥与口令永远不会写进 sow.yml、SQLite、操作日志、JSON 输出或错误文本。

passphrase 引用

passphrase 接受与 key 引用相同的路径、file://、env:// 三种写法, 但 不接受 agent:// —— 口令是一个值,不是密钥句柄。

两条规则:

• 有 passphrase 没有 key 是错误,因为它没有可解锁的对象:

  configuration error: ... repository "a" signing: deb metadata passphrase requires key
  

• passphrase 与 agent:// key 同时出现是错误。私钥由 agent 持有并自行处理口令交互, 第二条口令通道只会被忽略:

  configuration error: ... repository "a" signing: rpm metadata agent key uses its ambient gpg-agent and cannot accept a passphrase reference
  

发布目标

每个目标把一个已配置 Repository 绑定到一个存储命名空间。目标名使用与仓库相同的小写文法。

targets:
  local:
    repository: pigsty
    provider: filesystem
    endpoint: file:///srv/mirror
    prefix: pigsty
    public_endpoint: file:///srv/mirror/pigsty/
    max_cache_ttl: 0s
    authoritative_workspace: true
    single_writer: true
    exclusive_write_authority: true

  prod:
    repository: pigsty
    provider: r2
    endpoint: https://0123456789abcdef.r2.cloudflarestorage.com
    region: auto
    bucket: packages
    prefix: pigsty
    credential: env://SOW_R2_CREDENTIAL
    public_endpoint: https://repo.example.com/pigsty/
    max_cache_ttl: 24h0m0s
    authoritative_workspace: true
    single_writer: true
    exclusive_write_authority: true

三个 authority 布尔值是显式安全确认,不是默认值。同一存储上的目标前缀不能重叠; filesystem 目标也不能解析到重叠的有效路径。这些规则防止并发写者破坏条件式发布与 GC。

对 provider: filesystem，配置校验只检查 URL 形态与重叠关系。真正发布时，endpoint 目录 必须已经存在、不能是 symlink，并且必须解析为唯一规范真实目录。SOW 会在 endpoint 下创建 配置的 prefix，但不会创建 endpoint 本身。

首次 publish 会持久绑定 Repository、Provider Storage Identity 与 Prefix。之后修改 Target Name、 public_endpoint 或 max_cache_ttl，必须通过 sow publish TARGET --rebind 得到操作者显式确认。 Provider、Storage Endpoint、Region、Bucket、Prefix 与 Repository Identity 均不能 rebind；应配置 新目标。每次接受的 rebind 都会追加不可变 Binding Revision。Pending Maintenance 会阻止 TTL 变化；Filesystem Conditional-delete Maintenance 还会阻止公共端点变化。

R2 凭据是私有引用。环境变量值或被引用文件必须包含一份严格 JSON 文档，不能写路径或 Shell 赋值：

{"access_key_id":"R2_ACCESS_KEY_ID","secret_access_key":"R2_SECRET_ACCESS_KEY"}

临时凭据可以增加可选的 "session_token":"..."。未知字段、尾随内容、缺少 Access/Secret， 以及超过 64 KiB 的文档都会被拒绝。file:// 凭据必须是普通文件；指向普通文件的符号链接（例如 挂载的 Kubernetes Secret）可以使用，FIFO、设备与目录会被立即拒绝而不会阻塞。config show、JSON 输出与公共树不会包含凭据材料。

完整示例

一个工作区,两个仓库:一个受保护的生产仓库(两条元数据签名链 + RPM 补签), 一个不签名、不过滤的临时仓库。

# sow.yml —— 工作区根配置
schema: sow/v3

# 本工作区允许管理的 CPU 架构族。这是上限,不是目标。
# amd64/arm64 作为输入别名被接受,规范化为 x86_64/aarch64。
architectures: [x86_64, aarch64]

repos:

  # 生产仓库。要删除它必须先改这个文件。
  pigsty:
    protected: true

    signing:
      rpm:
        packages:
          # 对无签名或签名不受信的 RPM 补签;
          # 已由受信 key 签好的包保持字节不变。
          mode: fill
          key: keys/package-signing.asc
          trusted_keys:
            - keys/pgdg.asc        # 上游 PGDG 的签名原样认可
        metadata:
          # 每个 repomd.xml 旁边额外发布 repodata/repomd.xml.asc
          key: keys/repo-signing.asc
          passphrase: env://SOW_METADATA_PASSPHRASE
      deb:
        metadata:
          # 每个 Release 旁边额外发布 InRelease 与 Release.gpg
          key: keys/repo-signing.asc
          passphrase: env://SOW_METADATA_PASSPHRASE

    dists:

      # 稳定 EL9 通道:每个包只留一个版本,不要 debug 产物
      el9:
        format: rpm
        limit: 1
        exclude:
          - kind: [debuginfo, debugsource, llvmjit]

      # Beta 通道:同样的包,保留全部版本以便回滚
      el9-beta:
        format: rpm
        limit: 0
        exclude:
          - kind: [debuginfo, debugsource, llvmjit]

      # Debian trixie,只做 x86,保留最新版本
      trixie:
        format: deb
        architectures: [x86_64]
        limit: 1
        exclude:
          - kind: [dbgsym, dbg]
          - name: ["*-experimental"]

  # 临时仓库:不签名、不过滤、可随时删除
  sandbox:
    dists:
      el9:
        format: rpm
      trixie:
        format: deb

targets:
  prod:
    repository: pigsty
    provider: r2
    endpoint: https://0123456789abcdef.r2.cloudflarestorage.com
    region: auto
    bucket: packages
    prefix: pigsty
    credential: env://SOW_R2_CREDENTIAL
    public_endpoint: https://repo.example.com/pigsty/
    max_cache_ttl: 24h0m0s
    authoritative_workspace: true
    single_writer: true
    exclusive_write_authority: true

用之前先验证:

sow config check
sow config show --all

sow.yml 里没有什么

有些你可能以为能配的东西,是 有意 不做成配置项的:

• 仓库路径。 仓库永远位于 <workspace>/<name>,没有 path: 字段。 见仓库布局。
• APT component。 固定为 main;YUM 没有 component 概念。
• 架构视图。 由 architectures 与包头共同推导,不能逐包声明。
• 内联秘密。 目标只接受 credential 引用;key 与 passphrase 材料同样留在引用背后。
• 自动保留数量。 保留是显式 sow retain add/rm 操作,不是配置中的滚动计数。

延伸阅读

• sow config —— 读取本文件的命令
• 成员策略 —— exclude 与 limit 随时间演化的行为
• 签名模型 —— 两条信任链的详细解释
• publish、retain、gc 与 export —— 交付生命周期命令
• 退出码 —— 这里的 2 与 6 分别意味着什么

4.2 - 包引用

sow rm、sow show、sow where 都接受一个 PACKAGE 参数。本页定义你能在那里写什么。 三条命令共用同一套文法,只有对 歧义名称 的处理不同。

这里的内容与 sow add 无关 —— add 接受的是文件系统路径,不是包引用。

五种形态

前三种是 精确 引用:指名道姓,要么命中要么失败。后两种是便利写法,可能匹配多个对象。

你不需要手工拼这些字符串。sow ls 会直接打印每个包的摘要与坐标,可以原样粘回命令行: