zijunchiang/opendance-web
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 17 Wiki Activity
20 Commits 2 Branches 17 Tags
c092b833fb8cf6271646ba8f20294650dc481c78
Commit Graph
20 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
zijunchiang c092b833fb fix(deploy): 支持无 systemd 的环境，并修复降级路径的两个真实缺陷 
用户实测：服务器没有 systemctl，install.sh 直接报错退出。

原错误信息本身也是错的（建议 SKIP_NGINX=1，但那只跳过 nginx，仍走 systemctl）。

进程管理改为四层降级：
  systemd → OpenRC → SysVinit → nohup 后台进程（deploy/ctl.sh）
- 新增 deploy/ctl.sh：start/stop/restart/status/logs，PID 文件 + 进程名双重判定
- 新增 deploy/openrc/opendance-api、deploy/initd/opendance-api
- 无 init 系统时写 crontab @reboot 实现开机自启
- uninstall.sh 同步支持四种模式清理（原先只处理 systemd，会留下运行中的进程）
- 汇总输出按实际初始化系统给出对应运维命令

测试中发现并修复降级路径的两个真实缺陷：

1. nohup 无法调用 shell 函数
    实测退出码 127 且什么都不执行
   （nohup 是外部命令，只能执行可执行文件）。
   这会让无 systemd 的降级路径完全失效——服务根本起不来。
   改为按 runuser / setpriv / su 显式拼接成外部命令后再 nohup。
   另加启动后 1 秒存活检测，失败立即打印日志，不再白等 30 秒。

2. find_pids 在无进程时返回一个空格
    在空输入下仍会执行一次 echo，输出空行，
   最终得到 " "；调用方 [ -n ... ] 会判为「有进程」，
   导致 start 直接跳过、status 谎报运行中。改为纯 bash 拼接，空时返回空串。

实测（真实 API 进程，端口 3100）：
  start → 健康检查 200，PID 正确
  重复 start → 识别已在运行，进程数保持 1
  status → 运行中
  restart → 新 PID，健康检查 200
  stop → 无残留进程，端口释放
  无 process 时 find_pids 返回空串，is_running=false
 2026-09-15 00:34:52 +08:00
zijunchiang 1ffe3059af fix(deploy): install.sh 不再依赖 sudo 
用户实测报错：deploy/install.sh: line 173: sudo: command not found

本脚本已经强制要求 root 权限，用 sudo 降权到服务用户本就多余，
且部分服务器（尤其精简系统/容器）根本没有安装 sudo。

- 新增 as_service_user()：runuser → setpriv → su 依次回退，
  并在三者都不可用时给出明确错误
- 替换全部 sudo -u 调用（npm ci / npm install / npm run build / 迁移）
- 新增 http_get() / http_ok()：curl → wget → node fetch 依次回退，
  健康检查不再强依赖 curl
- 启动前检查 systemctl（本部署依赖 systemd），缺失时给出可操作提示
- 修正 install.sh / uninstall.sh 中所有「用 sudo 执行」的提示文案

实测（桩替换 runuser 验证分派与参数传递）：
  有 runuser：runuser -u opendance -- npm ci --omit=dev --loglevel=error
  仅 su：正确回退到 su
  HTTP：curl 路径与 node fetch 回退路径返回一致
 2026-09-15 00:27:27 +08:00
zijunchiang 7cd607ecde fix(deploy): 修复 install.sh 同步文件时的长时间卡死 
用户实测：执行到「同步程序文件到 /opt/opendance」后卡死。

根因：在源码检出目录执行时，web-server/ 下有 node_modules（236MB /
27359 个文件，admin 下还有 122MB），原实现用 cp -r 全量复制，
随后又对整个目录 chown -R，处理三万个文件表现为卡死。

修复：
- 复制改用 copy_tree()，排除 node_modules/.git/storage/dist-release 等
  运行期可再生目录；有 rsync 用 rsync -a --delete，否则用 tar 管道回退
- tar 回退的排除模式同时给出 './x' 与 '*/x'：只写 './x' 无法匹配嵌套的
  './admin/node_modules'（实测会漏掉 122MB，等于没修）
- 增加目录安全检查：安装目录与源目录相同、或二者互相包含时直接报错退出，
  避免 rm -rf 删掉源文件 / cp 无限递归
- 支持两种目录布局：发布包 admin/ 在根目录，源码检出在
  web-server/admin/dist（缺失则现场构建），此前从源码目录执行必然在
  「缺少 admin/ 目录」处失败
- 每个目录打印复制结果与文件数，npm 安装前给出预计耗时提示，
  不再有长时间无输出的「假卡死」
- 失败时 trap 打印行号

实测（用脚本中真实代码块驱动的用例）：
  源码检出目录 → /tmp：rsync 路径 1 秒 / 209 文件；tar 回退路径同样 209 文件
  发布包解压目录 → /tmp：0 秒，admin 与 dist/main.js 均正确
  同目录 / 嵌套目录两种危险布局：均被拒绝并给出可操作提示
  两条路径均无 node_modules 泄漏
 2026-09-15 00:14:06 +08:00
zijunchiang 32525dd59a docs(web): 清理残留的 Docker 引用（admin README / project.yaml / 注释） 2026-09-14 22:47:47 +08:00
zijunchiang 07ee30d704 docs(web): 开发环境样例补充 HOST 说明 2026-09-14 22:45:31 +08:00
zijunchiang 75498db1c0 feat(web): 部署方式由 Docker 改为 Linux 原生站点（nginx + systemd） 
需求变更：Web 服务端不再使用 Docker，改为直接运行在 Linux 上的网站。

- 移除 deploy/docker-compose.yml、web-server/Dockerfile、
  web-server/admin/Dockerfile、web-server/.dockerignore
- 新增 deploy/install.sh：建服务用户与目录 → 装运行期依赖 → 迁移
  → 注册 systemd 服务 → 配置 nginx 站点 → 健康检查，一键完成
- 新增 deploy/systemd/opendance-api.service：ProtectSystem=strict 等
  安全加固，ReadWritePaths 限定为上传目录
- 新增 deploy/nginx/opendance.conf：同站点托管管理端静态资源 +
  反代 /api /health /static，client_max_body_size 512m，SPA 回退
- 新增 deploy/uninstall.sh：默认保留数据，--purge 才删除
- 新增配置项 HOST（AppConfig.bindHost）：原生部署下 Node 只监听
  127.0.0.1，不直接对外暴露，实测外部 IP 不可达
- 同步更新 contracts/rest-api.yaml、DSH.md、project.yaml、README.txt、
  tasks/008、tasks/010 与发布打包脚本
 2026-09-14 22:42:56 +08:00
zijunchiang 0c133986b4 test(web): 新增演示数据播种脚本（供管理端与客户端联调） 2026-09-14 20:08:20 +08:00
zijunchiang dbd9155b40 fix(release): 打包清单读取避免 SIGPIPE 误报 v0.1.0 2026-09-14 19:01:58 +08:00
zijunchiang b9215d4190 docs(web): 任务说明、DSH 约束与交付文档 2026-09-14 19:00:55 +08:00
zijunchiang 5a8b77b0a4 feat(web): T-WEB-010 部署脚本（Docker Compose，不含 MySQL） 2026-09-14 19:00:55 +08:00
zijunchiang 640736c77b feat(web): T-WEB-008/009 管理端界面（歌曲/模型/动作/审核 + VRM 预览） 2026-09-14 19:00:55 +08:00
zijunchiang 0f66b53480 feat(web): 客户端目录导出 /api/catalog/export 与版本指纹 2026-09-14 19:00:55 +08:00
zijunchiang 7ff3f1598d feat(web): T-WEB-007 上传审核流程（状态机 + 审核流水） 2026-09-14 19:00:55 +08:00
zijunchiang a2e3282603 feat(web): T-WEB-006 BVH/FBX → MediaPipe33 关键点预处理 2026-09-14 19:00:55 +08:00
zijunchiang 73e793318e feat(web): T-WEB-005 模型上传 + VRM 优先 + 版本识别 2026-09-14 19:00:55 +08:00
zijunchiang ff8c4dd26a feat(web): T-WEB-004 动作数据上传 + 来源五元组校验 2026-09-14 19:00:55 +08:00
zijunchiang d9614aadb0 feat(web): T-WEB-003 /api/songs CRUD + 音频上传 2026-09-14 19:00:55 +08:00
zijunchiang 6714b1e67c feat(web): T-WEB-002 TypeORM 迁移生成表结构（5 表，可逆） 2026-09-14 19:00:55 +08:00
zijunchiang bd6cb9fa90 feat(web): T-WEB-001 NestJS 骨架 + 连接现有 MySQL 实例 2026-09-14 19:00:55 +08:00
zijunchiang 9b8fc6be96 chore(contracts): 冻结 v0.1.0 跨端契约（REST/WebSocket/数据模型/拓扑/格式/数据库） 2026-09-14 19:00:55 +08:00