Back to Work

Project / 005 · 2026

Remote Recovery|双遗留系统环境重建

面对数据库不完整、技术栈混合且缺少部署说明的两套编译系统,重建 Debian 生产环境、实时通信与 Android 构建工具链。

项目背景

Remote 目录中包含两套已经编译的遗留系统。它们没有统一的源码构建方式:一套缺少完整数据库初始化文件,另一套虽然附带 SQL 和部署脚本,但同时依赖 PHP、MySQL、Node.js、Python、.NET 与 Android 工具链。

这类接管工作的第一步不是分析业务,而是还原运行前提:数据库到底缺什么,哪些前端文件已经编译,哪些服务必须常驻,端口如何分配,Nginx 应该转发到哪里,APK 构建依赖哪些真实二进制。

我的工作

  • 对照 PHP 查询与历史 SQL,识别缺失表、字段和非空业务数据,避免直接覆盖导入。

  • 在 Debian 12 上建立 Nginx、PHP 8.2、MySQL、Node.js/PM2 和 HTTPS 环境。

  • 为两套系统分配独立数据库、站点与内部端口,避免 Flask、状态服务和 WebSocket 冲突。

  • 补齐 JDK 17、.NET 8 Runtime、Android Command-line Tools、Build Tools、Apktool、APKEditor、apksigner、zipalign、aapt/aapt2、7z 与图形字体依赖。

  • 修复 WebSocket 服务已运行但 Nginx 未代理、环境变量仍指向旧域名的问题。

  • 处理上传目录所有权、PHP open_basedir、后台入口路由和运行配置同步。

  • 复用现有编译文件调整登录界面,没有另建一套脱离项目的图片式页面。

阶段性验证

  • 两套站点均完成 HTTPS 访问、登录、独立数据库和 WebSocket 连通验证。

  • 第一套系统完成 Apktool 编译、zipalign、apksigner 签名以及 APK v2/v3 验证的工具链冒烟测试。

  • 第二套系统的 Flask API、心跳服务与 WebSocket 进程完成独立端口运行检查。

  • Nginx 与 PHP-FPM 配置通过检查,站点级上传权限问题完成修复。

当前边界

这个作品标记为进行中。后续运行中发现,PHP-FPM 的站点级安全函数策略可能在重载后重新禁用后台构建所需的进程启动函数,导致构建任务在进入工具链前失败。该问题已定位到运行策略,而不是模板、JDK 或签名工具,但历史对话没有留下最终修复与完整再构建的验收证据,因此不写成已完成。

此外,两套原始系统包含安全敏感能力。公开案例只讨论数据库考古、混合运行时恢复、反向代理、权限和构建环境,不公开其敏感业务功能与真实部署信息。

项目价值

Remote Recovery 展示的是“没有完整文档时如何恢复系统”的能力:从代码访问痕迹反推数据库,从二进制依赖还原运行时,从端口和代理层恢复服务链,并明确区分“工具链可用”与“真实业务构建已验收”。