3eeafa07b2dec6f1ee24378e8405adb193256c5a
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 zqlit
|
3eeafa07b2 |
fix(证书管家): writeapi.usj.cc 证书纳管（相对软链接）；pushall 改为先 rebase 再推
用户：「动手 推送吧」—— 动手处理两个有死线的遗留。
一、writeapi.usj.cc 的证书（12 月会断）→ 已解决
现状复核推翻了上一轮的判断：
· 上一轮记的「它的 ssl_certificate 引用不在 /www/sites/ 树里」是**错的** ——
/www/conf.d/writeapi.usj.cc.conf 里明确写着
ssl_certificate /www/sites/writeapi.usj.cc/ssl/fullchain.pem;
· 真正原因是**它在 1Panel 面板上根本不是一个网站**（面板共 11 个站点，没有它），
所以 `findWebsite('writeapi.usj.cc')` 必然抛「找不到网站」→
加进 one_panel_sites 只会让**每次续期都报错**（而且只警告不阻断，长期没人发现）
· 实测确认：redeploy 时其余 5 个站点正常，只有它失败
解法：**不写一行代码** —— 它与 artalk.usj.cc 本来就同用一张 *.usj.cc 证书，
让它用**相对软链接跟随 artalk** 即可，随续期自动更新：
ln -sfn ../../artalk.usj.cc/ssl/fullchain.pem /1panel/1panel/www/sites/writeapi.usj.cc/ssl/fullchain.pem
★★ 踩到的坑：软链接**必须相对路径**
宿主 /1panel/1panel/www/sites/ ↔ 容器内 /www/sites/（1Panel 的 openresty 跑在容器
`1Panel-openresty-Kmh2`）。第一版写成宿主绝对路径 → **容器侧断链** →
nginx -s reload **静默失败**（保留旧配置、服务不中断、握手照旧拿旧证书）→
表面全绿，真实后果是「等某天 nginx 重启，writeapi 的 HTTPS 直接挂」。
唯一线索是 worker 进程的启动时间没变 —— **所以验收必须看 worker 是否真的重启**。
验收（全部实测）：
替换前 CN=usj.cc / LiteSSL RSA CA / 2026-12-07（mtime 10-04 21:50）
替换后 CN=*.usj.cc / LiteSSL ECC CA / 2027-01-04
容器内 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 → *.usj.cc / Jan 4 2027；实访 /health → HTTP 200
新增 deploy/cn-certkeeper/src/dump-cert.mjs：把 KV 里（AES-GCM 加密）的证书导成明文 PEM，
补上「KV ↔ 手工 vhost 磁盘文件」之间原先不存在的桥。只读，用完即删（含明文私钥）。
操作层的两个坑（写进文档）：
· 1Panel 文件 API **拒绝写 .mjs**（返回 500「目标路径不存在」，实为可执行扩展名过滤）；
往新建的 root:root 700 目录写也会失败 → 临时脚本用
`docker exec -i … sh -c 'cat > 路径' < 本地文件` 送
· cnrun.py（1Panel 计划任务通道）偶发「退出码 0 但零输出」；
加 `timeout 30 docker exec …` 包一层即稳定，判断状态优先看容器内直接证据
二、配置回退 + 文档更正
· certkeeper-config.mjs：把 writeapi 从 one_panel_sites 移除，换成一段注释说明
「它不是 1Panel 站点，别加进来」+ 软链接做法 + 必须相对的警告；
线上 config.kv 同步回退（sha256 与改动前完全一致 ccac2530…）
· 更正「3 个手工 vhost」的说法：vaultwarden **是**正常纳管的站点（面板 #13，
主域名 vw.usj.cc，别名才是 vaultwarden）→ 手工 vhost 实际只剩 writeapi + dnsapi
· dnsapi.usj.cc 重新定性为**不做**：它是 cn-dns-helper 的反代入口
（proxy_pass 127.0.0.1:8018，仅 HTTP），去留应与 cn-dns-helper 一起决定，
不该单独给一个待退役的服务加 HTTPS
三、pushall 加固：先 fetch + rebase 再推（本次真实撞到的问题）
推 CNB 时被 rejected —— 因为线上写作后台（editor-api）发文章会**直接推 main**，
本机两笔提交与之分叉。这不是异常，是**日常**。原别名直接 push，必然反复撞。
· 新增 scripts/pushall.sh：fetch → 已在远端之后则 rebase → 推所有远端
- 冲突时**停在 rebase 中途**交人工（不强推、不丢东西）
- 工作区不干净时 git 自己会拒绝 rebase（不会吞改动）
- 任一远端失败**不改判另一个**（主仓失败辅仓照样推），退出码以第一次失败为准
- ⚠️ 修了自己写的一处疏漏：`if ! cmd; then ec=$?` 的 $? 是**取反后**的结果（0），
不是 git 的退出码 —— 必须显式 ec=1（靠 set -o pipefail 保证管道退出码不被 sed 掩盖）
· setup-cnb-remotes.sh 的别名改指向脚本；README 脚本表补这一行
四、文档
· docs/证书管家.md：速览表「已知遗留」→ 已解决；§9.14 遗留段重写（含纠正自己写错的判据
「路径像不像不构成判据，要直接查面板站点清单」）；**新增 §9.15**
「手工 vhost 的证书：用相对软链接跟随已纳管站点」（机制 + 路径坑 + 三条验收 + dump-cert 用法）
· docs/架构精简候选.md：候选 5 标记完成，补上「为什么 A 走不通、B 未采用」；
执行顺序里划掉它
· 架构总览.md：§5.7「已知遗留」重写（2 个手工 vhost + vaultwarden 更正）；
§6 待办 #13 改为已解决、#14 标注完成
|
||
|
zqlit
|
448b898e40 |
feat(远端): 恢复自建 Gitea 代码辅仓，OpenList 降为备选备份
用户定案：「自建 gitea 同步一下吧，openlist 也作为备选备份」。
于是把上一轮「撤销全部 git 辅仓」的决定部分回退：在线那一路回到自建 Gitea，
OpenList 上的加密 bundle 从「唯一异地备份」改为「备选异地备份」。
两层不是重复，而是失效模式不同：
· 自建 Gitea（在线、可增量、可浏览）—— 不受任何第三方平台规则约束
· 离线 bundle（离线、单一文件、完整历史）—— 平台全挂也能恢复
一、实际同步
- Gitea 位于 23.254.236.47:3001（Gitea 28.0.0），本机直连即可推，
**不需要广州中转机**（旧结论「沙箱跑不通 git smart HTTP」只针对当时的代理）
- 远端停在 ed38f938（2026-10-04），落后 57 个提交，且是本地 HEAD 的**祖先**
→ 一次 fast-forward 追平，**未强推、未丢历史**
- 同步后 origin 与 gitea 均指向
|
||
|
zqlit
|
5f27ad321d |
chore(备份): 异地备份定案为 OpenList 离线 bundle，撤销全部 git 辅仓
用户定案：「辅助仓就用 openlist，其他不再考虑」。
据此把前一轮为 Gitee 铺的路全部收回，git 远端只剩 CNB 一个。
一、git 配置收口
- `pushall` 别名 `origin + gitee` → `!git push origin main`（只推唯一远端）
- 移除 `gitea` remote（自建 23.254.236.47:3001）—— 远端仓库本身没删，
需要时可 `git remote add` 恢复；改动前配置存
`.workbuddy-backup/git-remotes.20261006-211516.txt`
- 确认无 gitee 相关 credential 残留
二、发布链路去 Gitee 化（6 处）
- `deploy/editor-api/bootstrap.sh`
· 删掉 GITEE_URL / GITEE_SSH_KEY 两个变量与「没给私钥就降级」的分支
· PUSH_REMOTES 默认 → origin
· 原「配 gitee 辅仓远端」一节改为「清理退役远端」循环（gh/gitee/gitea），
让从旧部署续用的工作区自动恢复干净
- `docker-compose.editor.yml`、`editor-api/server.mjs` → 默认值 origin
- `editor-api/README.md` → 变量表同步
- `editor-api/Dockerfile` → 注释里的「CNB / GitHub」改「CNB」
- `blog-admin/src/routes/rss/tools.ts` → deploy-notify 的注释里
「与 Gitea Actions 的构建通知配套」改为中性描述
（该轮询链路 2026-10-04 起已被 CNB 国内节点直传取代）
三、`scripts/setup-cnb-remotes.sh` 重写为单远端模式
- 去掉 GITEE_URL / GITEE_TOKEN 参数、校验、凭据写入与自检提示
- 新增「清理退役远端」步骤
- 凭据处理改为「已存在空的 credential.helper 就不再添加」，
不再用 --replace-all —— 本仓另有一个从 `$HOME/.workbuddy/secrets/cnb-token`
读令牌的自定义 helper，那是有效的，不能被脚本抹掉
四、备份升级为「唯一辅仓」的配置
- 保留份数 3 → 7（一周窗口；每份 605.5 MB ≈ 4.2 GB，F50 有 256 GB）
· `scripts/backup-task.cmd` 默认参数 --keep 7
· `scripts/backup-bundle.mjs` 的 KEEP 默认值同步为 7
（原先写的是 2，一直被命令行参数掩盖着）
- 远端目录 `/本地/备份` → `/本地/备份/blog-bundle`：
根目录是用户自己在用的（放着 github-zqlit-*、local-repos-* 等手工备份），
实测发现直接放根下的 bundle 已被清掉 —— 改子目录隔离，避免混放与误删
五、新增 `scripts/backup-run.mjs`：备份的推荐入口 + 失败告警
- 读 `.workbuddy-backup/openlist-backup.env`（只补空缺，环境变量优先）
- 跑 backup-bundle.mjs 并实时透传输出，同时留一份日志尾部
- 退出码非 0 → 经 `scripts/send_mail.js` 发告警邮件（附日志尾部与常见原因）；
成功默认不发，`--notify-success` 才发
- 退出用 `process.exitCode` 而非 `process.exit()`，避免截断未排干的 stdout
- 发信失败不改判备份退出码 —— 通知不该掩盖真正的故障
- 理由：这是当前**唯一**的异地备份，而「每天自动跑」的任务最典型的失败模式
恰恰是静默的（F50 被带出门、换了网段、OpenList 没起来、口令改过……），
没有告警就要等到真要用备份那天才发现
- `scripts/backup-task.cmd` 改调它
六、文档
- `架构总览.md`
· §1.2 地址地图：备份行改指 F50/OpenList；通知行补「兼做备份失败告警」
· §2 旅程图：双推改单推，并说明备份换了介质
· §5.1 / §5.2 推送与远端：只剩 origin；补「已移除远端」表与恢复命令；
GitHub 退役记录保留并补上「CI 定义也已删除」
· §5.3 由「辅仓选型」改为「异地备份的定案」—— 明确不走 git 远端；
平台对比数据保留备查，并注明 `bin/linux/hugo` 出库不必再做了
· §5.6 补「唯一备份」定位、专属子目录、失败告警、keep 7、SMTP 配置键，
实测数据更新为本次复测值
· §6 待办：#2 定案、#3 不必做、#4 已移除、#8 已更新、#10 定位升级，
新增 #11（F50 目录使用约定）
- `CNB构建落地方案.md` §4.0：双远端改单远端，脚本示例去掉 Gitee 参数
- `README.md`：推送说明改单推；脚本表补 backup-run.mjs
实测（2026-10-06，本轮复测）：
bundle 7.4s / AES-256-GCM 加密 1.3s / 上传 19.2s（31.6 MB/s）
/ 读回 sha256 一致 → 端到端 60.6s，退出码 0
告警邮件链路已实测（发出一封「备份成功」验证信）
★ 一处过程记录，供以后避免重复踩坑：
中途我把「本机沙箱里 `env -u ... cmd > file` 会让输出整个消失」
误判成 process.exit 截断 stdout，并据此改了日志实现；
随后用 `env -u FOO echo hi > file`（同样零输出）证伪 ——
那是沙箱文件重定向的伪影，与脚本无关。相关改动已回滚，
只留下本身无害的 process.exitCode 写法。
|
||
|
zqlit
|
b39dc29753 |
chore(远端): 移除 GitHub，改为「CNB 主仓 + Gitee 辅仓」
起因：GitHub 账号被平台标记，随后仓库被按 AUP 合规条款清空 ——
远端只剩一条孤立提交（无父提交、无内容）：
c21d5669 2026-10-06 20:08:32 +0800 zqlit
chore: remove repository content (AUP compliance)
同时远端 main 的历史与本地**完全分叉**：两边只共享 2024-07-11 的 Initial commit，
之后每个提交 SHA 都不同（远端那份 989 提交、剥离了 .env/私钥/大二进制）。
所以 `git push gh main` 无法快进，也不可能再当备份用。
改动：
- `git remote remove gh`（改动前配置存 .workbuddy-backup/git-remotes.20261006-201354.txt）
- `pushall` 别名 → `git push origin main; git push gitee main`
- `scripts/setup-cnb-remotes.sh`：参数化第二个远端为 Gitee，
顺带把「若残留 gh remote 就清掉」做进脚本；Gitee 凭据走 wincred
- `架构总览.md`：§2 发布旅程图、§5.2 远端表、§6 遗留待办全部改指向；
新增 §5.2 的 GitHub 退役记录（含那条孤立提交的原文）
与 §5.3「Gitee 辅仓的两条硬约束」实测核算
- `CNB构建落地方案.md`、`README.md`：远端与 pushall 说明同步
- **发布链路一起去 GitHub 化**（这几处原先都写死了 gh）：
· `deploy/editor-api/bootstrap.sh` GH_URL/GH_SSH_KEY → GITEE_URL/GITEE_SSH_KEY，
remote `gh` → `gitee`，known_hosts/私钥文件名跟着改；
保留原设计：**没给私钥就自动降级成只推 origin**，不会让每次发布都报错
· `docker-compose.editor.yml` PUSH_REMOTES → origin,gitee
· `editor-api/server.mjs` 默认值 → 'origin,gitee'
· `editor-api/README.md` 变量表同步
★ 尚未解决 / 需要决策的两条 Gitee 硬约束（详见 架构总览.md §5.3）：
1. **单文件 ≤ 50MB，而 `bin/linux/hugo` 是 83.1MB**
—— 不管怎么瘦身历史，只要它还跟踪在 HEAD 里，Gitee 一律拒收。
2. 单仓库 ≤ 500MB，而 `.git` 是 620MB
—— 移出那个 83MB 后 HEAD ≈ 374MB，才有余量。
另：线上 editor-api 容器的 .env 仍是 `PUSH_REMOTES=origin,gh`，
且仓库里还有一个 `gh` remote。因为推送逻辑对辅仓失败只警告、不阻断发布
（`git.mjs`：主仓成即算成），所以**线上发布没有坏**；
但要真正切到 Gitee，需要等 Gitee 仓库与私钥就位后再部署一次。
|
||
|
zqlit
|
e0218b42bb |
docs: 迁 CNB 前的架构决策文档 + 构建骨架
- 决策文档：架构总览 / 代码源与构建平台选型 / CNB构建落地方案 / EdgeOne双区域 / Gitee / 阿里云ESA / 精简方案 - CNB 构建骨架：deploy/Dockerfile、bin/linux/hugo （84MB，linux/amd64 extended 0.128.2，供 CNB 容器 COPY 用） - scripts/setup-cnb-remotes.sh：双远端切换（CNB 主仓 + GitHub 备份） - .gitignore 补 .workbuddy/（工作数据不入库） |