| | |
|---|
| | | |
|---|
| | | | 路径 | 内容 | |
|---|
| | | |---|---| |
|---|
| | | | `/data/talent-card/app.jar` | 后端 fat jar（103 MiB）。**2026-09-29 16:51 更新到提交 `7a5303f`**：V156 已应用（库版本 156，`merchant_onboarding_application.store_cashier_url` 列已建），启动 14.7 s、`/actuator/health` UP。上一版（提交 `61ba794`、库版本 155）留在 `app.jar.bak-20260929-1650`，更早一版在 `app.jar.bak-20260929-1326`；回滚直接换回即可（V156 同样只加一列可空列，旧代码忽略它，安全）。上传来源文件的 sha256：`79d63e44…e4554` | |
|---|
| | | | `/data/talent-card/admin/` | 后台管理端 dist（nginx 托管）。**2026-09-29 16:54 由 `redeploy-admin.sh` 从 Gitblit `main`(`7a5303f`) 重建并替换**：进件详情的「门店照片」区多了「店铺收银台」一列。注意本次构建日志里有「没有 `/etc/talent-card/admin-build.env`，本次不带高德 key 构建」——见下文「已知缺口」 | |
|---|
| | | | `/data/talent-card/app.jar` | 后端 fat jar（103 MiB）。**2026-10-10 13:57 更新到提交 `38e39c5`**：库版本仍是 156（`DbMigrate` 报 `Schema is up to date. No migration necessary.`，150 个迁移校验通过），启动 16.2 s、`/actuator/health` UP、`https://rencaika.dqrcfwpt.com/api/health` 与 `http://117.172.73.106:8082/api/health` 均 200。**这一版起改为「在服务器上从 Gitblit 源码就地构建」，不再上传 103 MiB 的包** —— 做法与由来见下「重建后端」，构建产物 sha256 `19efe2b4…ca66`。上一版（提交 `7a5303f`、上传来源文件 sha256 `79d63e44…e4554`）留在 **`app.jar.bak-20261010-1341`**（`cp -p` 保留原 mtime，sha 已校验 = `79d63e44…e4554`），更早两版是 `app.jar.bak-20260929-1650`（提交 `61ba794`、库版本 155）和 `app.jar.bak-20260929-1326`；回滚直接换回即可（本次前后都没有新迁移，旧代码读新库安全） | |
|---|
| | | | `/data/talent-card/admin/` | 后台管理端 dist（nginx 托管）。**最近一次：2026-10-10 13:59 由 `redeploy-admin.sh` 从 Gitblit `main`(`da90ca8`) 重建并替换**（当天与后端 `38e39c5` 的上线相隔约 2 分钟，两人并行操作，输出留在 `admin-redeploy-20261010.log`）：新增人才卡升级页 `TalentUpgradeView.vue`。**注意它 `git fetch` 会把 `/data/talent-card/src` 硬对齐到 `origin/main`**（这次就是从 `38e39c5` 推到 `da90ca8`），所以此后重建后端会以 `da90ca8` 为基线。上上次是 2026-09-29 16:54 从 `7a5303f` 重建（进件详情多了「店铺收银台」一列）。两次构建日志里都有「没有 `/etc/talent-card/admin-build.env`，本次不带高德 key 构建」——见下文「已知缺口」 | |
|---|
| | | | `/data/talent-card/uploads/` | 上传落盘目录（对应 `UPLOAD_DIR`） | |
|---|
| | | | `/data/talent-card/src/` | 从 Gitblit 克隆的源码，服务器上构建 admin 用 | |
|---|
| | | | `/data/talent-card/redeploy-admin.sh` | admin 重部署脚本（见下） | |
|---|
| | |
|---|
| | | > 命令通道单次只能带约 4KB，所以 dist（4.4MB）走不了命令通道——这是当初需要人工 SFTP 传包的原因， |
|---|
| | | > 现在用「服务器自建」绕过去了。 |
|---|
| | | |
|---|
| | | ## 重建后端（2026-10-10 起：服务器上构建，不再上传 jar） |
|---|
| | | |
|---|
| | | 在此之前后端 jar 是**人工传上去的**。2026-10-10 起改成和 admin 同一套路——**在服务器上从 Gitblit |
|---|
| | | 源码构建**，理由与 admin 一样，而且更硬：本机的**唯一通道是堡垒机**（`172.18.105.9`，见下「堡垒机」）， |
|---|
| | | 它是个**只给交互式菜单的审计系统**，不接受任意远程命令、没有 SFTP 通道；命令通道单次约 4KB， |
|---|
| | | 137MB 的 base64 分片要三万多次往返，且每一步都会被审计系统留档。所以**不要再试图"把 jar 传上去"**。 |
|---|
| | | |
|---|
| | | **前置条件（已装好，一次性的）**：机器原来只有 `openjdk-17-jre-headless`（**没有 `javac`**）， |
|---|
| | | 2026-10-10 装了 `openjdk-17-jdk-headless`（`javac 17.0.20.1`）。`java` 备选项随之指到 JDK 那份， |
|---|
| | | **与运行时同为 17**，不影响已在跑的服务。Maven 不用装：走仓库自带的 `mvnw`，它把 |
|---|
| | | **Maven 3.9.16 下到 `/root/.m2/wrapper/dists/`**，依赖也缓存在 `/root/.m2`。 |
|---|
| | | |
|---|
| | | ```bash |
|---|
| | | SRC=/data/talent-card/src # 与 admin 共用同一份 clone（浅克隆） |
|---|
| | | git -C $SRC fetch --depth 1 origin main |
|---|
| | | git -C $SRC checkout -B main origin/main # 与 redeploy-admin.sh 同款：硬对齐 origin/main |
|---|
| | | cd $SRC/talent-card-server |
|---|
| | | bash ./mvnw -B -DskipTests package # 首次 3m52s（要下全部依赖），4 vCPU |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | **替换 jar 一定要用「临时文件 + `mv`」，不要 `cp` 原地覆盖**：systemd 起的是 |
|---|
| | | `java -jar /data/talent-card/app.jar`，旧进程 mmap 着那个 inode，`cp` 会**原地截断同一个 inode**。 |
|---|
| | | 原子 rename 则让旧进程继续用旧 inode、重启后用新 inode。现成脚本留在 `/data/talent-card/do-deploy.sh` |
|---|
| | | （做：拷 `.new` → `chmod 644` → `sha256sum` → `mv -f` → `systemctl restart` → 等 35 s → |
|---|
| | | `is-active` / `NRestarts` / `/actuator/health` → `tail app.log`），全部输出写 `/data/talent-card/deploy.log`。 |
|---|
| | | |
|---|
| | | **这台机器没有 `curl`**（`curl: command not found`），探健康检查用 `python3`： |
|---|
| | | |
|---|
| | | ```bash |
|---|
| | | python3 -c "import urllib.request as u;print(u.urlopen('http://127.0.0.1:8080/actuator/health',timeout=8).read().decode())" |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | ## 堡垒机（唯一的进入通道，2026-10-10 实测） |
|---|
| | | |
|---|
| | | **这台机器没有公网自服务控制台，SSH 也只有这一条路**：`ssh <账号>@172.18.105.9`，它是一台 |
|---|
| | | **运维审计系统（VNC/console 之外的唯一入口）**。两条硬性质，决定了不能用普通跳板机的姿势： |
|---|
| | | |
|---|
| | | - **它不是跳板机、也不接受任意远程命令。** 登录后是一个**读 stdin 的交互式菜单**：自动列目录→ |
|---|
| | | 自动选中目标 `GT-KC-XXHJSB-DQRCKXM-YYserver (172.192.19.1)` → 停在 `Input account:`。 |
|---|
| | | 用 `ssh host '命令'` 这种形式会把"命令"当成账号喂进去、连错三次被断开（**症状是 exec 被接受后 |
|---|
| | | 立刻 broken pipe、无任何输出**）。 |
|---|
| | | - **没有 SFTP / 端口转发通道**（子系统与 `-W` 都过不去），所以**传文件只能靠服务器自己去拉**（见 |
|---|
| | | 「重建后端」）。同理，`scp` 到这台机器是不通的。 |
|---|
| | | |
|---|
| | | 可用的姿势（免交互密码用 `SSH_ASKPASS` + `SSH_ASKPASS_REQUIRE=force`，密码通过环境变量传入、 |
|---|
| | | **不要写进仓库**）：按 4 s / 5 s / 6 s 的节奏依次喂 `<账号>`、`<服务器密码>`、`<远端命令>`，会话结束 |
|---|
| | | 再喂 `exit`。推荐**把长任务 `nohup ... &` 放后台、结果重定向进文件，下一个会话再 `cat`**——审计系统 |
|---|
| | | 有 900 s 自动退出，长任务卡在会话里会被截断（只喂固定等待时长的输出常被切掉）。本机可用的半成品 |
|---|
| | | 脚本在 `/tmp/sshtest/connect2.sh`（临时目录，**每次重启就没了**，照上面节奏重写即可）。 |
|---|
| | | |
|---|
| | | ## HTTPS（2026-09-29 已上线；2026-10-08 域名变更） |
|---|
| | | |
|---|
| | | > **2026-10-08 域名变更**：甲方把 `www.dqrcfwpt.com` 与退域名 `dqrcfwpt.com` 解析到了他们自己的机器（公司官网）， |
|---|
