diff --git a/README.md b/README.md index dfeb5c55..a78c8417 100644 --- a/README.md +++ b/README.md @@ -145,6 +145,7 @@ hugo server -D # 含草稿 | `send_mail.js` | 构建结果邮件通知（零依赖 SMTP） | **CI** | | `fetch_snapshots.sh` | 构建期拉 conf/友链/友圈快照 → `data/` | **CI** | | `setup-cnb-remotes.sh` | 重建 git 远端（CNB 主仓 + Gitea 辅仓；顺手清退役远端） | 本机 | +| `pushall.sh` | `git pushall` 的实现：**先 `fetch`+`rebase` 再推** CNB 与 Gitea。为何必须 rebase —— 线上后台发文章会直接推 `main`，本机不先同步必被 rejected | 本机 | | `backup-run.mjs` | 备份推荐入口：跑 `backup-bundle` + **失败时发告警邮件** | 本机/计划任务 | | `backup-bundle.mjs` | `git fetch --all` → 整仓 bundle → AES-256-GCM 加密 → WebDAV 传 F50 | 本机/计划任务 | | `backup-task.cmd` | 上面的计划任务入口（每天 03:30；**内容必须全 ASCII**） | 计划任务 | diff --git a/blog-admin/tools/certkeeper-config.mjs b/blog-admin/tools/certkeeper-config.mjs index 8885f637..ed3155ce 100644 --- a/blog-admin/tools/certkeeper-config.mjs +++ b/blog-admin/tools/certkeeper-config.mjs @@ -32,6 +32,20 @@ export const CONFIG = { 'wifi.usj.cc', 'openwrt.usj.cc', 'vw.usj.cc', // vaultwarden（alias 才是这个名字） + // ★★ 不要在这里加 writeapi.usj.cc —— 它**不是 1Panel 站点** + // （2026-10-06 实测：面板上共 11 个网站，没有它；它连面板都没有， + // nginx 配置是手工放在 /www/conf.d/writeapi.usj.cc.conf 的）。 + // 加进来会让**每次续期**都报「1Panel 里找不到网站「writeapi.usj.cc」」—— + // 只警告不中断，所以很容易长期没人发现。 + // + // 它是**手工 vhost**，证书靠**软链接跟随这里第一个站点**获取： + // ln -sfn ../../artalk.usj.cc/ssl/fullchain.pem \ + // /1panel/1panel/www/sites/writeapi.usj.cc/ssl/fullchain.pem + // ln -sfn ../../artalk.usj.cc/ssl/privkey.pem \ + // /1panel/1panel/www/sites/writeapi.usj.cc/ssl/privkey.pem + // ⚠️ 必须是**相对路径**：宿主是 /1panel/1panel/www/…，容器内是 /www/…， + // 写绝对路径会在容器里断链（nginx 重启后 HTTPS 直接挂）。 + // 机制与排错见 docs/证书管家.md「手工 vhost 的证书」一节。 ], // ★ 源站直连探针：usj.cc 走多吉云 CDN，公网握手拿到的是 CDN 边缘证书； // 要续的是本机 1Panel 上那张。面板里没有 usj.cc 同名站点， diff --git a/deploy/cn-certkeeper/src/dump-cert.mjs b/deploy/cn-certkeeper/src/dump-cert.mjs new file mode 100644 index 00000000..c73024e3 --- /dev/null +++ b/deploy/cn-certkeeper/src/dump-cert.mjs @@ -0,0 +1,61 @@ +/** + * 把 KV 里**已签好**的证书导出成明文 PEM 文件（运维工具，不联网、不改任何线上状态）。 + * + * 为什么需要它（2026-10-06 加）： + * 证书管家把证书存在数据目录的 KV 里（AES-GCM 加密），而**手工 vhost** 用的是 + * 磁盘上的 .pem 文件。两者之间原先没有任何桥 —— 手工 vhost 的证书只能靠人 + * 上传，续期自然覆盖不到（writeapi.usj.cc 就是这么停在旧证书上的）。 + * 这个脚本负责「把锁在 KV 里的证书取出来」，取出来之后往哪儿放由调用方决定 + * （通常配合 1Panel 的 /files/save 或直接 cp）。 + * + * ★ 只读：不签发、不部署、不改 KV。 + * ★ 输出含**明文私钥**，写到 /data/tmp/ 下（容器内路径，宿主对应 + * <数据目录>/tmp/）。用完请删除，不要进任何备份或日志。 + * + * 用法（在容器内跑）： + * docker exec cn-certkeeper node /data/tmp/dump-cert.mjs usj.cc + * 需要把脚本先放进数据目录（宿主 <数据目录>/tmp/ 与容器 /data/tmp/ 是同一处）： + * cp deploy/cn-certkeeper/src/dump-cert.mjs /srv/cn-certkeeper/data/tmp/ + */ +import fs from 'node:fs'; +import path from 'node:path'; +import { createRequire } from 'node:module'; + +const require = createRequire(import.meta.url); +const lib = (n) => require('/app/lib/' + n + '.js'); +const { FileKV } = await import('/app/src/kv-file.mjs'); + +const name = process.argv.find((a) => !a.startsWith('--')); +if (!name) { + console.error('用法：node dump-cert.mjs <域名> （容器内路径建议 /data/tmp/dump-cert.mjs）'); + process.exit(2); +} + +const dataDir = process.env.DATA_DIR || '/data'; +const kv = new FileKV(dataDir); +const env = { + RSS_KV: kv, + TOKEN_SECRET: String(process.env.TOKEN_SECRET || '').trim(), + EDITOR_API_BASE: '', + EDITOR_TOKEN: '', +}; + +const { getCert } = lib('certstore'); +const rec = await getCert(env, name); +if (!rec?.cert || !rec?.key) { + console.error(`KV 里没有「${name}」的证书内容（先跑一次签发）`); + process.exit(2); +} + +const outDir = path.join(dataDir, 'tmp'); +fs.mkdirSync(outDir, { recursive: true }); +const certPath = path.join(outDir, `${name}.fullchain.pem`); +const keyPath = path.join(outDir, `${name}.privkey.pem`); +fs.writeFileSync(certPath, rec.cert); +fs.writeFileSync(keyPath, rec.key, { mode: 0o600 }); + +console.log(`域名 ${name}：证书到期 ${new Date(rec.expireAt).toISOString()}` + + `（${Math.round((rec.expireAt - Date.now()) / 86400000)} 天）`); +console.log('已写出（★ 含明文私钥，用完请删）：'); +console.log(' ' + certPath); +console.log(' ' + keyPath); diff --git a/docs/架构精简候选.md b/docs/架构精简候选.md index d1651eb3..636a4f9d 100644 --- a/docs/架构精简候选.md +++ b/docs/架构精简候选.md @@ -100,15 +100,38 @@ --- -### 候选 5 三个手工 vhost 的证书（不是精简，是收尾） +### 候选 5 手工 vhost 的证书（不是精简，是收尾）—— ✅ **已完成**（2026-10-06） -`writeapi.usj.cc` 的证书**没被本项目纳管**（配置在 `/www/conf.d/`，不在 1Panel 站点树里）， -实测仍是 **RSA / 到期 2026-12-07**，而本项目续期不会更新它 → **12 月会断**。 +`writeapi.usj.cc` 的证书**没被本项目纳管**，实测当时是 **RSA / 到期 2026-12-07** → **12 月会断**。 -两条路： -- **A. 让 cn-certkeeper 覆盖它**：把 `/www/conf.d/writeapi.usj.cc.conf` 的证书路径指到 - `openlist.usj.cc` 那种「已被纳管」的文件，或把它纳入部署目标 -- **B. 在 1Panel 里把它建成正式站点**，自然被 `ssl/upload` + `sslID` 覆盖 +**实际采用的第三条路（比下面 A/B 都省）**：它和 `artalk.usj.cc` **本来就同用一张 +`*.usj.cc` 证书**，所以直接让它**用相对软链接跟随 artalk** 即可 —— +零代码、零新增凭据、随续期自动跟随： + +```bash +D=/1panel/1panel/www/sites/writeapi.usj.cc/ssl +ln -sfn ../../artalk.usj.cc/ssl/fullchain.pem "$D/fullchain.pem" +ln -sfn ../../artalk.usj.cc/ssl/privkey.pem "$D/privkey.pem" +``` + +> ⚠️ **必须用相对路径**：宿主是 `/1panel/1panel/www/…`、容器内是 `/www/…`， +> 写绝对路径会在容器侧**断链**，而断链后 `nginx -s reload` 会**静默失败** +> （服务不中断、握手照旧）—— 直到某天 nginx 重启才发现 HTTPS 挂了。 +> 验收必须看 **worker 进程是否真的重启**，不能只看握手。 +> 完整机制与排错见 [`证书管家.md`](证书管家.md) §9.15。 + +结果：`CN=usj.cc`/RSA/2026-12-07 → **`CN=*.usj.cc`/ECC/2027-01-04**，容器内可读、 +预检通过、worker 已重启、`/health` 200。 + +当时考虑过的另外两条路（保留备查）： +- **A. 让 cn-certkeeper 覆盖它**：把它纳入部署目标 —— ❌ **走不通**：它**不是 1Panel 站点** + （面板 11 个网站里没有它），`findWebsite('writeapi.usj.cc')` 必然抛「找不到网站」 +- **B. 在 1Panel 里把它建成正式站点**，自然被 `ssl/upload` + `sslID` 覆盖 —— + 技术上可行，但要动生产 conf（`client_max_body_size 30m`、`proxy/*.conf` 都得迁）， + 风险与本收益不成比例，**未采用** + +另一个手工 vhost `dnsapi.usj.cc` **不做**：它是 `cn-dns-helper` 的反代入口（`127.0.0.1:8018`，仅 HTTP）， +去留应与候选 2（`cn-dns-helper`）一起决定。 详见 [`../架构总览.md`](../架构总览.md) §6 待办 #13。 @@ -130,11 +153,12 @@ ## 四、建议的执行顺序 ``` -1. 【立刻】候选 5 —— writeapi.usj.cc 证书纳管（12 月会断，有死线） -2. 【本周】候选 1 —— stop certimate 容器（零风险，观察即可） -3. 【本周】候选 2 —— 停 cn-dns-helper + 跑一次续期验证（大概率能省一个容器） -4. 【11 月前】候选 3 —— Gitea：迁 or 不留（★ 必须决定，机器要到期了） -5. 【有空】候选 4 —— 写作前端收敛（先看使用频率） +✅ 已完成（2026-10-06）候选 5 —— writeapi.usj.cc 证书纳管（相对软链接跟随 artalk，见上） +1. 【本周】候选 1 —— stop certimate 容器（零风险，观察即可） +2. 【本周】候选 2 —— 停 cn-dns-helper + 跑一次续期验证（大概率能省一个容器； + 顺带决定 dnsapi.usj.cc 这个反代入口的去留） +3. 【11 月前】候选 3 —— Gitea：迁 or 不留（★ 必须决定，机器要到期了） +4. 【有空】候选 4 —— 写作前端收敛（先看使用频率） ``` > 前三项做完，国内机上属于**本项目**的容器从 3 个降到 1 个（只剩 `editor-api`）， diff --git a/docs/证书管家.md b/docs/证书管家.md index 8434031b..1bc1587c 100644 --- a/docs/证书管家.md +++ b/docs/证书管家.md @@ -19,7 +19,7 @@ | CA | LiteSSL / freessl.cn（EAB 继承 certimate 账户，见 §9.10） | | 自测 | 125/125 通过；`npm run typecheck` 零错误 | | 数据目录 | 容器内 `/data`，7 条凭据（AES-GCM）+ 1 条 config | -| **已知遗留** | `writeapi.usj.cc` 等 3 个手工 vhost 不在站点管理面内（§9.14 末节）—— 证书是文件拷贝，需单独纳管 | +| **手工 vhost 的证书** | ✅ **已解决**（2026-10-06）：`writeapi.usj.cc` 靠**相对软链接跟随 `artalk.usj.cc`**，随续期自动更新 —— 机制与坑见 §9.15 | --- @@ -594,8 +594,13 @@ private importSigningKey(): Promise { > 判据用**证书记录自带的 `websites` 字段**（1Panel 自己算的引用关系）， > 比遍历 `/websites/{id}/https` 更权威。删除接口 `POST /websites/ssl/del {"ids":[...]}`。 > -> ⚠️ 3 个手工建的 nginx vhost（`dnsapi.usj.cc` / `writeapi.usj.cc` / `vaultwarden`） -> **不归 1Panel 站点管理**，证书是**文件拷贝**（指纹与 id 11 一致），与证书库记录解耦。 +> ⚠️ **2 个**手工建的 nginx vhost（`dnsapi.usj.cc` / `writeapi.usj.cc`） +> **不归 1Panel 站点管理**，证书是**文件拷贝**，与证书库记录解耦。 +> +> 🔧 **2026-10-06 更正**：这里原先写的是「3 个」，把 `vaultwarden` 也算进去了 —— +> **实测错**：`vaultwarden` 是**正常纳管**的 1Panel 站点（面板 #13，主域名 `vw.usj.cc`， +> 别名才是 `vaultwarden`），续期时会被正常绑定。 +> 手工 vhost 只剩 `writeapi.usj.cc`（已用软链接解决，§9.15）与 `dnsapi.usj.cc`（待随 `cn-dns-helper` 一起决策）。 ### 9.7 ★ 未决冲突：t-t.live 的「两套管理」 → 已定案：本项目接管 @@ -695,7 +700,7 @@ ssh.200181.xyz 公网 → 解析失败 / 源站 → 48 天 ← 修复了「天 | Worker 的续期 cron `10 4 * * *` | **停掉**。`wrangler.toml` 的 crons 改为 `["17 3 * * *", "0 * * * *"]`；`index.ts` 里整个 renew 分支删除 | | Worker 的签发入口 `POST /ssl/issue` | **改成 501 硬拒绝**，响应里给出「去国内机执行」的 curl 命令；后台按钮文案改成「签发/续期（在国内机）」 | | `usj.cc` 的 SAN 升级为 `usj.cc;*.usj.cc` | **接受**（线上原本是单名 `CN=usj.cc`，升级后一张证书同时覆盖主域与全部子域） | -| `dnsapi.usj.cc` 上 HTTPS | 仍未做；`cn-certkeeper` 只绑 `127.0.0.1:8019`，暂不走反代 | +| `dnsapi.usj.cc` 上 HTTPS | **不做**（2026-10-06 重新定性）：它其实是 `cn-dns-helper` 的反代入口（`proxy_pass http://127.0.0.1:8018`），而 `cn-dns-helper` 大概率已是遗留（见 `架构精简候选.md` 候选 2）→ **去留应与它一起决定**，不该单独给一个待退役的服务加 HTTPS | | 停 certd / 接管 t-t.live | **certd 根本不存在**，真正的竞争者是 certimate 容器；处理方式见 §9.10 | ### 9.9 ★★ 上线前修掉的两个 ACME 客户端真实 bug（只有打真 CA 才会现形） @@ -964,14 +969,108 @@ docker start 1Panel-certimate-OKCO > 回滚：`sqlite3 data.db "update workflow set enabled=1 where id='bsmqgpygir8l01s';"` > （库在 `/1panel/1panel/apps/certimate/certimate/data/data.db`，同目录留了 `.bak-20261006-200609`） -#### 遗留：`writeapi.usj.cc` 的手工 vhost 不在本项目的部署面内 +#### 遗留（已解决）：`writeapi.usj.cc` 的手工 vhost 不在本项目的部署面内 + +> ✅ **2026-10-06 当天解决** —— 解法与踩到的坑见下一节 §9.15。 +> 下面保留**当时的诊断**，但请注意其中一处**判断是错的**（已在 §9.15 更正）。 全网核验时发现 `writeapi.usj.cc` 的 `ssl/fullchain.pem` 仍是 **旧证书** （`CN=usj.cc` / RSA / LiteSSL RSA CA / 到期 2026-12-07，mtime 2026-10-04 21:50）。 -原因：它是 **1Panel 手工建的 vhost**，nginx 的 `ssl_certificate` 引用**不在 `/www/sites/` 目录树里** -（`grep -rn ssl_certificate sites/writeapi.usj.cc/` 无结果），因此**不走站点管理**， -`/websites/{id}/https` 的绑定操作碰不到它 —— 证书是**文件拷贝**，与证书库记录解耦。 +原因：它是 **1Panel 手工建的 vhost**，因此**不走 1Panel 的站点管理面** —— +`/websites/{id}/https` 的绑定操作碰不到它，证书与证书库记录解耦。 + +⚠️ **当时写错的一点**：本文档原先记的是「它的 `ssl_certificate` 引用不在 `/www/sites/` 目录树里」 +（依据是一次 `grep -rn ssl_certificate sites/writeapi.usj.cc/` 没结果）。 +**实测推翻**：`/www/conf.d/writeapi.usj.cc.conf` 里明确写着 +`ssl_certificate /www/sites/writeapi.usj.cc/ssl/fullchain.pem;` —— 路径**在**管理树里。 +真正的原因是**它在 1Panel 面板上根本不是一个站点**（面板共 11 个网站，没有它）， +所以「按站点名去绑定」这条路径永远找不到目标。 +> 教训：**「路径像不像」不构成判据，要直接查面板的站点清单**（`POST /websites/search`）。 + +--- + +### 9.15 ★ 手工 vhost 的证书：用**相对软链接**跟随已纳管站点 + +**背景**：`writeapi.usj.cc`（写作后台 `post.usj.cc` 的 API 入口）是手工 vhost， +不在 1Panel 站点清单里。而它与 `artalk.usj.cc` 用的是**同一张证书** +（`usj.cc` 的 SAN = `[usj.cc, *.usj.cc]`，两者都被覆盖）。 + +**解法 —— 不写一行代码**： + +```bash +# 宿主上执行（路径是宿主视角；容器内是 /www/sites/...） +D=/1panel/1panel/www/sites/writeapi.usj.cc/ssl +ln -sfn ../../artalk.usj.cc/ssl/fullchain.pem "$D/fullchain.pem" +ln -sfn ../../artalk.usj.cc/ssl/privkey.pem "$D/privkey.pem" +``` + +这样 `artalk` 每次续期被 1Panel 物化新证书时，`writeapi` **通过软链接自动跟随**； +1Panel 绑定 artalk 时本来就会 reload nginx，所以 writeapi 那边也一并生效 —— +**零代码、零新增凭据、零额外机制**。 + +#### ★★ 坑：软链接**必须用相对路径**（写绝对路径会在容器里断链） + +1Panel 的 openresty 跑在容器 `1Panel-openresty-Kmh2` 里，挂载关系是： + +| | 宿主 | 容器内 | +|---|---|---| +| sites 根 | `/1panel/1panel/www/sites/` | `/www/sites/` | + +所以宿主绝对路径 `/1panel/1panel/www/sites/artalk.usj.cc/ssl/privkey.pem` +**在容器里不存在** → 软链接在容器侧**断链** → nginx 重启/reload 时读不到证书。 + +**这个坑的隐蔽之处**：断链后 nginx 的 `-s reload` 会**静默失败**（保留旧配置、服务不中断）， +握手看起来一切正常（拿到的还是旧配置里那张内容相同的证书）， +**只有 worker 进程的启动时间没变**这一条线索 —— +真实后果是「**等某天 nginx 重启，writeapi 的 HTTPS 直接挂**」。 + +**所以验收必须包含这三条**（缺一不可）： + +```bash +# 1) 容器内能真正读到（最关键 —— 宿主侧 ls 看不出断链） +docker exec 1Panel-openresty-Kmh2 head -1 /www/sites/writeapi.usj.cc/ssl/privkey.pem +# 应输出 -----BEGIN PRIVATE KEY----- + +# 2) 配置预检 +docker exec 1Panel-openresty-Kmh2 /usr/local/openresty/bin/openresty -t + +# 3) reload 后 **worker 进程确实换了**（只看握手会被"内容相同的旧证书"骗过） +docker exec 1Panel-openresty-Kmh2 /usr/local/openresty/bin/openresty -s reload +ps -eo pid,lstart,args | grep "nginx: worker" | grep -v grep +``` + +#### 把锁在 KV 里的证书取出来：`src/dump-cert.mjs` + +证书在数据目录的 KV 里（AES-GCM 加密），手工 vhost 用的是磁盘 `.pem`，两者原先没有桥。 +新增的 `deploy/cn-certkeeper/src/dump-cert.mjs` 负责这一步（只读，不签发不部署）： + +```bash +# 脚本要先送进容器（1Panel 的文件 API 会拒绝 .mjs，见下） +docker exec -i cn-certkeeper sh -c 'cat > /tmp/dump-cert.mjs' < deploy/cn-certkeeper/src/dump-cert.mjs +docker exec cn-certkeeper node /tmp/dump-cert.mjs usj.cc +# 产物落在 /data/tmp/（宿主 <数据目录>/tmp/）—— ★ 含明文私钥，用完立刻删 +``` + +**两个操作层面的坑**： + +- **1Panel 的文件 API 拒绝写 `.mjs`**（`/files/save` 返回 500「目标路径不存在」）。 + 这是它的可执行扩展名过滤（防脚本落盘）。同样地，往**新建的 root:root 700 目录**写也会失败。 + 临时脚本的可靠送法是 `docker exec -i … sh -c 'cat > 路径' < 本地文件`。 +- **「命令带 `docker exec` 时远程执行返回空」**：本地 `.editor-tmp/cnrun.py`（1Panel 计划任务通道） + 偶发出现「退出码 0 但零输出」。加 `timeout 30 docker exec …` 包一层即可稳定复现结果； + 判断真实状态时**优先看容器内的直接证据**，不要只看那一次调用的输出。 + +#### 验收记录（2026-10-06） + +``` +替换前：CN=usj.cc / LiteSSL RSA CA / 到期 2026-12-07（mtime 10-04 21:50） +替换后：CN=*.usj.cc / LiteSSL ECC CA / 到期 2027-01-04 +软链接：fullchain.pem -> ../../artalk.usj.cc/ssl/fullchain.pem +容器内可读：head -1 → -----BEGIN CERTIFICATE----- / -----BEGIN PRIVATE KEY----- +预检：syntax is ok / test is successful +reload：signal process started；worker 于 22:51:39 重启（**证明软链接真的被读了**） +握手：SNI=writeapi.usj.cc → CN=*.usj.cc，notAfter=Jan 4 2027 +实访：https://writeapi.usj.cc/health → HTTP 200 +``` -功能上没问题（该证书 SAN 含 `*.usj.cc`，能覆盖 `writeapi.usj.cc`），但： -算法仍是 RSA、62 天后到期、且不会随本项目的续期自动更新 → **需要单独纳管**。 diff --git a/scripts/pushall.sh b/scripts/pushall.sh new file mode 100644 index 00000000..f745b05c --- /dev/null +++ b/scripts/pushall.sh @@ -0,0 +1,67 @@ +#!/usr/bin/env bash +# ===================================================================== +# 一条命令把本机提交推到所有远端（CNB 主仓 + 自建 Gitea 代码辅仓） +# +# 为什么需要「先 fetch 再 rebase」： +# 线上写作后台（editor-api 容器，post.usj.cc）发布文章时是**直接往 main 推**的。 +# 所以本机在「上次 fetch 之后」只要后台发过文章，本机 main 就与远端分叉 —— +# 此时直接 push 会被 rejected（fetch first）。 +# 这不是异常，是**日常**：2026-10-06 第一次实测就撞上了。 +# 所以推送前先把自己的提交 rebase 到远端之上，保持线性历史。 +# +# 安全边界： +# · 只 rebase **本机未推送的**提交，不外加强推 +# · 有冲突就**停在 rebase 中途**交给人工处理（`git rebase --abort` 可放弃） +# · 工作区不干净时 git 自己会拒绝 rebase，不会吞掉改动 +# · 任一远端推送失败**不改判另一个** —— 主仓失败时辅仓照样推， +# 备份的意义正在于「主仓出问题时它那儿还有」；但退出码以第一次失败为准 +# +# 用法： +# git pushall （别名指向本脚本，等价于直接 bash scripts/pushall.sh） +# bash scripts/pushall.sh +# ===================================================================== +set -uo pipefail + +cd "$(git rev-parse --show-toplevel)" || exit 1 + +REMOTES=("origin") +git remote | grep -qx gitea && REMOTES+=("gitea") + +echo "1/3 同步远端 (origin)…" +git fetch origin --prune 2>&1 | sed 's/^/ /' || { echo "!! fetch 失败，中止"; exit 1; } + +if git rev-parse --verify --quiet origin/main >/dev/null; then + behind=$(git rev-list --count HEAD..origin/main) + if [ "$behind" -gt 0 ]; then + echo " 远端领先 $behind 笔（大概是后台发的文章）→ rebase 到其之上" + if ! git rebase origin/main 2>&1 | sed 's/^/ /'; then + echo "!! rebase 冲突 —— 已停在 rebase 中途，请处理：" + echo " git status 看冲突文件" + echo " git rebase --continue 解决后继续" + echo " git rebase --abort 放弃本次 rebase（回到原状）" + exit 1 + fi + else + echo " 本机已是最新" + fi +fi + +echo "2/3 推送 → ${REMOTES[*]}" +ec=0 +for r in "${REMOTES[@]}"; do + # set -o pipefail 在，所以管道退出码 = git push 的（sed 不会掩盖它） + if ! git push "$r" main 2>&1 | sed "s/^/ [$r] /"; then + # ★ 这里不能写 ec=$? —— `!` 之后的 $? 是取反后的结果（0），不是 git 的退出码 + [ "$ec" -eq 0 ] && ec=1 + fi +done + +if [ "$ec" -eq 0 ]; then + echo "3/3 ✓ 全部远端同步完成" + for r in "${REMOTES[@]}"; do + echo " $r = $(git ls-remote "$r" refs/heads/main 2>/dev/null | cut -c1-8)" + done +else + echo "3/3 ✗ 有远端推送失败（退出码 $ec）" +fi +exit "$ec" diff --git a/scripts/setup-cnb-remotes.sh b/scripts/setup-cnb-remotes.sh index 9d75c5e2..46fef580 100644 --- a/scripts/setup-cnb-remotes.sh +++ b/scripts/setup-cnb-remotes.sh @@ -120,11 +120,13 @@ for retired in gh gitee; do done # 4) pushall —— CNB 与 Gitea 都推 -# ★ 用 `;` 而不是 `&&`：主仓失败时辅仓照样得推上去， -# 备份的意义正在于「主仓出问题时它那儿还有」。 -# 但退出码仍以主仓为准（exit $ec），免得辅仓推成功把主仓的失败盖掉。 +# ★ 2026-10-06 起逻辑搬到 scripts/pushall.sh —— 因为线上写作后台（editor-api） +# 发文章时**会直接往 main 推**，本机推送前必须先 fetch+rebase，否则必被 rejected。 +# （最初的别名就是被这个场景打回来的：本地两笔 vs 远端一篇新文章 → 分叉。） +# 脚本里还带：rebase 冲突时停在半路交人工、gitea 不存在时静默跳过、 +# 「主仓失败辅仓照样推」且退出码以主仓为准。 # 先探一下 gitea 在不在，免得没配辅仓时每次 pushall 都白报一行错。 -git config alias.pushall '!git push origin main; ec=$?; git remote | grep -qx gitea && git push gitea main; exit $ec' +git config alias.pushall '!bash "$(git rev-parse --show-toplevel)/scripts/pushall.sh"' # 5) 凭据 # diff --git a/架构总览.md b/架构总览.md index d3b2935c..3286fae6 100644 --- a/架构总览.md +++ b/架构总览.md @@ -473,8 +473,16 @@ git clone blog.bundle blog # 或 git fetch blog.bundle 'refs/*:refs/*' **已知遗留**： -- `writeapi.usj.cc` / `dnsapi.usj.cc` / `vaultwarden` 三个**手工 nginx vhost 不归 1Panel 站点管理** —— - 证书是**文件拷贝**，与证书库记录解耦，`/websites/{id}/https` 碰不到它们 → 需单独纳管 +- **手工 nginx vhost**（不归 1Panel 站点管理，`/websites/{id}/https` 碰不到）目前**只剩 2 个**： + - `writeapi.usj.cc`（写作后台 API 入口）—— ✅ **已解决**（2026-10-06）：证书改用 + **相对软链接跟随 `artalk.usj.cc`**（两者本就同用 `*.usj.cc` 那张证书），随续期自动更新。 + ⚠️ 软链接**必须相对路径**（宿主 `/1panel/1panel/www/…` vs 容器 `/www/…`，绝对路径会在容器内断链， + 且断链后 nginx reload 会**静默失败**）；验收要看 **worker 进程是否真的重启**，光看握手会被骗。 + 机制与坑见 [`docs/证书管家.md`](docs/证书管家.md) §9.15 + - `dnsapi.usj.cc` —— 其实是 `cn-dns-helper` 的反代入口（`proxy_pass 127.0.0.1:8018`，**仅 HTTP**）。 + 它的去留应与 `cn-dns-helper` 一起决定，**不单独**给它加 HTTPS（见 [`docs/架构精简候选.md`](docs/架构精简候选.md) 候选 2） + - 注：`vaultwarden` **不是**手工 vhost —— 它是面板 #13 站点（主域名 `vw.usj.cc`），正常纳管。 + （本文档早先把它误算作手工 vhost，2026-10-06 更正） - 动代码前必看 [`docs/证书管家.md`](docs/证书管家.md) 的 **§8.4 / §9.9 / §9.11 / §9.12** 四节 「易误判、勿回退」的坑（ACME 客户端 bug、CSR 三层 SEQ、`ssl/update` 不物化站点文件、 1Panel HTTPS 字段名是大写 `SSL` 等） @@ -497,8 +505,8 @@ git clone blog.bundle blog # 或 git fetch blog.bundle 'refs/*:refs/*' | 10 | **整仓离线备份** | ✅ **已上线**（2026-10-06），现为**备选**异地备份（在线那一路是自建 Gitea 辅仓），见 §5.6。计划任务 `Blog-BundleBackup` 每天 03:30 跑，端到端已验证；失败会发告警邮件（已实测）。**2026-10-06 补**：打包前加 `git fetch --all` —— 原来备的是「本机已知 ref」的快照，后台新发的文章可能一份都不在里面，且备份照样报成功（§5.6）。待补三件安全项：把 `BACKUP_PASSPHRASE` 抄进密码管理器；给 OpenList **改掉 admin 密码 + 开两步验证**（现 `otp: false`，且旧密码已出现在对话里）；确认 5244 端口**未暴露到公网** | | 11 | **F50 存储目录的使用约定** | `/本地/` 下的 `刷机` / `系统` / `资料` / `软件` / `驱动` / `备份` 都是用户自己在管的类别。**本项目的 bundle 只写 `备份/blog-bundle/` 子目录**，不与用户手工备份（`github-zqlit-*`、`local-repos-*`）混放 | | 12 | **editor-api 容器的三层留存** | ✅ **已落地**（2026-10-06，国内机 `119.29.215.187`）：`PUSH_REMOTES=origin,gitea`（CNB 主仓 + 自建 Gitea 备份仓），文件层走 §5.6 的加密 bundle。实测：容器内推 `origin` ✅ / 推 `gitea` ✅（临时分支推完即删），`/health` 返回 `remotes:["origin","gitea"]`，三处 `main` 对齐 `448b898e`。接入时 `/srv/blog` 落后 10 个提交，一次 fast-forward 追平 | -| 13 | ★ **证书管家的两个遗留** | 见 §5.7。**① `writeapi.usj.cc` 的证书没纳管**（真问题，会到期）：它的 nginx 配置在 `/www/conf.d/writeapi.usj.cc.conf` —— **不在 `/www/sites/` 管理树里**，所以 1Panel 的 `ssl/upload`+`sslID` 物化时碰不到它。现状实测：`CN=usj.cc` / **RSA** / 到期 **2026-12-07**，而本项目续期**不会更新它** → 12 月会断。**② `dnsapi.usj.cc` 没上 HTTPS**（`ssl/` 目录空、源站握手失败）。
（附带澄清：`200181.xyz` 公网走 Cloudflare，看到的 LE 证书是 **CF 自家的边缘证书**，与本项目无关；源站 `ssh.200181.xyz` 已是本项目签的 `*.200181.xyz` / 2027-01-04 ✅） | -| 14 | **架构复杂度盘点** | 「感觉架构还是复杂了」的正面回应 → 已盘点：**跨 6 个环境，其中 4 个要自己维护**，这才是复杂度的来源；国内机 9 个容器里属于本项目的只有 3 个，能动的只有 2 个。**5 个精简候选 + 建议执行顺序**见 [`docs/架构精简候选.md`](docs/架构精简候选.md)：certimate 容器可停、`cn-dns-helper` 大概率是遗留、Gitea 迁 or 不留、两套写作前端收敛、writeapi 证书纳管 | +| 13 | ★ **证书管家遗留** | ✅ **① 已解决**（2026-10-06）：`writeapi.usj.cc` 是**手工 vhost**（面板 11 个网站里没有它，所以按站点名绑定永远找不到目标）→ 改用**相对软链接跟随 `artalk.usj.cc`**，随续期自动更新。证书从 `CN=usj.cc`/RSA/**2026-12-07** 换成 `CN=*.usj.cc`/ECC/**2027-01-04**，容器内可读、预检通过、**worker 已重启**、`/health` 200；机制与「必须用相对路径」的坑见 [`docs/证书管家.md`](docs/证书管家.md) §9.15。
**② `dnsapi.usj.cc` 重新定性为「不做」**：它是 `cn-dns-helper` 的反代入口（`proxy_pass 127.0.0.1:8018`，仅 HTTP），去留应与 `cn-dns-helper` 一起决定。
（附带澄清：`200181.xyz` 公网走 Cloudflare，看到的 LE 证书是 **CF 自家的边缘证书**，与本项目无关；源站 `ssh.200181.xyz` 已是本项目签的 `*.200181.xyz` / 2027-01-04 ✅） | +| 14 | **架构复杂度盘点** | 「感觉架构还是复杂了」的正面回应 → 已盘点：**跨 6 个环境，其中 4 个要自己维护**，这才是复杂度的来源；国内机 9 个容器里属于本项目的只有 3 个，能动的只有 2 个。**5 个精简候选 + 建议执行顺序**见 [`docs/架构精简候选.md`](docs/架构精简候选.md)：certimate 容器可停、`cn-dns-helper` 大概率是遗留、Gitea 迁 or 不留、两套写作前端收敛、~~writeapi 证书纳管~~（✅ 2026-10-06 已完成，见 #13） | ---